An accessible name is the short text label that identifies an interface element to assistive technologies such as screen readers, voice control software and switch devices. In accessibility, the accessible name is what a screen reader announces for a button, link, form field or image, and what a voice control user says to activate it, so every interactive element needs one that is present, accurate and concise.
The name is not stored directly on the element. Browsers compute it from several possible sources, such as visible text, an associated label or ARIA attributes, following the rules of the W3C Accessible Name and Description Computation specification, and expose it through the platform accessibility tree.
How browsers compute the accessible name
The browser checks possible sources in a fixed order of precedence and uses the first one that yields text. Higher-priority sources override lower ones completely, which is why an aria-label can silently replace the visible text of a button for screen reader users.
| Priority | Source | Example | Notes |
|---|---|---|---|
| 1 | aria-labelledby | References the id of a visible heading | Can combine text from several elements |
| 2 | aria-label | aria-label set to Close dialog | Invisible string, not translated by many tools |
| 3 | Native label | label element tied to an input, alt on an image | Preferred for form fields and images |
| 4 | Element content | Text inside a button or link | Only for roles that allow naming from content |
| 5 | title attribute | Tooltip text | Last resort, unreliable on touch devices |
Naming from content only applies to certain roles, such as buttons, links, tabs and menu items. A div with text but no role, or a container such as a navigation region, does not take its name from its content and needs an explicit label if a name is required.
Accessible name, role, value and description
Assistive technologies build their output from several properties at once. The accessible name is only one of them, and confusing it with the others leads to redundant or misleading announcements.
| Property | Answers | Typical source | Example announcement |
|---|---|---|---|
| Name | What is it called | Label, content, ARIA | Search |
| Role | What kind of control is it | Element type or role attribute | Button |
| State or value | What condition is it in | checked, expanded, input value | Collapsed |
| Description | What extra detail applies | aria-describedby | Opens in a new window |
Because the role is announced separately, the name should not repeat the role. A button named Submit button is announced as Submit button, button. The WCAG success criterion 4.1.2 Name, Role, Value requires that all user interface components expose a name and role that can be determined programmatically.
What makes a good accessible name
A good accessible name is short, specific and unique within its context. It identifies the purpose of the control rather than describing its appearance, and it starts with the most distinctive word so that users navigating by lists of links or buttons can scan efficiently.
| Element | Weak name | Strong name | Why it is better |
|---|---|---|---|
| Icon-only search button | Magnifying glass | Search | Names the function, not the icon |
| Repeated product links | Read more | Read more about trail shoes | Unique out of context |
| Close icon in a dialog | X | Close | Pronounceable and clear |
| Logo link | Logo image | Company name, home | States the destination |
| Delete row button | Delete | Delete invoice 1043 | Identifies the affected item |
WCAG success criterion 2.5.3 Label in Name adds a key rule for voice control: when a control has a visible text label, the accessible name must contain that visible text, ideally at the beginning. A button that shows Send but is named Submit message cannot be activated by a user who says click Send.
Native HTML versus ARIA labeling
The most robust way to provide an accessible name is native HTML: visible text inside buttons and links, a label element for every form field and an alt attribute for meaningful images. ARIA attributes are powerful but should be a supplement, not a substitute, because they create names that sighted users cannot see and that browser translation tools often skip.
Use aria-labelledby when a visible text already names the element, such as a dialog titled by its heading. Use aria-label mainly for icon-only controls that have no visible text. For decorative images, an empty alt attribute removes the image from the accessibility tree, which is the correct outcome when it carries no information.
Dynamic interfaces need extra care. When a toggle button changes its visible text from Show details to Hide details, the accessible name changes too, which is acceptable. When a control keeps the same text and only its condition changes, the change belongs in a state attribute such as aria-expanded or aria-pressed, not in a rewritten name, so that users hear a stable name followed by the current state.
Common errors and how to detect them
Missing and mismatched accessible names are among the most frequent findings in accessibility audits. Browser developer tools display the computed name of any element, and automated checkers flag missing names reliably, but only manual review can judge whether a name is meaningful.
- Missing name: icon buttons and image links with no text, alt or label are announced only as button or link.
- Placeholder as label: placeholder text disappears on input and is not a dependable name source.
- Overriding visible text: an aria-label that differs from the visible label breaks voice control.
- Generic duplicates: many links named More or Click here are indistinguishable in a links list.
- File names as alt text: names such as IMG_4021 are announced verbatim and convey nothing.
Understanding it simply
Every button, link and form field on a page needs a name that a computer can read aloud. That name is the accessible name. People who are blind hear it through a screen reader. People who control a computer by voice say it to press the button.
Think of it as the name tag on each control. A button that only shows a small picture of a trash can still needs a name tag that says Delete. Without it, the screen reader can only say button, and the user has to guess.
Applied in practice
An online grocery store receives complaints from screen reader users who cannot complete checkout. An accessibility audit finds that the quantity controls are icon-only plus and minus buttons with no accessible name, so each is announced only as button. The cart page also contains twelve links all named Remove.
The developers add names such as Increase quantity of oat milk and Remove oat milk from cart, keeping the visible icons unchanged. The checkout button, which visibly reads Pay now but carried an aria-label of Proceed to payment, gets its aria-label removed so that the visible text becomes its accessible name.
In retesting with a screen reader and with voice control software, testers complete the entire checkout without assistance. The fix required no visual redesign, only correct names on existing controls.