WCAG 1.3.1 Info and Relationships

What it asks

A sighted person reads structure from how things look: big bold text is a heading, indented lines with bullets are a list, a grid with a bold top row is a table, and the words next to a box are its label. A screen reader cannot see any of that. It reads the code, and it announces structure only where the code declares it.

This rule says the relationships that are shown must also be programmatically determinable, or available in text. Headings use heading elements at the right level. Lists use list elements. Data tables use header cells, associated with the cells they describe. Form fields have labels tied to them in code, and related fields, such as a set of radio buttons, are grouped with a name for the group. Emphasis, required-field markers and "see note 3" relationships all count too.

The other direction matters as well. Code that declares structure that is not there, such as a layout table with header cells, or a heading element used to make text big, tells the screen reader something false.

This is the broadest criterion in WCAG. It has no single test; it is a family of them, one per kind of structure.

Its official name is success criterion 1.3.1 Info and Relationships, 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:

“Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”

From WCAG 2.2, W3C. Full explanation: Understanding 1.3.1 Info and Relationships.

Who it helps

Screen reader users above all. Headings let them jump through a page, lists tell them how many items are coming, table headers tell them what a cell means, and labels tell them what a field is for. Without the code, a page is a flat run of text.

It also helps people using braille displays, people who apply their own stylesheets or reader modes, and people using voice control, who say a field’s label to reach it.

What passes and what fails

These pass

• Section titles marked with h2 and h3 elements that follow the visual hierarchy.
• A list of steps marked up as an ordered list, so the screen reader says "list, five items".
• A pricing table with th header cells, and scope or headers attributes where the layout is complex.
• A set of radio buttons inside a fieldset whose legend is the question they answer.
• A text field whose visible label is tied to it with the for attribute.
• A page with main, nav and footer landmarks matching its visible regions.

These fail

• Headings faked with styled div or span elements, which look like headings and read as plain text.
• A layout table, used only to position content, marked up with th header cells.
• Related radio buttons with no fieldset, group or shared name, so the question is read once and lost.
• A multi-level list built from indented paragraphs and typed bullet characters.
• A data table built from div elements with no table semantics at all.
• ARIA roles whose required children are missing, such as a role="list" with no role="listitem" inside.

How to test it by hand

1. Read the page as a sighted person and write down its structure: headings and their levels, lists, tables, form groups and labels.
2. Open the browser’s accessibility tree, or a headings and landmarks extension, and compare. Every heading you saw should be a heading element at the right level.
3. Check each list is a list element and each data table has header cells tied to its data cells.
4. Click each visible label. If the field gains focus, it is tied to the label.
5. For each group of related fields, check for a fieldset and legend or an equivalent ARIA group with a name.
6. Look for the reverse: tables, headings or lists declared in code where nothing of the kind is shown.
7. Note each mismatch, by kind of structure.

What automated testing can decide

What a machine can decide

The code half of this criterion is well suited to automated testing. A table with header cells that are not associated with data cells, a list element with stray children, an ARIA role missing its required children, a set of same-name radio buttons with no group, and a page with no main landmark are all in the markup and can be found reliably. Some of those are clear failures; others are evidence that needs a look.

What it cannot

Automated testing cannot see what the page looks like in the way a person does. Text that is styled to look like a heading, and is not one, is the most common failure here, and deciding it means comparing the look of the text with the role of the text. A tool can raise the question; it cannot be the last word. Nor can it tell whether a table is laying out content or presenting data, or whether a missing group label leaves the person confused on this particular form.

How Dreven handles it

Dreven finds the headings, lists, tables, landmarks and form groups on your pages and shows you each one, with what a screen reader would be told beside what a sighted person sees.

A reviewer decides each result from that evidence, and the report records how. Every result is one of four: passed, failed, not applicable or can’t tell.

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

Related criteria

• 1.3.2 Meaningful Sequence (Level A). Once structure is in the code, its order has to make sense too.
• 2.4.6 Headings and Labels (Level AA). Headings and labels, once marked up, must describe what they introduce.
• 4.1.2 Name, Role, Value (Level A). Custom controls need a name, a role and a state in code.
• 3.3.2 Labels or Instructions (Level A). Every field needs a label or instructions.
• 1.4.1 Use of Color (Level A). Information shown by colour alone has the same problem from the other side.

Questions people ask

All WCAG 2.2 criteria, in plain words