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>

<div role=”tabpanel”>


<div role=”tabpanel”>


<div role=”tabpanel”>


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.

Using tabbed interfaces with a screen reader

7 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, 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.

  4. Comment by Christiane

    Hi Leonie,
    Thank you for this article. I am currently implementing a tabpanel and have questions about the keyboard implementation. Is it still common to use the arrow keys to navigate through the tabs? A friend told me that it got old fashioned and that a navigation only with the tab key is possible. Is it though? I can imagine that it could be in-convenient, because you have to tab through the whole content.
    My second question is: how do you access the content (e.g. a paragraph) of an activated tab with a screen reader? Does the content need to get an attribute tabindex=”0″, to make it accessible with the tab key, or can you use the arrow keys, like you can do for selecting a value in a select form element?

    1. Comment by Léonie Watson

      The arrow keys are still recommended. This mimics the keyboard interaction for tabs in software applications, the origin of the design pattern we use on the web. It also means that the set of tabs represents a single tab stop, which is much more convenient for keyboard users who want to bypass the tabs and move to the content beneath as quickly as possible.

      You can use tabindex=0 on the tabpanel container, yes. You can also use aria-controls (to associate the tab with the corresponding tabpanel), but note that only the Jaws screen reader supports this attribute and provides the expected keyboard shortcut for moving focus.

Leave a reply to Christiane Cancel your reply

Will not be published

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