1.3.2 Meaningful Sequence
- Level A
- Perceivable
- Since WCAG 2.0
Summary
Sighted users take reading order from the visual layout: left to right, top to bottom, column by column. Screen reader users, braille display users, and anyone consuming a linearised view of the page get the order the code exposes instead. When those two orders diverge on content whose meaning depends on sequence (step-by-step instructions, a dialogue, a label followed by its value), the assistive technology user hears a scrambled version of the page. This criterion, at Level A since WCAG 2.0, requires that a correct reading sequence be programmatically determinable whenever sequence carries meaning.
The auditor's mental model has two steps. First, does the order of this content affect its meaning at all? Many layouts are order-agnostic: a grid of unrelated teaser cards reads sensibly in any order, and that is not a fail no matter what the code order is. Second, where order does matter, does the programmatic order preserve the meaning? You are not grading whether the code order matches the visual order pixel for pixel; you are grading whether reading in programmatic order still makes sense.
Official wording
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
EN 301 549 mapping
- Web pages
- Clause 9.1.3.2
- Software and native apps
- Clause 11.1.3.2
- Closed functionality (kiosks, terminals)
On systems closed to screen readers, the standard recommends (does not require) auditory information that lets users correlate what they hear with what is shown on screen.
Clause 9.1.3.2 applies this criterion to web pages unchanged and clause 11.1.3.2 applies it to software that supports assistive technologies. On closed systems the standard only recommends auditory correlation with the screen, so a sequence finding on a kiosk is not a failure of a mandatory requirement.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
The programmatic reading order on the web is the DOM order. The fastest structural check is to compare the two orders directly: in browser developer tools, walk the DOM in the Elements panel and ask whether reading top to bottom through the source matches the meaning the visual layout conveys. Disabling CSS (or using a reader view) gives you the linearised page in one glance; if the CSS-off version reads as nonsense where the styled version reads fine, you have a candidate fail.
The usual culprits are CSS mechanisms that move things visually without moving them in the DOM: absolute positioning, negative margins, float, the flexbox order property, flex-direction: row-reverse or column-reverse, and explicit grid placement (grid-row, grid-column, named areas). None of these is a failure by itself; each becomes one only when it reorders content whose sequence carries meaning. Multi-column layouts deserve specific attention: check that the DOM reads down one column then the next in the intended order, not interleaved across columns.
Confirm suspect areas with a screen reader read-through: start a continuous read (for example VoiceOver on macOS with a read-all command, or any screen reader's browse mode) and listen for the point where the spoken order stops making sense. Do not use Tab to test this: tabbing visits only interactive elements and tests focus order, which is a different criterion.
iOS
The European standard applies this criterion to native software that supports assistive technologies, so iOS findings here are gradeable, not merely advisory. With VoiceOver on, swipe right repeatedly from the top of the screen and note the order elements are announced in. Standard UIKit and SwiftUI layouts usually derive a sensible order from element geometry, so the failures concentrate in custom layouts: overlapping views, elements added to the hierarchy in a different order than they appear, card designs where the amount is announced before the label that gives it meaning.
Use Accessibility Inspector (in Xcode) to step through the accessibility hierarchy without a device in hand; the inspector's element order is the order VoiceOver will follow. Where a custom container reads in the wrong order, the fix on the development side is the container's accessibilityElements array, which lets the author state the correct sequence explicitly; as an auditor you only need to verify the announced order preserves meaning, but naming the mechanism in your finding shortens the remediation conversation.
Android
The same European standard position applies to Android: this is a gradeable requirement in apps that support assistive technologies. With TalkBack on, swipe right through the screen and compare the traversal order against the meaning of the layout. TalkBack derives its default traversal from the view hierarchy and on-screen geometry, so, as on iOS, failures cluster in custom and overlapping layouts, RecyclerView items with complex internal structure, and screens built back to front.
Layout Inspector in Android Studio shows the view hierarchy order that traversal starts from. Where the order is wrong, view-based apps correct it with android:accessibilityTraversalBefore and android:accessibilityTraversalAfter; Compose apps control it through semantics ordering (traversal groups and traversal indexes on the relevant composables). Again, your job is the outcome: does the TalkBack read-through of sequence-dependent content preserve its meaning? A visually reordered summary row that announces value before label, or step 3 before step 1, is the finding.
Pass and fail examples
Passes:
- A two-column article page whose DOM reads the full article first, then the complementary sidebar: both orders make sense, meaning is preserved.
- A responsive card grid that uses CSS grid placement to rearrange cards at different breakpoints: each card is self-contained and the collection is order-agnostic, so sequence does not affect meaning.
- A price tag styled so the currency badge appears visually above the label, while the DOM reads label then price: the programmatic order is the meaningful one.
- An iOS checkout screen where a VoiceOver swipe-through announces each line item, then the delivery cost, then the total, matching the logical order of the visual receipt.
Fails:
- Numbered setup instructions positioned with CSS so the visual order is steps 1, 2, 3 but the DOM order is 2, 1, 3: a screen reader read-through gives the steps out of order.
- A magazine-style layout where the DOM interleaves across columns, so continuous reading jumps mid-sentence from column one to column two and back.
- Letter-spacing a heading by inserting spaces between the letters ("W E L C O M E"): the programmatic sequence of characters no longer forms the word, and screen readers spell out gibberish.
- An Android summary card where TalkBack announces "£" then the label then the digits, because the custom layout's traversal order splits a single meaningful unit.
Not a fail under this criterion:
- A Tab key order that jumps around the page: keyboard focus order among interactive controls is SC 2.4.3 Focus Order, not reading order.
- A visual pseudo-heading made of bold text with no heading markup: the content still reads in the right order; the missing structure is a finding under Info and Relationships.
- A footer that reads before an aside in the DOM when neither depends on the other: sequence does not affect meaning, so the criterion is not triggered.
Commonly confused with
- Info and Relationships, SC 1.3.1. Its sibling criterion covers what things are (headings, lists, labels, table relationships); 1.3.2 covers what order they come in. "This is not marked up as a heading" files under 1.3.1; "this reads in the wrong order" files here. One screen can earn both, but they are separate findings with separate evidence.
- Focus Order, SC 2.4.3. Focus order covers the sequence of interactive stops when navigating with the keyboard; reading order covers all content, interactive or not. Testing with Tab tells you about 2.4.3; testing with a screen reader read-through or DOM inspection tells you about 1.3.2. A page can have a correct focus order and a broken reading order, and vice versa.
- Visual-only emphasis and structure. Bold text acting as a heading, colour acting as a group label, indentation acting as hierarchy: these are programmatic-structure findings under 1.3.1, not sequence findings. If the content reads in a sensible order, do not file it here just because the structure is weak.
- Order-agnostic layouts. The trigger in the normative text is "affects its meaning". Reordered galleries, dashboards of independent widgets, and rearranged marketing sections are not failures unless a reader following the programmatic order would misunderstand the content. Grading every DOM-versus-visual mismatch as a fail is the most common false positive under this criterion.
How AUDITSU tests this
AUDITSU's audit walkthrough covers reading order on every screen you review, with the screen reader running. The walkthrough prompts you to perform a continuous read-through of the screen and compare the announced order against the visual meaning, paying attention to multi-column regions, custom layouts, and label-value pairs. Each question records a pass, fail, or not applicable result per screen, with evidence attached, so a scrambled read-through lands in your report tied to the exact screen where it happens.
For audits of closed systems such as kiosks, where the European standard does not require assistive technology support and recommends only that any speech output correlate with the displayed content, the walkthrough records reading order findings as advisory guidance rather than mandatory failures.
For the full guided workflow, see the audit platform.