Rules · button-name
Failure reference
Buttons without an accessible name.
A hamburger, a magnifier, an X — obvious to the eye, silent to assistive technology when the button has no name.
What fails — and who it fails
The failure, in plain language.
Icon-only buttons for menus, search, close and carousels. Announced as "button" with no purpose; untargetable by voice control ("click close" finds nothing).
Detection — what the machine can and cannot judge
How the scanner finds it.
- Every <button> and role="button" is checked for a name from content, aria-label or aria-labelledby.
- What automation cannot judge: name quality and state announcements (expanded/collapsed) — humans and journeys cover those.
The legal reading — factual, not fearful
Where this sits in enforcement.
Same evidentiary profile as unnamed links: Level A, demonstrated in seconds, and it gates core tasks (open menu, close dialog, search). These lead the fix list because they unblock everything behind them.
The fix — by pattern
The pattern that clears it.
- <button class="nav-toggle"><svg>…</svg></button>
+ <button class="nav-toggle" aria-label="Menü öffnen"><svg aria-hidden="true">…</svg></button>Fix the template, not the page — one change typically clears every instance at once. The triage engine groups findings by template pattern for exactly that reason.
Verification — resolution is evidence, not a checkbox
Fixed means a scan said so.
On monitored domains, mark the finding fixed and the next scan verifies it: zero remaining instances converts the finding to Resolved, and both the claim and the confirmation land in the append-only ledger. Criteria that need human judgement close through sign-off in the coverage matrix — covered by the right method, never by assumption.
Related failures:
See where your templates stand.
A complimentary assessment renders up to 25 public pages in an EU-hosted browser and shows every instance of this failure — grouped, ranked, and honest about what still needs a human.