Accessible Name

The accessible name is the text that assistive technologies use to identify an interface element. The browser calculates it according to a W3C algorithm by consulting multiple sources in a strict priority order: aria-labelledby, aria-label, HTML <label>, text content, and finally the title attribute as a last resort.

A button displays "Send". A screen reader announces "Send". A voice control user says "click Send" and nothing happens. The problem: the accessible name of the button doesn't match the text displayed on screen.

#How the browser calculates the accessible name

The W3C publishes a dedicated algorithm (AccName) that defines a strict priority order. The browser checks these sources one by one and stops at the first one that provides text:

1. aria-labelledby — references one or more other elements in the DOM
2. aria-label — invisible text placed directly on the element
3. Native HTML labeling — <label>, <legend>, <caption>
4. Text content — the text inside the element
5. title — last resort, often poorly conveyed by screen readers

<!-- Name via <label>: most reliable method for fields -->
<label for="email">Email address</label>
<input id="email" type="email">
 
<!-- Name via text content -->
<button>Send</button>
 
<!-- Name via aria-label: useful for icon buttons -->
<button aria-label="Close window">×</button>

The highest source wins. If a button has both an aria-labelledby and an aria-label, it's aria-labelledby that takes precedence.

#The trap of visible text being ignored

The WCAG 2.5.3 criterion "Label in Name" (Level A) requires that the accessible name contains the visible text of the component. When these two texts diverge, voice control stops working.

<!-- ❌ The accessible name ("Close") does not contain the visible text ("Fermer") -->
<button aria-label="Close">Fermer</button>
 
<!-- ✅ The accessible name reproduces the visible text -->
<button aria-label="Close confirmation window">Close</button>

Another common mistake: placing an aria-label on an element that already names itself correctly. A <button>Send</button> doesn't need an aria-label. Every ARIA attribute added without necessity is an extra maintenance point and a source of future mismatch between what the screen displays and what assistive technologies announce.

#Native HTML element first

For form fields, a <label for="..."> associated with the field's id remains the most reliable method. It works everywhere: screen readers, voice control, clicking the label activates the field. Reserve aria-label and aria-labelledby for cases where native HTML isn't enough — icon buttons, custom components, page regions identified by landmarks.

#In summary

The accessible name is what assistive technologies "see". The browser calculates it according to a fixed priority order defined by the W3C. Always verify that this name matches the text visible on screen — it's a WCAG Level A requirement. And when a <label> or the content of a <button> is enough, don't add ARIA.