Keyboard navigation in composite widgets: roving tabindex, arrow keys and Escape

What it is

The APG keyboard-interface guide describes the convention shared by desktop platforms: Tab and Shift+Tab move focus from one UI component to the next, while other keys, primarily the arrow keys, move focus inside a component that contains several focusable elements. A radio group is the native example: one radio button is in the Tab sequence, arrows move between options, Tab leaves the group. Custom composites (tab lists, toolbars, menus, grids, trees, listboxes) should behave the same way, so a twenty-item toolbar costs one Tab press, not twenty.

The guide names two implementation strategies. With a roving tabindex, exactly one item has tabindex="0" and all others tabindex="-1"; arrow-key handlers move DOM focus to the next item and swap the values, so that returning to the component later lands on the last used item. With aria-activedescendant, DOM focus stays on the container and the attribute points at the item that is "virtually" focused, which suits comboboxes, where focus must stay in the text field.

Why it matters

Users who cannot use a pointer depend on these conventions to predict what a key will do. WCAG 2.1.2 (No Keyboard Trap, level A) requires that focus moved into a component with the keyboard can be moved out again with the keyboard alone, and that any exit needing more than unmodified arrow or Tab keys or other standard methods is explained to the user.

How to apply

• Give each composite one Tab stop and move within it with arrow keys; the individual APG patterns add Home and End and, for listboxes, menus and trees, first-character navigation. Follow the pattern for the widget: a horizontal tab list uses Left/Right, a vertical menu Up/Down, a grid all four.
• Escape closes transient surfaces: the APG dialog pattern lists Escape as the key that closes the dialog, and the menu button and combobox patterns use it to close their popups. Also close on focus leaving the surface.
• Enter and Space activate; the guide advises against binding modifier keys with Tab, Enter, Space or Escape, which belong to the platform.
• Keep the visual focus indicator moving with the roving index; a virtual focus via aria-activedescendant needs its own highlight.
• Decide whether selection follows focus (arrow keys select immediately, as in native radio groups) or is separate (Space selects); the guide discusses when each is appropriate.

Pitfalls

Setting tabindex="0" on every item makes Tab crawl through the whole widget. Removing the tabindex="0" item from the DOM (a deleted tab) leaves no Tab stop at all. Handlers that call preventDefault() on every key swallow browser shortcuts. Embedded editors that capture Tab must offer the documented exit.