Tab order should match visual reading order

What it is

When keyboard users move among focusable controls with Tab (and Shift+Tab), the sequence should match reading order on the screen: typically left-to-right and top-to-bottom, or the corresponding order in a right-to-left document. If the visual next step is the button on the right, but Tab jumps into a control on the card below or the card above, the spatial map and the focus map have split in two.

Why it happens

Focus order follows the document tree by default; visual order is decided by layout. Floats, absolute positioning, Flex/Grid order, and DOM written in a footer but painted in a header fork the two sequences. A positive tabindex pulls a control out of natural order into a first-pass queue of all positive values, making the fork harder to predict. During a scan, people already expect the next control’s place; if focus lands outside the field of view or on a visually earlier control, they must search “where is focus now?”, and the time spent finding focus eats the keyboard path’s advantage. Consistency is not cosmetics. It lets spatial expectation keep predicting the next hop.

Studying it

Have keyboard users complete form fill, dialog confirmation, and multi-column toolbar tasks. Record each hop’s landing against their report of “what should be next.” Independent variables include whether DOM order matches visual order, use of positive tabindex, column count, and reading direction; dependent measures include lost-focus incidents, completion time, and hops that land outside the viewport. Checking only “every control is reachable by Tab” writes order errors down as passes. Overlay a visual index map on a Tab index map.

Where it stops holding

Tables and spreadsheet-like widgets often use arrow keys inside cells, and Tab may mean “next field” or “leave the grid”; that is an in-widget convention, not a demand that the whole page walk a grid. Dynamically inserted controls (a field that appears after a failed check) temporarily scramble the existing sequence; decide whether to insert at the visual counterpart or at the end. In right-to-left UIs, reading order itself is reversed; scoring them with an LTR left-to-right walk will mis-fail them.

Applying it

• Order the DOM in visual reading order. Avoid CSS order or absolute positioning that moves focusable controls visually off their tree order.
• Do not reshape a whole page with positive tabindex; change the DOM instead of inserting a second sequence.
• In acceptance tests, number each hop on a screenshot against the design’s reading order. Jumps to a previous card, skipped columns, or focus leaving the viewport fail the order check.

Related

• Same group: C6.05.2 Focus must be visible · C6.05.3 Overlays must capture focus and return it on close · C6.05.4 Hidden elements must not remain in the focus sequence
• Adjacent: C6.22 Focus order and keyboard navigation · C6.13 Text selection and caret placement
• Search: tab order · reading order · focus sequence