WCAG 1.3.2 — Meaningful Sequence
The DOM order has to match the visual reading order. CSS can move things around for sighted users, but a screen reader reads the source — and if the source is scrambled, the announcement is scrambled.
What this requires
When the sequence in which content is presented affects its meaning,
that sequence has to be programmatically determinable. In practice
this means the DOM order has to match the intended reading order.
A screen reader reads the DOM top to bottom; CSS rearrangements with
flex order, grid order, position: absolute, float, or
transform: translate only move pixels, not the source. If your
visual order tells one story and your DOM tells another, screen-reader
users hear the wrong story.
How AI coding tools fail this
When asked to "make this card grid look good on mobile" or "put the
sidebar after the main content on desktop", AI tools reach for
flex-direction: row-reverse, order: -1, or grid-template-areas
that reposition siblings across the layout. The visual result is what
the designer asked for; the DOM order is unchanged and now mismatches.
The second pattern: absolute positioning a "Save" button at the
bottom of a long form via position: absolute; bottom: 0, while
keeping it at the top of the DOM. Sighted users see it where they
expect; keyboard and screen-reader users hit it before they've filled
in the fields it submits.
The third: hero blocks with the H1 visually below a paragraph of body copy but above it in the DOM (or vice versa). Either the visual order is wrong or the DOM is — the two need to agree.
Edge cases
- Test by reading the DOM aloud. If a sighted-only reading order works but a screen-reader reading from top to bottom doesn't, the sequence is meaningful and the DOM is wrong.
- Tabular data has reading order in two dimensions. Use real
<table>markup so screen readers can navigate row by row or column by column. - Multi-column layouts (
column-count) read top-to-bottom within the source, regardless of which visual column they appear in. CSS columns are usually safe; flex/grid reordering rarely is. - Absolute positioning can break sequence even when the DOM order
looks fine. A toast notification absolutely positioned at the top of
the viewport but placed at the end of
<body>is announced late. - Live regions (see 4.1.3) are announced when the content changes, not in DOM order — so they're an exception to this rule.
How Jeikin handles this
axe-core flags some sequence problems automatically (tabindex values
greater than zero, for example). The harder cases require comparing
the rendered visual order to the DOM order, which is a guided review.
The dashboard records each finding, including the reviewer's note when
a layout pattern (CSS column ordering, for instance) is intentional and
documented.