The two reading orders
A sighted mouse user reads a page visually: their eye lands where the design points. A keyboard user reads a page in DOM order: Tab walks the document tree, and every visual trick — CSS grid reordering, fl exbox order, absolutely-positioned sidebars — is invisible to that walk unless the DOM matches the visual. When a layout visually places the product grid left of the filters but the DOM lists the filters first, the keyboard user tabs through forty filter options before reaching the first product. The layout and the keyboard are telling two different stories.
<!-- visually: products left, filters right (grid areas)
DOM order decides Tab order: products FIRST -->
<div class="shop">
<main class="products"> <!-- Tab stops here first -->
...cards...
</main>
<aside class="filters"> <!-- then here -->
...filters...
</aside>
</div>
<!-- Do NOT fix with tabindex="5" / "6" — fragile, and
positive tabindex breaks the natural order for
everything after it. Fix the DOM order instead. -->The reordering tools, judged
- DOM order first: the professional default — write the DOM in reading order and let CSS place it visually (grid areas, flex order do not change the walk).
- tabindex='-1' is the legitimate tool: it makes an element script-focusable without adding it to the Tab sequence — used for focus management in modals and for skip-link targets.
- Positive tabindex (1, 2, 3…) is the trap: it pulls elements to the front of the walk and makes every later element's position depend on it — one positive tabindex is a bug report waiting to happen.
- The skip link is not optional: 'Skip to content' as the first focusable element is how keyboard users skip your nav — without it, every page visit starts with forty nav links.
The visual-order audit
The audit is a side-by-side: walk the page with Tab and note each stop's visual position. Draw the path. If the path zigzags — down the sidebar, up to the header, over to the footer — the DOM and the layout disagree. The fix is usually humble: reorder the source so reading order matches visual order, and let the layout do the arranging. When visual order genuinely cannot be the reading order, the visual layout needs the rethink, not the DOM.