WCAG 1.3.2 — Meaningful Sequence

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.

Failing examples

A grid that reorders siblings visually without reordering the DOM:

<div className="grid grid-cols-2">
  <aside className="order-2">Sidebar</aside>
  <main className="order-1">Main content</main>
</div>

A "Skip to top" anchor positioned at the top of the page with CSS but sitting at the bottom of the DOM:

<>
  <main>{/* very long content */}</main>
  <a href="#top" className="fixed top-2 right-2">Back to top</a>
</>

Passing examples

Put the main content first in the DOM and reorder visually only if needed (without changing semantic order):

<div className="grid grid-cols-[1fr_240px]">
  <main>Main content</main>
  <aside>Sidebar</aside>
</div>

If you need a visual flip on small screens, do it in CSS without changing what's read first:

<div className="flex flex-col sm:flex-row">
  <main className="order-2 sm:order-1">Main content</main>
  <aside className="order-1 sm:order-2">Helpful context above on mobile</aside>
</div>

(Here the mobile order is intentional — the aside is genuinely meant to come first on small screens. The DOM matches that intent.)

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.