What 1.3.1 requires
Information, structure and relationships conveyed through presentation must be programmatically determinable, or available in text. If a bold line looks like a heading, it should be a heading. If a form label sits beside a field, it should be associated with that field. If data is laid out in a grid, the header cells should be marked as headers. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.3.1 (opens in a new tab) [1][2].
Exceptions and scope:
- The criterion is satisfied either through markup (preferred) or by stating the relationship in text where markup isn't possible.
Why it matters
Screen-reader users move through pages by structure: jump to the next heading, list the landmarks, move cell by cell through a table hearing its headers. When structure is only visual, those shortcuts disappear. A pricing table without header cells reads as a stream of unrelated numbers. A required-field asterisk that's only red says nothing at all.
Common failures
Visual headings that aren't headings
Styled text looks like a heading but can't be reached with heading navigation.
<!-- Fails -->
<div class="h2">Shipping</div>
<!-- Better -->
<h2>Shipping</h2>Data tables without header cells
Without <th>, a screen reader can't announce which column a value belongs to.
<!-- Fails -->
<tr><td>Plan</td><td>Price</td></tr>
<!-- Better -->
<tr><th scope="col">Plan</th><th scope="col">Price</th></tr>Groups of controls with no group label
A set of radio buttons asks a question the screen reader never reads.
<!-- Fails -->
<p>Delivery speed</p> <input type="radio" id="s"> <label for="s">Standard</label>
<!-- Better -->
<fieldset><legend>Delivery speed</legend> … </fieldset>Errors shown under a field but not tied to it
Returning to the field announces only its label, not what's wrong.
<!-- Fails -->
<input id="email"> <span class="err">Enter a valid email</span>
<!-- Better -->
<input id="email" aria-describedby="email-err" aria-invalid="true"> <span id="email-err">Enter a valid email</span>Can automated testing check 1.3.1?
Partly. Automation can check that structural markup is used correctly. It can't tell whether something that looks structural is missing its markup.
| axe-core 4.13.0 rule | What it checks |
|---|---|
list, listitem | lists contain only list items and list items sit inside lists |
definition-list, dlitem | definition lists are structured correctly |
th-has-data-cells | header cells have data cells they describe |
td-headers-attr | cells using headers refer to cells in the same table |
aria-required-children, aria-required-parent | ARIA roles have the children and parents they require |
aria-hidden-body | aria-hidden isn't set on the document body |
p-as-heading, td-has-header, table-fake-caption (experimental) | styled paragraphs used as headings, and tables missing headers or captions |
What automation can't decide: Whether a bold line should be a heading, whether a layout table is really a data table, whether related fields form a group, and whether an error message relates to the field beside it. Heading hierarchy (heading-order) is only an axe-core best-practice rule, not mapped to 1.3.1.
A clean automated result is never proof that 1.3.1 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Turn off CSS (or use reader view) and check whether the page still makes sense: headings, lists and tables should survive.
- With a screen reader, list the headings. Does every visual section heading appear, at a sensible level?
- Move through any data table cell by cell and check the column and row headers are announced.
- Tab through each form. Every field should announce its label, its group question (for radios and checkboxes) and any instructions.
- Submit a form with errors and move back to a field in error. The error should be announced with the field.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Scanning runs the structural axe-core rules on every URL on a paid plan. Journeys navigate the way a screen-reader user does (by headings, landmarks, roles and tab order), so missing structure shows up as a step that can't be found or understood, and form errors that aren't associated with their field are reported at the step where they occur. Our form-accessibility page lists these as found by journeys. The assistant tools produce a reading-order transcript of one page's accessibility tree, which is a fast way to see the structure a screen reader actually gets.
Where it stops: Accessible reports structure that's missing or broken in the steps it tests. Deciding what the right structure for your content is (which text is a heading, which table is data) still needs a person. No automated tool, ours included, can certify that a criterion is met.
Related criteria
- 1.1.1 Non-text Content
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value
- WCAG 2.2 success criteria checklist
Sources
- Understanding Success Criterion 1.3.1: Info and Relationships (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.3.1 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.