The WAI-ARIA specification remains unfinished and its implementation incomplete. All the same, some of it, e.g., landmark roles, can be used right now to improve the accessibility of web content and applications without causing a detrimental effect in older browsers or assistive technologies. I’m a big fan of WAI-ARIA, and think it is already a very useful collection of techniques with which to improve accessibility.
However, where tabbed interfaces are concerned, it may be that maximising their accessibility for most or all users means avoiding, at least for the time being, the use of ARIA. Of course, nothing is stopping us from building ARIA-enabled tabbed interfaces today, and these can work quite well with the latest versions of JAWS and NVDA in Internet Explorer 8 and Firefox 3.6. After all, we have to start somewhere, sometime. But there are a number of things that one should probably be aware of when doing so.
For what it’s worth, what follows is an examination of some typical implementations of ARIA-enabled tabbed interfaces, and some of the issues raised by the way screen readers work with them. Of particular concern are tabbed interfaces to regular text content as opposed to application or form controls.
ARIA Tabs Design Pattern and Screen Readers
The interaction design pattern promoted for ARIA-enabled tabs suggests that just the currently active
tab control be found in the Tab order, and that the
tab controls be navigable using the arrow keys. Setting focus to a
tab control loads the associated content
tabpanel which is otherwise hidden. This effectively mimics the way tabbed interfaces work in desktop applications. In a web page, for most screen readers (or, at least those that work with a virtual buffer) this means switching to Application Mode, where the Virtual Cursor is off. That is, keyboard commands entered by the user must be passed through to the browser instead of being intercepted by the screen reader. This is also know as Forms or Focus Mode, depending on screen reader and context, and will be variously referred to as such in this article.
In a screen reader’s normal reading or Browse Mode, when the Virtual Cursor is on, the press of an arrow key will be intercepted by a screen reader as a command to read the adjacent letter or line of text. This prevents using the arrow keys to select a different
tab control, thereby loading the associated
JAWS 11 and NVDA 2010.1 both automatically enter Application Mode when focus is set to a
tab control. In Application Mode, we can navigate through the various
tabs using the arrow keys. Yet, because the screen reader is now passing keyboard commands through to the browser, we can no longer use the normal reading commands to access the
tabpanel’s content. This is not necessarily an issue where the
tabpanel content is an application, that is, where it contains only form controls or otherwise focussable elements. This is because, even while in Application Mode, we can still easily use the Tab key to move to the first form control or focussable element in the
tabpanel and interact with it.
However, if a
tabpanel contains nothing but regular text content, there is nothing to set focus to using the Tab key. If the regular text content includes one or more links, then pressing the Tab key will set focus to the first link, skipping over any text content that might come before it. So, unless the screen reader is somehow placed back in Browse Mode with the Virtual Cursor on, it remains in Application Mode, and cannot be made to read any regular text content using the normal reading commands. The user can, of course, manually turn the Virtual Cursor back on, but it is worth noting that setting focus to a non-form or non-application element can accomplish the same thing in some instances; so this suggests a possible workaround, namely including such an element, for example, a heading, in the Tab order at the beginning of the
tabpanel content. This is explored in Version #3a and Version #3b of the ARIA tabbed interfaces presented below.
It is true that NVDA, like VoiceOver, provides object navigation by which the user can move from object to object in the DOM tree, thereby accessing all content in the
tabpanel, whether in Application or Browse Mode, but I wonder if this may be somewhat unfamiliar to or more complicated for the average Windows screen reader user. And while most users are likely fine entering and exiting Forms Mode when dealing with typical form elements, there remains the question of how comfortable they are encountering and managing Forms or Application Mode in other contexts, particularly with new features such as ARIA. Similar concerns were raised in Terrill Thompson's Musings on ARIA role="application".
Implementing ARIA Tabs
There may be some other approaches that I’m not aware of, but I’ve noticed roughly two general approaches to implementing ARIA-enabled
tab controls. Each approach has its pros and cons. The first approach involves using list items, or another non-link element such as a
span, to contain each
tab control. The iCITA-based ARIA tabpanel and the Tabbed UI examples listed in the WAI-ARIA Authoring Practices 1.0 are instances of this first approach. It is also the approach taken in the Version #1 example listed below.
The second approach wraps the
tab control in a link element. In this case, should the link itself be contained in something like a list item, the list item can be given an ARIA
role of “presentation,” since the link element is the active
tab control and the semantics of the list item are not relevant in this context. Examples of this approach can be found in Version #2a and Version #2b below.
The second approach, using
a elements to contain the
tab controls, is also used by Yahoo!’s YUI TabView ARIA plugin. By default, the YUI TabView plugin enables ARIA only in Internet Explorer 8 and Firefox 3 and above, since prior versions of these browsers do not support ARIA. By using natively focussable link elements for the
tab controls, users of other screen readers in earlier browsers, where the plugin is not active, are able to use the Tab key to move focus between the
tab controls. Unfortunately, someone using IE8 with an older version of JAWS, for example, will have difficulty as the ARIA plugin will be enabled and all the
tab control links except for the currently active one are removed from the Tab order using
tabindex="-1". These earlier screen readers also do not automatically enter Focus or Application Mode when setting focus to one of the
Testing Different Implementations
The following versions of ARIA-enabled tabbed interfaces include only text with some links in the
tabpanel content, and not any form or application controls. They were tested with a number of screen readers, some of which have little to no support for ARIA. For the Windows-based screen readers (JAWS 9, 10, and 11; Window-Eyes 7.11 and 7.2; NVDA 2010.1; and SAToGo 3.1.24), tests were performed with Internet Explorer 8 and Firefox 3.6. VoiceOver 3 on the Mac was tested in Safari 5.0.1.
The results for each version are summarised below. For more detailed results for each screen reader tested, follow the link to the specific version’s page.
A simple unordered list, with relevant ARIA
roles applied, serves as the
tablist containing the
This version works as expected with NVDA 2010.1 and JAWS 11, although without exiting Application or Focus Mode, the screen reader cannot access the
tabpanel content with the normal reading commands.
Because the active
tab control is not a focussable link, Window-Eyes does not even recognise that it is there unless the user first manually turns off Browse Mode, which may or may not be an obvious step for many users.
VoiceOver 3, which does not employ a virtual buffer model, but instead uses object navigation, pretty well just works, allowing arrow key navigation among the
tab controls and easy reading of the
tabpanel with the standard VoiceOver commands. But, presumably because the
tab controls are not links, pressing Ctrl+Option+Space to perform the default action on the
tab control does not load its associated
SAToGo 3.1.24 also does well in IE8, but not in FF3.6. While SAToGo does not allow use of the arrow keys, you can use the Tab key to move among the
tab controls, and, in IE8 only, select the desired
tabpanel with the Enter or Space keys, at which point it begins reading the
Version #2a is the same as Version #1, except that the
tab controls are links within the list elements. The links have their
href attributes removed to prevent JAWS 9, JAWS 10, NVDA 2010.1, and JAWS 11 in a certain context, from reading the absolute URL with fragment identifier when the
tab control link gains focus in IE8. This has the unfortunate side effect of preventing Window-Eyes from even finding the
tab controls when using the Tab key.
JAWS 11 and NVDA 2010.1 automatically enter Forms Mode when focus is set to a
tab control, but with JAWS 11 in IE8, moving focus to an adjacent
tab control causes it to automatically exit Forms Mode. This makes moving through the available
tab controls a cumbersome process of manually toggling Forms Mode back on every time in order to switch
tabs. At the same time, after selecting a new
tab, it is thus a simple matter to continue reading the
tabpanel content since we are already back in Browse Mode with the Virtual Cursor on. Update (Sept. 29, 2010): These tests were originally performed using JAWS 11.0.756. Since then, one of the updates to JAWS 11 fixed this. As such, in version 11.0.1471, at least, this is no longer a problem, and JAWS in IE8 no longer automatically exits Forms Mode upon moving focus to an adjacent
VoiceOver 3 works the same as with Version #1, except that in this case, because the
tabs are within links, and therefore have a default action, pressing Ctrl+Option+Space does load the
SAToGo 3.1.24 works the same in both IE8 and FF3.6 here, allowing navigation among the
tab controls using the Tab key, and activation of a
tab with the Enter or Space keys.
This is the same as Version #2a, except that the
tab control links keep their
href attributes, thus allowing Window-Eyes in IE8 only, to find the currently active
tab control in the Tab order.
However, in IE8, JAWS 9, JAWS 10, and NVDA, as well as JAWS 11 when its Virtual PC Cursor is off, will read the full page URL with fragment identifier for each
tab control when it gains focus. So, with this approach to implementing
tab controls, improving the experience for Window-Eyes users means reducing it somewhat for JAWS and NVDA in IE8.
On the plus side, Window-Eyes in IE8 actually provides access via the Tab key to all of the
tab controls, even those with
tabindex="-1". Unfortunately, even though pressing the Enter key on a
tab control loads the relevant
tabpanel, in Windows XP, Window-Eyes’ virtual buffer does not seem to get updated, and so it reads the previously loaded and now hidden
tabpanel’s content. In Windows 7, this is not a problem and Window-Eyes appropriately reads the newly loaded
tabpanel’s content. I don't know why this happens, and if anyone has a different experience with Window-Eyes in IE8 in either version of Windows, please let me know.
Also unfortunate is the fact that in FF3.6, Window-Eyes just does not want to play along in any helpful manner and cannot find the
tab controls unless its Browse Mode is turned off.
SAToGo and VoiceOver work the same as they do with Version #2a.
Same as Version #2b, with list items that contain links serving as the
tab controls, but here the main heading in each
tabindex="0" to place it in the Tab order. This allows the use of the Tab key to move focus from the active
tab control into the
tabpanel’s regular text content. In FF3.6, but not in IE8, this causes both JAWS 11 and NVDA 2010.1 to automatically exit Application Mode and permit the use of the screen reader’s normal reading commands for accessing the
tabpanel content. So this is one way to help users of these two ARIA-supporting screen readers more easily find their way from
tab control to content. But the fact that it doesn’t seem to help in IE8 is an issue. But not all is lost: check out Version #3b below.
It’s also important to note that Window-Eyes 7.2 does not find the main heading in the Tab order unless its Browse Mode is off, while the earlier 7.11 version of Window-Eyes does not suffer this, and has no problems placing the heading in the Tab order.
SAToGo in IE8 does not register the
tabpanel’s heading as a focussable element. While it does place the heading in the Tab order in FF3.6, it does not read the heading’s text. Either way, not too much is lost or gained as SAToGo will still read the
tabpanel’s main content.
For VoiceOver, the heading is simply another element in the Tab order, which is read out upon receiving focus.
Same as Version #3a, but instead of setting
tabindex="0" on the first heading in each
tabpanel itself is set with
tabindex="0" to place it in the Tab order. In this case, JAWS 11 and NVDA 2010.1 automatically exit Application Mode and enter Browse Mode in both IE8 and FF3.6 when using the Tab key to move focus to the
tabpanel. This, then, allows these screen readers easy access to the
tabpanel content through the normal reading commands.
However, in neither browser is either version of Window-Eyes able to find the
tabpanel itself in the Tab order unless Browse Mode is turned off.
SAToGo in IE8 behaves much as it does with Version #3a. But in FF3.6, it does not like this version, pretty much ignoring the
tabpanel’s content entirely.
With VoiceOver, moving focus from the
tab control to the
tabpanel using the Tab key causes it to start reading all of the
So, which version is best? Which version provides the greatest accessibility across the screen reader and browser combinations tested here? Well, it’s hard to say. While these tests likely go a little overboard with all the screen reader and browser combinations they examine, at the very least they serve to drive home the impression that there does not appear to be one ideal approach where broad accessibility is concerned.
If one is dead set on adding ARIA to their tabbed interface, or if the screen reader and browser combination available to a site's users is known to be compatible, as might be the case, for example, in a government or corporate setting, Version #2b or Version #3b, which are more or less the same, might be the ones to go with. While they have some less than ideal behaviour in IE8 with JAWS 9, JAWS 10, and NVDA 2010.1, they do work to varying degrees with those screen readers. More importantly, they also work well with VoiceOver 3, and to some degree with Window-Eyes in IE8 in Windows 7, but not Windows XP, nor with Window-Eyes in FF3.6. For that matter, none of the versions examined here really work well for Window-Eyes in FF3.6.
In Version #3b, including the
tabpanel as a focussable element allows users of some screen readers, Window-Eyes being the notable exception, to press the Tab key to move focus to the
tabpanel, which also forces JAWS 11 and NVDA 2010.1 back into Browse Mode. This makes it easy to then have those two screen readers continue reading the
tabpanel content using their normal reading commands. This is particularly useful if the
tabpanel contains regular text content as opposed to form or application controls. At the same time, while this feature is quite useful for JAWS 11 and NVDA 2010.1, it would seem to make things extra difficult for SAToGo 3.1.24 in FF3.6.
Whatever approach is taken, it might also make sense to enable ARIA for a tabbed interface only when IE8 or FF3 and above are used, as the YUI TabView ARIA plugin does. Sure, this amounts to browser sniffing, but if it reduces the potential difficulty or confusion for users of older browser and screen reader combinations, it seems a not unreasonable thing to do. Of course, it will not catch users of older screen readers with the latest browsers, but it should help in some cases.
It may also be reasonable to include for screen reader users some sort of instructions just before the tabbed interface. These instructions could be visually hidden so as not to interfere with the page’s visual layout, should that be of concern. They could be something like “To navigate the following tab controls using the arrow keys, make sure your screen reader is in Forms or Application Mode, and not in Browse Mode. After selecting a tab, set the screen reader back to Browse Mode to read the tab’s content.” But even this may be too verbose and cryptic for some users, though I’m sure it could be improved. Still, the very fact that such instructions should prove useful suggests, I think, that an ARIA-enabled tabbed interface might for now just get in the way of a usable experience for too many users.
To sum up, in none of the versions presented here will the experience necessarily be clear and obvious for all users with all screen readers, and especially not for older versions. All the variability in how different screen readers perform in different browsers, some for better, some for worse, and some for much worse, should be taken as an indication that for the time being, maximising the accessibility of a tabbed interface really means employing a considered, non-ARIA approach, maybe something more like Ginader’s Accessible Tabs plugin. That being said, I would love to learn that I have misunderstood something about ARIA-enabled tabbed interfaces, or overlooked something that might contribute to improving these results or changing the conclusion I am suggesting they leave us with.