# Your Visual Order and Your DOM Order Disagree. Keyboard Users Follow the DOM.

Source: https://adareadyhq.com/blog/2026-11-13-dom-order-vs-visual-order.html

November 13, 2026

*The tab order follows the DOM order, not the visual layout. When CSS moves a sidebar, a filter panel, or a call to action away from its source position, keyboard users tab through the page in an order that matches nothing on screen.*

## The layout lies; the source tells the truth

A sighted user reads the page the way CSS arranged it: header, hero, filters on the left, products on the right, footer at the bottom. A keyboard user reads the page the way the HTML is written, and those two orders are only the same when nobody moved anything. The moment a layout uses flex order, grid placement, or absolute positioning to put an element somewhere other than its source position, the two orders split. The visual user sees the filter panel on the left and the tab user reaches it after the product grid, or before the header, or somewhere in between that matches no visual logic at all.

Success criterion 1.3.2, [Meaningful Sequence](https://adareadyhq.com/blog/2026-11-12-placeholder-not-a-label-3-3-2.md), requires the reading order to match the meaning, and 2.4.3, Focus Order, requires the tab order to preserve meaning and operability. Both are Level A. The failure is not that the page looks wrong; it looks right. The failure is that the order a keyboard user experiences is incoherent, and incoherence is a barrier even when every control is reachable and every label is correct.

## The three CSS properties that reorder the tab path

[Flex order](https://adareadyhq.com/blog/2026-11-12-skip-links-sticky-header.md) is the usual suspect on storefronts. A product grid that reorders cards by badge or by promotion puts the visual first card third in the DOM, and the tab user meets the cards in DOM order while looking at a different sequence. Grid placement does the same thing more quietly, because grid areas let any element sit in any cell regardless of source position. Absolute positioning is the third: a call to action pinned to the bottom of a hero that sits early in the source will be reached long before the content above it visually, and a skip link positioned off screen with CSS will be announced in a place the user cannot see.

None of these properties is wrong to use. The failure is using them to reorder content without reordering the source to match. The fix is to write the HTML in the order the user should meet it, and let CSS style that order, rather than writing the HTML in one order and using CSS to pretend it is another. When the source order and the visual order agree, the tab order agrees with both, and the problem disappears without any JavaScript.

## The test

Tab through the page with the screen on and watch the focus indicator. If it jumps from the header to the footer, then back to the product grid, then to the sidebar, the DOM order and the visual order disagree. The test takes a minute and it is definitive, because the focus indicator shows the order directly. For a second check, turn off CSS in the browser and read the page as a document: if the document reads sensibly top to bottom, the source order is right. If it reads like a shuffled deck, the source order is wrong, and the visual layout is hiding it.

Test the pages where layout does the most work: the collection page with its filter panel, the product page with its sidebar, and any page with a sticky element that CSS has pinned somewhere the source never intended. The homepage is usually fine, because it is the page the theme author laid out by hand. The template pages are where the reordering happens, because the template was built to be flexible and flexibility is what splits the orders.

## The fix that does not touch the design

Reorder the source, not the layout. Move the filter panel markup to where it appears visually, move the call to action to where the user meets it, and let the CSS keep doing what it does. The design does not change, because the CSS already puts everything where it belongs; only the source changes, and the source is invisible to sighted users. Where reordering the source is genuinely impossible, because a component is shared across pages, use tabindex sparingly and only with a comment explaining why, because positive tabindex values create an order that is harder to maintain than the source order it replaces. The right fix is almost always the boring one: write the HTML in reading order.

## Frequently asked questions

### Does CSS order change the tab order?

No. The tab order follows the DOM source order, not the visual layout. Flex order, grid placement, and absolute positioning change where things appear on screen, but the keyboard still follows the source.

### Which WCAG criteria cover this?

Success criterion 1.3.2, Meaningful Sequence, and 2.4.3, Focus Order, both Level A. The first is about the reading order matching the meaning; the second is about the tab order preserving meaning and operability.

### Is positive tabindex a fix for a bad order?

Almost never. Positive tabindex values create a tab order that overrides the source, which is fragile and hard to maintain. The fix is to reorder the source HTML to match the visual order.

### How do I test for this quickly?

Tab through the page and watch the focus indicator. If it jumps around the screen instead of moving in reading order, the DOM order and the visual order disagree. Turning off CSS and reading the page as a document is a good second check.