What WAI-ARIA attributes and keyboard interactions make Tabs accessible?

WHAT THIS TESTS: Whether you can implement the W3C APG Tabs pattern correctly, including semantic roles, state management, keyboard roving focus, and the distinction between automatic and manual activation. Interviewers want to see that you treat accessibility as a contract with the browser and assistive technologies, not just a sprinkle of ARIA attributes.

A GOOD ANSWER COVERS: First, the three required roles: the container must have role tablist, each tab must have role tab, and each content container must have role tabpanel. Second, the relationships and states: each tab needs aria-selected set to true when active and false otherwise, plus aria-controls pointing to the id of its associated tabpanel. The tabpanel should have aria-labelledby referencing the id of its controlling tab. Third, keyboard interaction: Tab should move focus into the active tab and then out of the tablist to the tabpanel or its first focusable child. Inside the tablist, Left and Right Arrow keys should implement roving focus, cycling from the first tab to the last and vice versa. If the tablist is vertical, use Up and Down Arrow instead, and do not trap those keys when horizontal so scrolling still works. Fourth, activation behavior: automatic activation on focus is recommended when panels preload instantly, while manual activation requires Space or Enter to show the panel. Optional enhancements include Home and End to jump to the first or last tab, Delete to close a tab, and Shift plus F10 for an associated popup menu.

COMMON WRONG ANSWERS: Treating tabs as button or link elements without role tab, which breaks the screen-reader mapping. Relying solely on the Tab key to navigate between tabs instead of arrow keys, which forces keyboard users through every tab to reach the panel. Forgetting to toggle aria-selected, leaving all tabs selected or none selected. Omitting aria-controls or aria-labelledby, which severs the programmatic link between tab and panel. Implementing Up and Down Arrow behavior on horizontal tabs, which blocks normal page scrolling. Using display none or visibility hidden on inactive panels without also ensuring focus does not land inside hidden content.

LIKELY FOLLOW-UPS: How would you handle lazy-loaded tab panels with automatic activation? When would you choose manual activation over automatic? How do you manage focus after deleting a tab? How would you support nested tabs or a responsive design that collapses into a different pattern? What is your testing strategy with screen readers and keyboard-only navigation?

ONE CONCRETE EXAMPLE: Imagine a horizontal settings page with three tabs labeled Account, Privacy, and Notifications. The Account tab has role tab, aria-selected true, and aria-controls set to account-panel. The ul or div wrapping the tabs has role tablist. The div containing Account settings has role tabpanel and aria-labelledby set to the Account tab id. Pressing Tab from the previous page element lands focus on the active Account tab. Pressing Right Arrow moves focus to Privacy but does not activate it if you chose manual activation; pressing Space then swaps the visible panel and updates aria-selected on Privacy while setting it to false on Account. Pressing Tab again moves focus directly into the Privacy panel or its first focusable input, not back to the tab list.

Source: W3C ARIA Authoring Practices Guide (APG) Tabs Pattern