In a tabs component following the WAI-ARIA Authoring Practices, how should the keyboard move between tabs and into the panel, and why?

## The model: one widget, one stop A **composite widget** is a control made of several focusable parts that the keyboard treats as a single stop. A tab list is the canonical example. Instead of each tab being its own stop in the **Tab sequence** (the order focus follows when the user presses Tab), the whole tab list takes one stop, and arrow keys move *within* it. ## The keyboard contract from the Authoring Practices | Key | Behaviour in the tabs pattern | |---|---| | **Tab** (entering) | Focus lands on the **active** tab | | **Tab** (inside the list) | Focus leaves the list to the next element in the Tab sequence — the tab panel, unless the first meaningful element inside it is focusable | | **Right Arrow** (horizontal) | Next tab; from the **last** tab, wraps to the **first** | | **Left Arrow** (horizontal) | Previous tab; from the **first** tab, wraps to the **last** | | **Down / Up Arrow** (vertical) | Behave as Right / Left do in a horizontal list | | **Home / End** (optional) | First / last tab | | **Space / Enter** | Activates the focused tab if it was not activated automatically on focus | | **Delete** (optional) | Closes the current tab, where tabs can be closed | Two details are easy to miss: - In a **horizontal** list the guide says the widget does **not** listen for Up and Down Arrow, so those keys keep their normal page-scrolling behaviour. - When the panel contains no focusable element, or its first content is not focusable, the **panel itself** is made focusable so that Tab has somewhere meaningful to go. ## Why this model and not Tab through every tab 1. **Cost of passing through.** A keyboard user who wants to reach the content after the tabs presses Tab once to pass a six-tab list, instead of six times. 2. **Predictability.** Arrow keys inside and Tab to leave is the same model the Authoring Practices use for other composites such as radio groups, menus and toolbars, so one lesson serves many widgets. 3. **A clear place to land.** Arriving on the *active* tab tells the user which panel is showing now. 4. **Wrapping** makes the list feel continuous and saves travel from one end to the other. ## Worked example: a library catalog's account page A member's account page has tabs for Loans, Holds, Fines and Reading history, with Holds active. A keyboard user tabs in and lands on Holds; Right Arrow moves to Fines, Right again to Reading history, Right again wraps to Loans. Tab then leaves the list. If the tabs activate automatically, the Loans panel is already showing and focus moves into it; in manual activation the Holds panel is still displayed, so Tab moves into Holds unless the user first presses Space or Enter on Loans. ## Beyond the web On native mobile, touch users tap tabs directly and screen-reader users swipe through elements one at a time, so the arrow contract matters mainly when a **hardware keyboard** is attached or on desktop platforms. A design system that ships to several platforms should still specify the model — one stop for the list, arrows between tabs, Tab to the panel — and let each platform's component express it with its own focus mechanism. ## Common defects to check in review - Every tab is a **separate Tab stop**, and arrows do nothing. - Arrows move focus but **stop dead** at the ends instead of wrapping. - Tab from the list jumps **past the panel** to the next section. - A horizontal list **swallows Up and Down**, breaking page scrolling. - Entering the list lands on the **first** tab rather than the active one.