What is the Accessible Name? - The Name for Assistive Technologies
Information about the article
Author: Dmitry Dugarev
Imagine you enter a room full of switches, but none of them are labeled. You wouldn't know which switch turns on the light, which starts the ventilation, or which triggers the alarm.
Quite impractical, right?
That's exactly how users of assistive technologies (AT), such as screen readers, feel when interactive elements on a webpage lack a name. The Accessible Name is this crucial label for the digital world. It gives an element an identity that can be programmatically read by software and conveyed to users.
Without it, a button is just a "Button" and an input field is just an "Input Field" – without any context about what they do or what they are for.
What is the Accessible Name?
The official specification "Accessible Name and Description Computation 1.1" of the W3C defines the Accessible Name as follows:
The accessible name is the programmatic name of a user interface element that is presented to an accessibility API. The accessible name is used by assistive technologies to identify and refer to an object. [1]
Translated, this means: The Accessible Name is the programmatic name of a user interface element that is made available to an Accessibility API. The Accessible Name is used by assistive technologies to identify and refer to an object.
Detailed Explanation
The Accessible Name is a central concept of digital accessibility. It is the textual representation of an element that is passed to the Accessibility Tree. This tree is a special representation of the webpage created by browsers, optimized for assistive technologies. A screen reader does not read the HTML code (DOM) directly but interacts with this Accessibility Tree.
The browser calculates the Accessible Name for every relevant element according to a fixed priority list. If you, as a developer, know these mechanisms, you can intentionally control how your UI elements are perceived by screen readers and other tools. The computation is surprisingly logical and follows a cascade that ensures the most robust method takes precedence.
The following diagram illustrates this decision process in a highly simplified manner:
Text description for the schema "Simplified Hierarchy of Accessible Name Computation"
The flowchart begins with the assertion that an element requires a name. The first check step is whether an aria-labelledby attribute is present. If yes, the content of the elements it refers to is used as the Accessible Name, and the process ends. If no, it checks whether an aria-label attribute exists. If yes, its value becomes the Accessible Name. If no, it searches for a native HTML label, such as a <label> element for an input field or an alt attribute for an image. If one is present, its content becomes the Accessible Name. If not, it checks whether the element itself has text content, such as a button. If yes, this text is the Accessible Name. As a last resort, it checks whether a title attribute is present. If yes, its value is used as a fallback. If none of these conditions are met, the element has no Accessible Name, which constitutes an accessibility problem.
It is important to understand that this cascade stops at the first successful method. An aria-label therefore always overrides the text content of a button. This can be useful, but it is also a common source of errors.
What is it used for?
The Accessible Name is essential for virtually every interactive or meaning-bearing element on a webpage. Its main tasks are:
- Identification of Controls: Buttons, links, input fields, checkboxes, radio buttons, and other form elements require a clear name so that users know what action they trigger or what information is expected.
- Description of Images: For images that convey information, the
alttext serves as the Accessible Name. It describes what is visible in the image, allowing blind users to understand the visual content. - Context for Regions and Landmarks: ARIA landmarks such as
<nav>,<main>, or<aside>can also receive an Accessible Name (e.g., viaaria-label="Main Navigation") to help users orient themselves on the page, especially if multiple identical landmarks are present. - Fulfillment of WCAG Criteria: A correct Accessible Name is a basic prerequisite for fulfilling numerous success criteria of the Web Content Accessibility Guidelines (WCAG), especially under the principles "Perceivable" and "Operable."
Practical Examples
Here are some typical examples that illustrate the difference between an element with and without an Accessible Name.
- Good Example
- Bad Example
<!--
Good Example: The text "Delete Profile" is contained directly within the button.
It serves as a robust, visible, and accessible name.
-->
<button type="button">
<svg aria-hidden="true" focusable="false" ...>
<!-- ... Icon Path ... -->
</svg>
Delete Profile
</button>
<!--
Good Example: The button has no visible text.
`aria-label` gives it a clear Accessible Name for screen readers.
-->
<button type="button" aria-label="Open Settings">
<svg aria-hidden="true" focusable="false" ...>
<!-- ... Gear Icon ... -->
</svg>
</button>
<!--
Good Example: The <label> is firmly connected to the <input> via the `for` attribute.
This is the best method for form fields.
-->
<label for="username">Username</label>
<input type="text" id="username" name="username" />
<!--
Bad Example: This button has neither text content nor an ARIA label.
A screen reader would only announce "Button" – the function is unclear.
-->
<button type="button">
<svg aria-hidden="true" focusable="false" ...>
<!-- ... Gear Icon ... -->
</svg>
</button>
<!--
Bad Example: The `placeholder` is not a substitute for a <label>.
It disappears upon input and is not reliably used as an Accessible Name
by some browser/AT combinations.
-->
<input type="text" name="username" placeholder="Username" />
<!--
Bad Example: The link wraps an image without an alt attribute.
Screen readers might read the image file name ("logo.png")
or just "Link," which is not helpful.
-->
<a href="/startseite">
<img src="/logo.png" />
</a>
Best Practices & Recommendations
To ensure that your elements always have a correct and useful Accessible Name, you should follow some basic rules.
Always use visible labels if possible
The best label is the one that all users can see [2]. Use the text content of a button or link directly as its name. For form fields, the <label> element, linked to the field's id with the for attribute, is the most robust and preferred method.
aria-label only as a last resort for invisible labels
If a design absolutely does not provide a visible label (e.g., for an icon button), aria-label is a good solution. But be careful: the content of aria-label is only visible to users of assistive technologies and overrides all other textual content of the element.
aria-labelledby for complex labels
Sometimes the name of an element is composed of existing text on the page. Instead of duplicating the text in an aria-label, you can use aria-labelledby to refer to the IDs of the corresponding text elements. The browser then combines their contents to form the Accessible Name.
<h2 id="article-title">Exciting article about accessibility</h2>
<p>A short introduction to the article...</p>
<a href="..." aria-labelledby="read-more-link article-title">
<span id="read-more-link">Read more</span>
</a>
The Accessible Name here would be: "Read more Exciting article about accessibility".
Visible label must be contained in the Accessible Name
Users of speech recognition software navigate by saying what they see. If a button is visibly labeled "Send," the Accessible Name must include the word "Send" [3]. A user says "Click Send," but if the Accessible Name is "Submit Form," the command will fail.
Common Misconceptions
"The title attribute is a good Accessible Name"
This is a widespread misconception. The title attribute is the absolute last and most unreliable option in the name calculation cascade. Support by browsers and screen readers is inconsistent. It is often ignored or only read under certain conditions (e.g., after a pause). Never rely on the title attribute to convey important information. It is primarily intended for a tooltip on mouse hover and is not a reliable accessible label.
"placeholder is a good label for an input field"
A placeholder is an input aid or an example format, not a label. It disappears as soon as the user starts typing and is then no longer available as context. Older screen readers often do not read placeholders aloud, and they generally have too low a color contrast to count as a label. Every input field needs a proper, persistent <label>.
Related Terms
- Accessible Description
- ARIA (Accessible Rich Internet Applications)
- Accessibility Tree
- screen reader
- WCAG (Web Content Accessibility Guidelines)
- Name, Role, Value
Frequently Asked Questions
What is the difference between Accessible Name and Accessible Description?
The Accessible Name is the short, concise designation of an element (like the text on a button). The Accessible Description provides additional, but non-essential, information. It is typically read after the name and role, often with a short pause. For example: A link with the Accessible Name "Help Center" might have the Accessible Description "Opens the Help Center in a new tab."
When should I use aria-label instead of <label>?
The rule of thumb is: always use <label> when possible, especially for standard form elements. aria-label is intended for cases where a visible label is not present for design reasons (e.g., icon buttons) or when native HTML mechanisms are insufficient.
Can an image have an Accessible Name?
Yes, absolutely. For an <img> element, the content of the alt attribute is the Accessible Name. If an image is purely decorative, the alt attribute should be left empty (alt="") so that it is ignored by screen readers.
Why is WCAG 2.5.3 "Label in Name" so important?
This success criterion is crucial for users of speech recognition software. They interact with the page by speaking the visible labels (e.g., "Click 'Buy Now'"). If the Accessible Name of the button is "Add to Cart" but the visible text is "Buy Now," the software cannot associate the command. The visible text must therefore be part of the Accessible Name.
How can I test the Accessible Name of an element?
The easiest method is to use your browser's developer tools. In Chrome, Edge, and Firefox, there is an "Accessibility" tab. If you select an element there, the browser displays the calculated Accessible Name in the Accessibility Tree. Alternatively, you can of course use a screen reader like NVDA (Windows), VoiceOver (macOS), or TalkBack (Android) to test the page and hear how the elements are announced.
Note
This article is for knowledge transfer and does not constitute legal advice. When implementing accessibility, the specific legal requirements of the respective country or region must always be taken into account.
About the author