HTML5, ARIA Roles, and Screen Readers in March 2011

Last year, in HTML5, ARIA Roles, and Screen Readers in March 2010, I took a look at how then current screen readers behaved with some of the HTML5 section elements and related WAI-ARIA document and landmark roles. Now that the major screen readers have all seen some significant updates, and both Firefox 4 and Internet Explorer 9 have officially been released, I figure it's time to perform the review again and see what, if anything, has changed.

Update (August 21, 2011): See Steve Faulkner's recent update on screen readers and ARIA landmarks.

The Screen Readers

This time around, the tests were performed using the following screen readers:

Each of the Windows-based screen readers were tested in both FF4 and IE9, with the exception of SAToGo, which only works with Internet Explorer.

The latest version of VoiceOver in Mac OS X 10.6.7 was tested in Safari 5.0.4.

The Test Cases

As was the case with the previous research, there are two test cases. The first features a simple page using just HTML5 sectioning and a few other semantic elements. The second effectively reproduces the same page, but applies ARIA landmark roles, and two document structure roles.

In particular, the HTML5 elements employed in the test cases are:

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

The ARIA roles used in the second test case are:

  • application
  • article
  • banner
  • complementary
  • contentinfo
  • main
  • navigation
  • region

I included the one landmark role that I left out last time, namely, application. Additionally, because the HTML5 Annotations for assistive technology products specifies region as the default implied ARIA role for the section element, I've explicitly assigned this document structure role to one of the sections in the second test case. It's doubtful that this role will see much usage, but for the sake of testing what happens when it is used, I've gone ahead and added it. Also note that, as suggested in the specification for region, I've added an aria-labelledby attribute that references the region's associated heading.

Finally, I've trimmed much of the extraneous text and needless duplication of certain elements that was present in the previous versions of these test cases.

Result Summaries

The following presents some comments on FF4's new behaviour, along with summarised reviews of the major findings for each screen reader. Detailed results for each test case are available further below.

Firefox 4's New Behaviour

Things with FF4 are somewhat interesting, as it now exposes, via the IAccessible2 accessibility API, all nav, header, and footer elements as navigation, banner, and contentinfo landmarks, respectively. While this behaviour is fine for nav elements, it is not quite correct for header and footer.

The ARIA specification clearly notes that each document should only have one banner and one contentinfo landmark. By exposing every header and footer in this way, pages with more than one of either of these, which is not uncommon, will effectively have multiple banner and/or contentinfo landmarks as far as supporting assistive technology is concerned. Such is the case with NVDA 2011.1.

Fortunately, Mozilla is well-aware of this situation, for which there is a bug report, and it's probably reasonable to expect that this will be addressed soon enough in an upcoming release. Ideally, only the header and footer elements found at the document's root sectioning element will be exposed as banner and contentinfo landmarks. In any case, Mozilla deserves praise for starting to implement this kind of accessibility support for basic HTML5 elements with default implied ARIA semantics.

How the Screen Readers Do

NVDA 2011.1

NVDA is again the clear winner this time around. While its behaviour in FF4 with the header and footer elements, namely identifying each and every one as banner and contentinfo landmarks, is less than ideal, it's important to note that this is a Firefox issue, and not an NVDA issue. Otherwise, NVDA happily reads all content from both test cases in FF4.

NVDA in IE9 is not bad, but things are hardly great. With the HTML5 Plus ARIA Roles test case, NVDA in IE9 says the word "edit" before reading each line of text, e.g., Edit, Heading Level Two, Articles Section; Edit, Link, Skip to Link in Article A; Edit, Heading Level 3, Article A….

NVDA also provides navigation by landmark (via the D key), moving focus to and announcing the implied navigation, banner, and contentinfo landmarks in the HTML5 Only test case, as well as all explicitly identified landmarks in the second HTML5 Plus ARIA Roles test case.

Update (August 21, 2011): Note that NVDA 2011.1 in FF4 (and NVDA 2011.2 in FF6 for that matter) does not provide landmark navigation to or announce application landmarks.

JAWS 12

JAWS behaves identically in both FF4 and IE9. It doesn't do anything special with the simple HTML5 elements from the first test case, but does, in the second test case, announce all explicitly identified landmark roles: application, banner, complementary, contentinfo, main, and navigation. Further, JAWS also announces the ARIA document structure roles, article and region, as landmarks.

Like NVDA, in the second test case, JAWS offers landmark navigation (via the ; key) to all explicitly identified ARIA landmark roles, as well as to the two document structure roles, article and region, which JAWS equally considers landmarks.

Crucially, JAWS 12 fixes the Firefox and header bug from which JAWS 10 and 11 suffer, whereby all content contained in that element was effectively invisible to JAWS when used with Firefox.

Window-Eyes 7.5

With its latest version, Window-Eyes is still struggling with HTML5. In FF4, the results were fine with both test cases, in that all content was accessible and read as expected, even if Window-Eyes doesn't announce either the HTML5 elements or ARIA roles.

Where Window-Eyes in IE9 is concerned, however, the results are very disconcerting. So disconcerting, in fact, that I would very much appreciate their confirmation by other users. Briefly, Window-Eyes appears to suffer some serious difficulties with both test cases. With the HTML5 Only test case, it completely misrepresents the lists on the page, of which there are only two, while Window-Eyes finds five. It also finds only one heading, which isn't actually a heading, while the page actually contains six headings.

With the second test case with ARIA roles, Window-Eyes correctly identifies the two lists, but doesn't quite properly recognise those lists' content. It finds two headings on the page in this test case, but again, neither of the headings it identifies are actual headings on the page. Finally, it finds three non-existent frames, to only two of which it provides navigational access.

Window-Eyes does not provide keyboard shortcuts for navigation by landmark.

Needless to say, Window-Eyes 7.5 in IE9 is an iffy combination where HTML5 or HTML5 combined with ARIA roles are concerned. What exactly is going on requires further research, but Window-Eyes' problem with lists, particularly when ARIA roles are applied, has been noted before.

SAToGo 3.2.197

Since SAToGo clearly announces that it can only provide complete spoken prompts if you use Internet Explorer, I tested it in IE9 only. With the first test case, it read and provided easy access to all content. However, with the HTML5 Plus ARIA Roles page, when reading through the whole page using the "say all" command or the arrow keys, the two article elements are not read, but each is announced as editable text, blank. Yet, if using the Tab key to move through the focussable items on the page, SAToGo stops at each article, reads its contents as if it were all just simple text, and then finishes by saying editable text, blank.

SAToGo offers landmark navigation (via the ; key) for the banner, navigation, main, application, and contentinfo landmarks, but not the complementary landmark. And it does not announce the type of landmark when so navigating.

VoiceOver 3

With the first test case, VoiceOver reads and provides access to all content, but does not announce or do anything special with the HTML5 elements.

Its behaviour with the second test case is the same, except that, when reading through the page using the "Read All" command (Ctrl+Option+A), the aria-labelledby attribute on the section with role="region" seems to cause VoiceOver to repeatedly announce the value of the referenced label, in this case, "Articles Section", after practically each node within that section. Removing the aria-labelledby attribute prevents this.

While VoiceOver in iOS 4 provides landmark navigation, this functionality does not appear to be available in the Mac OS X version of VoiceOver.

Detailed Results

Unless noted otherwise, the screen reader reads and provides access to all content on the page in each test case.

HTML5 Only Test Case

Screen Reader FF4 IE9 Safari 5.0.4
NVDA
  • announces nav elements as navigation landmark
  • announces every header element as banner landmark
  • announces every footer element as contentinfo landmark
  • does not announce section, article, or aside elements
  • navigation by landmark to implied nav, header, and footer landmarks
  • does nothing special with the HTML5 elements
 N/A
JAWS
  • does nothing special with the HTML5 elements
  • does nothing special with the HTML5 elements
 N/A
Window-Eyes
  • does nothing special with the HTML5 elements
  • There are only two lists on the page, but WE identifies five lists:
    • the first list item under the "Test Cases" heading is not identified as part of a list, while the second list item is (List 1 with 1 item)
    • the list under the "HTML5 Only" heading is identified as a list of two items (List 2 with 2 items)
    • just before the "Article A" heading, WE identifies an empty list (List 3 with 0 items)
    • just before the aside in "Article A", WE identifies an empty list (List 4 with 0 items)
    • just before the last footer on the page, WE identifies an empty list (List 5 with 0 items)
  • recognises one heading on the page, an empty first-level heading somewhere between the link and footer in "Article B"
 N/A
SAToGo N/A
  • does nothing special with the HTML5 elements
 N/A
VoiceOver N/A N/A
  • does nothing special with the HTML5 elements

HTML5 Plus ARIA Roles Test Case

Screen Reader FF4 IE9 Safari 5.0.4
NVDA
  • same behaviour as HTML5 Only
  • additionally announces all explicitly identified landmark roles: application, banner, complementary, contentinfo, main, and navigation
  • does not announce application landmark
  • does not announce document structure roles: article, region
  • navigation by landmark to the implied nav, header, and footer landmarks, as well as all explicitly identified landmarks
  • same behaviour as HTML5 Only
  • additionally says "edit" before reading each line of text, e.g., Edit, Heading Level Two, Articles Section; Edit, Link, Skip to Link in Article A; Edit, Edit, Heading Level 3, Article A…
 N/A
JAWS
  • same as in IE9
  • announces all explicitly identified landmark roles: application, banner, complementary, contentinfo, main, and navigation
  • also announces the document structure roles, article and region, as landmarks
  • navigation by landmark to all landmark roles as well as the two document structure roles which JAWS considers landmarks
 N/A
Window-Eyes
  • same as in HTML5 Only
  • WE properly identifies only two lists, but:
    • WE considers the first list under "Test Cases" to contain only one item, the one with the link
    • the second list is correctly recognised as a two item list
  • WE incorrectly recognises two headings on this page: the non-heading text "Vivamus placerat" in "Article A" is considered an h3, as is the text "Aliquam vehicula justo ut metus" in "Article B"
  • additionally, while WE announces that the page has three frames, it only provides navigational access to two, one being the "Articles Section" section element, and one it calls the Application Section Button that does nothing frame
 N/A
SAToGo N/A
  • same as HTML5 Only, except that, when reading through the page using the "say all" command or the arrow keys, each article elements' content is not read, but collectively announced only as editable text, blank
  • however, if using the Tab key, SAToGo stops at each article, reads its contents as if it were just simple text, finishing with editable text, blank
  • navigation by landmark to the application, banner, contentinfo, main, and navigation landmarks, but not the complementary landmark
  • does not announce the type of landmark when navigating by landmark
 N/A
VoiceOver N/A N/A
  • same as HTML5 Only, except that in "Read All" mode, the aria-labelledby on the section with role="region" makes VoiceOver announce the value of the referenced label after practically each node within that section. For example, VoiceOver reads Articles Section; Skip to link in Article A, Articles Section, link; Article A, Vivamus placerat, Articles Section; libero ut convallis elementum, Articles Section, link, Articles Section; This is some text in an aside, Articles Section…. Once it gets to the end of the section, it says the word "region", which is the ARIA document structure role assigned to the section. Removing the aria-labelledby attribute prevents VoiceOver from doing this, and from mentioning that the section is a "region"

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 March 2011

Comments are now closed.