When focus order stops matching the page
The layout reads left to right. The Tab key does something else entirely, and CSS is the reason.
- Level
- ENGINEER
- Read time
- 08 min
- Experiment
- Available
- Type
- INTERACTIVE
The question
Why can a visually ordered row of controls be traversed in a different order by the keyboard, and what actually determines the sequence?
Hypothesis
Sequential focus follows the DOM, not the visual layout. Any CSS that reorders boxes without reordering nodes, such as order, row-reverse or grid placement, separates the two.
Method
Laboratory available
The instrument for this investigation runs in the laboratory, where the controls, the live model and the observation log share one workstation.
Enter the laboratoryChange the markup and watch the accessibility tree recompute. Role, name and focusability are derived from what you wrote, not from what you styled.
What we observed
.toolbar { display: flex; flex-direction: row-reverse;}.toolbar .primary { order: -1; }Why it happens
A keyboard user experiences the order you wrote; a sighted mouse user experiences the order you styled. When the two disagree, focus appears to jump across the screen, and a user relying on a screen magnifier can lose the caret entirely.
| Value | Effect |
|---|---|
| tabindex="0" | Adds the element to the sequence in document order |
| tabindex="-1" | Focusable by script only, which is correct for a dialog container |
| tabindex="1" or higher | Jumps ahead of everything else. Almost always a bug |
| CSS order / reverse | Moves the box, never the focus position |
The remedy is to fix the source order and let CSS follow it. If the design truly needs a different reading order, that is a signal to restructure the markup rather than to reach for tabindex.
Further research
Test it the way it will be used. Tab through the page from the address bar, watch where the focus ring goes, and confirm that it never disappears, never jumps backwards, and always returns somewhere sensible after a dialog closes.