5. Interactive WAI-ARIA (Intermediate)
Tab panels, much like accordions, are often used to conserve space and reduce scrolling. They are typically made up of a tablist that contains a series of tabs, each tab controlling the display of a panel. As each tab is activated, its associated panel is displayed and other panels are hidden. When a tab is selected, it is highlighted to indicate which tab and panel are active.
WAI-ARIA roles, states, and properties used in a tab panel
- tabindex = [0 | -1]
- aria-controls=”[panel id]”
In our case, we are generating the tabs for each child
<div> defined in the HTML, though tabs and tab panels could be static HTML. The tablist is made up of a
<ul> and child
<li> elements. We assign
role="tablist" to the
<ul> to remove its list semantics and replace it with tab panel semantics.
Next, we add WAI-ARIA to the panels, assigning
role="tabpanel" to each of the original
<div> elements, hide them by default with
aria-hidden="true", and finally adding
tabindex="0" to make the panels keyboard focusable.
The tabs themselves are now defined, replacing the list item semantics with tab semantics adding
role="tab" to each of the
<li> elements generated. We also need to define which tab controls which tabpanel, dynamically generating
aria-controls="[panel_id]" for each of the tabs.
When a tab is selected, we want to remove selection from other tabs with
aria-selected="false", and remove keyboard access temporarily by assigning
tabindex="-1" to the unselected tabs, so that that tabpanel becomes next in the tab order, and users can navigate directly from the tab to the panel without having to pass through the other tabs in the tablist.
Likewise, when a tab is selected we assign
aria-selected="true" so screen readers announce the selected tab, we add
tabindex="0" as the roving tabindex to make that tab focusable.
As the tabs change, hide all the panels with
aria-hidden="true" so screen readers do not see them, then open the panel the current tab controls with
aria-hidden="false" so screen readers can see the active panel. These are added to the end of the
Adding Keyboard Operability
W3C describes authoring practices for tab panel keyboard interactions as follows.
Keyboard Interaction for Tab Panels
For the tab list:
- Tab: When focus moves into the tab list, places focus on the active
tabelement. When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.
- When focus is on a tab element in a horizontal tab list:
- Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
- Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
- When focus is on a tab in a tablist with either horizontal or vertical orientation:
- Space or Enter: Activates the tab if it was not activated automatically on focus.
- Home (Optional): Moves focus to the first tab
- End (Optional): Moves focus to the last tab.
- Shift + F10: If the tab has an associated pop-up menu, opens the menu.
- Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel. If any tabs remain, sets focus to the tab following the tab that was closed and activates the newly focused tab. Alternatively, or in addition, the delete function is available in a context menu.
- It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency. This typically requires tab panel content to be preloaded. Otherwise, automatic activation slows focus movement, which significantly hampers users’ ability to navigate efficiently across the tab list. For additional guidance, see 5.4 Deciding When to Make Selection Automatically Follow Focus.
- If the tabs in a tab list are arranged vertically:
- Down Arrow performs as Right Arrow is described above.
- Up Arrow performs as Left Arrow is described above.
- If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.
As usual, the tab panel needs to be keyboard operable to be accessible to screen readers. The
onKeyDown() function is added to the functions, to add arrow key navigation between tabs, and between tabs and panels. Tab navigation and Enter keys are enabled by default and do not need to be defined here.
onKeyDown function is then added to each tab, referenced with jQuery’s
.on('keydown') function, added to the
Now, with keyboard access and WAI-ARIA added to define the semantics of the tab panel, it should be fully functional for screen readers.
Accessible Tab Panel in Action
Watch the following video showing ChromeVox interacting with a tab panel. The Tab key is used to navigate into the tab panel and to the first tab. The arrow keys are used to move between tabs and, when on a tab, the Tab key is used to navigate to the associated panel. While on a panel, Shift + Tab is used to return to the tablist. There might also be Up and Down arrows enabled to move between tabs and panels, though we have not enabled them here. Aim to have the tab panel you update in the activity coming up on the next page operate and announce itself like the one in the video.
Video: Accessible Tab Panel