Tabbed interfaces

Tabbed interfaces can stack up information, like in a stack of index cards. Selecting a tab shows the corresponding card (the tab panel).

The tabs in a tabbed interface are usually arranged horizontally, sometimes vertically.

A tabbed interface in action

The following video shows a typical tabbed interface in action. The screen reader NVDA is turned on to show what non-visual users experience.

Video description

On the page in the sas.com website, a tabbed interface shows different data visualisations.

  • The user tabs to the first tab in the tab list, which announces "Registerkarte" (German for tab)
  • The screen reader then announces the name of the tab ("Net Operating Income") as well as the role (tab) and the state and the total number of tabs in the tablist.
  • The user uses the right arrow key → to focus the next tab.
  • The user hits enter ENTER to select the tab and show the corresponding tab panel.

Different types of tabbed interfaces

There are two types of tabbed interfaces: tabs with automatic activation and tabs with manual activation. When the tabbed interface has automatic activation, focusing a tab immediately shows the corresponding tab panel. On a tabbed interface with manual activation, the user has to select the tab in focus (by hitting the space bar or ENTER) to show the corresponding tab panel.

There is another important distinction. You can build tabbed interfaces according to the ARIA Authoring practices so that they behave like tab widgets in applications. In this case, tabs are focused with the arrow key, not the tab key. Or you can choose to implement tabs as a list of links (or buttons) which can be focused by the tab key. This is still the more common keyboard behaviour of tabbed interfaces on the web today.

Typical usability problems with tabbed interfaces

Tabbed interfaces are difficult for many users.

Realising that arrow keys should be used for focusing tabs

When keyboard users encounter tabbed interfaces built according to the Aria Authoring practices 1.1, tabbing to the tablist focuses by default the first (or the last previously selected) tab. Focusing other tabs is then done via the arrow keys ← →. Users may not realise that they need to switch to arrow keys, especially when a tabbed interface does not look like one. Web authors sometimes respond to that usability problem by making the individual tabs also selectable via the tab key ⇥.

However, implementing tabbing to tabs can also cause a problem when the tabpanel corresponding to the currently selected tab has focusable elements. These would then not be the next focusable thing immediately after the selected tab. You'd have to tab through the other tabs in the tablist before getting to the tabpanel. Compare Heydon Pickering's page on tabbed interfaces.

Screen reader users and tab panels

When a screen reader encounters a tablist element (or rather, the focus is moved inside a tablist element) it goes into forms/application mode, a mode in which screen reader navigation (with arrow keys / short cut keys) is unavailable.

This makes a tabpanel element with no focusable elements more difficult to discover by a screen reader user because they have to manually force the screen reader out of forms/application mode once they have activated a tab.

This is why the idea of putting tabindex="0" on a tabpanel element has been floated and can be acceptable in this particular context (it is not ideal, because it represents an element which is focusable but has no interactive properties).

The solution to use JavaScript to send focus to the tabpanel as soon as the corresponding tab is focused is not recommended. This is like having an onchange event in a dropdown that automatically sends focus elsewhere. Imagine that the tab the user wants to activate is the last in a list of 5 tabs. You don't want the user to have to press the arrow key, then shift-tab to get back to the tablist, and repeat this four times to get to the desired tab.

Understanding the screen reader instructions for interacting with tabbed interfaces

As Alastair Campbell has pointed out, usability testing shows that many non-expert screenreader users are not familar with the ARIA tab panel construct (because implementations conforming to the spec are quite rare in published web content). Some users confuse the tab (the element with role=tab") with the action of tabbing (using the tab key), which in conforming implementations is not what takes them to the next tab.

Potentially missing content in hidden panels

If the tabbed interface is not marked up properly according to WAI ARIA best practices, blind users may not realise what type of content they have encountered and may bypass content in the currently hidden panels. The same problem can occur if users work on older systems with older browsers or older assistive technology where the tablist and tab roles may not be exposed.

Bypassing visible panel content

Another problem is that screen reader users may bypass the content of the visible panel, especially if there are no focusable elements in it. When they enter the tablist by arrowing / reading content, the screen reader switches to forms mode. For reading the panel content, users have to switch back to reading mode. JAWS announces a shortcut for jumping to the panel, other Screenreaders like NVDA and VoiceOver don't. So tabbing on would take users to the first interactive content after the panel. This is why some authors recommend making the panel itself focusable. A simple way would be using tabindex="0" on the panel, but many advise against making non-interactive elements receive keyboard focus via the tab key. An alternative is use tabindex="-1" on the panel and programmatically move the focus to it. Heydon Pickering's Tabbed interfaces recommends implementing the down arrow key for moving focus to the panel.

Linear reading problems

Users that read content linearly from top to bottom in the browse mode of a screen reader or with theor own CSS will usually first see the tabs in one section, followed by the panel content below, in a separate section. This can make it difficult to associate tabs and corresponding panel content. tabs that are implemented as skip links and proper headings in panels can alleviate this problem.

Examples

The following examples show typical usability problems when interacting with tabbed interfaces.

1 Keyboard use: Content cannot be reached

Some tabbed interfaces only work for mouse users. Keyboard users have no focus indication and cannot reach the tabs in the tablist to select any other than the currently selected tab.

Video description

The tab panel on the main site of bahn.de is not keyboard accessible.

  • The keyboard user activates the force focus bookmarklet to be able to see the focus
  • The user tabs through the main navigation items and reaches the login link
  • The focus then jumps straight to the contents of Tab "Reiseauskunft", bypassing the tablist

2 Keyboard & screen reader use: Unexpected keyboard behaviour

When a navigation menu has been implemented as a tab panel but looks like a regular navigation menu, keyboard users will expect to be able to use the tab key ⇥ to traverse the menu items. But this wilL not work if the tab panel supports the keyboard behaviour for this component. Users will have to use the arrow keys → ← instead.

Video description

The test shows the behaviour when accessing the main navigation menu familyreunion-syria.diplo.de in the Firefox Browser with the screen reader NVDA turned on, using the keyboard.

  • When tabbing into the main navigation menu, the first menu item Startseite is focused.
  • Tabbing further to focus the next menu item fails. Instead, the focus moves to the content underneath.
  • The user moves the focus back to the main menu item and tries the right arrow key →  instead.
  • But now the screen reader reads the single letters of the link text.

3 Screen reader use, cognitive issues: Understanding the structure of a tabbed interface

For screen reader users of mobile operating systems, even properly marked-up tabbed interfaces can be difficult to understand. Without keyboard, there is no distinct focus operation and no difference between the tab key ⇥ and arrow keys ← → — all elements are swiped to. Roles may not be noticed or misunderstood.

Video description

The test shows a blind user with some residual sight exploring the Tabs pattern of the GOV.UK Design System. on his own iPhone. The user is very familiar with his phone, but does not use some of the features the screen reader VoiceOver offers.

  • The user swipes through the tabs
  • He reaches the content, but does not notice the break between tab list and tab panel
  • He somehow associates the 3 columns of the tables in the panel with the 4 tabs.
  • Asked whether he knows where he is, he is not certain; he then offers that he is on tab "Cases closed" (there is no such tab)
  • Moving backwards and forwards, the user does not notice the distinction between the tabs and the h2 headings of the panels
  • The user does not realise that in order to show a panel, he has to activate the corresponding tab
  • He works out his own system of interpreting the content structure by counting, a system which does not reflect the actual structure.

Accessibility tips for tabbed interfaces

Tabbed interfaces built according to WAI-ARIA Authoring practices

  • Show panels on automatic or manual activation. Consider wether your panels should automatically appear when users traverse the tabs, or only appear after manual activation of a tab.
  • Use the appropriate roles (tablist, tab, tabpanel) and attributes, especially aria-selected to reflect the state of the current tab. It does not do any harm to also use aria-controls to point to the id of the corresponding panel, even though aria-controls is currently poorly supported.
  • Use role="presentation" on list elements (li) when assigning role="tab" to the links inside the list elements. This removes the list semantics which only gets in the way when using the ARIA roles for tabbed interfaces.
  • Implement keyboard behaviour. Left/right arrow navigation for traversing the tablist. The focus should circulate in the tablist. If your tabs are links, consider including a JavaScript event key handler for the space key so pressing space will also select tabs.
  • On the panel, use the aria-labelledby attribute to reference the respective tabs. When screen reader users enter the panel, the tab name will then be voiced as the label of the panel, so it is clear that the panel content to follow belongs to that tab.
  • Make the panel content focusable. If there are no focusable elements in the panel, or if there is important content before the first focusable element, consider putting tabindex="0" on the panel. Another approach is to use the down arrow to move focus to the panel. When the tabbed interface is implemente in a way that the user has to press the enter key to activate the tab,  a script can set the focus to the start of the corresponding panel.</p>
  • Give instructions. Some authors recommend using a visible hint inserted above the tablist when it receives focus, such as "Use arrow keys to select tabs". This text can be linked to the tablist via aria-describedby.

Tabbed interfaces where tabs can be tabbed to

In contrast to ARIA tabs, tabbed interfaces are based on a (usually horizontally arranged) list of links or buttons to ensure that users can traverse the tabs by tabbing instead of arrow keys.

  • Use appropriate ARIA roles (tablist, tab, tabpanel), even though keyboard handling deviates from the spec.
  • If panels have interactive content, choose manual activation instead of automatic activation. When you show panels on focus (automatic activation), you would be unable to directly enter interactive content in the panel unless you place each panel directly after its tab (in the source code order). In that case, you would need to tab through all interactive content before reaching the next tab.
  • On activation of a tab link or button, move the focus to the panel via an in-page link or a script to the content element at the start of the panel. If this is non-interactive content like a heading, support across browsers and assistive technologies is improved when you set tabindex="-1" on this element.
  • Set an attribute on the tab to reflect the current state (i.e., communicate whether the corresponding panel is currently visible or hidden). On links, you cannot use aria-selected, but you can use it on buttons or links that you have given a role="tab".

Resources for tabbed interfaces

Best practice examples

Articles about pros and cons of tabs, and best implementation approach