WCAG fix guide

How to Fix Empty Buttons and Missing Button Names (WCAG 2.2)

Last reviewed 7 min read

Applies to: SC 4.1.2 Name, Role, Value, Level A · SC 2.5.3 Label in Name, Level A · SC 1.1.1 Non-text Content, Level A (image buttons)

Empty buttons appeared on 30.6% of home pages in the WebAIM Million 2026 (detected with WebAIM's WAVE tool). Of WebAIM's six most common error types, it is the only one that has risen every year since 2021, when it stood at 26.9%. WebAIM also counted an average of 4.8 role="button" attributes per home page, up from 3.6 in 2025 (WebAIM). A button with no name is announced as just "button", so screen reader and voice control users can't tell what it does. Search, menu, close, cart, carousel arrows and quantity +/− are the usual culprits.

What counts as a button name

The accessible name is what a screen reader reads out and what a voice control user says to press the button. In order of preference:

  1. Visible text inside the <button>: the most robust option, and what sighted users see too.
  2. Visually hidden text inside the button, for icon-only designs.
  3. aria-label or aria-labelledby pointing at visible text that exists on the page.
  4. alt text on an <img> inside the button, or value on <input type="submit">.

A title attribute alone is a weak name. The HTML Standard says relying on it "is currently discouraged" because many browsers only show it on mouse hover (HTML Standard).

Common causes and fixes

CauseFix
Icon font or SVG only (<i class="icon-search">)Add visually hidden text or aria-label="Search"; add aria-hidden="true" to the icon
Icon drawn with CSS ::before / ::afterSame as above. The symbol in the stylesheet is not a usable name
<img> inside the button with empty or missing altGive the image alt text that says what the button does (alt="Close")
<input type="submit" value=""> or <input type="image"> without altAdd a value ("Subscribe") or alt text
aria-labelledby pointing at an id that doesn't existFix the id, or use aria-label
Clickable <div> or <span>Use a real <button type="button">; it gets keyboard focus and the button role for free
Visible text "Send" but aria-label="Submit form"Start the name with the visible words, or drop the aria-label (SC 2.5.3)
Menu or accordion toggleName it, and add aria-expanded="true/false", updated by your script
<!-- Icon-only button: hidden text, decorative icon -->
<button type="button" class="cart-toggle" aria-expanded="false" aria-controls="mini-cart">
  <svg aria-hidden="true" focusable="false">…</svg>
  <span class="visually-hidden">Cart</span>
</button>

<!-- Quantity stepper: name each button with the product -->
<button type="button" aria-label="Decrease quantity for Linen shirt">−</button>

Button or link? If it goes to another URL, use a link. If it does something on the page (opens a menu, submits, closes a dialog), use a <button>. See the link names guide for icon links.

What automated checks flag, and what they don't

In our test of 21 button patterns in headless Chrome with axe-core 4.14.0, the open-source engine many scanners use, with the WCAG A/AA and best-practice rules switched on (October 2026), the results were:

PatternFlagged?
Empty <button>, icon font or SVG only, CSS-only icon, img with alt=""Yes (button-name)
<div role="button"> with no textYes (aria-command-name)
<input type="submit" value=""> / <input type="image"> without altYes
Visible "Send" with aria-label="Submit form"Yes (label-content-name-mismatch)
aria-hidden="true" on a focusable buttonYes (aria-hidden-focus)
Name from title onlyNo: passes, but the name is hover-only for many users
Only "×" as textNo: passes, but the name is a symbol, not a word like "Close"
aria-label="button" or "icon"No: passes, but the name is meaningless
Menu toggle with no aria-expandedNo: the state isn't checked
Clickable <div> with no roleNo: it isn't in the accessibility tree, so the scanner can't see a button at all

Who owns the button?

On client sites, the fix route depends on where the button comes from:

CMS-specific steps

Menu names can change between platform versions (steps checked October 2026). If a path doesn't match, check your platform's current help pages.

WordPress, Shopify, Webflow, Squarespace and Wix are trademarks of their respective owners. Glimscope is not affiliated with or endorsed by any of them.

What automated tools can and can't tell you: Automated checkers (including axe-core, which our monitor uses) can flag many instances of this issue, but they cannot judge everything. A human still has to check meaning and context. For scale: Deque reports that in its own sample of first-time audits, its automated tests found 57.38% of issues by volume (Deque report). That is Deque's figure for its sample, not a detection rate for any one tool, and it means a large share of issues still needs manual testing. Scanners catch buttons with no name. They can't tell whether a name like "×" or "button" makes sense, whether a toggle reports its state, or that a clickable <div> is meant to be a button. Automated tests find only some accessibility issues; manual testing is still required. Not legal advice.

Manual checklist

Sources

  1. www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
  2. www.w3.org/WAI/WCAG22/Understanding/label-in-name.html
  3. www.w3.org/WAI/WCAG22/Understanding/non-text-content.html
  4. webaim.org/projects/million/
  5. html.spec.whatwg.org/multipage/dom.html#the-title-attribute
  6. www.deque.com/automated-accessibility-coverage-report/

Check your own site

Run a free automated scan of one page to check it for some issues like this one.

Run a free automated scan

Automated tests find only some accessibility issues; manual testing is still required. Not legal advice.