WCAG 2.2 success criterion 1.3.1, Info and Relationships, is a Level A requirement. In practice: form controls are programmatically labelled; data tables expose their headers; lists, tables and ARIA structures are marked up correctly; and ARIA ID references resolve. It’s among the most common failures on the web: WebAIM found detectable WCAG failures on 95.9% of the top million home pages, and this criterion covers one of the six failure types they found most often (WebAIM Million, 2026 (opens in a new tab)).
Read the criterion in the W3C Recommendation, WCAG 2.2 (opens in a new tab).
How BearScan checks it
Form controls are programmatically labelled
Checked automatically: reads the HTML. Severity: blocker. An unlabelled control is unusable. A screen-reader user hears the field type and nothing else, so the form cannot be completed.
An approximation: Names are resolved from the markup by the accname computation: aria-labelledby, aria-label, the label element, then title. A name supplied only by CSS-generated content is not visible in markup and may be reported as missing.
How to fix it. Associate a visible <label for="id"> with every control, or supply an aria-label or aria-labelledby that names it.
Data tables expose their headers
Checked automatically: reads the HTML. Severity: medium. Without header association a screen-reader user hears an undifferentiated stream of numbers.
How to fix it. Use <th> for header cells, give each a scope attribute, and give every data table a <caption> describing what it contains.
Lists, tables and ARIA structures are marked up correctly
Checked automatically: loads the page in a browser. Severity: medium. A list that is not a list, or a table cell tied to the wrong header, reads as a jumble of unrelated text to a screen-reader user.
An approximation: Takes every axe-core rule tagged for 1.3.1 (list, listitem, definition-list, dlitem, aria-required-children, aria-required-parent, td-headers-attr, th-has-data-cells, and the experimental table and heading checks). Structure conveyed only visually, such as bold text styled as a heading, is beyond them, which is what the experimental p-as-heading check reports as unconfirmed. Each paragraph it flags is read by a decisions model (TypeSafe's Jev) with the text before and after it: at 80% sure it is a heading of what follows it fails, at 80% sure it is not (a label, a lead-in, a line inside a card or an illustration) it is cleared, and in between it asks for review. A flagged paragraph with no letters in it (a large figure such as a price or a count), or one hidden from assistive technology, is left out.
How to fix it. Use <ul>, <ol> and <dl> with only their permitted children, associate data cells with real header cells, and give ARIA composite roles the parent and child roles they require.
ARIA ID references resolve
Checked automatically: reads the HTML. Severity: high. A dangling aria-labelledby produces an unnamed control, which removes it from the accessibility tree.
How to fix it. Correct the id references so each points at an element that exists in the document, or remove the attribute.
All WCAG 2.2 criteria · Next: 1.3.2 Meaningful Sequence
Questions
Is WCAG 1.3.1 required by the ADA?
The ADA doesn't name a technical standard for businesses, but the Justice Department's 2022 guidance points businesses to WCAG, and its 2024 rule for state and local governments adopted WCAG 2.1 Level AA, which includes 1.3.1.
Can an automated tool check WCAG 1.3.1?
Mostly. BearScan checks it automatically (reads the HTML, loads the page in a browser). A clean result still isn't proof every page passes, only the pages scanned.
How do I fix a WCAG 1.3.1 failure?
Associate a visible <label for="id"> with every control, or supply an aria-label or aria-labelledby that names it.