WCAG 4.1.2Level ACriticalForms

How to fix: Buttons with no accessible name

Every <button> (and every element with role="button") needs an accessible name, usually visible text or an aria-label describing the action, so a screen reader announces what the button does instead of just saying "button."

What it is

An accessible name is the text assistive technology speaks when focus lands on a control. WCAG Success Criterion 4.1.2 Name, Role, Value requires that every interactive component expose a name, a role, and its state in code. A native <button> already has the right role, but it still needs a name, and when it has none, a screen reader announces a bare "button," giving the user nothing to act on.

By far the most common cause is the icon-only button: a hamburger menu, a close X, a play control, a search magnifier, or a settings gear whose entire content is an SVG or icon font with no text beside it. To a sighted user the glyph reads as an obvious action; programmatically the button is empty. The same failure appears on custom controls built from a <div> or <span> carrying role="button" with only an icon inside.

You give the button a name in one of a few ways: put visible text inside it, add an aria-label that states the action, reference visible text with aria-labelledby, or, as a weaker fallback, add a title attribute. When the button is icon-only, label the button itself and mark the decorative inner icon aria-hidden="true" so the glyph is not announced as stray content.

Who it affects & why it matters

Screen reader users are blocked outright. A toolbar of unnamed icon buttons all read "button, button, button," so the user cannot tell the close button from the menu or the play control, and a wrong guess can submit a form, delete an item, or dismiss a dialog.

Voice-control users are affected just as directly, because they activate a control by speaking its name; with no name there is nothing to say. Switch-device and keyboard users also benefit when the announced name matches the visible action, keeping the interface predictable as they move focus.

A button with no accessible name is a Level A failure under SC 4.1.2, and empty buttons and links sit near the top of the violation types that trigger ADA website lawsuits because they are trivial to detect programmatically and easy to demonstrate with a screenshot. WCAG 2.1 Level AA is the de-facto benchmark U.S. courts apply to ADA Title III claims, and named controls are foundational to it.

The business impact is concentrated on exactly the elements you most want people to use: the unnamed control is often the cart button, the menu toggle, the search submit, or the checkout action. The WebAIM Million report repeatedly finds empty buttons among the most common home-page failures, and the majority of accessibility suits target businesses under $25 million in revenue. Naming a button is usually a one-attribute fix.

How to fix it

Find every <button> and every element with role="button" whose only content is an icon (an SVG, an icon font, or an image).
If the action can carry visible text, add it inside the button; visible text doubles as the accessible name and helps everyone.
When the design must stay icon-only, add an aria-label that names the action, for example aria-label="Close dialog" or aria-label="Open menu".
Mark the decorative inner icon aria-hidden="true" so it is not announced separately from the button name.
Name the action, not the glyph: write "Play video", not "triangle", so the user learns what happens, not what it looks like.
Re-scan to confirm every button now reports an accessible name.

Before

<button><svg viewBox="0 0 24 24">...</svg></button>
<div role="button" tabindex="0"><span class="icon-search"></span></div>

After

<button aria-label="Close dialog">
  <svg viewBox="0 0 24 24" aria-hidden="true">...</svg>
</button>
<div role="button" tabindex="0" aria-label="Search">
  <span class="icon-search" aria-hidden="true"></span>
</div>

How AccessKnight detects this

AccessKnight inspects every <button> element and every element carrying role="button", and flags a control only when it has no accessible name from any source: its trimmed text content is empty AND it has no aria-label, no title attribute, and does not contain an image with non-empty alt. Because each of those counts as a name, an icon button that adds an aria-label, or one that wraps an <img> with real alt text, passes. The classic failure it catches is the icon-only button whose sole content is an inline SVG or an icon-font span with no label.

Frequently asked questions

Is a button with no accessible name a Level A or AA issue?

It fails WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value, which is Level A, the minimum conformance tier. Because an unnamed button is unusable for screen reader and voice-control users, AccessKnight scores it as a critical-severity violation.

My button only has an icon. How do I label it?

Add an aria-label to the button that names the action, for example aria-label="Close dialog", and set aria-hidden="true" on the decorative SVG or icon-font element inside. This gives the button a name while keeping it visually icon-only and stops the glyph from being announced as stray content.

Does a title attribute alone fix an empty button?

A title does satisfy the accessible-name check, but it is the weakest option: title text does not appear on touch devices and is announced inconsistently across screen readers. Prefer visible text or an aria-label, and treat title as a last resort.

What is the difference from the empty-link rule?

Both check for a missing accessible name, but on different elements. The empty-link rule targets <a> elements under SC 2.4.4 Link Purpose, while this rule targets <button> and role="button" controls under SC 4.1.2 Name, Role, Value. A link navigates somewhere; a button performs an action, so name it for the action it triggers.