Skip to content
UX Atlas
AccessibilityCraft conventionIntermediate

Accessible Names

What assistive technology announces for a control, which must match what a user would call it.

Definition

The accessible name is computed from several sources in a defined order: aria-labelledby, then aria-label, then native labelling such as a label element or the element's own text content. Every interactive element needs one.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this page
  1. Definition
  2. Rules
  3. Sources
  4. Continue from here

Rules

  • Prefer visible text as the name. A visible label serves everyone, including speech input users who say the label aloud.
  • WCAG 2.5.3 requires the accessible name to contain the visible label text, and to begin with it where possible.
  • Use aria-label only where no visible label exists, such as an icon-only button.
  • Do not use aria-label to override a visible label with different wording. Speech control users will say the visible words.
  • Give each landmark region an accessible name when there is more than one of a type, such as two nav elements.
  • Do not put a title attribute in place of a label. It is inconsistently exposed.

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A Search ExperienceAuthenticationNavigationSettings

Relied on by

Entries that assume this is already in place.

Commonly confused with

Close enough to be mixed up, different enough to matter.

  • Alt TextAccessibility

    Alt text is one way a name gets computed. Buttons, inputs and regions need names too.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.