ARIA roles for an accessible tab interface
Correct ARIA wiring for tabs.
tablist contains tabs, each tab uses aria-selected and aria-controls, panels use role tabpanel with aria-labelledby, and arrow keys move between tabs.
making every tab a Tab stop.
What's really being asked
The question checks whether you can build the WAI-ARIA tabs pattern correctly, both the role and state wiring and the expected keyboard interaction, which together let assistive tech describe the widget and let keyboard users operate it.
The full answer
The structure uses three roles. A container element gets role tablist. Each clickable tab gets role tab. Each content region gets role tabpanel. State and relationships: the active tab carries aria-selected true and the others aria-selected false; each tab uses aria-controls to reference the id of the panel it shows; each panel uses aria-labelledby to reference the id of its tab, giving the panel an accessible name. The tablist should have an accessible name via aria-label or aria-labelledby. Keyboard behavior is critical: a roving tabindex keeps only the selected tab focusable with Tab, and Left and Right arrows move between tabs, with Home and End jumping to first and last. Tab then moves from the tab to its panel.
The mistakes people make
Making every tab tabindex 0 forces users to Tab through all tabs, defeating the arrow key model. Omitting aria-selected leaves screen readers unable to announce the current tab. Forgetting aria-controls and aria-labelledby breaks the announced relationship between tab and panel. Using clicks only with no keyboard support excludes keyboard users.
What usually comes next
Should tabs activate automatically on focus or only on Enter? Automatic suits cheap panels; manual suits expensive ones. How do you handle vertical tabs with aria-orientation? How does focus move into the panel? What if a panel has no focusable content?
A concrete example
A settings page has Profile, Security, and Billing tabs. The tablist is labeled Settings sections. Profile is selected, so its tab has aria-selected true and aria-controls the profile panel id, and that panel has aria-labelledby the Profile tab id. Right arrow moves focus to Security; pressing Enter shows the Security panel, and a screen reader announces Security tab selected.
Interview question
In an accessible tab widget, why is a roving tabindex preferred over giving every tab tabindex 0?
- a.It improves rendering performance of the panels
- b.It is required for aria-selected to function correctly
- c.It lets the Tab key cycle through all tabs quickly
- d.It keeps only the active tab in the Tab order, with arrows moving between tabsCorrect
Why? this is the answer
The tabs pattern expects Tab to enter and leave the tablist once, while arrow keys move among tabs; a roving tabindex achieves this. Making every tab tabindex 0 forces tedious tabbing and violates the pattern.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
- #accessibility
- #aria
- #tabs
- #keyboard-navigation
- #wai-aria
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles