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
Basically, an ARIA-enabled tabbed interface has three components: the tablist, which contains a collection of tabs, each of which is a control for loading its associated content tabpanel.
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. In Application Mode, however, the arrow keypress is passed through to the browser and, because of the JavaScript at work, causes focus to move to the adjacent tab control, thereby loading the associated tabpanel.
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.
Text-Only tabpanels
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 div or 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 tab controls.
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.
Version #1: tab controls are simple list items
A simple unordered list, with relevant ARIA roles applied, serves as the tablist containing the tab controls.
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 tabpanel.
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 tabpanel content.
Version #2a: tab controls are links with href removed
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 tab control.
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 tab’s associated tabpanel.
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.
Version #2b: tab controls are links with href present
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.
Version #3a: first heading in tabpanel is focussable
Same as Version #2b, with list items that contain links serving as the tab controls, but here the main heading in each tabpanel has 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.
Version #3b: tabpanel itself is focussable
Same as Version #3a, but instead of setting tabindex="0" on the first heading in each tabpanel, the 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 tabpanel content.
Conclusions
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.