Category: ARIA and Semantic Structure

aria-labelledby

Also known as: aria-labelledby attribute

Simply put

aria-labelledby is a code attribute that gives an on-screen element an accessible name by pointing to other text already visible on the page. Instead of typing a label directly into the code, it references the id of one or more existing elements whose text serves as the label. This helps assistive technologies, such as screen readers, announce what a control or region is for.

Formal definition

aria-labelledby is a WAI-ARIA attribute that establishes an accessible name for an element by referencing the id (or a space-separated list of ids) of one or more other elements whose text content forms the label. When multiple ids are supplied, the referenced text is concatenated in the order listed to produce the accessible name. It is commonly used to associate a user interface control, such as a form field, with visible text elsewhere on the page, as described in W3C WCAG technique ARIA16. Because the label is derived from existing content, aria-labelledby is generally preferred over aria-label where suitable visible text already exists. Correct implementation should be verified through manual and assistive technology testing, as automated checks alone do not confirm that the resulting accessible name is meaningful.

Why it matters

An accessible name is how assistive technologies identify what a control or region does. When a form field, button, or landmark lacks a properly associated name, screen reader users may hear only a generic announcement such as "edit text" with no indication of its purpose. aria-labelledby addresses this by tying an element to visible text already present on the page, so the announced name matches what sighted users see. This alignment between the visible and programmatic label supports a more consistent experience across users.

Because aria-labelledby derives its label from existing on-screen content, it is generally preferred over aria-label when suitable visible text already exists. Reusing visible text reduces the risk of the two getting out of sync during future edits and keeps the accessible name meaningful rather than duplicating or contradicting what appears on screen. The W3C documents this approach in WCAG technique ARIA16, which describes associating a user interface control, such as a form field, with text on the page that labels it.

Correct use is not guaranteed by simply adding the attribute. The referenced id must exist and point to text that actually describes the element, and when multiple ids are supplied the referenced text is concatenated in the order listed. A broken reference or a poorly chosen order can produce a confusing or empty accessible name. For this reason, implementation should be confirmed through manual and assistive technology testing; automated checks alone do not confirm that the resulting accessible name is meaningful. This entry is informational and not legal advice.

Who it's relevant to

Front-end and accessibility engineers

Developers implementing forms, controls, and landmark regions use aria-labelledby to give elements accessible names drawn from visible text. They are responsible for ensuring referenced ids exist and are unique, that the referenced text is meaningful, and that the concatenation order produces a coherent name. Following the pattern in WCAG technique ARIA16 and verifying results with assistive technology is part of correct implementation.

UX and content designers

Designers who define visible labels and interface copy influence what aria-labelledby can reference. Because the attribute reuses on-screen text, clear and descriptive visible labels directly improve the quality of the accessible name that assistive technology announces.

QA and accessibility testers

Testers confirm that the accessible name produced by aria-labelledby is present, correct, and understandable. Since automated checks detect only a portion of issues and cannot confirm that a name is meaningful, manual review and screen reader testing are needed to catch broken references, incorrect ordering, or empty names.

Compliance and accessibility program leads

Those overseeing accessibility conformance efforts should understand where aria-labelledby fits among labeling techniques such as native HTML labels and aria-label, and when it is the preferred choice. Meeting a WCAG technique supports conformance goals but does not by itself guarantee an accessible experience or legal compliance; consult qualified counsel for legal questions.

Inside aria-labelledby

aria-labelledby attribute

A WAI-ARIA attribute that provides an accessible name for an element by referencing the ID or IDs of one or more other elements whose text content serves as the label.

ID reference list

The attribute's value is a space-separated list of one or more element IDs. The referenced elements' text content is concatenated, in the order listed, to form the accessible name.

Accessible name computation

aria-labelledby participates in the accessible name and description computation defined by the W3C. When present, it generally takes precedence over other naming methods such as aria-label or a native label element.

Referenced element content

The label is derived from the visible or programmatically available text of the referenced elements, allowing existing on-screen text to be reused as an accessible name rather than duplicating it.

Relationship to aria-label

Both attributes set an accessible name, but aria-labelledby points to existing element content by ID, while aria-label supplies a string directly in the attribute. Where both are present, aria-labelledby is commonly given precedence in the name computation.

Common questions

Answers to the questions practitioners most commonly ask about aria-labelledby.

Does aria-labelledby work the same way as aria-label?

No. While both provide an accessible name, they work differently. aria-label takes a string value directly in the attribute, whereas aria-labelledby takes one or more ID references that point to other elements in the DOM whose text content becomes the accessible name. aria-labelledby is generally preferred when visible text already exists on the page that should serve as the label, because it reuses on-screen content rather than duplicating it in an attribute. When both aria-labelledby and aria-label are present on the same element, aria-labelledby commonly takes precedence in the accessible name calculation.

Does adding aria-labelledby automatically make an element accessible?

No. aria-labelledby contributes to the accessible name of an element, but a name alone does not guarantee an accessible experience. The element still needs an appropriate role, keyboard operability, correct states and properties, and it must behave predictably with assistive technology. Automated checks may confirm that an aria-labelledby reference resolves, but they detect only a portion of potential issues, so manual and assistive technology testing remain necessary to confirm the label is announced correctly and is meaningful in context.

Can aria-labelledby reference more than one element?

Yes. The attribute accepts a space-separated list of element IDs, and assistive technology generally concatenates the text content of the referenced elements in the order listed to form a single accessible name. This is often used to combine multiple pieces of visible text, such as a label and a unit or a group heading and a field label, into one coherent name.

What happens if aria-labelledby points to an ID that does not exist?

If a referenced ID does not match any element in the DOM, that portion of the label generally cannot be resolved and may be ignored, which can result in a missing or incomplete accessible name. Because the reference depends on IDs being present and unique in the document, broken or duplicated IDs are a common source of failures. Testing with assistive technology helps confirm that the intended name is actually announced.

Should I use aria-labelledby to reference hidden text?

aria-labelledby can reference text that is visually hidden but still present in the DOM, and this is sometimes done to provide context that is not needed on screen. However, referencing an element hidden with display:none or similar techniques may prevent the text from being used, depending on the implementation. When visible on-screen text conveys the label, referencing that visible text is generally preferred so the accessible name matches what sighted users see.

How does aria-labelledby differ from aria-describedby in practice?

aria-labelledby provides the accessible name, which identifies what an element is, while aria-describedby provides an accessible description, which offers additional supplementary information such as instructions or error details. Assistive technology commonly announces the name first and the description afterward, often with a pause or lower priority. Using the wrong one can cause important identifying information to be treated as an afterthought, so choose based on whether the referenced content names the element or merely describes it.

Common misconceptions

aria-labelledby can reference elements by class name, tag, or other selectors.

It references elements only by their ID attribute values. The value must be a space-separated list of valid IDs that exist in the same document; non-existent or mistyped IDs will not produce the intended accessible name.

Using aria-labelledby guarantees an accessible and usable experience.

Setting an accessible name is one factor among many. It does not by itself ensure usability, and meeting individual success criteria does not guarantee an accessible experience for all users or immunity from legal claims. Manual and assistive technology testing remain necessary because automated tools detect only a portion of issues.

aria-labelledby and aria-describedby serve the same purpose.

aria-labelledby contributes to the accessible name (what the element is), while aria-describedby contributes to the accessible description (additional supplementary information). They are computed separately and are generally announced differently by assistive technologies.

Best practices

Ensure every ID listed in aria-labelledby exists in the document and matches exactly, since typos or missing IDs prevent the accessible name from being formed as intended.

Reuse existing visible text as the label where possible so the accessible name stays synchronized with what sighted users see.

List multiple IDs in the intended reading order when concatenating text, and verify the resulting name reads clearly since referenced content is joined in the order specified.

Prefer native labeling mechanisms, such as a label element for form controls, where they suffice, and reserve aria-labelledby for cases where existing content should provide the name.

Verify the computed accessible name with assistive technologies rather than relying on automated checks alone, as automated testing detects only a portion of issues.

Understand the precedence rules: where aria-labelledby, aria-label, and native labels coexist, confirm which one is actually announced and remove redundant or conflicting sources.