Skip to main content
WCAGrules
Quick navigation
1.3.1Level APerceivable

Info and Relationships

Whatever a sighted reader works out from the way a page looks has to be recoverable another way. Headings, lists, data tables, which label belongs to which field, which fields belong together. There are two routes to that, and most people only know one. Put the structure in the code, which is what you do in HTML. Or state it in words on the page, which is how "required fields are marked with an asterisk" conforms. Code wins wherever the technology supports it. A bold, larger sentence is not a heading to a screen reader. An h2 element is. Relationships signaled by sound count too, so a chime marking a new section needs something else saying the same thing.

Why it matters

Screen reader users do not read a page from the top. They pull up a list of its headings and jump, or move landmark by landmark, doing with their ears what a sighted reader does with their eyes when skimming. Strip the structure out of the code and you take the skimming away. The page becomes a tape somebody has to sit through from the beginning. Voice control users lose something different and just as practical. They operate the page by speaking the name of a control, so a control with a visible label and no accessible name cannot be spoken to at all. It is sitting right there on screen, and the command bounces off it.

Who this rule protects

Screen reader users depend on this rule above everyone else, and braille display users read the same structure. Voice control users need a control's visible label to match its accessible name, or the spoken command finds nothing to act on. Reader-mode users, and anyone whose browser or extension rebuilds the page, rely on the same markup underneath.

How to check it yourself

  1. Open the heading outline, in the browser or in a screen reader's heading list, and read it on its own. It should work as a table of contents for the page.
  2. Check that visually grouped lists use real list markup, and that data tables use header cells rather than plain cells throughout.
  3. Click each form label and confirm focus jumps into its field. That is the quickest sign the label is connected in code rather than just placed nearby, though script can move focus too, so check the markup on anything that matters.
  4. Check the accessibility tree for controls named with aria-label or aria-labelledby. Those conform without moving focus on a label click, so the click test alone would raise a false finding against them.
  5. Check related fields are grouped. A set of radio buttons or an address block usually needs a fieldset with a legend, so the group's question is announced alongside each option.
  6. Check the page has landmarks, meaning header, nav, main and footer as real elements or roles. Landmark jumping is the second thing a screen reader user does after headings.
  7. Look for a table that is really a layout grid and confirm it carries no header cells and no caption. Asserting relationships the content does not have is its own failure, and it is the trap a developer falls into while fixing the first one.
  8. Check that emphasis carrying meaning is marked as emphasis, rather than bolded in CSS with nothing underneath it.

Failures we see most often

  • Headings are faked with bold, larger text, so a screen reader's heading list comes up empty.
  • A real data table ships with no header cells, so a screen reader can read a number and not what it is a number for.
  • Header cells and data cells are wired together with mismatched id references, so the table announces the wrong header for the wrong value.
  • A form label sits beside its field and is never connected to it, so the field announces as "edit text" with no name at all.
  • A control has visible label text and no accessible name, so a voice control user cannot say its name to activate it.
  • Content that carries meaning is marked with a presentation role, which strips the semantics out of a table or a list that needed them.
  • A layout table carries header cells or a caption, which asserts relationships its content does not have.
  • Columns or a table are drawn with runs of spaces inside preformatted text, so the arrangement exists only for somebody who can see the shape.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

How this one is tested

We list 11 ACT rules against 1.3.1. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

How to fix it

  • Mark every visual heading as a heading element at the level its place in the outline calls for, then style it however the design wants. Real heading semantics is what the rule requires, and in HTML the heading element is the way to get it. A role of heading with its level declared does the same job where the element is genuinely not available. One h1 per page and no skipped levels is good practice and our own house rule, not a condition of passing.
  • Mark up lists as list elements and data tables as tables with header cells, using scope to say whether a header runs down a column or across a row.
  • Attach every label with a for attribute pointing at the field's id, or wrap the input inside the label. The styling stays identical and the structure becomes real.
  • Group related controls in a fieldset with a legend, so the question is announced with each answer rather than once at the top.
  • Add landmark elements, meaning header, nav, main and footer, and name them wherever a page has more than one of the same kind.
  • Where the technology genuinely cannot express a relationship, state it in words on the page. That is the second route the rule allows, and it is why the asterisk convention works as long as the sentence explaining it is there.
Step-by-step fix guides (52)
Routes and related guidance (41)
Documented failures (11)

Passes vs. fails

A general illustration of the pattern rather than a test of 1.3.1. Passes: headings exist in the code. Fails: one flat wall of text.

Passes

A real h2, a fieldset with a legend, and a label whose for attribute names the ZIP code field keep the same look while giving a screen reader real structure to move through.

Fails

A div styled to look like a heading sits above a set of unlabeled fields, so nothing about the structure survives outside the visual styling.

In audits and lawsuits

After alt text, structure is the most common finding in our expert reviews. It turns up on nearly every site built out of plain divs by a team that styled headings to look right instead of marking them up to read right. One thing about scanner output is worth knowing before you open the report. Most automated findings against this rule are ARIA problems rather than heading problems. What a machine can check here is narrow. Whether an attribute exists, whether a role's required states are present, and whether a table header cell has any cells assigned to it. So a scan reporting a pile of issues against this rule is usually reporting broken ARIA. The heading and label work is still yours to check by hand.

Related on this site

Guides, checklists, techniques, and terms that bear on this rule.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations

↑ ↓ navigate · Esc closeSearch the full site