button-name
Web validation
Buttons lacking an accessible name prevents assistive technologies users from knowing the button’s purpose and makes interaction impossible. The accessible name can come from text content, aria-label, or aria-labelledby. Every interactive button must expose a descriptive accessible name..
Pass Patterns
Accessible name via text content
A button with visible text automatically exposes that text as its accessible name:
<button>Submit</button>Using aria-label
A button with no visible text but an aria-label still has a programmatically determined accessible name:
<button aria-label="Close">
<img src="/path/to/closeIcon.svg" alt="" />
</button>Fail Patterns
Missing name
A button with no accessible name provides no information to assistive technology:
<button></button>Button with a non-text content
A button that only includes an icon without aria-label or aria-labelledby has no accessible name:
<button>
<img src="/path/to/avatarIcon.svg" alt="" />
</button>WCAG techniques
Sufficient techniques
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- ARIA14: Using aria-label to provide an accessible name where a visible label cannot be used
Failure techniques
ACT Rules
Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Load the page, open a screen reader
- Move to the button with Tab.
- Listen to what the screen reader announces.
Expected result: It speaks the button’s name (“Play,” “Search,” and so on).
Actual result: It announces “button”, “unnamed button” or nothing at all.
Inspecting the browser dev-tools
- Open the Accessibility Tree panel.
- Select the input element.
Expected result: The Name field shows the text you provided.
Actual result: If unnamed, Name is empty.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires that all user interface components expose names, roles, and values to assistive technologies. A button without an accessible name violates this requirement because the purpose of the button cannot be determined.
Why is this issue marked as Critical?
A button without an accessible name is completely unusable for assistive technology users. It prevents people from completing tasks like submitting a form, closing a dialog, or proceeding in a workflow. This creates a major accessibility barrier and blocks essential functionality.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.22(a) | A text equivalent for every non-text element shall be provided (e.g., via “`alt`”, “`longdesc`”, or in-element content). |
| 508 Trusted Tester | 2.4.4-link-purpose, 6.A | The purpose of each link or button can be determined from any combination of the link/button text, accessible name, accessible description, and/or programmatically determined link/button context. |