Layout testing
Test reading order when a layout wraps
Check visual order, DOM order, and keyboard focus order separately when a layout wraps, and decide whether a rearrangement actually changes meaning.
When a two-column layout collapses into one, content that sat side by side has to be stacked in some order. The browser decides that order from the source and the layout rules, and the result may differ from what anyone pictured at full width.
Three orders are involved. Sighted readers see the visual order, assistive technology reads the document order, and keyboard focus moves through interactive items in its own sequence. This guide checks each one separately, because a screenshot can only show the first.
Know which sequences matter
The W3C explanation of meaningful sequence applies where the order of content affects its meaning. In those cases, a correct reading order needs to be programmatically determinable. The explanation also allows that more than one order can preserve meaning.
CSS that rearranges content is therefore not a failure on its own. A list of related links read before or after an article usually changes nothing. A warning read after the step it warns about can change what someone does. Before testing, list the places where order carries meaning, such as numbered steps, warnings, form instructions, and captions tied to images.
Run three checks at each width
Visual order: read the page top to bottom as it appears and note where each meaningful item sits. DOM order: inspect the element order in your browser's developer tools and list the same items. Focus order: press Tab from the top of the page and record each interactive item that receives focus.
Put the three lists side by side for every width you test. A difference between the lists is a lead, not a verdict. The real question is whether any list puts a meaningful item in a position that changes its meaning.
Worked example: a reset procedure with a warning
A fictional help page explains how to reset a router in three steps. A warning callout says to unplug the power cable before step 2 and contains a link to an explanation. Step 3 contains a link to contact support. In the source, the warning sits between steps 1 and 2. At 1200 CSS pixels, a grid places the callout in a side column next to step 2. At 600 pixels, the grid moves it below step 3.
| Check | 1200 px | 600 px |
|---|---|---|
| Visual | Step 1, step 2 with warning beside it, step 3 | Step 1, step 2, step 3, warning |
| DOM | Step 1, warning, step 2, step 3 | Step 1, warning, step 2, step 3 |
| Focus | Warning link, then support link | Warning link, then support link; focus jumps down to the warning and back up to step 3 |
Read the example's results
The DOM order keeps the warning before step 2, so the programmatic sequence carries the intended meaning. At 600 pixels, though, a sighted reader meets the warning only after finishing every step, and focus moves out of the visual sequence. That is a real defect, found by the visual check and confirmed by the focus check. A reasonable fix is to let the callout keep its source position in the narrow layout.
State what each check can claim
A screenshot or visual pass shows positions at one width, zoom level, and page state. It shows nothing about source order, focus, or what a screen reader announces. Developer tools show element order but not how a particular browser and screen reader present it, which needs its own test. A tab-through only covers interactive items, so it reveals nothing about the order of static text.
These checks cover only the widths you chose, and content may reorder at a breakpoint you skipped. Deciding which sequences carry meaning is a judgment, and reviewers can disagree. Clean results at two widths are evidence about those widths, not a conformance result for the page.