Skip to main content
Accessibility.com, LLC
Category: ARIA and Semantic Structure

Accessible Name

Also known as: Name, Accessible Label
Simply put

An accessible name is the short piece of text that identifies what an element on a web page is or does, such as a button or link. Assistive technologies like screen readers use this name to announce the element to users, helping them understand its purpose and how to interact with it.

Formal definition

An accessible name is a programmatically determined string that authors associate with a user interface element to identify it to assistive technologies. It is typically a short label (often 1 to 3 words) that conveys the purpose or intent of an element, and it is used by assistive technologies to label, announce, and expose interactive components such as buttons, links, and input fields. Accessible names can be derived from several sources depending on the element and markup used.

Why it matters

The accessible name is the primary way that assistive technology users understand what an interactive element is and what it does. When a screen reader encounters a button, link, or form field, it announces the element's accessible name so the user can decide whether to activate it. If that name is missing, inaccurate, or unclear, a screen reader may announce something unhelpful such as "button" with no further context, leaving the user unable to determine the element's purpose. This makes the accessible name foundational to navigating and operating a page with assistive technology.

Accessible names are especially consequential for elements that convey meaning visually but not textually, such as icon-only buttons or image links. Sighted users may recognize a magnifying-glass icon as a search control, but without a properly associated accessible name, that meaning is not exposed programmatically and is therefore lost to users who rely on assistive technology. Because accessible names can be derived from several sources depending on the element and markup used, getting them right requires deliberate authoring rather than assuming the browser will infer an adequate label.

The presence of an accessible name alone does not guarantee an accessible experience; a name can be technically present yet unclear, redundant, or misleading. Verifying that accessible names are meaningful and correctly associated generally requires manual review and testing with assistive technologies in addition to automated checks, since automated tools can detect the absence of a name more reliably than they can judge whether a name is genuinely useful.

Who it's relevant to

Front-end developers and engineers
Developers are responsible for implementing markup so that each interactive element has a correct and meaningful accessible name. Because a name can be derived from several sources depending on the element and markup, developers need to understand how names are calculated and verify that the intended text is actually exposed to assistive technologies.
UX and UI designers
Designers influence accessible names by deciding how controls are labeled, including icon-only buttons and links whose meaning may be conveyed visually but not textually. Providing clear, concise text labels and annotating design intent helps ensure that developers can associate an accurate name with each element.
Accessibility and QA testers
Testers verify that interactive elements have accessible names that are present, accurate, and meaningful. Because automated tools detect only a portion of issues and are better at flagging missing names than judging whether a name is useful, manual review and testing with screen readers and other assistive technologies are generally needed.
Screen reader and assistive technology users
These users depend directly on accessible names to identify and operate buttons, links, and form fields. A missing or unclear name can make an element difficult or impossible to understand and use, while a clear name supports independent navigation and interaction.
Compliance and accessibility program owners
Those overseeing accessibility programs should recognize accessible names as a core technical requirement that affects whether interactive content is usable with assistive technology. This entry is informational and not legal advice; how accessible-name issues relate to specific legal obligations depends on applicable authorities and evolving guidance, and qualified counsel should be consulted where needed.

Inside Accessible Name

Definition
The accessible name is the text label that assistive technologies, such as screen readers, present to users to identify a user interface element like a link, button, form field, or image. It is what is announced when the element receives focus or is otherwise conveyed to the user.
Accessible Name Computation
Browsers and assistive technologies derive the accessible name through an ordered process defined by W3C specifications (the Accessible Name and Description Computation). The computation checks multiple potential sources in a defined order of precedence to determine the final name.
Common Naming Sources
An accessible name can come from sources such as associated label elements, the aria-labelledby attribute, the aria-label attribute, alt text on images, title attributes, and the visible text content of an element. Which source wins depends on the specification's order of precedence.
Relationship to WCAG
The accessible name is relevant to WCAG success criteria concerning the availability of names and roles for interface components, and to criteria addressing whether a visible label's text is included in the element's accessible name so speech-input users can activate it.
Distinction from Accessible Description
The accessible name identifies an element, while the accessible description provides supplementary information. They are computed separately and serve different purposes for assistive technology users.

Common questions

Answers to the questions practitioners most commonly ask about Accessible Name.

Is the accessible name the same as the visible text label on a control?
Not always. The accessible name is the name computed and exposed to assistive technologies through the accessibility API, and while it is often derived from the visible label, it can differ. For example, an aria-label, aria-labelledby, or a title attribute may override or supply a name that does not match the visible text. When the visible label and the accessible name diverge, users of speech input and screen readers may be affected. WCAG 2.1 added Success Criterion 2.5.3 Label in Name (Level A), which addresses cases where the visible label text is not contained within the accessible name.
Does adding any accessible name mean a component is accessible?
No. Providing an accessible name is one necessary part of exposing a control's purpose, but it does not by itself make a component accessible. The name must be meaningful and accurate, and the component also needs an appropriate role, state information, keyboard operability, and other properties to be usable. Passing an automated check that a name exists does not confirm the name is clear, correctly associated, or that the overall experience works with assistive technology. Manual testing and testing with assistive technologies are generally needed.
How is the accessible name determined for an element?
User agents compute the accessible name using the accessible name and description computation, which the W3C defines through algorithms such as those in the Accessible Name and Description Computation (accname) specification and related host language rules. The computation follows an order of precedence among sources, which commonly includes attributes such as aria-labelledby and aria-label, native labeling mechanisms like the label element or alt text, and fallbacks such as the title attribute. Because precedence rules vary by element and specification, results should be verified with an accessibility inspection tool and with assistive technologies.
Which method should I use to provide an accessible name?
Native, built-in labeling mechanisms are generally preferred where they exist, such as a properly associated label element for form controls or alt text for images. ARIA attributes like aria-labelledby (to reference existing visible text) and aria-label (to supply a name not otherwise present) are commonly used when native mechanisms are unavailable or insufficient. As a general practice, referencing visible text is often favored over hidden text so the accessible name stays consistent with what users see, which also supports WCAG Success Criterion 2.5.3 Label in Name.
How can I test whether an element has the intended accessible name?
You can inspect the computed accessible name using browser developer tools and accessibility inspection panels, as well as dedicated accessibility testing tools that display the accessibility tree. Automated tools may detect missing names but cannot fully judge whether a name is meaningful, so manual review is important. Testing with screen readers and other assistive technologies helps confirm how the name is actually announced, since results can vary across browser and assistive technology combinations.
What are common problems that result in a missing or incorrect accessible name?
Frequent issues include icon-only buttons or links with no text and no aria-label, images missing appropriate alternative text, form fields without an associated label, and reliance on placeholder text rather than a persistent label. Names that describe the element inaccurately, aria-labelledby references pointing to nonexistent or hidden elements, and accessible names that omit the visible label text can also cause problems. Because behavior depends on element type and precedence rules, verify outcomes with an accessibility inspector and assistive technology rather than assuming an attribute was applied as intended.

Common misconceptions

If an element displays visible text, it automatically has a correct accessible name.
Visible text is only one possible source in the name computation, and other attributes such as aria-label or aria-labelledby can override it. This can cause the announced name to differ from what is displayed, which may create confusion for users and can affect criteria addressing whether visible label text matches the accessible name.
Providing any accessible name is sufficient for accessibility.
A name that is present but vague, inaccurate, or duplicated across elements can still create a poor experience. Meeting the technical requirement that a name exists does not guarantee usability, and automated tools may detect a missing name but often cannot judge whether the name is meaningful; manual and assistive technology testing are generally needed.
The accessible name and the accessible description are the same thing.
They are computed separately and serve different roles. The name identifies the element, while the description supplements it. Conflating them can lead to overloaded names or missing identifying information.

Best practices

Prefer native, visible labels (such as associated label elements or an element's text content) so that the accessible name matches what sighted users see.
When a visible label exists, ensure the accessible name includes that visible text so speech-input users can activate the control by its displayed label.
Use aria-label or aria-labelledby deliberately and sparingly, remembering they can override visible text and change what assistive technologies announce.
Write names that are concise, unique where practical, and descriptive of the element's purpose rather than generic terms alone.
Verify accessible names with manual testing using screen readers and other assistive technology, since automated checks detect only a portion of naming issues and generally cannot assess whether a name is meaningful.
Confirm the computed name against the W3C accessible name computation order of precedence when multiple potential naming sources are present on an element.