Accessible name.

The accessible name is the name of an interface element as read by assistive technology, and it can differ from the text shown on screen.

Every interactive element must have an accessible name; without one the screen reader announces only the role. The user hears “button” and never learns what that button does. This is the most common defect on buttons that carry an icon but no text.

The name can come from several sources, and the browser evaluates them in a set order. Roughly: an explicitly given ARIA label, then an ARIA reference to another element, then a native label relationship, then the element’s own text content, and last of all alternative text or the title attribute.

That order of precedence is the source of the most common mistake: when an element is given both visible text and an ARIA label, ARIA wins and the visible text disappears silently. A button reading “Send” on screen is read as “Submit the form” if that is its ARIA label.

1. When the visible text and the name read out diverge, a voice control user cannot activate the element — they say what they see and the system does not recognise it.
2. WCAG 2.5.3 “Label in Name” governs exactly this and is at level A: the accessible name MUST CONTAIN the visible label.
3. The title attribute is a last resort; it is never visible on touch devices and is unreliable as a source of the name.
4. An empty ARIA label leaves the element nameless — worse than giving no label at all.

The practical rule is this: try first to give the name through the element’s own text content; if that is not possible — as with icon buttons — use an ARIA label and make sure that label begins with the visible text, if there is one.

The way to audit this is to look at the accessibility tree: read each interactive element’s name there and ask “does this name say what the element does?” Every element that is nameless or meaninglessly named is a defect.

The accessible name has a sibling: the accessible description. The name says what the element is, the description carries additional context — the expected format of a form field, or an error message. A screen reader reads the name first, then the role, then the description.

Confusing the two produces a common defect: giving a long help text as the name. The user hears that long text from the beginning every time they reach the element. The name should be short and distinguishing; the detail belongs in the description.