Using WAI ARIA Landmark Roles
WAI-ARIA Landmark Roles
The WAI ARIA specification defines a set of specialised “landmark” roles. These roles provide a method to programmatically identify commonly found sections of web page content in a consistent way. they can be used now in whatever flavour of (X)HTML you prefer. This allows assistive technologies to provide users with features which they can use to identify and navigate to sections of page content.
Information about WAI - ARIA landmarks from WAI-ARIA Best Practices (Editor’s Draft 14 January 2009)
Landmarks are a vast improvement over the rudimentary “skip to main content” technique employed prior to WAI-ARIA. If possible it is best to use these as landmarks.
…
The presence of common, semantic, navigation landmarks allows each site to support the same standard and allows your assistive technology to provide a consistent navigation experience - an important feature for screen readers and alternate input solutions. For users with cognitive and learning disabilities the landmark information could be used to expand and collapse these regions of your page to aid in simplifying the user experience by allowing the user to manage the amount of information processed at any one time.
There are also mainstream benefits of providing navigation landmarks. Your browser may assign key sequences to move focus to these sections as they can be set on every site. Navigation to these landmarks is device independent. A personal digital assistant (PDA) could assign a device key to get to them in your document.
How to use landmark roles
It is a painless process to add landmark roles to existing (and new) pages. Simply add a role attribute to a container element, using the most appropriate role value for the content of the container, for example
<div class="content" role=”main”>
- An example page with ARIA landmark roles
- A list and descriptions of landmark roles is available in Table 1
Adding Landmark Roles to WordPress
I added them to the TPG blog (uses WordPress) in about 20 minutes, it involved the editing of the following WordPress files: sidebar.php (added complementary, navigation (x2) and search landmarks), header.php (added banner landmark), single.php (added main landmark), footer.php (added contentinfo landmark) & index.php (added main landmark). The results can be visualised using The Juicy Studio Accessibility Toolbar document landmarks feature:
Support for Landmark Roles
Landmark roles are currently supported In JAWS 10 screen reader. It is expected that other assistive technology will provide support in the near future. For JAWS 10 landmark keyboard navigation in virtual mode is:
- next landmark ; (semi-colon)
- previous landmark SHIFT + ; (semi-colon)
- list landmarks CTRL + INS + ; (semi-colon)
Landmark Support behaviour in JAWS 10
When cycling through landmarks using the semi-colon key, the landmark role name +”landmark” is announced. A user can then cursor (down arrow key) to the content. If a landmark is a container for other landmarks it is not included within the cycle order, but is included within the list order. By default the list does not display nested landmarks, but when a nested landmark container item receives focus, it is announced to the user that the list item is closed, informing the user that the item has subitems. A user can then use the right arrow key to open the sub list.
ARIA Landmark Role Tests
Detailed information about current assistive technology support can be found in the accompanying document ARIA Landmark Role Tests.
What about the new Sectioning Elements in HTML5
The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority of of cases there is no equivalent for the ARIA landmark roles in HTML5. It is suggested that where there is a similarity the ARIA roles can be used to provide semantic identification that has a practical use now, for example if you want to use the HTML5 nav element, add role="navigation" to it, so supporting Assistive Technology (AT) can convey the semantic information to users. When HTML5 elements such as nav are supported by AT, you can then remove the role as it will no longer be rquired.
<nav role=”navigation”>
For an example of the use of HTML5 elements and ARIA landmark roles have a look at code of Bruce Lawsons site.
Comparison of ARIA landmark roles and HTML5 structural elements
| ARIA Landmark Role | HTML5 Sectioning Element |
|---|---|
role=”application” Represents a region of the page representing a unique software unit executing a set of tasks for its users. It is an area where assistive technologiesshould also return browse navigation keys back over to the web application in this region.
If the entire web page has a role of application then it should not be treated as a navigational landmark by an assistive technology. |
No equivalent |
role=”banner” A region that contains the prime heading or internal title of a page. Most of the content of a banner is site-oriented, rather than being page-specific. Site-oriented content typically includes things such as the logo of the site sponsor, the main heading for the page, and site-specific search tool. Typically this appears at the top of the page spanning the full width. |
No equivalent |
role=”complementary” A supporting section of the document that remains meaningful even when separated from the main content.There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The content should be relevant to the main content; if it is completely separable, a more general role should be used instead. |
<aside> The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. |
role=”contentinfo” Metadata that applies to the parent document.For example, footnotes, copyrights, and links to privacy statements would belong here. |
<footer> The footer element represents a footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. |
role=”main” The main content of a document. This marks the content that is directly related to or expands upon the central topic of the document. Within any document or application, the author SHOULD mark no more than one element with the main role. |
No equivalent |
role=”navigation” A collection of navigational elements (usually links) for navigating the document or related documents. |
<nav> The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. |
role=”search” The search tool of a web document. This is typically a form used to submit search requests about the site or to a more general Internet search service. |
No equivalent |
Role and element descriptions from:
You don’t think the banner role maps to the HTML5 header element? And that the main role maps to the HTML5 article element? And that the search role maps to the HTML5 Search state of the input element?
Hi Anne, not from my reading of the spec, for example, i would expect there to be only one section of content with a role of banner or main in a web page, the html5 header element can be used multiple times in a web page as can article. While role=”search” can be added to containers that contain the whole search form, the search state of the input element identifies only the input itself. But i do not see an issue with using <header role=”banner”> for a section of content that contains what ARIA describes as banner content, which is what bruce lawson has done on his site.
I’m redesigning the WebAIM site now and will be implementing landmark roles and other ARIA properties. My current dilemma is that I don’t think I can stomach all of the “I can’t believe your site doesn’t validate!” emails I’m certain to get. When I accidentally break validation now, I hardly go a day without somebody nagging me about it. As such, I’m leaning toward adding the ARIA roles and properties through scripting.
So, in your opinion, are there any disadvantages to doing this (beyond the fact that those without javascript don’t get it)? And are you aware of any plans to update the W3C validator to support ARIA?
This is excellent, Steve. Many thanks.
I have a couple of quick questions:
1. Do you think that the element with the role of “main” and the element with the role of “complementary” should be separate or do you think the “complementary” element should be nested within the “main” element?
2. Would it be appropriate to apply a role of “application” to an object element containing a Flash movie?
I’ve looked at the draft spec but couldn’t find answers to those questions there.
Hi Jared, I don’t see any disadvantages apart from the one you mentioned. you have brought up the issue of how the ARIA stuff can be validated, I don’t know of any plans to update the W3C validator at this stage, though there has been some discussion about how to validate (X)HTML+ARIA. I am working on a possibility right now, will keep you posted.
Hi Jeremy,
I think it depends on the page layout, if there is an “island” of complementary content included with the main content then it could be nested. Where there is a clear visual delineation between the main content (example its in the middle) and the complementary content (on the side) then it would make sense to have them seperated.
It’s a great question! The role of application does something quite specific, it tells the AT to switch modes (if the AT uses them). It was only added as a landmark role the other day, so I don’t think the PF WG have thought about it in terms of its landmark use. It would make sense for a flash movie that is an interactive widget to be given a role=”application” i guess, I will bring this up on the mailing list and see what other people think.
Excellent! Thanks, Steve. I’ll try to keep an eye on the mailing list to see what people think about applying an “application” role to Flash movies.
I can see the benefit of using application on a Flash movie for the sake of landmark navigation, but it also is intended to communicate to the UA/AT to switch from ‘document browsing’ mode into ‘application interface’ mode, so it doesn’t make as much sense b/c Flash movies aren’t ARIA applications. In a sense, because Flash isn’t accessible on all systems, and because the interface is very different from the web browser’s interface, the author is promising the user something they can’t always deliver, or may not deliver in the way the user expects.
In theory, on the platforms where Flash is accessible, the Flash player could/should communicate role, state, and property information directly to the accessibility API, instead of going through the browser via ARIA.
[...] have undertaken this exercise, because people have asked about ARIA validation and I myself wanted to be able to check documents containing ARIA. What I [...]
Thanks for a great article. I’ve been wondering about the overlap between the roles in ARIA and the new elements in HTML 5, this has helped answer some of the questions. I was going to ask if you thought there would be a 1-1 matching of the two for all the pieces of both, but the more I read and think about it I see it’s going to depend on how each page is designed. Overall, this is a great starting point for understanding how they can work together.
[...] Using WAI ARIA Landmark Roles - The Paciello Group Blog [...]
[...] pre-defined keywords that assistive technologies look out for. Steve Faulkner has a useful list of equivalences between HTML 5 elements and landmark roles, although I disagree with him on one aspect, as I believe header to be fucntionally the same as [...]
[...] Using WAI ARIA Landmark Roles - The Paciello Group Blog [...]
[...] correspondance between the HTML 5 footer element and aria-role="contentinfo" and (see Comparison of ARIA landmark roles and HTML5 structural elements by Steve Faulkner and ARIA in HTML5 Integration: Document Conformance (Draft) by Henri [...]
[...] the case of the ARIA Landmark roles, the JAWS screen reader supports them, although they are not exposed using an accessibility API. It [...]
[...] Forum in Frankfurt I met Steve Faulkner who has done a lot of research on WAI-ARIA (see Using WAI ARIA Landmark Roles). Although the specification isn’t finalized yet there are many advantages to WAI-ARIA and [...]
Thanks for this post, it’s been quite helpful for us.
Question: I have an application with 2 areas of the page that I’d consider to be landmarks (the app content area and the header/toolbar area. Using the “main” role for the content area of the application seems to make good sense, but the header/toolbar area contains both global navigation and local page tools (menus, radiogroups, slider roles, etc). Given your description of the “banner” role, it seems it wouldn’t be an appropriate landmark to use for this header/toolbar div, but I’d like to use a landmark of some form for page organization purposes. Do you think the banner role really needs to be so strictly tied to global site actions or could it be appropriate here?
Also, could I use multiple roles on one element or would I have to add another wrapper div to specify that the div is both a toolbar and a banner?
Thanks for your thoughts!
[...] Paciello Group: Using WAI ARIA Landmark Roles [...]
role=main does have a corresponding HTML5 element: article.
Also, in HTML5 an input can be of type=search, so the form that contains such an input is equivalent to role=search.
What interface does JAWS use for finding out the landmark roles? Does any other screen reader on a non-Windows platfrom support landmarks by now?
role=”main” does not correspond to the html5 article element , role=”article” does though, but it is not a landmark.
That can work if the form element contains the text (instructions labels etc.) associated with the search and does not include content extraneous to the search interface and the form element is present and the input type=”search” is supported by AT/browsers.
If all these issues are taken into consideration, there is still a place for role=”search” which can be placed on any container element to define the element as containing the search interface.
i think I answered the second question over on Anne’s blog. The answer to the first question I am not so sure about. IE8 supposedly exposes all ARIA roles via the UI Automation AriaRole property, but have not been able to confirm this with the testing tools available.
[...] landmark roles and HTML5 section elements may work together with Steve Faulkner recommending that landmark roles be used now and removed once support for HTML5 becomes more robust. The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority [...]
[...] which bit is navigation, which bit is complementary content, etc.). The Pacielleo Group has a great blog post on landmark roles that explains what they are and how they work. Where supported (e.g. in the screenreader JAWS 10), [...]
[...] more than 60% of the ARIA roles, up from 25% a few months ago. Improved support includes all ARIA landmark roles and many document structure [...]
[...] more than 60% of the ARIA roles, up from 25% a few months ago. Improved support includes all ARIA landmark roles and many document structure [...]
[...] more than 60% of the ARIA roles, up from 25% a few months ago. Improved support includes all ARIA landmark roles and many document structure [...]
This could get messy.
I currently have in an HTML 5 document a “header” with and id of “branding” and a role of “banner”.
I have a “footer” with an id of “siteInformation” and a role of “contentinfo”.
It strikes me there’s going to be instances where the readability of the code could get confusing.
Any ideas?
There is an elephant in this Landmark room: keyboard access. Sure skip link are incredibly arcane but even if not visible, a skip link can be used from the keyboard by checking the status area. I know that is awful. But where is any keyboard support for landmarks?