Accessible Name Computation: How Interface Labels Are Exposed
An accessible name tells assistive technology the purpose of an interface element. W3C computation depends on role and markup; this guide explains aria-labelledby, aria-label, and host-language labels without treating them as interchangeable.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Visible text alone does not always tell a screen reader what an interface control does. An accessible name identifies a user-interface element such as a button or link for assistive technology. The name is computed from the element’s role and its HTML or ARIA markup, and it does not always come from the same place as visible text.
Conceptual illustration, not a browser or spoken-output test.
1. A name and a description serve different roles
The Accessible Name and Description Computation specification defines how names and descriptions are determined across content technologies. A name is a concise label that identifies what an element is for. A description can add context. A button might be named “Search,” while a description clarifies the search scope. Repeating identical text in both can make assistive-technology users hear redundant information.
An element’s role determines whether naming is allowed and which sources can contribute. Identify the role before selecting a naming mechanism.
The AccName 1.2 text read here is the 12 October 2026 Working Draft, not a Recommendation. AccName 1.1 is the 18 December 2018 Recommendation. Detailed traversal and empty-result fallback rules should not be silently combined between editions. 1.2 draft status 1.1 Recommendation Purpose of a name
2. Associated text and author-provided attributes
HTML has host-language naming mechanisms such as an HTML <label> element associated with a form control, button contents, and an image’s alt text. WAI-ARIA also defines aria-labelledby, which references text from another element, and aria-label, which provides an author-supplied name. The role and naming rules participate in the actual calculation, so inspect the computed name in the accessibility tree instead of inferring it from an attribute alone.
When a visible label exists, connecting that text to the control gives visual and assistive-technology users a consistent cue. aria-labelledby is useful when existing visible text should label an element or when multiple text nodes form its name. An icon-only button with no visible wording may need an aria-label, but that name should describe the action rather than the icon’s appearance.
Applicable aria-labelledby references are evaluated first. Their computed text takes precedence over aria-label only when it is non-empty; if the result is empty, the algorithm continues to the next applicable source, aria-label. This does not authorize naming a role that prohibits it. A referenced element’s own aria-labelledby is not automatically followed as a chain, although text-alternative computation within an applicable traversal can be recursive. ARIA naming properties APG reference restrictions Author naming guidance
3. Keep the computed name aligned with the interface
An accessible name can come from markup that is not visible. A control may display “Close” while a stale aria-label still names it “Open menu.” Adding an aria-label to an element that already has useful text can replace or alter the name in ways the author did not expect. Prefer meaningful visible text and native HTML labeling where they provide the intended name.
Alternative text should reflect an image’s purpose in context. A decorative image should not create a duplicate name for nearby content. An image that is the only content of a link, by contrast, needs alternative text that communicates the link’s purpose. Make that choice from the element’s function, not from the filename or visual style alone. Functional image guidance
Distinguish a hidden reference from hidden children
The 1.2 draft treats a hidden directly referenced traversal root specially: otherwise excluded text can contribute. A visible referenced element does not thereby include every hidden descendant. Nor is every form of visual concealment identical to algorithmic hidden status. Draft hidden-reference rules
In an illustrative comparison, keep the label wording unchanged while recording the referenced root’s hidden status separately from its children. Separating those inputs helps explain a changed name. A node contributing text does not imply that it is independently navigable. This comparison supplies no result from an implementation test.
A diagnostic path when the name is unexpected
If the computed name differs from the visible wording, inspect four things before adding another attribute: (1) the element’s actual role in the accessibility tree, (2) whether every referenced ID exists and points to the intended text, (3) whether multiple references appear in the intended order without accidental duplicates, and (4) whether the name updates after the user changes the control’s state. For example, if the screen says “Close” but the tree says “Open menu,” a stale aria-label or aria-labelledby reference is one plausible cause. This is a debugging hypothesis, not a result observed in every browser.
The computed name is the value the browser exposes through an accessibility API. A screen reader may combine it with role, state, focus context, or present it through speech or braille. When the result seems wrong, inspect the tree first to separate a name-computation problem from an assistive-technology presentation or navigation problem. Even when the tree value is right, test important tasks with the target browser and assistive-technology combination, checking spoken order and repetition. This article reports no test result for a particular combination.
4. Practitioner perspective: inspect the computed name
Use browser accessibility tools or assistive technology to inspect the computed names of important buttons, links, inputs, and icon-only controls. Check that names are present, distinct where necessary, aligned with visible labels, and describe the actual action. If a name changes with interface state, verify the value after each relevant transition.
Adding ARIA attributes does not by itself make an interface accessible. Match the role, keyboard behavior, and name computation. Do not force aria-label or aria-labelledby onto roles that prohibit author-provided names; choose the appropriate native HTML element instead. Automated checks do not replace manual review of important flows with assistive technology.
Distinguish the name computed by the user agent and exposed through an accessibility API from its presentation by a screen reader. A tree value does not guarantee exact spoken words, order or interaction across products. Computation and presentation Expert practice guidance