Reading order is not visual order
CSS can put anything anywhere. Screen readers and the Tab key follow the DOM, not the layout. When the two disagree, the page tells two different stories.
Here are three steps in a checkout, as a sighted user sees them: Address, Payment, Review. Here is the same list as a screen reader reads it: Payment, Review, Address. Nothing is broken in the HTML. Someone wrote order: 3 on the first item to move it to the end for a layout reason, and the layout moved. The reading order did not.
Two orders
Every page has two orders. The visual order is where things are on the screen. The DOM order is the sequence of elements in the HTML. Sighted readers use the first. Screen readers, the Tab key, reader modes, search engine snippets, and copy-and-paste all use the second.
Most of the time they match, because most layouts flow top to bottom and left to right in the same order as the markup. CSS gives you several ways to make them not match, and each one is a trap.
orderon flex or grid itemsflex-direction: row-reverseorcolumn-reverse- Explicit grid placement (
grid-row,grid-column,grid-area) that puts a later item earlier - Absolute positioning that lifts an element out of the flow and places it elsewhere
- Floats, in older layouts, that push an aside above content that comes first in the source
Visual order (what you see)
- 1. Address
- 2. Payment
- 3. Review
DOM order (what a screen reader reads)
- 1. Address
- 2. Payment
- 3. Review
The first list is one ol with order on each item. The numbers in the text say what the author meant. The positions say something else. A screen reader reads the second list, which is the same markup without the CSS.
Why the DOM is the one that counts
Because it is the only order every tool agrees on. A screen reader builds its reading sequence from the accessibility tree, which follows the DOM. The Tab key moves through focusable elements in DOM order. Reader modes strip the CSS and show the DOM. An agent reading the page gets the DOM. Only the pixels see the CSS.
When visual and DOM order differ, a keyboard user watches focus jump around the screen in an order that makes no sense. A screen reader user hears a sequence that contradicts what a sighted colleague describes. Both are told the page is "fine," because it looks fine.
The rule
Change the DOM, not the CSS. If Payment should come first, put it first in the HTML. If the sidebar should appear above the article on small screens, ask whether it should also be read first; if yes, move it in the source, and if no, leave it where it is and accept that it appears below.
The exceptions are real but narrow. A set of items whose order genuinely does not matter, like a row of equal-weight cards, can be reordered visually without harm. A purely decorative element can go anywhere. Everything that reads as a sequence, steps, headings, form fields, navigation, has to keep its DOM order and its visual order the same.
Checking a page
Press Tab from the top and watch where focus goes. If it jumps backward or sideways, the orders disagree. Then open a reader mode, or disable CSS, and read the page top to bottom. If it tells a different story from the styled page, same problem.
An agent reviewing CSS can grep for order:, row-reverse, column-reverse, and explicit grid-row or grid-column placements, and flag each one for a human to confirm the content is order-independent. That is AW-ORDER-001 in the ruleset, and corpus page 18-reading-order plants both the flex order and the row-reverse cases. The Reading Order lab lets you move cards around and watch the DOM order refuse to follow, then switch modes and fix it.