Screen readers, ARIA roles & HTML5 support

Several screen readers now support ARIA landmark roles. Some screen readers such as NVDA and Jaws are also improving support for HTML5 elements. This means that it’s important to put your ARIA roles in the right place.

It’s increasingly common to find landmark roles applied to HTML4 documents. They’re extremely useful to screen reader users, who can use them to navigate around a page and understand the purpose of different areas of content.

A simple example is role=”navigation”. It might be applied like this:

<div>
<ul role=”navigation”>

</ul>
</div>

With NVDA and Jaws you can move from one landmark role on a page to the next using a shortcut key. Both screen readers behave similarly when they encounter a landmark role. Using the example above, they would announce “Navigation landmark” on reaching the list.

So far, so good. With the move to HTML though, the code example might evolve into something like this:

<nav>
<ul role=”navigation”>

</ul>
</nav>

In slightly older screen readers this transition makes no difference. The <nav> element is effectively ignored, and the navigation role behaves exactly as expected. There’s a bit of a problem though.

The introduction of HTML5 support for elements such as <nav> means that both Jaws and NVDA now treat the above code exactly as they should. In other words, they both behave as though two navigation landmarks were present in quick succession. The result is that screen reader users hear “Navigation landmark navigation landmark”, which isn’t a great user experience.

Logically, the answer is to remove the role=”navigation” from the code entirely:

<nav>
<ul>

</ul>
</nav>

The trouble is that this removes the role for anyone using a slightly older version of either screen reader. Happily the solution is straight forward. Apply the role to the element it maps to:

<nav role=”navigation”>
<ul>

</ul>
</nav>

Current versions of NVDA and Jaws will announce the landmark once, and so will the slightly older versions that have ARIA support but not HTML5. It isn’t quite the minimalist approach many would prefer, but it’s currently the one that delivers the best experience for screen reader users.

2 comments on “Screen readers, ARIA roles & HTML5 support”

Skip to Post a comment
  1. Comment by Jason Kiss

    Thanks for this, Léonie. It’s clear that JAWS is making advances in its support for basic HTML5 elements, which is great.

    Back in March, JAWS version 12.0.525 didn’t identify any HTML5 elements on their own as landmarks. In would appear that in some sub-version of JAWS 12, I believe 12.0.1158, it started identifying both NAV and ARTICLE elements as “navigation” and “article” landmarks, respectively (even though “article” is not strictly speaking an ARIA landmark role).

    I think it’s important to note the browser relationship here. While the latest version of JAWS 12 identifies NAV and ARTICLE elements as “navigation” and “article” landmarks in both IE and Firefox, NVDA 2011.2 does not identify NAV elements as a landmark in IE, but only in Firefox. It doesn’t identify ARTICLE as a landmark in either browser, which is more in line with the spec.

    It would seem that JAWS is getting its information for NAV and ARTICLE straight from the DOM. This is why, even in IE6 of all things (!), JAWS 12 is identifying these two elements as landmarks, which is kinda neat. NVDA, on the other hand, seems to be largely relying on the accessibility APIs to furnish it with information. Since IE is not registering these elements’ implicit ARIA roles to the APIs, NVDA doesn’t identify them as such in that browser.

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.