HTML5, ARIA Roles, and Screen Readers in May 2010

Note: Updated research and results for March 2011.

There are some good, helpful examples and work out there already showing how some screen readers deal with various HTML5 constructs and ARIA roles. I know the specs are not finished yet and assistive technology vendors are always working on it, but I wanted to play around a bit and confirm for myself how some of the leading screen readers for Windows, namely JAWS 11, Window-Eyes 7.11, NVDA 2010.1, and SAToGo 3.0.202, currently handle basic HTML5 sectioning elements as well as ARIA landmark and other roles. It has been suggested that until browsers and screen readers fully support HTML5 elements and their implicit ARIA roles, we should be explicitly supplementing certain HTML5 elements with their associated ARIA roles.

Update: Results for VoiceOver in MacOS X Snow Leopard with Safari 4.0.3 added. —May 07, 2010

The Test Cases

The first test case uses just the HTML5 elements, in particular:

  • header
  • nav
  • section
  • article
  • aside
  • footer

The second test case also applies the following ARIA roles:

  • banner
  • navigation
  • main
  • article
  • complementary
  • contentinfo

I tested with the four screen readers using both Internet Explorer 8 and Firefox 3.6.

Note: Depending on the screen reader and browser combination you use, internal page links within the test cases, particularly those with targets that are simple headings with an id attribute, may or may not properly set focus and update the position in the TAB order. This is a problem, well enough documented, with particular browsers and screen readers, and unrelated to the use of HTML5 and ARIA roles. It can be variously mitigated by adding tabindex="-1" and/or using actual a elements in different ways instead, but that's for a different set of test cases.

The Results

Briefly, NVDA does very well with the HTML5 and the HTML5 with ARIA roles test cases, whether it is in IE8 or FF3.6. Navigating, reading, and interacting with the HTML5 markup and ARIA landmarks is just straightforward. So much so that it doesn't warrant including it in the test results: It suffices to say that NVDA rocks.

JAWS does well, although in FF3.6 it doesn't seem to like a nav element nested within a header. For now, at least, it may be reasonable to avoid nesting nav elements within header elements. Update (Aug. 27, 2010): See comment #3 by Terrill Thompson below. Unfortunately, JAWS 11 in Firefox 3.6 doesn't deal well with the header element in any implementation.

SAToGo also does okay, and now even allows navigation by ARIA landmark, though it does not automatically announce the type of landmark as it comes across it. And I could only get it to navigate by landmark in one direction in IE8, while in FF3.6, I could navigate to both the next and previous landmark by pressing ; and Shift+; respectively. Update: New results for SAToGo version 3.1.24, May 21, 2010.

Window-Eyes 7.11, on the other hand, and this is one thing we knew already, does not recognise ARIA roles at all. Further, Window-Eyes just seems to balk in IE8 when it comes to HTML5 and ARIA roles being used together: in "Browse Mode" it cannot find any links within an HTML5 sectioning element that also has an ARIA role. If you turn "Browse Mode" off, it does find all the links, but this means you would have to continually toggle "Browse Mode" off and on to actually read and use the page.

Some additional quick testing I did showed that in IE8, Window-Eyes has no problems finding links within a simple div that also han an ARIA role, or within an HTML5 sectioning element with no ARIA role, but combine the two and Window-Eyes in IE8 just gets lost. This is confirmed, for example, by Bruce Lawson's site, which makes good use of HTML5 and ARIA. If you visit Bruce's site with Window-Eyes and IE8, none of the links in the header or the #sidebar nav are found since both of these HTML5 elements also have ARIA roles implemented. But there is no problem with the links in the main content area, even though it has role="main" since it just uses a regular div. If it used a section element instead, most of the links on the page would just disappear for Window-Eyes in IE8.

While I don't have numbers to prove it, I figure that a majority of Window-Eyes users run Internet Explorer instead of Firefox, so this may be a reason to avoid using HTML5 and ARIA roles together for the time being, depending on how you feel about catering to Window-Eyes users with IE8. It will be interesting to see how things change once IE9 and Window-Eyes 8 are out.

The more detailed test results are below. Unless otherwise indicated, the screen reader performed as one might hope and expect for a usable experience.

Update #1 (June 30, 2010): It seems that even nesting an element with a role attribute within a parent HTML5 sectioning element similarly causes problems for Window-Eyes. For example, links within a ul with role="navigation" nested inside a parent nav element will not be found by Window-Eyes.

Update #2 (July 5, 2010): On the other hand, and interestingly, nesting an HTML5 element inside a div with an ARIA role does not seem to trigger the problem in Window-Eyes. For example, the links in a nav element that is nested within a div with role="navigation" are still found by Window-Eyes. So this is, for now, probably the best way to use HTML5 elements and ARIA landmark roles together without negatively impacting Window-Eyes users.

Update #3 (July 7, 2010): With the latest update to Window-Eyes 7.2, links within HTML5 elements that have an ARIA landmark role are now found and usable. Unfortunately, nesting at least some semantic HTML 4 elements with a role attribute within a parent HTML5 sectioning element still causes problems for Window-Eyes 7.2. That is, links within a ul with role="navigation" nested inside a parent nav element, for example, are still not found and actionable using this latest version of Window-Eyes.

Update #4 (July 21, 2010): I think I've managed to make things a little confusing at this point, so let’s recap: In Internet Explorer 8, Window-Eyes versions 7.2 and below, when in normal Browse Mode, have some problems finding and using links in content where ARIA roles are used in conjunction with HTML5 sectioning elements in certain arrangements. Using links in an HTML5 element with an ARIA role attribute is a problem with Window-Eyes 7.11 and below. This is not a problem with Window-Eyes 7.2, but with version 7.2 there does remain an issue with at least unordered and ordered lists, and possibly some other elements as well, that have an ARIA role applied. Neither Window-Eyes 7.11 nor 7.2 can use the links in a ul element with role="navigation", whether or not it is nested within a nav element. The same goes, for example, for links within an ol element with role="contentinfo". (This Window-Eyes bug also manifests to some degree with Firefox 3.6). However, nesting the HTML5 element within a generic div with an ARIA role, or vice versa, nesting a div with ARIA role within an HTML5 element, does not seem to cause a problem in Window-Eyes. So, for example, one could wrap their nav element with <div role="navigation"> or, alternatively, wrap the internal contents of the nav in a div with the ARIA role. Examples of these different arrangements can be found on this special test page for Window-Eyes.

HTML5 Only Test Case

JAWS 11

IE8
  • no obvious problems or issues
FF3.6
  • does not like nav within the header element: On page load, JAWS jumps somewhere below the header and starts reading, often the h1 or the "First Section" internal page link; and the nav links inside the header do not show up in JAWS' links list
  • can press TAB to reach every link, but, in VirtualPC Cursor mode, the links within the header, when selected by keyboard, register and act as whatever link outside the header previously had focus (e.g., often the "First Section" internal page link within the "main" section)
  • with VirtualPC Cursor mode off, the links in the header work fine via keyboard
  • the links in the header seem to work fine when selected with the mouse, whether VirtualPC Cursor mode is on or off
  • links outside of the header are all recognised and work properly

Window-Eyes 7.11

IE8 and FF3.6
  • no obvious problems or issues

SAToGo 3.0.202

IE8 and FF3.6
  • no obvious problems or issues

VoiceOver

Safari 4.0.3
  • no obvious problems or issues

HTML5 + ARIA Roles Test Case

JAWS 11

IE8
  • same as the HTML5 Only version, except that,
  • all ARIA landmarks are found and navigable
  • also considers role="article" a landmark
FF3.6
  • same issues with the nav in the header as the HTML5 Only version
  • all ARIA landmarks are found and navigable, except for the navigation ARIA landmark nested within the header
  • also considers role="article" a landmark

Window-Eyes 7.11

IE8
  • no ARIA landmarks found
  • no links found because the page's three main sections use HTML5 elements together with ARIA roles
  • the header with role="banner", the section with role="main", and the footer with role="contentinfo" are each recognised as controls (e.g., they can be accessed by pressing C) and are in the TAB order
FF3.6
  • no ARIA landmarks found
  • all links are found, unlike in IE8
  • the header, the section with role="main", and the footer are NOT recognised as controls as they are in IE8

SAToGo 3.0.202

IE8
  • all ARIA landmarks are found and navigable, but only in one direction (by pressing ; for the next landmark), and the type of landmark role is not announced
FF3.6
  • all ARIA landmarks are found and navigable in both directions (by pressing ; and Shift+;), but the type of landmark role is not announced

SAToGo 3.1.24 (May 21, 2010)

IE8
  • while this version of SAToGo now allows navigation by ARIA landmark in both directions in IE8 (by pressing ; and Shift+;), it no longer finds the complementary landmark role
  • the type of landmark role remains unannounced
FF3.6
  • SAToGo still finds all landmarks, allows navigation in both directions, and the type of landmark role remains unannounced

VoiceOver

Safari 4.0.3
  • no ARIA landmarks found

Translations

Note: The translations below are listed with no guarantee of their accuracy (or the accessibility of their content).

Tagged , , , , , , , , .
Comments (RSS)

5 Responses to HTML5, ARIA Roles, and Screen Readers in May 2010

Comments are now closed.