ARIA Label – Accessible Names for Screen Readers and Assistive Technologies
ARIA label (aria-label) is an HTML attribute from the WAI-ARIA specification that assigns an accessible name to interactive elements – regardless of whether visible text is present. Screen readers and other assistive technologies announce this value when a user focuses the element, enabling full navigation without visual perception.
The attribute is particularly critical for buttons containing only an icon, linked images, and form fields without visible labels. In these cases, aria-label provides the only accessible information about an element's purpose for users of assistive technologies – making it a core tool for digital accessibility across the internet.
Since 28 June 2025, the European Accessibility Act (EAA) requires businesses to meet WCAG 2.1 Level AA compliance. A missing aria-label on interactive elements directly violates WCAG Success Criterion 4.1.2 (Name, Role, Value) and can result in legal enforcement actions under national EAA implementations.
ARIA Label at a Glance
- Definition: HTML attribute from the WAI-ARIA specification – assigns an accessible name to elements that is announced by screen readers
- Typical use: Icon buttons, linked images, form fields, and interactive controls without visible text
- Screen reader behavior: The aria-label value replaces the visible element content as the announced name in the accessibility tree
- Variants:
aria-labelledbyreferences existing text via ID (higher priority);aria-describedbyprovides supplementary descriptions - WCAG relevance: Required under WCAG 2.1 Criterion 4.1.2 (Name, Role, Value) – directly relevant for EAA compliance
What Is an ARIA Label? – Definition and Fundamentals
ARIA stands for Accessible Rich Internet Applications – a W3C standard for improving the accessibility of web content for assistive technologies. The attribute aria-label is one of the most fundamental tools in this specification: it assigns an accessible name directly to an HTML element without that name needing to be visually displayed.
The attribute value is a plain text string. Screen readers announce this value when the user focuses the element. Example: a button containing only a trash icon without visible text receives aria-label="Delete entry". The screen reader then outputs "Delete entry, button" – complete information for users without sight.
Important: aria-label should only be used when no native HTML element or visible text already adequately describes the function. Semantic HTML like <button> with text content is always preferable. ARIA fills gaps that native HTML cannot close – it is not a substitute for semantic structure.
Screen Readers and ARIA Roles: How the Accessibility Tree Works
When a screen reader processes a page, it builds an accessibility tree – a simplified representation of the DOM containing only accessibility-relevant information. Each element in this tree has a name, a role, and optionally a value. The aria-label attribute directly influences the "name" entry of an element in this tree.
The priority for computing the accessible name is clearly defined by the W3C specification:
- 1st priority:
aria-labelledby– references visible text viaidattribute - 2nd priority:
aria-label– direct text value in the attribute - 3rd priority: Native name from HTML element content,
titleattribute, or associated<label> - No name present: WCAG 4.1.2 violation – users receive no usable information about the element
ARIA roles define what type of element is present – role="button", role="img", role="dialog" – and determine which ARIA attributes are permitted. aria-label is valid on most interactive roles and is correctly processed by all major accessibility tools and screen reader applications.
aria-label, aria-labelledby and aria-describedby Compared
These three ARIA attributes are frequently confused but serve clearly distinct purposes:
- aria-label: Assigns an accessible name directly as a text value. Use when no suitable visible text exists in the element.
- aria-labelledby: References another element via
idas the name source. Takes precedence overaria-label– preferred when suitable visible text already exists. - aria-describedby: Provides a supplementary description, not a name. The screen reader announces the description after the element name – suitable for error messages, format hints, or additional information.
A practical example: a search field receives its name via aria-labelledby="search-heading" pointing to a visible heading. Additionally, aria-describedby="search-hint" provides a format hint. Correct id assignment is critical here – without unique, valid IDs, aria-labelledby does not function. Developers must never use duplicate IDs.
Practical Use Cases: Button, Icon, Image and Form
The most common scenarios for aria-label in development practice:
- Icon button:
<button aria-label="Close menu"><svg ...></svg></button>– the button contains only an icon with no visible label - Linked image:
<a href="/" aria-label="Go to homepage"><img src="logo.svg" alt=""></a>– when the logo already carries an empty alt attribute - Search field without label:
<input type="search" aria-label="Search website">– no visible<label>element present - SVG image with role:
<div role="img" aria-label="Bar chart: Revenue Q1–Q4 2024">– for complex CSS- or SVG-based graphics without a native<img>element
The golden rule for developers: native HTML with visible text always takes priority. aria-label solves the case where semantic HTML elements alone are insufficient. Applied consistently, it measurably improves the accessibility of any website – and secures WCAG compliance under the EAA.
SiteCockpit Solution
easyMonitoring automatically detects missing ARIA labels
Missing or empty aria-label attributes are among the most common WCAG violations – and without systematic monitoring, they often go undetected. easyMonitoring scans your website automatically for interactive elements without an accessible name: icon buttons without labels, form fields without descriptions, linked images without accessible text. Each finding is categorized by WCAG criterion, prioritized by severity, and displayed directly in the dashboard – with a reference to the exact location in the code.
Detect ARIA gaps immediately after deployment – before they become EAA enforcement issues.
Discover easyMonitoring →Frequently Asked Questions about ARIA Label
Can aria-label replace visible text?
Technically yes – but it is not recommended. When aria-label and visible text differ, users of speech input software may have problems: voice commands must match the visible text. The accessible name should contain or match the visible text to avoid discrepancies.
Do I need to set aria-label on every button?
No. Buttons with visible, descriptive text do not need aria-label – the text content is automatically used as the accessible name. The attribute is only necessary when the button contains no visible text or when the text alone does not clearly convey the button's purpose.
How do I test whether my aria-label works correctly?
Most reliably with a real screen reader such as NVDA, JAWS, or VoiceOver. Alternatively, the Accessibility tab in Chrome DevTools shows the computed name in the accessibility tree. Automated tools like easyMonitoring detect WCAG violations from missing names across all pages of a website.
Does aria-label apply to ARIA roles like role="img"?
Yes. When an element is assigned an ARIA role that supports a name – such as role="img", role="dialog", or role="region" – an accessible name must always be provided, either via aria-label or aria-labelledby. Without a name, the element is not uniquely identifiable for screen reader users.
Are ARIA labels correctly implemented on your website?
Missing accessible names are among the most common yet invisible WCAG barriers – nearly impossible to spot without a screen reader. With easyMonitoring, you automatically scan your entire website for ARIA gaps and WCAG violations – and demonstrate EAA compliance with verifiable reports.
Try for free