WCAG 4.1.2
Name, Role, Value
60.4%
of the 609 sites we scanned fail this
Ranging from 42.1% of EU e-commerce to 78.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, 7.7% of the 941 county government PDFs we scanned fail it (72 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 4.1.2 covers
- We detect this: Buttons, links and inputs with no accessible name
- We detect this: ARIA attributes that are invalid, prohibited, or point at a missing id
- Partly detected: Custom widgets whose role does not match what they doWe detect a role used incorrectly against the ARIA spec. Whether the role chosen is the right one for the component's actual behaviour is not decidable from markup.
- Partly detected: State changes that are never announcedA missing aria-expanded is detectable. Whether it updates when the control is used is not, without driving the component.
Of that, 6 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 60.4% above: a site can fail more than one of them, and most that fail any fail several. A further 3 failures were detected on fewer than five sites each and are not listed.
- Some links don't say where they go34%
Screen reader users cannot determine the destination or purpose of links without accessible names.
- Some buttons have no readable name13.3%
Screen reader users cannot determine the purpose of buttons without accessible names, making key actions unreachable.
- An ARIA attribute isn't allowed on this element11.3%
The attribute is ignored, so whatever it was meant to convey never reaches a screen reader, and the control can be announced with the wrong name or state.
- A hidden element can still be reached by keyboard11%
Focusable elements hidden from the accessibility tree create keyboard traps that disorient users.
- One control is nested inside another9.5%
A button inside a link, or a link inside a button, produces something assistive technology can't describe coherently, and usually only one of the two can be activated at all.
- An element uses accessibility info it shouldn't8.7%
Incorrect ARIA attributes may cause screen readers to misrepresent element state or purpose.
What it looks like in code
HTML<a href="/path">
<svg viewBox="0 0 71 48" width="71" height="48" xmlns="http://www.w3.org/2000/svg">...</svg>
</a><a href="/pricing">See pricing</a>
<!-- Icon-only link -->
<a href="/cart" aria-label="Basket, 3 items">
<svg aria-hidden="true" focusable="false">...</svg>
</a>A link with no discernible text is announced as "link" and nothing else, which is unusable in a links list.
Shown for Some links don't say where they go. 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 sector, country, state
By sector
By country
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 most-failed criterion in our corpus, and the one least visible to a sighted reviewer: a control with no accessible name looks completely normal on screen. It only surfaces when something has to speak the interface aloud. It is also the criterion that most rewards fixing a component library rather than a page, because the same unnamed button usually ships everywhere the component does.
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 4.1.2 alongside everything else, with the exact elements that fail.
Run a free scan