In a component library, what keyboard contract should a tabs component implement per the WAI-ARIA Authoring Practices, and when should activation be manual?
answer
- one Tab stop for the whole list
- arrows move between tabs, and wrap
- Tab again reaches the panel
- selection following focus has a cost
- latency decides automatic or manual
basics
~20 sTab enters the list on the active tab and leaves it for the panel; arrow keys move between tabs and wrap. Activation follows focus only when panels appear without noticeable latency; otherwise Space or Enter activates.
solid answer
~50 sThe Authoring Practices tabs pattern makes the whole tab list **one Tab stop**: Tab moves focus onto the *active* tab, and Tab again leaves the list for the tab panel (or its first focusable content). Inside the list, Left and Right Arrow move between tabs and **wrap** from last to first; a vertical list uses Up and Down instead; Home and End are optional extras. With **automatic activation**, a tab's panel shows as soon as the tab receives focus; with **manual activation**, Space or Enter activates it. The pattern recommends automatic activation only when panels display without noticeable latency — so an accounting product's report tabs that each run a heavy query should be manual, or arrowing past three tabs fires three reports. A library implements this once, exposes activation mode as an option with a sensible default, and does not let consumers rewire the keys.
go deeper
Recall the core contract: one Tab stop on the active tab, arrows between tabs with wrapping, Tab again to the panel.
Explain automatic versus manual activation, why latency decides it, and how orientation changes which arrow keys the list handles.
Show how you would audit several products' hand-rolled tabs, replace them with one library implementation, and pick activation defaults per use.
Decide how strictly a library should lock keyboard contracts against consumer customisation, and how web contracts relate to native platforms' own conventions.
## Why a library owns the keyboard contract A **keyboard contract** is the set of keys a widget responds to and what each does. The WAI-ARIA **Authoring Practices** publish one per pattern, so that a person who has learned tabs in one product can operate tabs in every product. What the tabs *look like* and when to use them belongs to the component family's spec; **implementing the contract once, correctly, for every consumer** is the library's job. If each product team wires its own arrow keys, the system ships several subtly different tabs, and every bug must be fixed several times. ## The contract, key by key | Key | Where focus is | What happens | |---|---|---| | Tab | moving into the tab list | focus lands on the **active** tab, not the first | | Tab | on a tab | focus leaves the list, to the tab panel unless its first meaningful content is focusable | | Right Arrow | on a tab (horizontal) | next tab; from the last tab, wraps to the first | | Left Arrow | on a tab (horizontal) | previous tab; from the first, wraps to the last | | Down / Up Arrow | on a tab (vertical list) | behave as Right / Left | | Space or Enter | on a tab | activates it, if it was not activated on focus | | Home / End | on a tab | optional: first / last tab | | Delete | on a closable tab | optional: closes it and moves focus to a neighbouring tab | Two details are easy to miss: - A **horizontal** list does not handle Up and Down, so those keys keep scrolling the page even while focus is in the list. - Only **one** tab is in the page's Tab sequence at a time. The rest are reached with arrows. Libraries usually implement this with a shared **roving focus** utility, the same one a toolbar or a radio group uses. ## Automatic versus manual activation - **Automatic activation** — *selection follows focus*: arrowing onto a tab immediately shows its panel. - **Manual activation** — arrowing only moves focus; Space or Enter shows the panel. The pattern recommends automatic activation **as long as panels display without noticeable latency**, which usually means their content is preloaded. Otherwise every arrow press triggers a load, focus movement slows down, and a screen-reader user who is only reading the tab names waits at each one. In a small-business accounting product the two cases sit side by side: 1. **Invoice detail** — *Details*, *Activity*, *Attachments*. The data is already loaded with the invoice, so automatic activation is fast and saves a keystroke. 2. **Reports** — *Profit and loss*, *Balance sheet*, *Cash flow*. Each panel runs a report over the ledger. Automatic activation would start three expensive reports as a user arrows from the first tab to the fourth; manual activation lets them choose. Whichever mode is chosen, the pattern expects the active tab to expose its **selected** state and each panel to be labelled by its tab, so a screen-reader user always hears which panel is showing and which tab it belongs to. In manual mode this matters more, because focus and selection can sit on different tabs at the same moment. ## What the library exposes 1. **Activation mode as an option**, with a default and a documented rule for when to switch it — not a custom key-handler hook. 2. **Orientation as an option**, so the arrow keys change with it rather than being rewired by consumers. 3. **The roles and relationships built in**: the list, each tab and each panel are exposed to assistive technology with their roles, the selected state and the link from each tab to its panel, so consumers cannot forget them. 4. **Focus behaviour on close**, if tabs are closable, implemented once. What it does not expose is a way to remap the keys. A consumer who needs a different interaction probably needs a different pattern, not bent tabs. ## Native platforms This contract is the web's. Native mobile tab bars and segmented controls follow their platform's own focus and navigation conventions, and a cross-platform system should respect those rather than port arrow-key behaviour. What travels is the decision behind it: *one stop for the group, movement within it, and an explicit choice about whether selection follows focus.*
- Why does Tab land on the active tab rather than the first one?The active tab is where the user's context is: its panel is the one on screen. Landing there means one more Tab reaches the content they are looking at, and arrows move away from it only if they choose. Landing on the first tab would disconnect focus from the visible panel.
- A consumer asks the library for a hook to add Up and Down handling to horizontal tabs. How do you respond?Decline and ask what they need. The pattern deliberately leaves Up and Down alone on a horizontal list so they keep scrolling the page; adding them breaks a behaviour users rely on. If the layout is really vertical, the fix is the orientation option, which switches the arrow keys consistently.
saying these in an interview costs you the question
- Every tab should be a separate stop in the Tab sequence.
- Automatic activation is always better because it saves a keystroke.
- Home and End are required keys in the tabs pattern.
- Consumers should be able to remap the tab keys per product.
- Arrow keys should stop at the last tab rather than wrap.