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.
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:
The ARIA roles used in the second test case are:
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.
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
footer elements as
contentinfo landmarks, respectively. While this behaviour is fine for
nav elements, it is not quite correct for
The ARIA specification clearly notes that each document should only have one
banner and one
contentinfo landmark. By exposing every
footer in this way, pages with more than one of either of these, which is not uncommon, will effectively have multiple
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
footer elements found at the document's root sectioning element will be exposed as
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 is again the clear winner this time around. While its behaviour in FF4 with the
footer elements, namely identifying each and every one as
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
contentinfo landmarks in the HTML5 Only test case, as well as all explicitly identified landmarks in the second HTML5 Plus ARIA Roles test case.
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:
navigation. Further, JAWS also announces the ARIA document structure roles,
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,
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.
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.
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
contentinfo landmarks, but not the
complementary landmark. And it does not announce the type of landmark when so navigating.
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
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.
Unless noted otherwise, the screen reader reads and provides access to all content on the page in each test case.
|Screen Reader||FF4||IE9||Safari 5.0.4|
|Screen Reader||FF4||IE9||Safari 5.0.4|
Note: The translations below are listed with no guarantee of their accuracy (or the accessibility of their content).