WCAG 1.3.1
Info and Relationships
28.4%
of the 609 sites we scanned fail this
Ranging from 23% of Indian financial services to 46.7% of Shopify DTC stores. Pooled across five targeted cohorts, so treat it as a convenience sample rather than a rate for the web.
Separately, 90.5% of the 941 county government PDFs we scanned fail it (852 documents). That is a different population from the sites above, so the two figures are not comparable. How we scanned the PDFs
What it means and how to fix it
What 1.3.1 covers
- We detect this: Lists built from divs instead of list items
- We detect this: ARIA roles missing their required parent or child roles
- Partly detected: Data tables with no header cells, or headers not associated with their dataWe check that header cells have scope and data cells beneath them. We cannot tell a layout table from a data table when neither is marked up, so a table with no semantics at all can pass silently.
- Partly detected: Form fields whose visible label is not programmatically associatedA field with no accessible name at all is detected. A field whose label sits beside it visually but is wired to the wrong input is not, because both look correct to a machine.
- No engine can detect this: Headings faked with styled divs instead of h1 to h6A div styled to look like a heading is indistinguishable from a div to any engine. This is the single most common 1.3.1 failure we cannot measure, and it is why the rate on this page is a floor.
- No engine can detect this: Relationships conveyed only by visual position or proximityDeciding that two things look related requires seeing the page as a person does.
Of that, 5 failures are detectable automatically, and these are what the rates on this page measure. Each needs its own fix. The percentage is the share of all 609 scanned sites affected. These do not sum to the 28.4% above: a site can fail more than one of them, and most that fail any fail several. A further 2 failures were detected on fewer than five sites each and are not listed.
- A list isn't built correctly13.3%
Screen readers can't announce the list or its item count, so people lose the "list, 5 items" cue that tells them how much is there, and can't jump between items by list.
- A list role is missing its required child roles12.2%
Screen readers announce the container as a list but find no list items inside it, so users hear an empty or broken list and may skip past the content entirely.
- A list item sits outside any list9%
List items placed outside a list element may not be announced correctly by screen readers.
- A role is missing the parent role it needs8.2%
Roles like menuitem and option only mean anything inside their parent. Without it the widget is announced as unstructured text and its item count is lost.
- The whole page is hidden from assistive technology3.1%
Hiding the body removes the entire page from the accessibility tree, so a screen reader reports an empty document. It's usually a modal script that failed to clean up after itself.
What it looks like in code
HTML<ul>
<div>
<div>...</div>
</div>
</ul><ul>
<li>First item</li>
<li>Second item</li>
</ul>Only <li>, <script> and <template> may be direct children of a <ul> or <ol>. A <div> wrapper between the list and its items breaks the parent-child relationship a screen reader relies on to announce "list, 2 items".
Shown for A list isn't built correctly. The failing example is real markup from a site in our research cohorts. Class, style and data attributes are removed, and ... marks a value we elided. The structure is unchanged, because the structure is the failure.
For what the criterion formally requires, read the W3C Understanding document.
How often it fails
Share of scanned sites in each cohort. These are five targeted studies, not a random sample of the web, so read the contrast between cohorts rather than any one figure as a web-wide rate.
Who fails it most3 cuts by retail vertical, CMS vendor, state
By retail vertical
By CMS vendor
By state
Groups smaller than 8 sites are not shown: a rate over a handful of sites moves by tens of points on a single result.
What the numbers do not say
The sharpest single result in our corpus sits on this criterion. Among US city sites, 59.4% of those running CivicPlus fail it against 5.4% of those running Granicus. Same criterion, same scan, same year, an order of magnitude apart. A city inherits most of its accessibility from a procurement decision made before anyone wrote a page, which is worth knowing before blaming the web team.
What this does not measureLimits of these figures, and where the corpus came from
- These are five targeted cohorts, not a random sample of the web. Per-cohort rates are the figure to quote; the pooled rate is a convenience sample.
- Denominators count sites that produced a result. Sites that were blocked or errored are excluded rather than counted as passing.
- Occurrence counts are floors: the engine records at most 25 occurrences of a rule per page.
- The EU and Indian cohorts retained only the primary success criterion per finding, so a rule mapping to several criteria contributes to one of them in those two cohorts and to all of them in the other three.
| Cohort | Scanned | Attempted |
|---|---|---|
| Shopify DTC stores | 75 | 75 |
| US local government | 158 | 221 |
| US healthcare providers | 208 | 218 |
| EU e-commerce | 107 | 170 |
| Indian financial services | 61 | 72 |
Corpus generated 2026-09-18.
Check your own site
A free scan reports WCAG 1.3.1 alongside everything else, with the exact elements that fail.
Run a free scan