WCAG 1.3.2 Meaningful Sequence

What it asks

A sighted person reads a page in the order the layout suggests: top to bottom, left to right, one column before the next. A screen reader reads it in the order of the code. Usually those agree. When they do not, a listener can hear the answer before the question, the price before the product, or the second half of a sentence before the first.

This rule applies only where the sequence affects meaning. A footer with three columns of unrelated links can be read in any order. A form where the heading introduces the fields, a comparison where the left column comes first, or a dialog that appears mid-page cannot.

The usual causes are in CSS. Flexbox and grid can reorder items visually with order, row-reverse or explicit placement while leaving the code order alone. Floats and absolute positioning can put an element anywhere on screen regardless of where it is in the code. Multi-column text can be laid out so that reading across rather than down produces nonsense. And a modal appended to the end of the document reads last, however central it looks.

Note that 1.3.2 is about reading order. Keyboard focus order is a separate criterion, 2.4.3 Focus Order, though the two usually fail together.

Its official name is success criterion 1.3.2 Meaningful Sequence, at Level A. It was added in WCAG 2.2, under guideline 1.3 Adaptable and the principle Perceivable. The W3C’s normative text says, in part:

“When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.”

From WCAG 2.2, W3C. Full explanation: Understanding 1.3.2 Meaningful Sequence.

Who it helps

Screen reader users, who hear content in code order and have no view of the layout to correct it. People using braille displays, who read the same linear stream.

It also helps people who turn off the site’s styles, use a reader mode or reflow the page at high zoom, where the visual layout is replaced by the code order.

What passes and what fails

These pass

• A two-column layout where the code order follows the reading order: main content, then sidebar.
• A product card where the name comes before the price in the code, as it does on screen.
• A grid of cards where each card is self-contained, so reading them in any order loses nothing.
• A "step 1, step 2, step 3" layout whose code order matches the numbers, whatever the screen width.

These fail

• A layout that uses flex-direction: row-reverse to put the image on the left and the text on the right, so a screen reader reads the text first and then the image, against the visual flow.
• A pricing table built with CSS grid where the "Recommended" plan is moved to the middle visually but sits first in the code.
• Article text set in two CSS columns using absolutely positioned blocks, so the code reads across the columns instead of down them.
• A dialog appended to the end of the document that looks like it sits in the middle of the page.
• A caption placed above its image by CSS, while the code puts it after.

How to test it by hand

1. Read the page as a sighted person and decide which sequences matter: headings before their content, questions before answers, labels before fields, numbered steps, comparisons.
2. Turn off the page’s styles in the browser, or use a screen reader to read from the top, and read it again.
3. Compare the two orders. Where they differ, ask whether the difference changes the meaning.
4. Pay attention to flex and grid layouts, floated elements, absolutely positioned blocks, multi-column text and dialogs.
5. Repeat at a narrow width, where layouts often reorder.
6. Note each place where the code order would mislead a listener.

What automated testing can decide

What a machine can decide

Automated testing can notice where the code order and the layout disagree. Elements whose place in the code does not match their place on the page can be listed, which turns a whole page into a short list of places worth a look.

What it cannot

A mismatch is not a failure. Many pairs of elements can be read in either order without loss, and only a person who understands the content can tell which ones matter. Visual order itself is also not always obvious: a sidebar can be read before or after the main content, and either is reasonable. So automated testing can find candidates and cannot decide them.

How Dreven handles it

Dreven finds the places on your pages where the reading order and the visual order may disagree and shows you each one, with the elements concerned and a picture of the page.

A reviewer decides, for each one, whether the order changes the meaning. The report names the components involved and how each result was decided.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.4.3 Focus Order (Level A). Keyboard focus must also move in an order that makes sense.
• 1.3.1 Info and Relationships (Level A). Structure must be in the code before its order can be.
• 1.4.10 Reflow (Level AA). At narrow widths the layout reflows, which can change the order.
• 1.3.3 Sensory Characteristics (Level A). Instructions must not rely on position either, such as "the box on the left".

Questions people ask

All WCAG 2.2 criteria, in plain words