Label icon-only controls with aria-label
aria-label gives a control a name where a visible label cannot be used, and W3C's own title carries that caveat. It is sufficient for 4.1.2 Name, Role, Value, with no partner technique. The value names what the control does, not what it looks like. Close dialog, not X. Add to basket, not plus sign. Hide the icon itself from assistive technology with aria-hidden so the name is the only thing announced. It is not only for icon buttons, either. W3C's second example is a phone number split across three inputs for area code, prefix and line number, each named this way, which is the same problem in a different shape. One thing to weigh before reaching for it. An aria-label is an attribute value, and page translation tools handle attribute values less reliably than they handle text, so a visible label still travels better.
How we find it in an audit
Controls with no accessible name are an automated find and the easy half. The values need reading, because Button and Icon and menu-toggle all satisfy a scanner while W3C's own test asks whether the value properly describes the purpose. That question needs a person who knows what the control does.
How affected users experience it
A toolbar of unlabeled icon buttons announces as button, button, button, button. One of them empties the basket. There is no way to find out which except to press them, and pressing them is the thing nobody can afford to do. Names turn the same row into Save, Duplicate, Share, Delete, and the guessing stops.
Passes vs. fails
Passes
<button onclick="closeDialog()" aria-label="Close dialog">
<svg viewBox="0 0 24 24" aria-hidden="true"><path d="M6 6l12 12M18 6L6 18"></path></svg>
</button>Fails
<button onclick="closeDialog()">
<svg viewBox="0 0 24 24"><path d="M6 6l12 12M18 6L6 18"></path></svg>
</button>How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Image button has non-empty accessible nameA tool can check this
- Link has non-empty accessible nameA tool can check this
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA state or property is permittedA tool can check this
- Button has non-empty accessible nameA tool can check this
- Element with aria-hidden has no content in sequential focus navigationA tool can check this
- Element with presentational children has no focusable contentA tool can check this
- Menuitem has non-empty accessible nameA tool can check this
- Summary element has non-empty accessible nameA tool can check this
- Iframe element has non-empty accessible nameA tool can check this
- Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide
Other ways to satisfy this rule
23 guides on this site are filed under 4.1.2 Name, Role, Value. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- ARIA4sufficientGive custom widgets a real ARIA role
- ARIA5sufficientExpose widget state with ARIA attributes
- ARIA16sufficientName controls from visible text with aria-labelledby
- G10sufficientBuild custom components on accessibility-supported tech
- G108sufficientExpose name, role, and changes through markup
- G135sufficientExpose controls through the platform accessibility API
This guide is our interpretation of W3C technique ARIA14: Using aria-label to provide an accessible name where a visible label cannot be used. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.