Visual reordering scrambles the sequence
Aliases: CSS reorder mismatch · visual source divergence · reading order scramble
What it is
Name field on the left, address on the right, but the source writes address first. Sighted people read left to right; the screen reader speaks address first. Two sequences, two stories, from the first node. Visual reordering scrambles the sequence when order, reversed flex, absolute positioning, or grid placement paints one succession and the structure still holds another.
That announcement follows structure is the cause. This leaf is the symptom: when the picture moves and the tree does not, assistive-technology users do not get “a different layout.” They get meaning taken apart.
Why it happens
Paint and structure are two projections. Flex order, row-reverse, named grid areas, floats, absolute coordinates change paint only. Visual reading follows space (start to end, top to bottom); announcement follows the tree. Once they diverge, two items heard in succession may sit a whole column apart on screen, and two neighbours on screen may be separated by three unrelated nodes in the speech stream.
The damage is uneven. A decorative badge painted early, still late in the tree, is mostly noise. “Agree to terms” painted above Submit but placed after it in the tree means Submit is heard before the terms — cause and effect flipped. A promo with order: -1 at the visual top, still after main content in the tree, lands as an interruption mid-article.
Studying it
Two pages identical except for visual sequence: one with source matching paint, one that rearranges paint with order or absolute positioning. Screen-reader users do the same task. Compare the step list heard, whether they acted on the visual “previous” item, and reports that order felt scrambled. Independent: presence of visual reorder, how far it spans. Dependent: Kendall distance from task order, wrong actions, time.
A cheap self-check is to listen again with CSS off. If the sequence makes more sense unstyled, coherence was coming from paint and the structure is the scramble.
Where it stops holding
Responsive layouts that move a sidebar to another column are not this scramble so long as the tree stays one content-first list — the error is rewriting the tree, or using order to lie at one breakpoint. LTR/RTL mirroring changes inline direction, not “heading then body.” Users skipping a nav inside the reader is not reorder. Canvas UIs with no stable visual reading make this claim weak.
Applying it
- Treat
order, a reversed main axis, and absolute positioning as tools that create a second reading sequence. When they appear, walk the spoken list with a screen reader; looking at the picture is not enough. - Whatever is visually first should be first in the tree. If a breakpoint needs the sidebar painted on the other side, place it with the grid; do not swap nodes in the source, and do not apply
orderonly at that width. - How to check: listen to the same page styled and unstyled. The two lists should match, and both should match the steps you give a sighted person. Any item that swaps only when styles are on is visual reorder lying. Delete the matching
order/ absolute rules and listen until the lists coincide.