Meaningful Sequence:Understanding SC 1.3.2

Intent of this Success Criterion

The intent of this Success Criterion is to enable a user agent to provide an alternative presentation of content while preserving the reading order needed to understand the meaning. It is important that it be possible to programmatically determine at least one sequence of the content that makes sense. Content that does not meet this Success Criterion may confuse or disorient users when assistive technology reads the content in the wrong order, or when alternate style sheets or other formatting changes are applied.

A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning.
For example, if a page contains two independent articles, the relative order of the articles may not affect their meaning, as long as they are not interleaved. In such a situation, the articles themselves may have meaningful sequence, but the container that contains the articles may not have a meaningful sequence.

The semantics of some elements define whether or not their content is a meaningful sequence. For instance, in HTML, text is always a meaningful sequence. Tables and ordered lists are meaningful sequences, but unordered lists are not.

The order of content in a sequence is not always meaningful. For example, the relative order of the main section of a Web page and a navigation section does not affect their meaning. They could occur in either order in the programmatically determined reading sequence. As another example, a magazine article contains several callout sidebars. The order of the article and the sidebars does not affect their meaning. In these cases there are a number of different reading orders for a Web page that can satisfy the Success Criterion.

Specific Benefits of Success Criterion 1.3.2:

This Success Criterion may help people who rely on assistive technologies that read content aloud. The meaning evident in the sequencing of the information in the default presentation will be the same when the content is presented in spoken form.

Examples of Success Criterion 1.3.2

Example 1: In a multi-column document, the linear presentation of the content flows from the top of a column to the bottom of the column, then to the top of the next column.

Example 2: CSS is used to position a navigation bar, the main story on a page, and a side story. The visual presentation of the sections does not match the programmatically determined order, but the meaning of the page does not depend on the order of the sections.

Related Resources

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. The techniques listed only satisfy the Success Criterion if all of the WCAG 2.0 conformance requirements have been met.

Additional Techniques (Advisory) for 1.3.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Using left-justified text for languages that are written left to right and right-justified text for languages that are written right-to-left (future link)

Providing a link to linearized rendering (future link)

Providing a style switcher between style sheets that affect presentation order (future link)

Common Failures for SC 1.3.2

The following are common mistakes that are considered failures of Success Criterion 1.3.2 by the WCAG Working Group.

Key Terms

correct reading sequence

any sequence where words and paragraphs are presented in an order that does not change the meaning of the content

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a
way that different
user agents, including assistive technologies, can extract and present this information to users in different modalities

Example 1:
Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.

Example 2:
Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.