The Accessible Rich Internet Applications (WAI-ARIA) specification defines a set of roles known as document landmarks. They can be used to programmatically identify key areas of content on a page, which means they can be interpreted by access technologies such as screen readers. Although the WAI-ARIA specification hasn’t been officially published yet, several screen readers have begun to implement support for different features. Both Jaws and NVDA already have support for document landmark roles for example. There are eight document landmark roles in the specification. Their purpose is to help screen reader users navigate through content, and to identify the purpose of content in different areas of the page.
The application role is applied to areas of the page that contain application style content and functionality. It’s perhaps the most significant of the landmark roles because it’s the only one that forces the screen reader to behave differently. To understand why it does this, it’s helpful to know a little bit about the way some screen readers deal with web pages. When a page loads into the browser, some screen readers grab a snapshot of the code as it loads. The snapshot is held in a buffer, and it’s this that the screen reader user actually uses to browse the page. The screen reader then repurposes standard keys to allow the user to navigate through the content more easily. For example, the up/down arrows can be used to move focus between different lines of content. The trouble is that web applications often need those same keys in order to work properly. The application role tells the screen reader to switch out of browsing mode, and passes the keystrokes through to the web page instead. So as well as being a landmark to navigate by, it also causes a change in the behaviour of the screen reader when it gets there.
Banner and contentinfo roles
The remaining document landmark roles are more straight forward. The banner role is applied to an area of the page containing site wide information. Typically the banner area stretches the full width of the top of the page and includes content such as the primary heading, logo and site specific search. The content info role is applied to an area containing page specific information. Curiously, the specification suggests that the area might include a copyright notice or privacy link, neither of which tend to be page specific. To all intents and purposes though, the banner and contentinfo roles are most likely to be applied to the page header and footer areas respectively.
Main and complimentary roles
The main role is used to identify the primary content area of the page. In time it could replace the “skip to content” link mechanism as a means of jumping directly to the start of the main page body. For now there isn’t enough widespread support amongst browsers or screen readers for this to be an option though. The complimentary role can then be applied to an area containing content that is related to, but separate from, the main content topic. In other words, the area holding related links and associated content.
Form and search roles
The form role is used to identify areas of a page containing form fields. It can be used multiple times on a page, and for almost any kind of web form. The obvious exception is a search form, which has the search role applied instead.
The last of the document landmarks is the navigation role. It is used to identify areas of the page containing collections of navigational links. It can be used multiple times on the page, so an area with a navigation landmark might contain links for navigating within the page, or for navigating elsewhere on the site.
Using document landmark roles
The great thing is that you can use WAI-ARIA document landmark roles right now. Just add the role attribute to a container element and give it the most relevant value. For example: <div id=”header” role=”banner”>…</div< There is one drawback to using document landmarks within your existing code. WAI-ARIA isn’t part of the formal specification for either HTML 4.01 or XHTML. If you apply it to a page, it’s going to break the code validation. Code validation plays an important role in web accessibility, but WAI-ARIA represents an enormous benefit to the user. In my book, user benefit trumps code validation, so go ahead…. Use a little WAI-ARIA in your code.