Focus order must match visual order

What it is

The path the eye takes across a screen and the path focus takes from control to control are two coordinate systems. Focus order requires those coordinates to coincide: the next operable object seen left-to-right, top-to-bottom is the object Tab lands on. When they diverge, sighted users lose the spatial model; users who are not looking at the layout treat “next” as the wrong stage of the task.

This leaf does not care whether an overlay opens or a trap can be left. It cares about one thing: among the controls visible on this screen, is the keyboard queue the same path the eye takes.

Why it happens

Visual reading in a horizontal writing system advances by row. People expect “next” from that spatial model. The keyboard has no space, only a sequence. The sequence defaults to document source order. CSS that swaps visual position with flex or grid, reorders with order, or pins a button with absolute positioning leaves source order behind. Focus then jumps “forward” or back into a region already seen.

A tabindex greater than 0 inserts a third queue: all positive integers first, then the rest in source order. Pages start leaping to the footer before the body — a path the eye cannot predict. Positive tabindex is not an accelerator; it is a second coordinate system with no visual counterpart.

Studying it

Band the page visually, draw the expected sequence from the top left, then Tab only, marking actual landings on the same figure. Score mismatches as skipped indices: which visual number did focus actually reach.

Independent variables: layout tactic (source order, flex swap, absolute positioning, positive tabindex). Dependent variables: mismatch count, reports of “I thought I was here”.

Screen-reader browse-mode order is a different sequence, driven by structure. Do not collapse it with Tab order into one measurement. This leaf measures focus sequence against vision.

Where it stops holding

In right-to-left scripts, “match visual order” means that language’s reading direction, not a forced left-to-right. Inside grids and toolbars that roam with arrows, Tab only enters and leaves the widget; inner order must still follow the cells’ visual arrangement. Placing a “skip this repeated block” entry at the front of the sequence is a different purpose, not an order bug. Print styles or visually hidden but still focusable items make the two coordinates permanently unalignable — that is a hiding-strategy problem, not something extra tabindex can patch.

Applying it

• Write the DOM in visual reading order, then style it. Do not build a separate keyboard path with CSS order or positive tabindex.
• Reserve tabindex="0" for custom controls that must join the sequence. Ban tabindex="1" and above.
• How to check: Tab from the address bar into the page and let the eye follow focus. If focus lands in a region not yet reached visually, or already passed, this criterion fails.

Related

• Same group: J3.02.2 Overlays must capture focus and remain escapable · J3.02.3 An inescapable focus trap is a blocking defect · J3.02.4 Dynamically inserted content desynchronizes focus unless it is moved on purpose · J3.02.5 Focus order must update as content expands or hides · J3.02.6 Focus-order failures are found by walking with a keyboard, not by inspecting source order · J3.02.7 Nested overlays that each capture focus can deadlock
• Nearby: J2.08 Reading order · J2.06 Focus visibility · J3.01 Keyboard access
• Search terms: focus order · tab order · source order