Focus order must match visual order
Aliases: tab order · keyboard sequence · reading order
What it is
When a keyboard user Tabs (or the platform equivalent) through a form, the sequence of fields focus visits should be the sequence the eye scans top-to-bottom along the reading direction. Match is not “every control is focusable”—that is reachability—and not whether Enter submits. If CSS paints Email above Name while the DOM or a positive tabindex lands on Name first, order is broken. Mobile “Next” is another channel, but if desktop Tab is already scrambled, the same DOM usually scrambles the mobile jump too.
Why it happens
Visual order is the spatial model people use for “what is the next blank.” Tab order is the keyboard’s actual path. When they disagree, the hand arrives at a field the eye is not ready for, or skips the field the eye is on. A second layer is layout detached from document flow. Absolute positioning, a grid that paints later nodes first, a floating Help injected into the Tab chain, a positive tabindex that drops a footer link between fields—all create a path the eye cannot see. Two-column desktop forms are especially risky: the eye reads down the left column then the right, while the DOM walks left-right by row, or the reverse. The cost is not one extra Tab. It is answers in the wrong box, because people think focus is still on the item they were looking at. Screen-reader users follow the same focus sequence; visual misalignment is an entirely wrong spoken story for them.
Studying it
Number the visual order, number the Tab order, count inversions. Then have people fill blind on the keyboard (ignore the focus ring, watch the fields) and count wrong-column answers.
Independent variables: layout (single column / two column / absolutely positioned help), whether positive tabindex is used, whether DOM order matches paint order.
Dependent variables: inversions between Tab and visual sequences, answers in the wrong field, keypresses to finish a group.
Do not only test “can I reach Submit.” Reaching it on a interleaved path is what this entry catches. Screen-reader browse mode (virtual cursor) and focus mode can differ; fill the form in focus mode.
Where it stops holding
A label visually beside its input should not take Tab before the input—that is not “matching visual order,” it is a surplus node. When a modal is open, focus locked inside it skips fields behind; that is a legitimate trap, not an order bug. Dynamically inserted error copy that is focusable adds a stop between fields; keep the copy unfocusable and read with the field. In a right-to-left UI the visual order starts on the right; Tab should follow reading direction, not a hard LTR DOM.
Applying it
- Order the DOM as the eye reads. Do not patch with positive
tabindex. For two columns, decide whether people read by column or by row, and make the DOM follow that decision. - Absolutely positioned help, ads, and header links must not insert into the field Tab chain; place them before or after the form.
- After any layout change, Tab through and number every stop against the visual numbers on the mock.
- Verify by filling with Tab only: the focus-ring path matches visual numbering, zero inversions. Move Email above Name in CSS without touching the DOM as a required counterexample. Walk again in a reader’s focus mode and confirm the spoken story matches the visual story.