Composite widgets typically move among internals with arrow keys; Tab only enters and leaves

What it is

Toolbars, radio groups, trees, grids, and tab lists pack many selectable units into one composite widget. The keyboard convention is that Tab delivers focus into or out of the whole component, and arrow keys move among units inside it. If every icon and every radio is in the Tab sequence, crossing a toolbar takes a dozen presses. Arrows own the component's two-dimensional or linear space; Tab jumps between components.

Why it happens

The Tab sequence is a document-level linked list, good for advancing among controls. Internals often have rows, tree levels, or mutually exclusive options that a one-dimensional list cannot express as “right is the next tool, down is the next row.” Arrow keys hand that local space to the widget's own state machine: left/right in a toolbar, up/down in a menu or tree, Home/End to the ends. While focus moves inside, Tab stays at the widget grain and does not consume a Tab stop per cell. The cost is that users must know to switch to arrows after entry; people who only Tab may think the widget has a single operable point.

Studying it

Have keyboard users complete tasks such as “select the third toolbar item, then the main content,” comparing every child in the Tab order versus Tab-into-group plus arrows inside. Dependent measures are keystroke count, time to cross the widget, and whether remaining children were thought unreachable. Report widget types separately (toolbar, grid, tree); two-dimensional grids gain the most. Measuring only eventual arrival hides keystroke explosion.

Where it stops holding

A single-line field uses arrows to move the caret—that is text editing, not composite navigation; do not rebind arrows to “next control.” Touch has no Tab; internal movement becomes swipe or direct tap. Tiny radio groups of two items can afford to stay in the Tab sequence. Game UI often gives all navigation to arrows and discards Tab, reversing the convention. Screen-reader browse mode traverses with its own keys and may intercept application arrows.

Applying it

• Toolbars, tab lists, grids: one Tab stop to enter, arrows to move among children, Tab again to leave for the next control.
• When the widget takes focus, a visible cue should say that arrows now apply, so it does not look like a single item.
• Do not use arrows inside a text field to switch controls; leave that path to the caret.
• Verify keyboard-only from the top of the page to the primary button, crossing a toolbar of at least five items, and count Tabs. If count grows linearly with tool count, internal navigation has not been taken out of the Tab sequence.

Related

• Same group: C6.22.2 Skip links let keyboard users bypass repeating navigation and reach main content · C6.22.3 Roving tabindex keeps only one composite member in the Tab sequence; the rest move by arrows · C6.22.4 Keyboard paths must be functionally equivalent to mouse-reachable paths, not visual presentation only
• Adjacent: C6.05 Focus order · C6.03 Shortcut systems
• Search: composite widget · arrow key navigation · toolbar keyboard