Interactive demo
Try keyboard navigation in both modes. In AFTER mode, only the active tab is in the Tab order (roving tabindex), and arrow keys move focus within the tab row.
Profile
Click a “tab” to change this panel. Arrow keys do nothing, and assistive tech may not treat this as tabs.
- No
role="tablist"/role="tab"/role="tabpanel"semantics. - No programmatic link between “tabs” and the panel (e.g.,
aria-controls/aria-labelledby). - No arrow-key navigation; focus order is just “four buttons, then content”.
Profile
Editable fields belong inside the active panel. Press Tab to move into the panel content.
Security
Panels should be hidden with hidden (or equivalent) so they’re removed from the accessibility tree.
Billing
A good tabs pattern keeps focus predictable: arrows move within tabs, and Tab moves forward into the active panel.
Notifications
In manual activation mode, moving focus with arrows does not switch panels until Enter/Space.
Takeaways
- Use explicit roles:
tablist→tab→tabpanel. - Link tabs and panels with
aria-controls+aria-labelledby. - Use roving
tabindexso only one tab is in the tab order. - Support ←/→ (or ↑/↓ for vertical), plus Home/End.
- Hide inactive panels with
hiddento avoid “ghost focus”.
Companion note: Tabs checklist.