Why buttons need a name

How it works

Buttons, button in the code, trigger something on the page: open the menu, submit a form, close a dialog, move a slider on. A screen reader announces them with their role and name, such as “Menu, button”.

The name comes from the text inside the button. Many buttons show only a symbol, though: three lines for the menu, a magnifying glass, an X. Sighted users recognise the symbol, but there is no text in the code. The screen reader then just says “button”, and voice control can't address it.

WCAG 2.2 requires in success criterion 4.1.2 that every control has a name and a role that assistive technology can read.

What matters

• A name for every button. Without visible text, aria-label gives it a name; the symbol gets aria-hidden="true" so it isn't read twice:

<button type="button" aria-label="Open menu" aria-expanded="false">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

• The name says what happens. “Search”, “Close dialog”, “Next image”, not “icon” or “button”.
• Visible text is part of the name. If the button has text, that is enough; a different aria-label would override it, and voice control could no longer find the button by its visible name (success criterion 2.5.3).
• Real buttons, not imitations. A div with a click handler is not a button to keyboards or screen readers. With role="button" it also needs tabindex="0" and must work with Enter and Space. The button element brings all of that with it.
• Input buttons. For <input type="submit"> or type="button" the name goes into the value attribute.

How to set it up

Icon buttons almost always live in the theme, the page builder or plugins: menu button, search, basket, slider arrows, the X of pop-ups and cookie banners. Whoever maintains the theme, or the plugin vendor, adds the name; many page builders have an “ARIA label” field in the element's advanced settings. The report lists the affected buttons with their code so you can find them in the theme.