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: those with automatic activation and those 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.

Typical usability problems with tabbed interfaces

Some keyboard users (especially blind users) encounter problems when operating tabbed interfaces. If it is built according to best practice recommendations, tabbing to it  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 onel. Web authors sometimes respond to that usability problem by making the individual tabs also selectable via the tab key ⇥ .

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.

1 Keyboard use: Content cannot be reached

Some tabbed interfaes only worl for mouse users. Keyboard users have no focus indication and cannot reach the tabs in the tablist to select 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 straigt 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.

Resources for tabbed interfaces

Best practice examples

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