Using WAI-ARIA Landmarks – 2013

Posted on Tuesday, 12 February 2013 by Steve Faulkner

tl;dr

Adding ARIA landmarks to your existing site, or to a site you are developing, provides useful global navigation features and aids understanding of content structure for users. Over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics. There is widespread support for ARIA landmarks in browsers and screen readers.

How ARIA landmark roles help screen reader users

Leonie Watson demonstrates how ARIA landmark roles help screen reader users understand the purpose of different areas of a web page, such as search, navigation or main content.


video on YouTube

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 (Editors’ Draft 6 August 2010)

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:

<main role="main">

  • An example page with ARIA landmark roles
  • A list and descriptions of landmark roles is available in Table 1

Please note:

Probably the most important rule for applying landmarks is to ensure all content resides in a landmark region to ensure no content is orphaned. This way a screen reader user can safely use landmark navigation without missing content.

Rich Schwerdtfeger

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:

TPG blog page with banner, main, complementary, search and navigation landmark role usage visualised.

Support for Landmark Roles

Landmark roles are supported in JAWS, NVDA, ORCA, Chromevox, Window Eyes and VoiceOver and via a FireFox addon for keyboard users.

Landmark Support behaviour in JAWS version 10 and above

For JAWS version 10 and above, landmark keyboard navigation in virtual mode is:

  • next landmark ; (semi-colon)
  • previous landmark SHIFT + ; (semi-colon)
  • list landmarks CTRL + INS + ; (semi-colon)

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 sub items. A user can then use the right arrow key to open the sub list.

JAWS landmark dialog list 'complementary content' landmark item closed

JAWS landmark dialog list 'complementary content' landmark item open, displaying sub items

ARIA Landmark Role Tests

Detailed information about current assistive technology support can be found in the accompanying document ARIA Landmark Role Tests (November, 2011).

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 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 required.

<nav role="navigation">

For an example of the use of HTML5 elements and ARIA landmark roles have a look at code of Bruce Lawson’s 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 technologies should also return browse navigation keys back over to the web application in this region.
note: It is strongly recommended that role="application" be used very sparingly. Refer to Using role="application"
No HTML5 element equivalent.
Recommend using on a semantically neutral element such as a div.
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.
Note: Within any document or application, the author SHOULD mark no more than one element with the banner role.
No HTML5 element equivalent.
Recommended to be used on one header element per page if the header element is used as described for role=”banner”.
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.Note: Within any document or application, the author SHOULD mark no more than one element with the contentinfo role. No HTML5 element equivalent. Recommended to be used on one footer element per page if the footer element is used as described for role=”contentinfo”.
role="form" A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing. Recommend using on a semantically neutral element such as a div not on a form element, as the element already has default role semantics exposed.
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.
Note: Within any document or application, the author SHOULD mark no more than one element with the main role.
The main element represents the main content of the body of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application.
role="navigation" A collection of navigational elements (usually links) for navigating the document or related documents. 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 HTML5 element equivalent.
Recommend using on a semantically neutral element such as a div or on a form element, if the form contains only search related controls and instructions.

Role and element descriptions from:

Further reading:

 


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. I’m confused about using role=”form” on a form. It sounds like you are re-defining a form as a form. I would expect it to be used on a div that contained form-like elements, perhaps in an application.

    Does role=”form” create a landmark that can be discovered via the landmark menu? I’ve never tried it.

  2. Hi Ted,

    I’m confused about using role=”form” on a form. It sounds like you are re-defining a form as a form.

    The form role for a form element is not defined across platform accessibility APIs, some have it some don’t. If you look at the role mapping table in the ARIA user agent implementation guide, it shows how the form landmark maps in browsers to the various platform accessibility APIs. ARIA fills the gaps in native API role definition for form. in APIs that already have it defined, ARIA adds a ‘landmark’ flag to the role.

    Does role=”form” create a landmark that can be discovered via the landmark menu? I’ve never tried it.

    In browsers/AT that expose the landmark, yes it does. Note in theresults of testing from 2011, the form landmark was not uniformly supported, but when I get chance to update these results I expect there will be an improvement.

    Note: I don’t suggest every form element should or needs to be marked up with role=form. Landmarks should be used sparingly to mark up chunks of the page, where it makes sense.

  3. They are in no way equivalent. type=search is an input type on a single element, role=search is a landmark role applicable to a range of container elements that may include an input type=search as a child. i.e. do not put role=search on input type=search asit will override the native semantics and the input will no longer be expsoed as an input to the accessibility layer.

  4. Just wondering if it makes sense to use skip links together with WAI-ARIA roles? I think a skip link still makes sense for non-screenreader users (as anchor nav), but it might conflict with WAI-ARIA implementations? Suggestions?

  5. It still makes sense to add a main content link for keyboard users. But what we’re working towards is built in browser keyboard navigation of at least <main> to provide a native skip mechanism, but that’s a future feature not yet a reality.

    As the HTML specification states in the definition of the main element:

    User agents that support keyboard navigation of content are strongly encouraged to provide a method to navigate to the main element and once navigated to, ensure the next element in the focus order is the first focusable element within the main element. This will provide a simple method for keyboard users to bypass blocks of content such as navigation links.

    Currently there is a FireFox addon available that provides navigation to ARIA landmarks. I have just forked it with a view to adding navigation for HTML elements that map on to landmarks.

  6. When using role application for dynamic client side content, I received complaints from JAWS users that they are used to navigate only with the arrows keys and that tabbing in not a suitable alternative.
    Setting aside whether this is a legit complaint, I was wondering how I can work around this.
    Since there are no content segments other then focusable elements under the role application section, I arrived at a plan to replace key down / up events with a tab / Shift + tab simulations.
    I was wondering if such a solution may cause some unpredictable behavior? After all, this is kind of a hack.

  7. Hi Steve, sure did ;-) Would very much appreciate if you could explicitly state any fault with my [ineloquent, none native English] question.
    To rephrase my question, Is it advisable to simulate none forms mode in forms mode, in order to maintain arrow up / arrow down functionality for inexperienced Jaws users?

  8. Would you say that applying ARIA landmark roles to a web site was a major accessibility improvement, or a half-measure that doesn’t accomplish very much? That one step is in reach for many sites pretty easily, just by updating their blog or content management software template. Doing the whole nine yards to annotate every widget’s interaction state is much harder, unless the underlying platform already does it.

  9. Hey i have using NVDA 2012 2.1 screen reader… am just implementing the role attribute to my page. please see the below example;
    some text — > which is not reading by NVDA, means which should read the role na, but its not happening for me just reading the content inside the div.

    some text — > its reads both the role and content inside the div. i dont understand whts happening, how its working and all..

    role=”menuitem” for all the tags this role attribute only working. dunno why

    Please help me..

  10. sorry above example not visible !
    role=”banner” or role=”contentinfo” these kind of roles not reading by my screen reader NVDA 2012 2.1, and its reading only its content

    role=”menuitem” for all the tags this role attribute only working. dunno why

  11. above example :
    role=”contentinfo”or role=”banner” etc… not reading by NVDA…
    but role=”menuitem” reading well, dunno why specifically this role attribute only wroking…

  12. Is it a misuse of landmark roles if you have say 3 role=”navigation” because the template calls for 3 sections of navigable sections? The language is agnostic, wouldn’t this introduce confusion for adaptive tech users because it would list nav, nav, nav and not signify which was which?

  13. Hi Juli,
    It is not a misuse, but it is good to use landmark roles sparingly. Where you have multiple nav’s you could add a short descriptive label to each using aria-label="" to help differentiate them.

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

Sarah Horton’s approach fit into the style of the organization so well…kudos to TPG for having UX in the mix in such a valuable way.

Becky Reed, Sr. Director User Experience, Healthwise