Buttons Must Have Discernible Text: Fix Unlabeled Buttons

Your audit found a button that announces as just "button" — no label, no verb, no idea what it does. This is the axe-core button-name rule, mapped to WCAG 4.1.2 (Name, Role, Value). A nameless button is a control nobody using a screen reader can operate with confidence, and buttons are usually the thing you most want people to press: submit, buy, subscribe, menu.

Where nameless buttons come from

A button's accessible name comes from the text between its tags, or an aria-label, or the alt/title of an image inside it. The failure almost always shows up in three shapes: a hamburger menu that's just an icon, an <input type="submit"> with an empty value, or a "close" (×) button built from an icon font with no text. Modern UI leans hard on icons, and icons carry no text node — so the name comes out blank.

A real failing example and the fix

<!-- FAILS: icon-only hamburger, announces "button" -->
<button><span class="icon-bars"></span></button>

<!-- FAILS: submit with empty value -->
<input type="submit" value="">

<!-- FAILS: close button, glyph only -->
<button>&times;</button>

<!-- FIXED: label the control, hide the icon -->
<button aria-label="Open menu">
  <span class="icon-bars" aria-hidden="true"></span>
</button>

<!-- FIXED: give submit a real value -->
<input type="submit" value="Create account">

<!-- FIXED: name the close button -->
<button aria-label="Close dialog">
  <span aria-hidden="true">&times;</span>
</button>

When there's visible text, put it inside the button and you're done — no ARIA needed. Reach for aria-label only when the button is icon-only by design.

Button type to naming approach

Why it matters for accessibility and SEO

A button is a promise of action. Strip the label and a screen-reader user is left pressing something blind — will it submit the form, delete the record, close the tab? People don't gamble on that; they leave. Buttons drive your primary conversions, so a nameless one is the most expensive kind of accessibility bug you can ship.

For search, buttons aren't crawled for anchor text the way links are, so the SEO impact is about behaviour, not keywords: a button users can't confidently operate raises frustration, abandonment, and return-to-SERP bounces — the engagement signals that erode rankings over time. And "input buttons" (type="submit") that render as empty give crawlers a broken-looking form.

There's an agent angle worth flagging now, too. AI browsing tools and automated agents increasingly navigate pages by reading the accessibility tree — the same accessible names a screen reader uses. A button that announces as blank is invisible to those agents just as it is to a human using assistive tech, which means an unnamed "Buy" or "Continue" button can silently block an automated checkout or task flow. Naming your controls isn't only about compliance; it's about staying operable by the software that's starting to click through sites on users' behalf.

How to detect it on your own site

1. axe DevTools — scan and filter for button-name; it highlights each unnamed control.
2. Lighthouse — "Buttons do not have an accessible name" appears in the Accessibility report with the failing nodes.
3. WAVE — flags "Empty Button" with a red icon on the page.
4. Tab and listen — tab to each button with VoiceOver or NVDA running. If it says only "button", it's unnamed.
5. Accessibility panel — Inspect the button in DevTools; a blank "Name" field confirms the failure.

How to fix it

1. Locate the flagged button in your template or component.
2. If it should show text, put a clear verb-first label inside it ("Add to cart", "Submit form", "Close").
3. If it's icon-only by design, add aria-label to the button and aria-hidden="true" to the icon so the glyph isn't double-announced.
4. For <input type="submit">, set a real value; for type="image", add alt.
5. If it's a <div role="button">, swap it for a native <button> — you get keyboard and focus behaviour for free.
6. Re-run axe to confirm the button-name count is zero.

FAQ

What's the difference between this and the button's visible text?

They're usually the same thing — visible text inside a <button> becomes its accessible name automatically. The failure only appears when the button has no text, just an icon or an image.

Should I use aria-label or visible text?

Visible text whenever the design allows — it helps everyone and needs no ARIA. Use aria-label strictly for icon-only buttons like a hamburger or a close ×.

Is a <div> with an onclick a button?

Not a real one. It won't be keyboard-focusable or announced as a button unless you bolt on role, tabindex, and key handlers. Use a native <button> and skip the whole class of bugs.

My close button shows × but still fails — why?

The × character is decorative punctuation, not a word, so the name computes as empty or as a stray symbol. Add aria-label="Close" and hide the glyph with aria-hidden.

Does this apply to input-type buttons too?

Yes. <input type="submit"> and type="button" get their name from value. See input buttons must have discernible text for that variant.

Related checks

This is the button-specific member of the "discernible text" trio, alongside links must have discernible text and form input elements must have labels. Related naming checks: select element must have an accessible name and ARIA toggle fields need accessible names.