WCAG 1.3.1 requires that any structure or relationship shown visually, such as headings, lists, data tables, form labels, grouped options and required fields, is also present in the code or spelled out in text. It is Level A and fails in almost every audit we run, usually because something only looks like a heading or a label.
Below you will find the cues to check, who is affected, a broken and fixed form, a testing routine and how this rule differs from its neighbours. For a wider overview of the standard, start with WCAG explained.
Quick facts
Level
AAdded in
WCAG 2.0Principle
Perceivable, guideline 1.3 AdaptableCovers
Headings, lists, tables, labels, groups, landmarks, required fieldsFast test
Compare the heading outline with what looks like a headingHelps most
Screen reader users who navigate by structure
What you see has to be in the markup
Designers show structure with size, weight, spacing, borders and position. A sighted reader decodes all of that in a glance. A screen reader cannot see it. It only knows what the HTML says. So the rule is simple: if the layout tells a sighted person that something is a heading, a list, a table header, a group or a label, the code has to say the same thing.
| What sighted users see | What the code should use |
|---|---|
| Large bold line above a block | h1 to h6 in a logical order |
| Bullets or numbered items | ul, ol and li |
| Grid of figures with header row | table with th and scope, plus a caption |
| Text next to a form field | label linked by for and id |
| Boxed set of related options | fieldset with a legend |
| Red asterisk on a field | Text such as "required" or the required attribute |
| Header bar, sidebar, footer | header, nav, main, aside, footer |
Why WCAG 1.3.1 matters to the people using your page
Screen reader users rarely read a page from top to bottom. They jump by heading, list, landmark or form field. A page with real headings lets them skim like anyone else; a page of styled paragraphs forces them to listen to everything. In a data table, header cells tell them which column a number belongs to. Without them, "42" means nothing.
The rule also helps people who use their own style sheets, reading modes or high zoom, because structure in the code survives when the visual design is stripped away. Voice control users benefit from properly labelled fields too: they can say "click Email" and land in the right box.
Fake headings and other classic failures
| Failure | What a screen reader user gets | Repair |
|---|---|---|
| Bold paragraph styled as a heading | No way to jump to that section | Use a real heading element at the right level |
| Heading tags used only to make text big | A misleading outline | Use CSS for size; keep heading tags for real headings |
| Placeholder text standing in for a label | Field with no name once typing starts | Add a visible label |
Layout table with th cells | Bogus header announcements | Use CSS layout, or role="presentation" on old layout tables |
| Radio group with no group name | "Yes" and "No" with no question | Wrap in fieldset and legend |
| Required shown only by red color | No hint that the field is required | Add the word required or the required attribute |
| Div grid built to look like a table | Loose numbers with no headers | Rebuild as a real table |
Do not fix a missing heading by adding role="heading" to a div unless you also add aria-level. A plain h2 is shorter and works everywhere.
A form that only looks organised
Here is a delivery question that looks fine on screen. The question text is a paragraph and the options are bare inputs, so nothing ties them together.
Fails: the question and the option text are not connected to the inputs.
<p>Delivery speed</p>
<input type="radio" name="ship" id="std"> Standard
<input type="radio" name="ship" id="exp"> ExpressPasses: the legend names the group and each label belongs to its input.
<fieldset>
<legend>Delivery speed</legend>
<input type="radio" name="ship" id="std">
<label for="std">Standard</label>
<input type="radio" name="ship" id="exp">
<label for="exp">Express</label>
</fieldset>Now a screen reader says "Delivery speed, group, Standard, radio button, 1 of 2". The same idea applies to label text and instructions, which the rule on giving labels and instructions also checks.
Checking info and relationships by hand
Automated tools catch some of this, such as inputs with no label. They miss most of it, because only a person can see that a bold line is meant as a heading. Use the routine below.
- Pull up the heading outline. Use a browser extension or a screen reader heading list to see every heading level, and compare it with what looks like a heading on screen.
- Hunt for fake structure. Look for bold paragraphs posing as headings, lines starting with dashes posing as lists, and grids of div elements posing as tables.
- Inspect each form field. Click each field label; if the cursor does not jump into the field, the label is probably not tied to it in code.
- Check groups and required fields. Confirm radio buttons and checkboxes are wrapped in a fieldset whose legend names the group, and that required fields say so in text or with the required attribute.
- Read a data table cell by cell. Move through a table with a screen reader's table commands and confirm each cell is announced with its row and column headers.
- Switch styles off. Disable CSS and see whether the page still reads as headings, lists, tables and labelled fields in a sensible order.
How 1.3.1 lines up with 4.1.2, 2.4.6 and 1.3.2
- 2.4.6 (AA) judges whether the wording of headings and labels describes the topic. 1.3.1 asks whether visual headings are marked up at all. A page can pass one and fail the other. Our 2.4.6 guide has examples.
- 1.3.2 is about the order of content in the code, while 1.3.1 covers its structure. See 1.3.2.
- 4.1.2 deals with custom widgets. A div pretending to be a checkbox fails 4.1.2; a set of real checkboxes with no group fails 1.3.1. Read the widget naming guide.
- 1.3.3 sits next door and deals with instructions that lean on shape or position, not with markup.
W3C lists many sufficient techniques for this criterion on the Understanding Info and Relationships page, from table headers to ARIA landmarks.
Data tables: where most audits find trouble
Simple tables need only th cells with scope="col" or scope="row". Tables with two header rows, or headers in the middle, need the headers attribute or, better, splitting into smaller tables. Add a caption so users know what the table is before they enter it.
<table>
<caption>Opening hours</caption>
<tr><th scope="col">Day</th><th scope="col">Hours</th></tr>
<tr><th scope="row">Monday</th><td>9 to 5</td></tr>
</table>If a table is only there for layout, it should not use th, caption or summary at all.
Questions people ask
What does info and relationships wcag mean in plain terms?
It means that structure shown by visual design, such as headings, bullet lists, data tables, field labels and option groups, must also exist in the code or in the text. Assistive technology reads the code, not the look. Level A, since WCAG 2.0.
Does 1.3.1 wcag require a heading on every page?
No. It requires that anything which looks like a heading is coded as one. If a page has no visual headings, 1.3.1 does not force you to add them, although good headings help everyone.
Is skipping heading levels an info and relationships wcag failure?
Usually not on its own. Going from h2 to h4 is poor practice and confuses some users, but auditors fail it under 1.3.1 only when the levels misrepresent the real structure of the content.
Are ARIA landmarks required by 1.3.1?
Landmarks are one way to meet it for regions like navigation and main content. Native elements such as nav, main and footer give you the landmarks for free, so you rarely need ARIA roles.
Is a placeholder enough as a label under 1.3.1?
No. A placeholder disappears as soon as someone types and is not a reliable accessible name. Use a visible label element tied to the field.
Does bold or italic text fail 1.3.1?
Only if the emphasis carries meaning that is lost in code, such as bold marking the required items in a list. Plain styling for looks is fine; meaning needs text or proper markup.