The test pages used in the videos are:

• HTML5 Only Test Case
• HTML5 Plus ARIA Roles Test Case

For more on screen reader behaviour with HTML5 and ARIA landmarks, see my post HTML5, ARIA Roles, and Screen Readers in March 2011, as well as Steve Faulkner's ARIA Landmark role support tests from November 2011.

NVDA 2011.2 in FF6 with basic HTML5 section elements

In Firefox only, the header, footer, and nav elements are identified as landmarks. Note that in Firefox versions 7, 8 , and 9, header elements are no longer identified as banner landmarks, and aside elements are now identified as complementary landmarks. Otherwise, the behaviour is identical.

NVDA 2011.2 in FF6 with HTML5 and ARIA Landmark Roles

With the exception of the application and form landmarks, all landmark roles are recognised by NVDA in both Firefox and Internet Explorer. In this test case, Firefox 6 identifies the header and footer elements inside the article as banner and contentinfo landmarks, even though they do not have express ARIA landmark role attributes. In Firefox 7–9, the header element is no longer registered as a landmark, but footer still is.

JAWS 13 in IE9 with HTML5 and ARIA Landmark Roles

JAWS recognises all landmark roles. However, both region and article ARIA document structure roles are also announced as landmarks. JAWS also misrepresents the heading structure: see JAWS, IE and Headings in HTML5.

VoiceOver in Safari 5.1 with HTML5 and ARIA Landmark Roles

VoiceOver announces all landmark roles except for form landmarks.

Window-Eyes 7.5.0 in IE9 with HTML5 and ARIA Landmark Roles

Window-Eyes 7.5.0 has serious problems in Internet Explorer where HTML5 and ARIA landmarks are concerned, but not in Firefox. Fortunately, these issues have been corrected in Window-Eyes version 7.5.1.

Headings in HTML5

The HTML5 outline algorithm allows us to use the h1 element for every heading on a page, and depending on the nesting of the sectioning element in which the h1 is found, the heading's rank will be redefined accordingly. While the HMTL5 specification encourages us to use only h1 elements, we are permitted to use [h1 to h6] elements of the appropriate rank for the section's nesting level.

The sectioning elements are article, aside, nav, and section. As such, according to the algorithm, the following two structures create identical outlines:

Using h1s Only

<h1>Level 1</h1>
<nav>
   <h1>Level 2</h1>
</nav>
<section>
   <h1>Level 2</h1>
   <article>
      <h1>Level 3</h1>
      <aside>
         <h1>Level 4</h1>
      </aside>
   </article>
</section>

Using Explicitly Ranked Headings

<h1>Level 1</h1>
<nav>
   <h2>Level 2</h2>
</nav>
<section>
   <h2>Level 2</h2>
   <article>
      <h3>Level 3</h3>
      <aside>
         <h4>Level 4</h4>
      </aside>
   </article>
</section>

Use Explicitly Ranked Headings For Now

It's a good thing that we have a choice of which approach to take, as support for the HTML5 outline algorithm in current browsers and assistive technologies is not quite there yet.

Where only h1 elements are used, a non-supporting browser or assistive technology will find nothing but h1 headings, which does not help a user understand the document's structure or heading hierarchy. For now, it is probably best to continue using explicitly ranked h1 to h6 elements as appropriate.

However, at least one screen reader in one browser is now supporting the h1-only approach to using headings in HTML5. But as good as this sounds, the particular support it has introduced is problematic.

JAWS 12 and 13 in Internet Explorer

If you use an h1 for every heading, JAWS 12 and 13 beta will, in Internet Explorer but not Firefox, correctly rank the heading in accordance with its section's nesting level. For example, an h1 nested two sectioning elements deep will effectively become a third level heading. JAWS appears to be simply adding the required number of levels to the heading as appropriate.

At the same time, and this is the problematic part, JAWS appears to be doing this even if you've taken the alternative approach and have used explicitly ranked h1 to h6 elements. That is, if you've correctly used an h3 element nested two sectioning levels deep, it becomes an h5 as far as JAWS in IE is concerned. Obviously, this can significantly alter the page's document outline or heading hierarchy as represented to the user.

If we take the second HTML5 structure we saw above, where the heading levels are explicitly set using appropriately ranked heading elements, JAWS in IE effectively interprets it as follows:

<h1>Level 1</h1>
<nav>
   <h2>Level 3</h2>
</nav>
<section>
   <h2>Level 3</h2>
   <article>
      <h3>Level 5</h3>
      <aside>
         <h4>Level 7</h4>
      </aside>
   </article>
</section>

Not only does the heading hierarchy now jump from a level one, to a level three, to a level five heading, the h4 heading in the aside element, nested three sectioning elements deep, becomes a 7th level heading. Since there is no such thing as an h7 element, JAWS does not even identify it as a heading. When moving from heading to heading through the page, as JAWS permits using the h key, this heading is simply skipped over. Nor does the heading appear in JAWS' headings list dialog.

All Versions of IE Affected

Interestingly, this behaviour occurs in all versions of IE, from IE6 and above. With IE6 to IE8, which have no native support for HTML5, this behaviour depends on those versions of IE being forced to recognise the HTML5 elements through a now common JavaScript hack, e.g., the HTML5 Shiv. Without it, JAWS presents each heading at a level defined by the heading element used. So every h1 remains a level one heading, every h2 a level two heading, and so on, regardless of the relevant sectioning element's nesting level. Of course, without the JavaScript shim, there's no styling of HTML5 elements in IE8 and below, so this scenario is rather moot, unless the page's developer has decided to not bother supporting those browsers.

A Bug and a Dilemma

I'm happy calling this behaviour a bug. While it's great that JAWS now supports the h1-only approach to headings in HTML5, it's hardly reasonable to start misrepresenting properly ranked h1 to h6 elements. Using explicitly ranked heading elements is clearly permitted by the HTML5 specification, and remains the only way to provide most current user agents a representative and meaningful document outline.

The dilemma is that using only h1 headings to provide a meaningful document outline for users of what is possibly the most popular screen reader and browser combination today means providing users of all other current screen reader and browser combinations effectively no meaningful heading hierarchy. Or, conversely, where headings in HTML5 are concerned, supporting most screen readers and browsers means not supporting JAWS 12 and 13 in Internet Explorer.

These are the sorts of decisions we don't want and shouldn't have to make when building accessible web pages, but they are a reality that we unfortunately get used to. On the other hand, screen reader and browser development is moving very quickly these days, so this particular problem may not exist for long.

You'll have to make up your own mind on how you deal with this issue. For me, until there's broad support for the h1-only approach across most screen readers and browsers in use, I'll take the more backwards-compatible route and use appropriately ranked h1 to h6 elements in my HTML5 pages.

So now everything is an article, and found under the "Articles" section of the site.

Old links to bits that were once either in the "Research" or "Blog" sections of the site should be properly redirected to the appropriate article, but if not, they should still be easy enough to find using the site's search functionality or the tag links in the sidebar.

If not, let me know, and I'll happily try to rectify the situation.

I wondered, assuming that the CSS-generated column headers were read by screen readers, if the screen readers would repeat the header text when navigating the table using their table navigation commands, once for the actual column header in the HTML, and once for the CSS-generated header text.

NVDA and VoiceOver

It turns out that NVDA with Firefox and VoiceOver with Safari both read the CSS-generated content. More importantly, in both cases the responsive data tables are not registered as tables at all. In the end, interacting with and reading responsive tables like this seems fairly straightforward with these screen reader and browser combinations.

From what I can tell, because the responsive version of the table, as well as its thead, tbody, th, td, and tr elements, are all set to display:block;, the table isn't recognised as an actual table. In fact, this seems to be the case even if just the table element itself is set to display:block;.

I don't fully understand the ins and outs of accessibility APIs, so what follows is my best effort. In Firefox, the regular data table that is not set to display:block; is identified to the IAccessible2 API with a role of "table", while the responsive version of the table with display:block; seems to end up with a role of "paragraph".

In Safari, things are a little stranger. Even the non-responsive regular table doesn't get registered as a table by VoiceOver for some reason. That is, VoiceOver doesn't recognise that there is a table present, and the Control+Option+Command+T keystroke for moving to the next table on a page does nothing.

Checking Apple's Accessibility Inspector, the regular table's cells are identified to the Mac Accessibility API as having an "AXRole" of "AXGroup", presumably some more generic and non-tabular type of role. However, after adding a caption to the table, all of a sudden VoiceOver is able to find it. In this case, Safari identifies each table cell to the Mac Accessibility API as having an "AXRole" of "AXCell", which makes sense, and the table itself has an "AXRole" of "AXTable", whereas previously I was unable to determine what "AXRole" the table had, if any.

With the responsive data table set to display:block;, even after adding a caption, the table is not identified as such. So in Safari, the use of display:block; on a table seems to have the same effect as it does in Firefox.

I figure this is why, with those screen readers in those browsers, the responsive tables tend to work so nicely. The screen readers don't consider them tables and don't enable their table navigation commands. They simply read each (generated) header as text and then read its associated value, without identifying any tabular structure. There is no repetition of both the HTML and CSS-generated column headers when moving from cell to cell. For all intents and purposes, there are no data tables or cells to navigate.

So I'm impressed with the responsive table's behaviour in these screen reader and browser combinations. As far as I can tell, however, this has as much to do with how the browser is identifying the table with display:block; to the relevant accessibility API, as it does with the use of the media queries and CSS-generated content.

What About JAWS?

Note: Because of a problematic rendering issue in Internet Explorer 9 with tables set to display:block;, Chris' example does not work with IE.

JAWS 12 in Firefox doesn't behave the same. It appears to treat the responsive data table as a data table, and enables its typical table navigation commands. At the same time, JAWS doesn't seem to be reading the CSS-generated column header text. As a result, using JAWS' regular table navigation commands, the table's content is navigable as if it were a normal data table. This is probably fine for a blind user, who won't realise the disjunction between what is presented on screen and what JAWS is telling her. But for a sighted user working with JAWS, I imagine there could some confusion since the table's content is not visually laid out as a table, and the CSS-generated column headers that are visibly repeated for every cell will not be read out loud.

Obviously, in the case of an iPhone or iPad, or similar, for which the CSS media queries are largely intended, the behaviour of JAWS for Windows is not an issue. Still, for the admittedly very few users that might be using JAWS with Firefox set to a narrow enough viewport to engage the CSS media query that changes the table's layout, what's going on may not be very clear.

The JAWS Bug

Back then, the situation with JAWS 7.1 was that it announces content in a span element hidden with display: none if it is in an anchor element. This only works with a span element; other inline elements used in an anchor element, such as em, strong, abbr, code, and so on, are not announced in JAWS. Additionally, this only happened with JAWS in Internet Explorer.

Having just tested this, I can confirm that this bug no longer affects JAWS 12 in Internet Explorer 9. After all, it has been about four years since that bug was discovered. In which specific version of JAWS this was fixed I can't say, having only tested the latest version.

The Window-Eyes Bug

While Window-Eyes 5.5 worked as expected with such hidden content, as soon as you added a CSS background image to the anchor itself or any other ancestor, up to but excluding the body element, Window-Eyes would announce the hidden content. Even if the link itself was hidden using display:none, if an ancestor element had a background image applied, Window-Eyes would read the link.

Using this test page, it is clear that Window-Eyes 7.5 in Internet Explorer 9, but not in Firefox 5, still exhibits the same bug. That is, content hidden using display:none is read by Window-Eyes in IE9 if the element itself or an ancestor has a CSS background image.

As was noted by Jared Smith all those years ago, doubling up display:none with visibility:hidden solves this problem with Window-Eyes. So if you are applying CSS background images and want to keep hidden children hidden from Window-Eyes in IE, this is what you'll need to do.

Browser Complicity?

Working with AViewer, the very useful tool from the Paciello Group, it seems that the accessible name that Internet Explorer 9 passes to the MSAA accessibility API for each of the anchors in the test page includes both the visible link text and the nested span hidden using display:none. On the other hand, Firefox 5 passes only the visible link text to both the MSAA and IAccessible2 APIs, leaving out the hidden span content.

This leads me, without completely understanding it all, to wonder if this might have something to do with Window-Eyes' behaviour where both the visible and hidden link text is read in certain conditions in IE9, but not in Firefox. If you can shed any light on this, please do.

This is a mistake because there is an entire range of differently skilled and concerned developers out there. Some are full-time developers who should really know better, but don't. Others simply find themselves having to markup web content, in which case I don't think we can really expect them to be fully aware of and up-to-date with best practices.

In either case, I'm finding that it's worth it to take the few extra minutes to follow through in my comments with detailed explanations of every step involved and the reasons behind my suggestions. When I forego this step, and assume that the developer will, on their own, get the picture and follow through in implementing best practices to their proper end, I too regularly find myself getting frustrated and later having to provide a second set of comments that more clearly provide the detailed instructions and explanations that I reasonably could and should have offered the first time around.

Granted, this situation may just be up to laziness on my part, or it may be that old saying about what happens when you assume coming to fruition, but from now on, when asked for these one-off and informal types of reviews, I'm going to try to offer detailed explanations of the steps to take from beginning to end, and not just assume that identifying the problem and providing general instructions will do. For instance, when I suggest that headings on a page are not properly nested, I'll take the extra minute or two to identify what heading should be at what level, and why this matters.

Not only does this capitalise on a potential learning moment for the developer, and, I think, show some additional professionalism and concern for doing a good job, but it will, often enough I expect, save me from doing more work later.

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:

• JAWS 12
• NVDA 2011.1
• Window-Eyes 7.5
• SAToGo 3.2.197
• VoiceOver 3

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

HTML5 Plus ARIA Roles Test Case

Browser and Accessiblity API Support

Internet Explorer 8 supports both spellings, i.e., "aria-labelledby" and "aria-labeledby". No matter the attribute's spelling, IE8 passes the attribute value to the MSAA accessibility API, which allows supporting assistive technologies, such as screen readers, to construct the relevant component's accessible name using that value.

Update (March 7, 2011): Thanks to Steve Faulkner for setting things straight (see Steve's comment below). Turns out, in fact, that IE does not support the incorrect spelling "aria-labeledby", but instead, in the absence of a proper label, builds the component's accessible name using whatever text exists within the component. You can read my reply to Steve which explains how I ended up coming to this false conclusion about IE. This is good news, in the end.

Firefox 3.6, on the other hand, only supports the attribute when it is spelled correctly as per the specification. The attribute's value is passed along to both the MSAA and IA2 accessibility APIs that Firefox supports only when the attribute is spelled "aria-labelledby". Otherwise, if the attribute is spelled "aria-labeledby", assistive technologies running on top of Firefox are not able to construct an accessible name for the associated component.

It's in the Spelling

If you need an additional reason to spell the attribute according to spec, let it be that that Firefox only supports it when it's spelled "aria-labelledby". If it's spelled "aria-labeledby", any accessibility benefits intended by using the attribute will be lost to those using Firefox, which is the preferred browser for many, especially those using the NVDA screen reader.

This difference in how the two browsers behave and the information they provide accessibility APIs also helps to explain the results from the two tests provided below.

Spell it as Specified

Despite the fact that, in some instances, aria-labelledby is supported when it's spelled "aria-labeledby", it is probably best just to play it safe and spell it "aria-labelledby" as defined by the specification. You'll not only be following the standard, but, and more importantly, users of Firefox with assistive technologies that support ARIA will benefit. Update (March 7, 2011): While contrary to my initial conclusion, IE does not support the "aria-labeledby" spelling. Apparently, however, a development version of Google Chrome supports both spellings. I've not looked at this, but Chrome's accessibility support is still very much in development at this stage.

The Results Summarised

One, it seems that NVDA just doesn't want to do alerts in Internet Explorer, though it shines in Firefox, as you'd expect. I'd love to know why. I should probably know this. Is it as simple as some accessibility API thing?

Two, JAWS 11 and 12 do great with role="alert" in both Firefox and Internet Explorer.

Three, JAWS 10, on the other hand, while it does well in FF3.6, doesn't manage role="alert" in IE7 and IE8 at all. If you are looking to support JAWS 10 in IE7 or IE8 at all, it is likely best to double up on alerts with both role="alert" and aria-live="assertive". While this is somewhat redundant since, by definition, the alert role is to be processed as an assertive live region, doing so does allow JAWS 10 to automatically announce the updated alert's contents in those two browsers. And since the alert role is effectively an assertive live region by default, this shouldn't, I expect, cause any problems or conflicts.

The Tests

Below are four examples of ARIA alerts. Following each example is a table providing detailed results.

The examples were tested with NVDA 2010.2, JAWS 10, 11, and 12, using Firefox 3.6 and Internet Explorer 7 and 8. Do note that none of the examples were tested using the combination of JAWS 12 and IE7. However, I'm assuming that since JAWS 11 with IE7 works well in all cases, with the exception of Example D, that JAWS 12 with IE7 works the same.