ARIA labels are one of the most misunderstood tools in web accessibility. Developers reach for aria-label the moment something needs an accessible name, and in many cases, that instinct causes more problems than it solves. According to WebAIM's annual analysis, pages that use ARIA actually average 41 percent more detected accessibility errors than pages without it. That statistic is not an argument against ARIA. It is evidence that most developers use ARIA incorrectly. This guide walks through every ARIA labeling attribute, explains when each one is the right choice, covers the mistakes that trip up even experienced developers, and provides code patterns you can apply immediately. Whether you are remediating an existing site for European Accessibility Act compliance or building a new application from scratch, getting ARIA labels right is foundational to passing any WCAG 2.2 audit.
ARIA Label Quick Reference
What ARIA Labels Actually Do (and What They Do Not)
ARIA stands for Accessible Rich Internet Applications. The WAI-ARIA specification, maintained by the W3C, provides a set of attributes that modify how elements appear in the browser's accessibility tree. That tree is what screen readers, voice control software, and other assistive technologies use to present your interface to people who cannot see or interact with it visually.
An ARIA label gives an element its accessible name. When a screen reader encounters a button, it announces the accessible name so the user knows what the button does. If that name is wrong, missing, or confusing, the user either cannot operate the interface or makes incorrect assumptions about what will happen when they activate the element.
Three attributes handle the majority of ARIA labeling work: aria-label, aria-labelledby, and aria-describedby. Each one behaves differently, and choosing the wrong one for a given situation is one of the most common accessibility failures our checker detects across thousands of scanned sites.
One thing ARIA labels do not do is change anything visually. Adding aria-label to a button does not add visible text. It only changes what assistive technology announces. This distinction matters because sighted users and screen reader users can end up perceiving completely different interfaces when ARIA is used carelessly.
The Five Rules of ARIA You Must Know
Before diving into specific attributes, these five rules from the W3C govern all ARIA usage. Break any of them and you risk making your interface less accessible, not more.
Rule one: if you can use a native HTML element or attribute with the built-in semantics and behavior you need, do that instead of adding ARIA. A native button element already has an implicit role of button, responds to keyboard events, and derives its accessible name from its text content. A div with role button and aria-label requires you to manually replicate all of that. Native HTML is always the safer choice.
Rule two: do not change native semantics unless you really have to. Adding role presentation to a heading strips its heading semantics from the accessibility tree. There is almost never a legitimate reason to do this.
Rule three: all interactive ARIA controls must be usable with a keyboard. If you create a custom checkbox using role checkbox, you must also handle Space key toggling, focus management, and the aria-checked state. Forgetting the keyboard interaction is exactly what makes ARIA-heavy pages rack up more errors.
Rule four: do not use role presentation or aria-hidden true on a focusable element. An element that can receive keyboard focus but is hidden from the accessibility tree creates a phantom control that keyboard users can reach but screen reader users cannot perceive.
Rule five: all interactive elements must have an accessible name. This is where aria-label, aria-labelledby, and native text content come into play. An icon button with no visible text and no aria-label is invisible to assistive technology.
aria-label: When and How to Use It Correctly
The aria-label attribute provides a string of text as the accessible name for an element. Screen readers announce this string instead of any other text content the element might contain.
Use aria-label when an interactive element has no visible text and no other mechanism provides an accessible name. The classic example is an icon button. A close button that only contains an X icon or SVG needs aria-label="Close" so screen readers announce Close button rather than just button.
Another valid use case is distinguishing repeated navigation landmarks. If your page has two nav elements, one for the main site navigation and one for breadcrumbs, adding aria-label="Main navigation" and aria-label="Breadcrumb" lets screen reader users jump to the correct one using their landmark navigation shortcuts.
Here is where developers go wrong. Do not use aria-label on elements that already have visible text. If your button says Submit, adding aria-label="Submit form" creates a disconnect. Screen reader users hear Submit form while sighted users see Submit. Under WCAG 2.2 Success Criterion 2.5.3 Label in Name, the accessible name must contain the visible text. Voice control users who say click submit will fail to activate a button whose accessible name is submit form because the speech recognition does not match.
Do not use aria-label on non-interactive elements like div or span in most cases. The attribute is technically allowed on elements with certain roles, but applying it to a generic div that has no role is ignored by most assistive technology.
A critical limitation: aria-label does not get translated by browser translation tools. Adrian Roselli documented this extensively and the issue persists through 2026. Chrome, Edge, and Firefox all skip aria-label values when translating a page. A German-speaking user who translates your English page will hear English aria-label text announced by their screen reader while reading German visible text. If your site serves multiple languages, use visible text techniques or aria-labelledby referencing visible text instead.
aria-labelledby: The Preferred Alternative
The aria-labelledby attribute sets the accessible name by referencing the id of one or more elements whose text content should serve as the name. It is more robust than aria-label for several reasons.
First, since aria-labelledby references visible text on the page, browser translation tools translate the referenced text. Screen reader users get a translated accessible name for free.
Second, aria-labelledby keeps visible text and accessible names synchronized automatically. If someone updates the visible heading text, the accessible name updates with it. With aria-label, you have to remember to update the attribute separately.
Third, aria-labelledby can concatenate text from multiple elements by listing multiple IDs separated by spaces. A dialog whose heading says Delete and whose subheading says Are you sure you want to remove this file can use aria-labelledby referencing both elements, producing an accessible name of Delete Are you sure you want to remove this file.
Use aria-labelledby when visible text already exists on the page that could serve as the accessible name. Common patterns include labeling sections with their headings, labeling modal dialogs with their title element, and labeling form groups with visible legend-like text.
One important override behavior: aria-labelledby takes precedence over both aria-label and native labeling mechanisms like the HTML label element. If an input has a label element, an aria-label attribute, and an aria-labelledby attribute, the accessible name comes from aria-labelledby. Only use one labeling mechanism per element to avoid confusion.
Here is a practical pattern for a dialog:
Your dialog div has role dialog and aria-labelledby pointing to the id of the h2 inside the dialog. The h2 says Confirm deletion. The screen reader announces Confirm deletion dialog when focus moves into it. No aria-label needed, no duplication of text, and translation works automatically.
aria-describedby: Adding Context Without Changing the Name
The aria-describedby attribute is often confused with aria-labelledby but serves a different purpose. It does not set the accessible name. It adds a description that screen readers announce after the name.
When a screen reader encounters an input with a label of Password and an aria-describedby pointing to text that says Must be at least 8 characters including one number, the announcement is Password, edit text, Must be at least 8 characters including one number. The name is Password. The description provides additional context.
Use aria-describedby for form field instructions, format requirements, error messages tied to specific fields, and supplementary information that helps users understand a control without changing its identity.
A common pattern for form validation: when a user submits a form with errors, each invalid field gets aria-describedby pointing to its error message element. The error message says something like Email address must include an @ symbol. The screen reader user hears both the field name and the error without needing to search the page for the message.
Do not use aria-describedby as a substitute for aria-label or aria-labelledby. An element with no accessible name but an aria-describedby still has no name. Screen readers may announce the description, but navigation shortcuts that list all buttons or links on a page only show accessible names, not descriptions. A button with no name but a description shows up as unnamed button in those lists.
Also note that aria-describedby content does not appear in screen reader shortcut lists. If a user pulls up a list of all links on the page, the description is not included. Only the accessible name appears there.
Common ARIA Label Mistakes and How to Fix Them
After running accessibility scans on over ten thousand websites, certain ARIA mistakes show up repeatedly. Here are the ones that cause the most real-world problems for screen reader users.
Mistake one: aria-label on elements that already have visible text. A link with visible text Learn more and aria-label Read more about our pricing creates a mismatch. Voice control users say click learn more and nothing happens. Fix: either change the visible text to be descriptive on its own, like Learn more about pricing, or remove the aria-label entirely and use visually hidden text appended to the link text.
Mistake two: using aria-label on a div or span without a role. A div with aria-label Description of product but no role attribute has that label ignored by most screen readers. Fix: either add an appropriate role like role region or, better, use a semantic element like section with the aria-label.
Mistake three: duplicating content between aria-label and visible text. A button containing the text Search and also carrying aria-label Search has no benefit. The native text content already provides the accessible name. The redundant aria-label just adds code to maintain. Fix: remove the aria-label.
Mistake four: using aria-label instead of a label element for form inputs. An input with aria-label Email but no visible label means sighted users have no text label either, unless there is a visible placeholder. Placeholders disappear when the user starts typing. Fix: use a proper label element associated with the input via the for attribute. If you absolutely must hide the label visually, use a CSS visually-hidden class rather than removing it from the DOM.
Mistake five: broken aria-labelledby references. An aria-labelledby attribute pointing to an id that does not exist in the DOM produces no accessible name at all. The element ends up unnamed. This often happens after refactoring when heading ids get changed but aria-labelledby references are not updated. Fix: search your codebase for all aria-labelledby attributes and verify each id reference resolves. Our accessibility checker flags broken id references automatically.
Mistake six: using aria-label on landmarks without making labels unique. Three nav elements all with aria-label Navigation defeats the purpose. Screen reader users see three landmarks with identical names and cannot distinguish them. Fix: give each landmark a unique, descriptive label like Main navigation, Footer links, and Breadcrumb.
ARIA Labels in Practice: Real Component Patterns
Theory is useful. Working patterns are better. Here are ARIA labeling approaches for the components that cause the most accessibility issues.
Icon buttons. Every icon-only button needs an accessible name. The most robust approach is including visually hidden text inside the button element, like a span with a visually-hidden class containing the text Close. This text gets translated, works with voice control, and provides the accessible name without aria-label. If you use aria-label instead, add the same text as a tooltip via the title attribute so that sighted keyboard users can discover the function.
Modal dialogs. Give the dialog role dialog and aria-labelledby pointing to its heading element. Add aria-modal true to indicate that content behind the dialog is inert. Manage focus: move focus to the first focusable element inside the dialog when it opens, trap focus within the dialog, and return focus to the trigger element when the dialog closes.
Navigation landmarks. Use the native nav element. If you have multiple nav elements, label each one with aria-label. Main site menu gets aria-label Main navigation. A sidebar table of contents gets aria-label Table of contents. Test by opening the screen reader landmark list and confirming each navigation region has a distinct, understandable name.
Form groups. Use fieldset and legend for related groups of controls like radio buttons or checkbox groups. The legend provides the accessible group label. Do not replace this pattern with div and aria-label because fieldset and legend have universal screen reader support while custom ARIA labeling on divs varies across assistive technology.
Data tables. Use the caption element or aria-labelledby to provide a table name. Each table header cell should use the th element. For complex tables with merged cells, use scope attributes on headers. The table name should describe what data the table presents, not just say Data table.
Live regions. Use aria-live polite for non-urgent updates like a success message after saving. Use aria-live assertive for urgent messages like error alerts. Do not put aria-live on elements that already exist with content. Instead, create the live region container first and then inject content into it. Screen readers only announce changes to content within a live region, not the initial content when the region appears.
Tab interfaces. The container gets role tablist. Each tab gets role tab and aria-selected true or false. The panel gets role tabpanel and aria-labelledby referencing its associated tab. Keyboard behavior requires arrow keys to move between tabs and Tab key to move from the active tab into the tab panel content.
Testing Your ARIA Labels
Writing correct ARIA is half the job. Verifying it works is the other half.
Start with an automated scan. Run your pages through our free accessibility checker at web-accessibility-checker.com. It detects missing accessible names, broken aria-labelledby references, aria-label on non-interactive elements, duplicate landmark labels, and other ARIA issues that can be flagged programmatically.
Then open the browser accessibility tree. In Chrome DevTools, open the Elements panel, select an element, and check the Accessibility tab. It shows the computed accessible name and where it came from. If the name says empty string or is missing, the element lacks a name. If it shows a value from aria-label when you expected it from aria-labelledby, you have a precedence issue.
Test with a screen reader. NVDA on Windows and VoiceOver on macOS are both free. Navigate the page and listen to what gets announced. Pay attention to buttons, links, form fields, landmarks, and dialogs. Does each one have a name that makes sense out of visual context? Can you tell the difference between similar controls just from what the screen reader says?
Verify keyboard navigation. Tab through the page. Every element that has an ARIA label should be reachable with the keyboard. If you added role button with aria-label to a div but forgot tabindex, keyboard users cannot reach it.
Test in multiple screen readers. NVDA and JAWS on Windows, VoiceOver on macOS, and TalkBack on Android each interpret ARIA slightly differently. An aria-label on a div with role group might be announced by one screen reader and ignored by another. Cross-testing catches these discrepancies.
Check the label in context. An aria-label of Click here makes no sense to a user who is navigating a list of all buttons on the page. Every accessible name should be understandable without visual context.