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

aria-label

Also known as: ARIA label, aria-label attribute
Simply put

aria-label is a piece of code added to a web element, such as a button or link, that gives it a text name for assistive technology to announce. When a screen reader reaches an element with an aria-label, it reads the label text aloud, which helps when the element has no visible text of its own. It is part of ARIA, a set of markup created by the W3C to make web content more accessible.

Formal definition

aria-label is an attribute defined by the W3C's Accessible Rich Internet Applications (ARIA) specification that assigns a string value serving as the accessible name for an element. It is commonly used to name objects that lack visible or programmatically associated text, such as icon-only buttons, and the value is exposed to assistive technologies like screen readers. The attribute applies only to elements whose role permits naming; per ARIA guidance, roles that prohibit naming will not expose an aria-label value. Its use is described in WCAG 2.2 technique ARIA6 as one method for providing labels for objects, though conformance with a specific WCAG success criterion depends on correct implementation and should be verified through manual and assistive technology testing. This entry describes the technical attribute and is not legal advice.

Why it matters

Many interface elements convey their purpose visually without any readable text. An icon-only button showing a magnifying glass, a close control marked with an X, or a link wrapped around an image may be perfectly clear to sighted users but present nothing meaningful to someone using a screen reader. When such an element lacks an accessible name, assistive technology may announce only its role, such as "button," leaving the user unable to determine what it does. aria-label addresses this gap by supplying a text name that assistive technologies can announce, making otherwise unlabeled controls usable.

Providing accessible names is closely tied to WCAG expectations around labeling and name, role, and value. The W3C describes aria-label in technique ARIA6 as one method for providing labels for objects. However, meeting a specific success criterion depends on correct implementation, and using aria-label does not by itself guarantee conformance or an accessible experience. An aria-label with vague, inaccurate, or duplicated text can be as confusing as no label at all, and automated tools may detect that a label is present without evaluating whether it is meaningful.

Because aria-label overrides other potential sources of an element's accessible name, careless use can also suppress visible text that users rely on. This makes verification important: the attribute should be confirmed through manual review and testing with actual assistive technology rather than assumed to work from its presence in the markup alone. This entry describes the technical attribute and is not legal advice.

Who it's relevant to

Web Developers and Front-End Engineers
Developers implementing interactive components use aria-label to give accessible names to controls that lack visible text, such as icon-only buttons and image links. They need to understand that the attribute applies only to elements whose role permits naming and that it can override other sources of an accessible name, so it should be used deliberately and verified with assistive technology.
Accessibility Engineers and QA Testers
Those auditing interfaces evaluate whether aria-label values are present, accurate, and meaningful. Because automated checks may confirm that a label exists without assessing its quality, testers should combine automated tools with manual review and screen reader testing to confirm the announced name matches the element's purpose.
UX and Content Designers
Designers who specify icon-based controls and concise interfaces influence where accessible names are needed. Coordinating with developers on clear, descriptive label text helps ensure that visually communicated meaning is also conveyed to users of assistive technology.
Compliance and Accessibility Program Owners
Those responsible for accessibility programs should recognize aria-label as one technique cited in WCAG guidance for labeling objects, while understanding that its use does not by itself guarantee conformance with any success criterion or legal compliance. Requirements evolve through regulation and case law, and questions of legal obligation should be directed to qualified legal counsel.

Inside aria-label

ARIA attribute
aria-label is an attribute defined by the W3C's Accessible Rich Internet Applications (ARIA) specification, used to provide an accessible name for an element when no visible text label is present or when the visible label is insufficient.
Accessible name
The value of aria-label supplies the accessible name that assistive technologies, such as screen readers, announce to users when they encounter the element.
String value
aria-label takes a plain text string as its value, unlike aria-labelledby, which references the IDs of other elements to construct the accessible name.
Override behavior
When present, aria-label generally takes precedence over other sources of an accessible name for many elements, such as an element's inner text content, which can hide that visible text from assistive technology if used carelessly.
Element applicability
aria-label is intended for interactive or meaningful elements that support naming, such as buttons, links, and form controls; it is generally not honored on many static or non-interactive elements without an appropriate role.

Common questions

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

Does adding an aria-label make an element accessible?
Not on its own. An aria-label supplies an accessible name that assistive technologies can announce, but it does not address keyboard operability, focus management, appropriate roles, states, or visible presentation. An element can have a correct aria-label and still be unusable if, for example, it cannot be reached or operated with a keyboard. Accessible names are one part of a broader set of requirements, and conformance with a single technique does not guarantee an accessible experience for all users. Manual testing and testing with actual assistive technology are generally needed to confirm usability.
Should I add aria-label to every element to improve accessibility?
No. aria-label is intended for cases where a visible or programmatic accessible name is missing or insufficient, such as an icon-only button. Applying it broadly can override native semantics, suppress or replace content that is already exposed correctly, and create mismatches between what a user sees and what is announced. A widely cited principle in the accessibility community is that using native HTML elements and their built-in labeling mechanisms is generally preferable to adding ARIA. aria-label should be used deliberately, not by default.
When should I use aria-label instead of aria-labelledby?
aria-label provides an accessible name from a string value defined directly in the attribute, while aria-labelledby derives the name by referencing the IDs of other visible elements on the page. aria-labelledby is often preferred when suitable visible text already exists, because it keeps the accessible name synchronized with what sighted users see. aria-label is commonly used when there is no appropriate visible text to reference, such as labeling an icon-only control. When both are present, aria-labelledby generally takes precedence.
Does aria-label work on all HTML elements?
No. aria-label is generally respected on interactive elements and on elements with a semantic role that supports naming, such as buttons, links, and form controls. It is not reliably supported on many static or generic elements, such as plain span or div elements without an appropriate role, or on certain other elements per the ARIA specification. Support can also vary across browser and assistive technology combinations, so behavior should be verified through testing rather than assumed.
How does aria-label interact with visible text labels?
When aria-label is applied to an element that also has visible text, the aria-label value typically overrides the visible text as the accessible name announced by assistive technology. This can create a discrepancy between what a user sees and what is announced, which may confuse users of speech recognition software who attempt to activate a control by its visible name. Where visible text is present and adequate, referencing it with aria-labelledby, or relying on the visible text itself, is often the safer approach.
How can I verify that an aria-label is announced correctly?
Automated tools can detect some issues, such as an interactive element lacking any accessible name, but they detect only a portion of problems and cannot fully judge whether a name is meaningful or matches user expectations. Verification generally requires manual testing, including inspecting the computed accessible name in browser developer or accessibility inspection tools and testing with screen readers across different browser and assistive technology combinations. This helps confirm both that the label is exposed and that it reads clearly in context.

Common misconceptions

Adding aria-label to any element will make it accessible.
aria-label only provides an accessible name and is generally recognized on elements that support naming, such as interactive elements or those with appropriate roles. It does not add functionality, keyboard support, or a role, and it may be ignored on many non-interactive elements.
aria-label is interchangeable with visible text labels.
aria-label is not visible on screen and is exposed only to assistive technologies. Because it can override visible text content for the accessible name, mismatches between the visible label and the aria-label value can confuse users who rely on both, including speech input users.
Using aria-label guarantees WCAG conformance or a usable experience.
Correct use of aria-label may help satisfy relevant success criteria, but conformance depends on the full context and does not by itself guarantee an accessible experience. Manual and assistive technology testing are needed, since automated checks detect only a portion of issues.

Best practices

Prefer a visible text label or aria-labelledby referencing on-screen text when possible, and reserve aria-label for cases where no suitable visible label exists.
Apply aria-label to interactive elements or elements with an appropriate role that support naming, rather than to static, non-interactive elements where it may be ignored.
Keep the aria-label value concise, meaningful, and reflective of the element's purpose so screen reader users hear a clear accessible name.
Ensure the aria-label value is consistent with any visible text so that speech input users can activate controls by the name they see.
Verify results with manual testing and multiple screen readers, since automated tools alone cannot confirm that the accessible name is announced as intended.
Avoid using aria-label to hide or contradict important visible content, as its value can override an element's inner text for the accessible name.