The button-name rule flags <button> elements that have no accessible name, so a screen reader announces just "button" and nobody can tell whether it opens the menu, closes a dialog or deletes something. It is almost always an icon button. The fix is text inside the button – visible or visually hidden – or an aria-label.
What the rule means
Every button needs a name that says what it does. For a <button>, the name normally comes from the text inside it. The rule passes a button that gets its name from:
- text content, including the
altof an image inside it, aria-labeloraria-labelledby,- a
titleattribute, - or a
<label>connected to it.
It fails a button where all of these are empty. An SVG icon marked aria-hidden="true", a CSS background image or an icon-font glyph gives the button no name: axe does not count content generated by CSS. Buttons made from other elements with role="button" are not checked by this rule.
The rule checks only that there is a name. A button named "Click here" or "Icon" passes – whether the name tells people what the button does is a judgement, which is why the fact box above says "partly".
Who is affected
Blind people using a screen reader hear "button" several times in a row, with nothing to tell the buttons apart. Voice-control users cannot say "click Menu" if the menu button has no name – they fall back to numbered overlays or a grid. People using a braille display see only the role. Empty buttons are among the most common failures on the web: the WebAIM Million 2026 found them on 30.6% of the top one million home pages [4].
Why the check fails
- Icon-only buttons – hamburger menu, close ×, search, cart, play, slider arrows – with the icon as the only content.
- Icon fonts or background images that draw the symbol in CSS, leaving the
<button>empty in the markup. - Text hidden with
display: noneon small screens, which hides it from screen readers too. - Carousel dots and pagination buttons generated by a slider script.
- Component libraries whose
IconButtontakes a label prop that was left out. - Chat, cookie and feedback widgets from third parties.
How to fix it
- Where there is room, show the text: "Menu", "Search", "Add to basket".
- For an icon-only button, add visually hidden text inside the button, or
aria-labelon it. Mark the icon itselfaria-hidden="true"so it is not read out as well. - Name the action, not the icon: "Close dialog", not "X"; "Next slide", not "Arrow".
- Fix it in the button component, so every icon button needs a label to render at all.
<!-- Before: icon-only buttons with no name -->
<button class="menu-toggle" type="button" aria-expanded="false">
<svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24"><path d="M3 6h18M3 12h18M3 18h18"/></svg>
</button>
<button class="modal-close" type="button"><span aria-hidden="true">×</span></button>
<!-- After: hidden text in one button, aria-label on the other -->
<button class="menu-toggle" type="button" aria-expanded="false">
<svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24"><path d="M3 6h18M3 12h18M3 18h18"/></svg>
<span class="visually-hidden">Menu</span>
</button>
<button class="modal-close" type="button" aria-label="Close dialog"><span aria-hidden="true">×</span></button>
/* Visually hidden, still read by screen readers */
.visually-hidden { position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; }
Hidden text inside the button is translated along with the page by browser translation tools, which is one reason to prefer it over aria-label.
How to test it manually
- Open your browser's accessibility inspector (Chrome, Edge, Firefox) and select each icon button: the "Name" must not be empty.
- With a screen reader (NVDA on Windows, VoiceOver on macOS), Tab through the page. Every button should say what it does, and two different buttons should not sound the same.
- Check the names make sense out of context: "Button 1", "Icon" or "Submit" on a newsletter form tell people little.
- Try voice control, for example Voice Access on Windows or Voice Control on macOS: say "click" and the name you would expect.
Related WCAG criterion
4.1.2 Name, Role, Value, Level A: every user interface component needs a name that assistive technology can read. Related: 2.5.3 Label in Name – if the button shows text, its name must contain that text – and 1.1.1 Non-text Content for icons that carry meaning.
How Reviseberg reports it
Reviseberg runs button-name on every crawled page at 1280px. The issue list shows the rule with its severity, WCAG criterion and level, the number of buttons and pages affected, and the points you get back by fixing it. The detail view gives the CSS selector, the HTML snippet and every page the button appears on – a menu button in the header shows up once per page, and one template fix clears all of them.
You can mark findings as "ignore", "can't fix" or "false positive" with a reason, for example for a third-party widget; every decision is logged. A clean result here never marks 4.1.2 as passed: whether each name is right is a person's check.