Skip to content
Pandus
en Change language
Menu

WCAG 1.3.1 Info and Relationships

Updated October 14, 2026 · 3 min read

Level
A · WCAG 2.0
EN 301 549
9.1.3.1
What the checker tests
Partly automated: The whole page is hidden from screen readers, Custom menus or lists are built incorrectly, Custom menu items or tabs are outside their group, A label-and-value list is built incorrectly, A label or value stands outside its list, A list is built incorrectly, A list item is outside a list, Some headings are only bold or large text, A table's title is written inside a table cell, Large tables have cells without headers, Some table cells point to the wrong headers, Some table headers do not describe any data
Official text
Understanding 1.3.1 Info and Relationships (W3C, in English)

Success criterion 1.3.1 makes sure that the structure people see — headings, lists, tables, form labels, groups of options — is also in the code. Screen readers, voice control and reader modes use that structure to announce and navigate a page. It is level A and part of EN 301 549 (clause 9.1.3.1).

What the criterion requires

Information, structure and relationships conveyed through presentation must be programmatically determinable or available in text. In HTML that means:

  • headings use h1–h6, not just bold large text;
  • lists use ul, ol or dl, with list items directly inside;
  • data tables use th for headers (and scope or headers for complex tables), and a caption if the table has a title;
  • form fields have labels connected in code (label for), and related fields such as radio buttons are grouped (fieldset and legend);
  • information given by formatting — a required field marked with a red asterisk, a highlighted current step — is also available in text or code.

Typical failures on an online shop

  • section titles like "Bestsellers" or "Description" styled as headings but coded as div or bold p;
  • size and specification tables built from divs, or with no header cells;
  • checkout fields whose visible label is not connected to the field in code;
  • payment and delivery options as radio buttons with no group label;
  • "required" shown only by a red asterisk that is not in the label;
  • ARIA roles such as list or menu used without the required child roles.

How to check it

Automated: our checker catches many structural errors: lists and definition lists with wrong children, data cells without headers, bold paragraphs used as headings, fake table captions, ARIA roles missing required parents or children and aria-hidden on the body (rules list, listitem, td has header, p as heading and related). It cannot see whether something only looks like a heading or a group, so a clean scan is not proof.

By hand: use a headings outline (a browser extension or the screen reader's heading list) and compare it with what you see. Check each table, form and list in the code or with a screen reader. Make sure every visual cue, such as "required", is also in text.

How to fix it

  • Use real heading elements in the theme and editor; keep a logical order (one h1, then h2 sections).
  • Build specification tables with table, th and caption.
  • Give every field a visible label; group radio and checkbox sets with fieldset and legend.
  • Put "required" in the label text or add aria-required and explain the asterisk.
  • Prefer native HTML elements over ARIA roles.

Frequently asked questions

Does WCAG 1.3.1 require a correct heading order?

1.3.1 requires that text that looks like a heading is marked up as a heading. Skipping levels (h2 to h4) is not by itself a failure of 1.3.1, but a logical order makes the page much easier to navigate and is good practice.

How do I test WCAG 1.3.1?

Run an automated check for list, table and ARIA structure errors, then compare the visual page with its code or a screen reader: every heading, list, table header, form label and group should be in the markup.

Is a placeholder enough as a form label?

It is not a reliable label: it disappears when the user types and is not always announced. Use a visible label element connected to the field in code; 3.3.2 Labels or Instructions also asks for visible labels.

Are layout tables a failure?

Using tables for layout is discouraged, but not a failure in itself if they do not use header cells, captions or summaries. Data tables, however, need real header cells.