Accessibility & Standards

Accessible Name

Definition

Every interactive element needs a name, a role and, where it applies, a state. The name is the human-readable part: 'Download the price list', 'Search', 'Email address'. Browsers compute it by walking a defined list of sources and stopping at the first one that yields text, a process specified in the Accessible Name and Description Computation. In practice the order is aria-labelledby, then aria-label, then the element's native labelling mechanism — a label element for a form field, alt text for an image, a caption for a table, a legend for a fieldset — then the element's own text content, and finally the title attribute as a last resort. That last-resort ordering is why a button holding only an icon ends up nameless while a button holding the word Send does not. WCAG 4.1.2 Name, Role, Value at level A is the criterion that requires the name to exist at all.

Why It Matters

Screen reader users navigate by pulling up a list of the links or buttons on a page, stripped of their surroundings. In that list, nine entries reading 'click here' or 'Download' are indistinguishable, and the reader has to visit each one to find out which is which. A nameless icon button is worse: it is announced as 'button' and the only way to learn what it does is to press it. Speech-recognition users hit a different wall — they say the words they can see, so a button captioned Send with an accessible name of 'Submit form' simply does not respond, which is what 2.5.3 Label in Name at level A exists to prevent.

How It Works

Prefer real text inside the element, because it names the control and is visible to everyone at the same time. Where an icon stands alone, add an aria-label with the words you would have written, or keep visually hidden text inside the button rather than hiding it with display none, which removes it from the computation entirely. An aria-label overrides the element's text content, so applying one carelessly to a link silences the words a sighted reader can see. Names should be short and front-loaded, since the distinguishing part is what users scan for: 'Price list 2026 (PDF, 1.2 MB)' beats 'Click here to download our latest price list'. You can check the result in any browser's accessibility inspector, which prints the computed name and the source it came from.

Real-World Example

A consultancy publishes three files on 99helpers and lists them on a page at resources.99helpers.site. Each download link read 'Download', so the link list announced 'Download, Download, Download' and gave no way to choose. Rewriting the anchor text to name the file — 'Download the 2026 rate card (PDF, 420 KB)' and so on — fixed the link list, the hover tooltip and the search snippet at once, with no extra markup. The same text is also what the browser shows in its downloads panel, so the change paid for itself three times over.

Common Mistakes

  • Leaving an icon-only button unnamed — it is announced as just 'button', so the only way to discover what it does is to activate it and see
  • Putting an aria-label on an element that already has visible text — the label wins, the visible words are ignored, and speech-recognition users can no longer trigger the control by saying what they read
  • Relying on the title attribute for the name — it sits last in the computation, never appears on touch devices, and is skipped by several screen reader and browser combinations

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →