ARIA6Sufficient technique WCAG 1.1.1 Level A Partly scanner-detectable

Name icon-only controls with aria-label

aria-label puts an accessible name on something with no visible text to take one from. An icon-only close button, a search control drawn as a magnifying glass, a landmark that needs telling apart from another landmark. W3C's own worked example is the third of those, two navigation regions named Primary and Secondary, and it lists ARIA6 as sufficient for 1.1.1 Non-text Content. The word to watch is override. W3C says aria-label overrides native naming, including alt text on an image and a label element wired to a field, so it does not add to what a user can see. It replaces it. That is why putting one on a control that already shows words breaks voice control. Somebody who says click Send is naming the word printed on the button, and if aria-label has quietly renamed it Submit form, nothing happens. Where you need to attach extra words to a control that already has visible text, aria-describedby is the attribute for the job. There is a precedence rule sitting above both of them as well. The attribute aria-labelledby wins wherever it and aria-label are both present, which is the usual reason a hand-typed label silently does nothing at all.

How we find it in an audit

We walk the accessibility tree over every icon-only control on an audited page and collect the names it announces. A header row that reads button, button, button, button is the classic finding and takes seconds to produce. The slower pass is the opposite problem, a control that has a name and has the wrong one. The page looks perfect, and only the tree shows that the visible text and the announced name have come apart. We read those against what somebody would say out loud to activate the control.

How affected users experience it

An unnamed icon button is a mystery box. The listener hears button and has to press it to find out what it does, which is a fine game on a blog and a bad one on a checkout. Named properly it announces open cart, button, and the guessing stops. The version that hurts a different group is the silent rename, where a button clearly printed Send announces as Submit form. A screen reader user hears one thing, a sighted colleague reads another, and somebody driving the page by voice says the word they can see and gets nothing at all.

Passes vs. fails

Passes: name, role, and state exposed. Fails: a control with no identity.

Passes

<button aria-label="Open cart"><svg aria-hidden="true"><use href="#cart"/></svg></button>
<button aria-describedby="send-note">Send</button>
<p id="send-note">We reply within one business day.</p>

Fails

<button><svg aria-hidden="true"><use href="#cart"/></svg></button>
<button aria-label="Submit form">Send</button>

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Element marked as decorative is not exposedA tool can check this
Image accessible name is descriptiveA tool finds candidates, you decide
Image button has non-empty accessible nameA tool can check this
Image has non-empty accessible nameA tool can check this
Link has non-empty accessible nameA tool can check this
Object element rendering non-text content has non-empty accessible nameA tool can check this
SVG element with explicit role has non-empty accessible nameA tool can check this
Image not in the accessibility tree is decorativeA tool can check this

Other ways to satisfy this rule

39 guides on this site are filed under 1.1.1 Non-text Content. 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.

This guide is our interpretation of W3C technique ARIA6: Using aria-label to provide labels for objects. 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.