accessible-name

An accessible name is the text that assistive technology uses to identify a component's purpose. Buttons, links, form controls, and other interactive elements all need one, and this validation checks disabled controls too. The name comes from the computed accessible name. Common sources include aria-labelledby, aria-label, alt, title, a native label, button text, and visible text content. When an element has no accessible name, assistive technology may announce only a role, such as “button” or “edit text”. That leaves users without enough information to understand or operate the control.

Voice control software also relies on the accessible name: it's the phrase users say to activate a control. In the example below, the voice control software labels the named button "Submit", but can only mark the unnamed button with a question mark.

Pass Patterns

Button with visible text

The visible text gives the button a programmatically determinable accessible name.

<button type="button">Save changes</button>

Icon button named with aria-label

The aria-label names the icon-only button, since its visible content is hidden from assistive technology.

<button type="button" aria-label="Open settings">
    <svg aria-hidden="true" focusable="false"></svg>
</button>

Form field with an associated label

The <label> is linked to the input through for and id, so the field has an accessible name.

<label for="email">Email address</label>
<input id="email" type="email" />

Fail Patterns

Icon-only button with no name

The only content is an aria-hidden icon, so the button exposes no accessible name.

<button type="button">
    <svg aria-hidden="true" focusable="false"></svg>
</button>

Icon-only link with no name

The link contains only a hidden icon and no text, so it exposes no accessible name.

<a href="/settings">
    <svg aria-hidden="true" focusable="false"></svg>
</a>

Form field with no label

The text input has no associated <label>, aria-label, or aria-labelledby, so it has no accessible name.

<input type="text" />

WCAG techniques

Sufficient techniques

• ARIA14: Using aria-label to provide an accessible name where a visible label cannot be used
• ARIA16: Using aria-labelledby to provide a name for user interface controls
• G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
• H44: Using label elements to associate text labels with form controls
• H65: Using the title attribute to identify form controls when the label element cannot be used
• H91: Using HTML form controls and links

Failure techniques

• F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name

ACT Rules

• Button has non-empty accessible name
• Link has non-empty accessible name
• Form field has non-empty accessible name

Try It Yourself

Using a screen reader

1. Load the page and open a screen reader.
2. Move to the target control.
3. Listen to the name and role that are announced.

Expected results: The screen reader announces a clear name and role, such as “Save changes, button”.

Actual results: The screen reader announces only a role, an unclear symbol, or no useful name.

Inspecting the browser dev-tools

1. Inspect the target element in your browser's dev tools.
2. Open the Accessibility panel.
3. Check the computed Name value for the element.

Expected results: The computed Name value contains text that identifies the element's purpose.

Actual results: The computed Name value is empty or does not identify the element's purpose.

FAQ

Standards and Regulations

Personas impacted by this issue

• Screen Reader
• Braille
• Voice Input

Related Issues

• interactable-role
• modal-lacks-an-accessible-name
• frame-title
• missing-contextual-labeling