ARIA roles and keyboard nav for a Tabs component

WHAT THIS TESTS This verifies you can implement the established tabs pattern correctly, including the subtle distinction between Tab-key movement and arrow-key movement.

A GOOD ANSWER COVERS Structure and roles. A container with role tablist holds elements with role tab. Each tab has aria-selected true on the active one and false on the rest, and aria-controls referencing the id of its panel. Each panel has role tabpanel and aria-labelledby pointing back to its tab, plus tabindex 0 if it has no focusable children so it is reachable. Keyboard model. The tablist is a single Tab stop using roving tabindex: only the active tab has tabindex 0, the others minus 1. Pressing Tab from outside lands on the active tab; Left and Right arrows (or Up and Down for vertical) move selection and focus between tabs; Home and End jump to first and last. Pressing Tab again from the tablist moves into the active tabpanel, not to the next tab. Decide between automatic activation (selecting on arrow) and manual activation (arrow moves focus, Enter or Space activates), the latter being better when panels are expensive to load.

COMMON WRONG ANSWERS Making each tab its own Tab stop so keyboard users tab through all tabs. Omitting aria-selected or the aria-controls and aria-labelledby links. Forgetting roving tabindex. Using arrow keys for nothing and Tab for everything, the opposite of the pattern.

LIKELY FOLLOW-UPS Automatic versus manual activation trade-offs. How do you handle vertical tabs. What if a panel has no focusable content.

ONE CONCRETE EXAMPLE Three tabs share one tablist; Tab focuses the selected tab, Right arrow moves to the next and updates aria-selected, and a second Tab press jumps into the visible tabpanel, so a keyboard user navigates tabs with arrows and content with Tab as the pattern intends.