Most websites share a common structure: there’s a header, a navigation section, some main content, and a footer. Most of these sites are coded just like that, in a linear fashion. Unfortunately, this means that a screen reader may have to read the site to its user in that order. Since most sites repeat the same header and navigation on each page, the user will have to hear these elements each time they visit another page.
The recommended fix is to provide a hidden “skip navigation” link that screen readers will read aloud, which simply links to an anchor somewhere near the main content. However, that’s not something that’s built in, and it’s not something that everyone knows how (or remembers) to do.
HTML5’s new role attribute lets us assign a “responsibility” to each element on your page. A screen reader can then very easily parse the page and categorize all of those responsibilities so that you can create a simple index for the page. For example, it can find all the navigation roles on the page and present them to the user so they can quickly navigate around your application.
These roles come from the WLA-ARIA specification3 and have been incorporated into the HTML5 specification. There are two specific classifications of roles that you can put to use right now: landmark roles and document roles.
Landmark Roles
Landmark roles identify “points of interest” on your site, such as the banner, search area, or navigation that screen readers can quickly identify.
We can apply a few of these roles to the AwesomeCo blog template we worked on in Redefining a Blog Using Semantic Markup
For the overall header, let’s apply the banner role like this:
<header id=”page_header” role=”banner”>
<hl>AwesomeCo Blog!</hl>
</header>
All that’s needed is the addition of the role=”banner” to the existing header tag.
We can identify our navigation the same way:
<nav role=”navigation”>
<ul>
< l i x a href=”/”>Latest Posts</ax/l i>
<1 i x a href=”/archives”>Archives</ax/l i>
<1 i x a href=”/contributors”>Contributors</ax/l i>
< l i x a href=”/contact”>Contact Us</ax/li>
</ul>
</nav>
The HTML5 specification says that some elements have default roles and can’t be overridden. The nav element must have the role of navigation and technically doesn’t need to be specified. Screen readers aren’t quite ready to accept that default yet, but many of them do understand
these ARIA roles.
Our main and sidebar regions can be identified as follows:
<section id=”posts” role=”main”>
</section>
<section id=”sidebar” role=”complementary”>
<nav>
<h3>Archives</h3>
<ul>
<1 i x a href=”2010/10″>0ctober 2010</ax/l i>
<1 i x a href=”2010/09″>September 2010</ax/l i>
<1 i x a href=”2010/08″>August 2010</ax/li>
<1 i x a href=”2010/07″>July 2010</ax/li>
<1 i x a href=”2010/06″>June 2010</ax/li>
<1 i x a href=”2010/05″>May 2010</ax/li>
<1 i x a href=”2010/04″>Apri 1 2010</ax/li>
<1 i x a href=”2010/03″>March 2010</ax/li>
<1 i x a href=”2010/02″>February 2010</ax/li>
<1 i x a href=”2010/01″>January 2010</ax/li>
</ul>
</nav>
</section> <!– sidebar –>
We identify the publication and copyright info in our footer using the contentinfo role like this:
<footer id=”page_footer” role=”contentinfo”>
<p>© 2010 AwesomeCo.</p>
</footer> <!– footer –>
If we had a search for our blog, we could identify that region as well. Now that we’ve identified the landmarks, let’s take this a step further and help identify some of the document elements.
Document Structure Roles
Document structure roles help screen readers identify parts of static content easily, which can help better organize content for navigation.
Many of the document roles are implicitly defined by HTML tags, such as articles and headers. However, the document role isn’t, and it’s a very helpful role, especially in applications with a mix of dynamic and static content. For example, a web-based email client may have the document role attached to the element that contains the body of the email message. This is useful because screen readers often have different methods for navigating using the keyboard. When the screen reader’s focus is on an application element, it may need to allow keypresses through to the web application. However, when the focus is on static content, it
could allow the screen reader’s key bindings to work differently.
We can apply the document role to our blog by adding it to the body element.
<body role=”document”>
This can help ensure that a screen reader will treat this page as static content.
Falling Back
These roles are already usable on the latest browsers with the latest screen readers, so you can start working with them now. Browsers that don’t support them are just going to ignore them, so you’re really only helping those people who can use them.