For straightforward details/summary pairs where the summary element contains only text, browsers and screen readers do pretty well, assuming appropriate keyboard focus and WAI-ARIA support is provided where necessary. However, where one or more links are nested in the summary, things get a little more cumbersome.

What follows is a very long and detailed account of some of the browser, screen reader, and accessibility API behaviours involved in that likely very limited use case where a summary element also contains nested links. For this, I'm happy to apologise up front, and if you're already thinking "TL;DR", you just might want to jump to the overview and upshot at the end. I won't be offended. The extensive detail is just me sharing what I've managed to grasp about how these things go together as part of an ever-continuing attempt to learn more about the ways screen readers, accessibility APIs, and browsers work. That, and somebody told me that blogging is making a comeback.

Current Browser Support

Neither Internet Explorer 9, Firefox 11, nor Safari 5 provide native support for details and summary. While Chrome has supported them for several versions now, its current version 17 provides no default keyboard access, nor does it pass any meaningful semantics to the accessibility API. However, recent WebKit nightly builds support the elements with proper keyboard access, as do recent Chrome Canary builds, but still neither provide any useful accessibility information. And Opera is working on it.

How They Should Work

The summary element should be natively keyboard focussable. Clicking or pressing the Enter or Space keys on the summary element should toggle the visibility of the details element's content. When the details element is expanded, it should have an open attribute present, and its content should be available via the system's accessibility API. Conversely, when the details element is collapsed, which is its default state, the open attribute should be absent, and the details' content should not be present in the accessibility tree. That is, it should not be available to assistive technologies.

According to the HTML to Platform Accessibility APIs Implementation Guide, the summary element should be mapped to a typical button role, or, where available, as in the Mac Accessibility API, a disclosure triangle role. There's more to say about this below.

Polyfill Required for Now

Where a browser doesn't manage this itself, the summary element should be made keyboard focussable with tabindex="0". Additionally, consistent with the proposed accessibility API mapping for the summary element, a WAI-ARIA role of button should be added to the summary element, along with an aria-expanded attribute that changes based on the state of the details element. The non-summary content of the details element should be hidden using display:none; when the element is collapsed.

<details>
   <summary role="button" aria-expanded="false" tabindex="0">
      Summary element content
   </summary>
   <p>Details element content</p>
</details>

The good news is that with a polyfill of your own design, or using something like Mathias Bynens' jQuery plugin for details/summary, things work pretty well right now in most browsers and screen readers. One current exception with Mathias' plugin is Chrome 17, which, because it natively supports details and summary, doesn't get the plugin's keyboard support applied. But since Chrome 17's keyboard support for summary is non-existent, this leaves Chrome keyboard users without the ability to expand or collapse the details. This isn't a problem using the plugin in tandem with Chrome Canary 19.

Here is an example a simple details/summary element in action:

The bad news is that, if you include links in the content of the summary element, a few screen readers show rather problematic behaviour in some cases. Some of this has to do with the way certain screen readers manage keyboard interaction. Some of it has to do with the use of the ARIA role="button".

Note that when no screen reader is running, none of the browsers used in the tests below (namely Internet Explorer 9, Firefox 11, Safari 5, Chrome 17, and Opera 11) seem to have any difficulty providing access to both the summary and a nested link when using the Tab key (assuming keyboard access is supported either natively or through some polyfill).

Also note that the screen reader behaviour described below for the summary element goes for any other element you might use in a similar way. For example, if you're using a heading as the interactive element for showing and hiding other content, the same issues apply.

There's a Link in That summary!

The HTML5 specification for the button element, for instance, does not permit the nesting of other interactive content like links. This has always been the case, is expected given the typical use case of the button element, and so makes sense, I think. However, doing so, for better or worse, is permitted for the summary element, whose content model is phrasing content, which includes links.

I say "for better or worse" because, among other things, it could be easy enough, especially for sighted mouse users, to intend to expand or collapse the details element by clicking on the summary, but to accidentally click the nested link inside it instead. This would, of course, activate the nested link. However, it might be possible to mitigate this potentiality by clearly and visually distinguishing a link in the summary from the rest of the element, and providing a very obvious hover effect on the link to indicate the difference between clicking on it and clicking on the parent summary. Still, even then, I expect there remains some room for user confusion.

I've spoken to a few people who think it is a mistake to permit nested links, and that it is basically a bad design pattern. Personally, I have a feeling that it might be a potentially useful feature. My problem is that I'm unable to conjure a reasonable use case that argues well for this usefulness. Given the possible usability issue identified above, and the accessibility API and screen reader concerns discussed below, I don't know that I really have strong feelings about keeping nested links permitted in summary. It would, at least, be interesting to learn the reasoning behind permitting interactive content within the summary element.

Here's a details element with a summary containing a nested link surrounded by other inline text:

The Effect of role="button"

In setting role="button" on the summary, we are effectively telling user agents to identify the summary as a button in the accessibility API. As such, we might reasonably expect that, as per the specification for the button element, any interactive content, such as links, nested in the summary would not be passed through as accessible objects to the accessibility API. In this case, of course, links nested in a summary would not be available to assistive technologies relying on the accessibility API. This is how it works at the moment with Safari and the Mac Accessibility API. Things aren't the same with Internet Explorer and Firefox, which leads to some especially interesting effects in JAWS and NVDA.

Safari 5 and VoiceOver

Safari 5 identifies our summary element with role="button" to the Mac Accessibility API as having an AXRole of AXButton, and any nested links are not passed to the accessibility tree. That is, as far as VoiceOver is concerned, there are no nested links, and the contents of the summary are flattened to basic text. The summary element content is read and announced as a "button". It is not possible to navigate to a nested link using the standard VoiceOver keyboard commands. You can set focus to a nested link via the TAB key, and you can follow the link, but the link text is not announced, and the link is not listed in VoiceOver Web Rotor's list of links.

Internet Explorer and Firefox

With Internet Explorer 9 and Firefox 11, on the other hand, even while a summary element with role="button" is identified to the accessibility APIs with a role of "pushButton", which is the same as a regular button element, links nested within the summary are passed through to the accessibility APIs, and thereby available to a screen reader should it wish or be able to use them. This last bit is important.

Just because the accessibility API provides certain information doesn't mean that an assistive technology can or will necessarily make use of it. For instance, both IE and FF pass the nested links to the accessibility tree as accessible objects, albeit somewhat differently. While IE identifies a nested link to the MSAA API as an MsaaAccessible link object, FF identifies it through the IA2 API as an IA2Accessible link object. For this reason, based on how they interact with the accessibility APIs, JAWS 13 and NVDA 2012.1 exhibit different behaviour in these two browsers where links nested in a summary element with role="button" are concerned.

Is role="button" Appropriate?

Unfortunately, accessibility APIs like MSAA and IA2 don't provide accessible roles fully suited to a summary element that contains nested links. Out of all the roles they offer, a role of button seems the most appropriate option. To the degree that a user agent deals with role="button" in a way that is consistent with the specification for the button element, i.e., disallowing the nesting of other interactive content, this presents a problem.

Steve Faulkner has called the situation "suboptimal", and proposed that the HTML5 specification be changed to disallow the inclusion of interactive elements. I rely on Steve's knowledge and expertise in these areas, and while I have no alternative solution to offer, I can't help wonder if, assuming that there is a potential usefulness to links in summary, that this proposal doesn't suggest a change in order to provide for what is really a current limitation of accessibility APIs.

Might there be another way to allow the summary element to contain other interactive elements while still providing reasonable access to assistive technologies? Perhaps something along the lines of the approach taken by IE and FF is the way to go, namely, identifying elements with role="button" to the accessibility API as having a button role, but nonetheless passing nested interactive content through to the accessibility APIs and thereby leaving it up to the assistive technology to determine how to handle it based on context?

As I noted above, I don't really have strong feelings either way, should the specification change to disallow nested interactive content. It certainly would address the problems with screen readers described below.

Nested Link Following Other Inline Text

We have two possible scenarios for links nested inside a summary element. In this first scenario to be examined, the nested link follows some other inline text, as is the case with our details/summary with nested link example from above.

In the second scenario, which we'll look at afterwards, the nested link is the first item in the summary element. This proves to be the most problematic scenario, at least with JAWS and NVDA.

The screen readers used to produce the results discussed below are:

• JAWS 13.0.718
• NVDA 2012.1
• Window-Eyes 7.5.3
• VoiceOver in Mac OS X Snow Leopard and Lion
• ChromeVox 1.16.0
• Orca 3.2.1 in Ubuntu 11.10

A Note on Browse versus Focus Mode

For what follows, it helps to understand the difference between the two main ways JAWS and NVDA (and some other screen readers) provide for interacting with web content. Browse Mode is the default navigation mode in which keyboard commands are intercepted by the screen reader enabling users to navigate a virtual representation of the page's content and structure. For example, in Browse Mode, the user can press the up or down arrow keys to move a virtual cursor up or down a line in the page content and have it read, or they can press certain keys and move to the next or previous link, or call up a list of all the links on the page.

Browse Mode is distinct from what is sometimes called Focus Mode, or often Forms Mode in JAWS, wherein keyboard commands are passed directly through to the browser, allowing users to do such things as input text into form fields.

JAWS and IE9

When in Browse Mode, JAWS and IE users navigating with the up or down arrow keys can move the virtual, or Browse Mode, cursor to a summary element. If the summary element contains nothing but text, all that text will be read and called a "button", but the expanded/collapsed state of the details element will not be identified, even though the aria-expanded attribute is present. If there is a link in the summary, however, JAWS will read it as a separate node, as it were.

If we take our details/summary with nested link example from above, upon arrowing down to the summary element, JAWS will read "summary element with a, button". Another down arrow keypress is required to move the Browse Mode cursor to the link and hear "link, link to google.com". A third down arrow keypress gets us to the remaining text in the summary, and we hear "nested within it, button". At this point it sounds like we've got two buttons and one link between them. And in fact, we do. If the Browse Mode cursor is on the link, pressing Enter or Space will indeed expand or collapse the details, but it will also activate the link. Consistent with this behaviour is the fact that the link nested in our summary element with role="button" is included in JAWS' links dialog listing all the links it finds on the page.

On the other hand, using the Tab key to move focus to the summary element, JAWS in IE will read its entire contents, so we get something like "summary element with a link to google.com nested within it, button". Activating it with Enter or Space simply expands or collapses the details element as we would hope. One can also use the Tab key to move focus to the nested link itself and then follow the link as usual, although this equally expands/collapses the details element prior to the nested link's URL being loaded.

JAWS and FF11

JAWS in FF11 similarly announces the summary as a "button", and doesn't identify the details element's expanded/collapsed state. Otherwise, it behaves a little differently. When moving the Browse Mode cursor to the summary element via the down arrow key, JAWS reads all of the element's content just as it does in IE9 using the Tab key, at which point pressing Enter or Space expands or collapses the details element without also activating the nested link. It's not possible with JAWS and FF in Browse Mode to use the up or down arrow keys to move the cursor to the nested link. Even using the left or right arrow keys to move the Browse Mode cursor onto the link text doesn't get JAWS to recognise the link.

Using the Tab key in Browse Mode, you can move focus to the summary and to the nested link, but even when focus is on the nested link, pressing Enter or Space does not activate the link, and only serves to expand or collapse the details element. The only way in FF to get JAWS to activate the nested link is to manually switch to Focus Mode (Insert + z), at which point, after setting focus to the nested link using the Tab key, one can fire and follow the link.

Considering this behaviour of JAWS in FF, compared with its behaviour in IE, it might come as no surprise that links nested in a summary element are not listed in JAWS' links list dialog. As far as JAWS in Browse Mode with FF is concerned, there are no links inside a summary element set with role="button".

NVDA, IE9 and FF11

NVDA behaves somewhat differently from JAWS, but more or less the same in both IE9 and FF11. The summary is announced as a "button", but NVDA respects the aria-expanded attribute, and so identifies the expanded/collapsed state of the details element. When navigating by the up or down arrow keys and setting the Browse Mode cursor to the summary element, NVDA treats it as a complete item and reads its entire contents: "summary element with a link to google.com, link, nested within it, button, collapsed".

One can use the right or left arrow keys as required to move the Browse Mode cursor to the link, at which point it gains focus and can be activated via the Enter or Space keys. The details element will at the same time be expanded or collapsed, but this hardly matters since the browser is already fetching the nested link's URL. Focus can also be variously set to the summary or the nested link using the Tab key, and the activation behaviour in both cases is the same. There's no need, as there is with JAWS in FF, to switch to Focus Mode.

Consistent with the above behaviour is that regardless of which browser is being used, NVDA's links list dialog includes any link nested within a summary attribute, even if the latter is set with role="button".

Nested Link as the summary's First Item

In this second scenario, the nested link is the first bit of content inside the summary element. Here's an example of that:

JAWS and IE9

In IE9, as was noted above, when the summary element contains a link, JAWS parses its content as separate nodes in Browse Mode. If we use the down arrow to move the Browse Mode cursor to the summary element, the cursor moves to the first item in the summary. In this scenario, it lands on the nested link, and we hear, using the third details/summary example above, "Link, Link to google.com", with no indication that we are in a summary element as "button". Pressing Enter or Space obviously activates the link.

Another press of the down arrow and we hear "nested at the beginning of a summary element, button". At this point pressing Enter or Space will expand or collapse the details element without activating the link, but the relationship between what is read as the description of the "button" and the content that we are expanding or collapsing is hardly ideal.

If we use the Tab key to move focus to the summary element, the whole summary element's contents are read and called a "button". Pressing Enter or Space expands or collapses the details element, but it equally fires the nested link. The only way I've found to prevent this happening is to include some other inline text before the nested link. Even something like a non-breaking space character reference ( ) will do.

JAWS and FF11

Since we already know that in Browse Mode, and whether we use the up/down arrow or the Tab keys, JAWS doesn't recognise any nested links in the summary element with role="button", there is no real difference between scenarios one and two. Whether the link is nested at the beginning of the summary element or following some other inline text, the Browse Mode cursor and focus cannot be moved to the nested link. The only way to get to the link is to enter Focus Mode.

NVDA, IE9 and FF11

Just as with JAWS in IE, moving the Browse Mode cursor to the summary element and pressing Enter or Space to expand/collapse the details element ends up activating the nested link. And if we move focus to the summary using the Tab key, the same thing happens. James Teh, Director of NV Access Limited, makers of NVDA, kindly offered the following explanation:

This happens because when the [summary] gains focus, NVDA moves the Browse Mode cursor to the start of the [summary]. Unfortunately, the start of the [summary] is the link, so the Browse Mode cursor moves to the link. In Browse Mode, the Space and Enter keys always operate on the object under the Browse Mode cursor, not the focused object. (We need to do this because it's sometimes necessary to activate elements which aren't focusable; not every site is marked up as well as it should be.) Thus, pressing Enter activates the link.

James additionally noted that while he agrees this is a problem, a workable solution that won't also break a lot of other more common use cases is not easily had at this point. I have filed a bug report with NVDA (and another bug report for the same behaviour in JAWS).

Another pesky detail to mention here is that in IE9, even a nested link preceded by a non-breaking space character reference won't prevent the nested link from being followed. It takes actual text.

Also note that, while in Browse Mode, it is possible with NVDA in both IE9 and FF11 to move the cursor to the right of the nested link onto some non-link text, should it exist, and thereby expand/collapse the details element without activating the nested link. This is probably a little less intuitive than we should like, but it does provide the possibility of access. However, if the summary element contains nothing but a link, then we are totally out of luck, it would seem.

What About Other Screen Readers?

Window-Eyes 7.5.3

In both IE and FF, W-E 7.5.3 behaves the same. It announces the summary with role="button" as a "button", but doesn't identify its expanded/collapsed state. Links nested in the summary are not present in Browse Mode, nor are they to be found in the screen reader's links list dialog. Yet, apparently because of the role="button", W-E enters Focus Mode as soon as the summary element is activated, and then the links are accessible using the Tab key. But then reading the content using normal W-E's normal keyboard navigation commands requires manually turning Browse Mode back on.

With W-E, however, where focus is set to a summary element whose content begins with a nested link, activating the summary does not also fire the link.

ChromeVox 1.16.0

In Chrome 17.0.963.79, the summary element is not focussable. Links nested within it, however, can take focus and be followed. Interestingly, when setting focus to such a nested link, it is announced as a "button" and its expanded/collapsed state is noted. Nonetheless, it's not possible to expand or collapse the details content.

Orca 3.2.1 (Ubuntu 11.10)

Orca in FF11 provides full keyboard support to summary elements and any links nested within them. The summary is announced as "button", but its expanded/collapsed state is not identified. If a link is the first item nested within a summary, navigating by the up or down arrows will put the cursor to the link, and not the summary. In order to move focus to the summary parent, one can use the right arrow key to move to other non-link text if it exists. Otherwise, the only way is to use the Tab key.

Overview and Upshot

If you are using the HTML5 details and summary elements, and providing appropriate keyboard focus (i.e., tabindex="0") and WAI-ARIA support (i.e., role="button" and aria-expanded), users of most screen readers and browsers, at least more recent ones, will have little to no problem interacting with them. Mathias Bynens' jquery-details plugin works well.

Where role="button" and aria-expanded are applied to the summary element, JAWS 13, NVDA 2012.1, Window-Eyes 7.5.3, VoiceOver in Snow Leopard or Lion, and even Orca 3.2.1, all announce the summary element as a "button". Of these, only NVDA explicitly identifies the expanded/collapsed state of the element.

Chrome 17 is currently the only browser that supports details and summary. However, it does not provide keyboard support, which may leave keyboard-only Chrome users without access. However, recent nightly builds of WebKit and Chrome Canary support these elements with keyboard access.

Beware of Links in the summary

Things get tricky when we start to nest links within the summary element, which, no matter how you might feel about such a design pattern, is currently permitted according to its specification.

Links in a summary won't be clearly available to VoiceOver users with Safari. While such links are available to JAWS users in IE, they are not available to JAWS users with Firefox, nor to Window-Eyes users in either browser, unless one switches from Browse to Forms/Focus Mode, which likely won't be obvious to many. However, Window-Eyes does automatically enter Focus Mode as soon as the summary is activated, and then the links are accessible via the Tab key. And in NVDA, these nested links are available to users in both browsers.

It's also worth noting that links in the summary will change the way JAWS announces the summary's content in IE, reading it as separate nodes when accessed via the typical up or down arrow keys in Browse Mode. Using the Tab key gets past this, however.

When the summary Begins With a Nested Link

In JAWS with IE, and in NVDA with both IE and FF, setting focus directly to and activating a summary element whose first bit of content is a nested link will expand or collapse the details element, but at the same time cause that link to fire, which is likely to cause some serious disorientation. While NVDA users can play with the left or right arrow keys to move the Browse Mode cursor to any non-link text within the summary that might exist and then singularly expand/collapse the details element without also activating the nested link, this may not be intuitive. And if the summary contains nothing but a nested link, the user is pretty much out of luck: the nested link will always be fired when trying to expand or collapse the details.

The Upshot

Go ahead and use details and summary (with an appropriate polyfill). If you must have one or more links nested in the summary, arrange them so that they are not the first things within the summary element. And even if you manage this, you should recognise that:

• these links still won't be in any way clearly identifiable to users of VoiceOver in Safari;
• these links still won't be available to JAWS in FF or Window-Eyes in both FF and IE when these screen readers are in Browse Mode; and,
• JAWS users with IE will have a less than ideal experience reading the summary's content.

Acknowledgements

Thanks to Steve Faulkner and Jamie Teh for their help and opinions, and for answering my technical questions about browsers, accessibility APIs, and screen readers.

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.