Using tabbed interfaces with a screen reader

Tabbed interfaces are increasingly common on web pages. They make good use of space, and they can be visually intuitive. Using tabs with a screen reader is a different experience though.

When it comes to tabbed interfaces on web pages, there are two disadvantages for screen reader users. The visual clues that establish the tab metaphor are not available, and the required form of interaction isn’t obvious. This makes understanding and using a tabbed interface with a screen reader an interesting experience!

Understanding the tabbed interface

The first point is straight forward. The visual design helps a sighted person to understand the concept of layered content. The use of light and shadow gives a sense of depth, and the tabs are often styled to mimic their real life counterparts.

This problem can be solved with ARIA. The tablist, tabpanel and tab roles make additional information available to screen readers like NVDA and Jaws. A tablist is a set of tabs, and each tab has a corresponding tabpanel.

<ul role=”tablist”>
<li role=”tab”>Dogs</li>
<li role=”tab”>Cats</li>
<li role=”tab”>Sheep</li>
</ul>

<div role=”tabpanel”>
<h2>Dogs</h2>

</div>

<div role=”tabpanel”>
<h2>Cats</h2>

</div>

<div role=”tabpanel”>
<h2>Sheep</h2>

</div>

ARIA bridges the visual gap, and helps blind people understand a little more about the widget they’re dealing with. Instead of announcing “Dogs”, “Cats” and “Sheep”, screen readers like NVDA and Jaws will announce “Dogs tab”, “Cats tab” and “Sheep tab”.

Using the tabbed interface

The second point is more complex. To some extent the additional information provided through the ARIA indicates what form of interaction is required.

It’s standard screen reader behaviour to provide auditory clues that let people know what kind of action can be taken. Prefacing link text with the word “Link” sets up the expectation that pressing the Enter key will activate it for example. In this case the word “Tab” sets up the expectation that the set of tabs can be traversed, usually left to right (or vice versa).

The trouble is that it isn’t the action taken once a tab has focus that’s important. It’s the action taken to focus on the tab in the first place that makes all the difference.

For a tabbed interface to work, screen readers like Jaws and NVDA need to switch into applications mode. In other words they need to start passing the keystrokes through to the browser, instead of intercepting them to perform screen reader specific commands.

Ordinarily a screen reader intercepts the left/right arrow keys and uses them to move focus backwards/forwards one character at a time. To interact successfully with a set of tabs, the left/right arrow keys need to be ignored by the screen reader and used to move focus backwards/forwards through the set of tabs instead.

Triggering applications mode is the key to getting screen readers like NVDA and Jaws to work with tabbed interfaces. Using the tab key to move focus to one of the tabs is the key to triggering applications mode.

Using tabbed interfaces with a screen reader

The demo here uses Hans Hillen’s accessible jQuery UI components page. It’s a terrific set of accessible widgets, and the code is available from Hans’ Github repository.

This demo was recorded using NVDA 2012.2 beta and Firefox 12.

captions
Using tabbed interfaces with a screen reader

5 comments on “Using tabbed interfaces with a screen reader”

Skip to Post a comment
  1. Comment by Sam

    One key point in creating interactive tabs is that visually-conveyed selection state needs to be communicated nonvisually. This means that the aria-selected=true property must be set on the currently active tab. Unfortunately this property is not supported in IE but is supported in Firefox. In the working tab implementation we have at http://amp.ssbbartgroup.com, aira-selected=true doesn’t work on IE so selection state is never announced, whereas it does work in FF but ar-hidden=true is not supported, resulting in double speak because of the off-screen text we have included to support progressive enhancement for screen readers which do not support ARIA.

  2. Comment by buckthorn

    what makes tabs such a special case if the html behind them is similar to other navigation menus (and just as accessible and usable) ? Aren’t tabs basically a navigation menu (e.g., an unordered list of links), but with different css?

  3. Comment by Léonie Watson

    Thanks for your question Buckthorn.

    It doesn’t seem to matter too much whether the tabs are marked up as links or not. What seems to matter is the way you give focus to one of them.

    That said, I’m not sure it makes sense to mix up links and tabs?

    A link traditionally goes from page A to page B, or from one part of page A to another. A tab exchanges one piece of Page A content for another.

    Thinking out loud here.

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.