ARIA Explained: When aria-label Helps and When It Hurts

Run an accessibility scan and you will see “ARIA” everywhere in the results — aria-label, aria-hidden, role — flagged alongside warnings you did not ask for and cannot interpret. The natural reaction is to tell your developer to add more of it. That reaction is usually wrong, and it is the single most expensive misunderstanding in this whole subject.

ARIA is a set of attributes that describe your page to screen readers. Used well, it is how a custom dropdown or modal becomes usable by someone who cannot see it. Used badly — and it is very often used badly — it overrides what the browser already got right, so a working button starts announcing itself as something it is not. Bad ARIA is worse than no ARIA, because no ARIA at least falls back to the truth. By the end of this guide you will be able to look at a scan result and tell which ARIA needs fixing, which needs deleting outright, and which was never the real problem.

What Is ARIA?

ARIA stands for Accessible Rich Internet Applications. It is a set of special HTML attributes created by the W3C (the organization that maintains web standards) to help web developers communicate information to assistive technologies like screen readers.

Think of it this way: when a sighted person visits your website, they can see that a button looks like a button, a menu looks like a menu, and a notification banner is separate from the main content. But screen readers cannot “see” your website. They read the underlying code. ARIA attributes add invisible labels, descriptions, and roles to that code so screen readers can understand the purpose and state of every element on the page.

For example, imagine you have a hamburger menu icon (those three horizontal lines). A sighted visitor instantly recognizes it as a menu toggle. But without proper markup, a screen reader might announce it as just “button” or even ignore it entirely. An aria-label="Open navigation menu" attribute tells the screen reader exactly what that button does.

Why ARIA Matters for Compliance

Both the European Accessibility Act (EAA) and ADA compliance expectations reference WCAG (Web Content Accessibility Guidelines) as the technical standard. Several WCAG success criteria directly relate to proper ARIA usage:

  • WCAG 4.1.2 (Name, Role, Value) requires that all user interface components have accessible names and roles that assistive technologies can read. ARIA is often how this requirement is met for custom components.
  • WCAG 1.3.1 (Info and Relationships) requires that information conveyed through presentation is also available programmatically. ARIA roles and properties help establish these relationships.
  • WCAG 2.4.4 (Link Purpose) requires that the purpose of each link can be determined from the link text or its context. ARIA attributes like aria-label and aria-describedby help clarify ambiguous links.

If your website uses custom interactive elements (dropdown menus, tabs, accordions, modal dialogs, sliders), chances are it needs ARIA to meet WCAG requirements.

The First Rule of ARIA: Do Not Use ARIA

This might sound contradictory, but the accessibility community has a well-known principle: if you can use a native HTML element that already has the semantics you need, use that instead of adding ARIA.

Native HTML elements like <button>, <nav>, <input>, <select>, and <dialog> come with built-in accessibility. A <button> element is automatically announced as a button by screen readers, receives keyboard focus, and responds to Enter and Space key presses. No ARIA needed.

Problems arise when developers use generic elements like <div> or <span> and try to make them behave like buttons or other interactive elements. These generic elements have no built-in semantics, so ARIA becomes necessary to patch in what native HTML would have provided for free.

This matters for you because if your website’s accessibility audit shows many ARIA-related issues, the root cause might be that the site was built with too many custom components when standard HTML would have worked better. It is often more reliable (and cheaper) to rebuild with native elements than to fix ARIA on custom ones.

Common ARIA Attributes You Will Encounter

Here are the ARIA attributes most likely to appear in your accessibility audits:

aria-label

Provides an accessible name for an element when the visible text alone is insufficient. Common uses include icon buttons, search fields without visible labels, and navigation landmarks.

Where you will see issues: Icon-only buttons (search, close, menu) that lack any text alternative. If your site has buttons with just an icon and no aria-label, screen reader users have no idea what those buttons do.

aria-hidden

Tells assistive technologies to ignore an element entirely. Used for decorative icons, duplicate content, or visual elements that add nothing for screen reader users.

Where you will see issues: When aria-hidden="true" is accidentally applied to important content, making it invisible to screen readers. Worse still is aria-hidden on something focusable — a keyboard user can still tab to it, but the screen reader has nothing to announce when they land.

One correction worth making, because it is a common piece of bad advice: aria-hidden is not the tool for a decorative image. An <img> with no alt attribute at all is what makes a screen reader read the file name aloud, and the fix is an empty alt="", which drops the image from the accessibility tree cleanly. Save aria-hidden for decorative markup that is not an image — an inline <svg>, or an icon-font <span> sitting next to real text. See alt text that screen readers actually find useful for where that line falls.

role

Defines what type of element something is when the HTML tag alone does not convey it. For example, role="navigation", role="dialog", or role="tab".

Where you will see issues: Missing roles on custom components. A <div> that works as a tab panel needs role="tabpanel" so screen readers know what it is.

aria-expanded

Indicates whether an expandable element (like a dropdown menu or accordion section) is currently open or closed. The value toggles between true and false.

Where you will see issues: Dropdown menus and accordions that do not communicate their open/closed state. Screen reader users cannot tell whether a menu is currently showing or hidden.

aria-live

Tells screen readers to announce dynamic content changes. Used for notification banners, chat messages, form validation errors, and real-time updates.

Where you will see issues: Important notifications like form errors or shopping cart updates that appear visually but are never announced to screen reader users.

aria-describedby

Links an element to additional descriptive text elsewhere on the page. Commonly used for form fields that have help text or error messages.

Where you will see issues: Form fields with instructions like “Password must be at least 8 characters” where the instruction exists visually but is not connected to the field for screen reader users.

How to Check ARIA on Your Website

You do not need to read code to identify ARIA problems. Here are practical approaches:

1. Run an Automated Scan

Tools like Google Lighthouse (built into Chrome), axe DevTools, or WAVE can detect many ARIA issues automatically. They will flag missing labels, incorrect roles, and invalid ARIA usage. Automated scanners only ever catch a fraction of accessibility problems — estimates commonly land somewhere around a third, though the real share depends heavily on the site and the tool, so treat any single percentage you read as a rough shape rather than a measurement. ARIA errors are at the favourable end of that range, because most of them are machine-checkable: an invalid role or a missing accessible name is a fact about the markup. Whether the ARIA you do have describes the component honestly is not something a scanner can tell you.

2. Use a Screen Reader

The best way to understand ARIA’s impact is to hear your website the way screen reader users do. On Mac, turn on VoiceOver (Command + F5) and navigate your site using Tab and arrow keys. On Windows, download NVDA (free) and do the same. Pay attention to whether interactive elements are announced with useful descriptions.

3. Check for the Most Common ARIA Mistakes

These patterns cause the most real-world problems:

  • Missing labels on icon buttons. Tab through your site. If you hear just “button” without any description, that button needs an aria-label.
  • Focus trapped in modals. Open any popup or dialog on your site. Can you close it with the Escape key? When you close it, does focus return to where you were? Proper ARIA dialog implementation handles this.
  • Incorrectly hidden content. If screen reader users report that they cannot find content that is clearly visible on screen, check whether aria-hidden="true" has been applied incorrectly.

4. Ask Your Developer or Agency Specific Questions

When discussing accessibility fixes with your developer, these questions help:

  • “Are we using native HTML elements wherever possible, or are we relying on ARIA to make custom elements accessible?”
  • “Do all our interactive components have correct ARIA roles and states?”
  • “Have we tested with a screen reader, not just automated tools?”

Common ARIA Mistakes and How to Fix Them

Putting aria-label on Non-Interactive Elements

aria-label on a <div> or <span> that is not interactive is usually ignored by screen readers. The fix is to ensure labels are on the actual interactive elements (buttons, links, form inputs) or on landmark elements like <nav>.

Using role=“button” Instead of a Real Button

Adding role="button" to a <div> makes screen readers announce it as a button, but it does not add keyboard support. Real <button> elements are focusable and respond to keyboard events automatically. The fix is to use actual <button> elements.

Leaving aria-expanded Out of Sync

If a menu toggle says aria-expanded="false" when the menu is visually open, screen reader users get incorrect information. This is a JavaScript bug where the attribute value is not updated when the state changes.

Overusing aria-hidden

Hiding content from screen readers should be deliberate and limited to truly decorative elements. Some themes and page builders aggressively apply aria-hidden, accidentally removing important content from the accessibility tree.

What to Tell Your CMS Provider or Developer

If your website audit reveals ARIA issues, here is a prioritized action list to share:

  1. Fix missing accessible names first. Buttons, links, and form fields without labels are the most impactful issues for real users.
  2. Replace custom components with native HTML where possible. This is often easier and more maintainable than fixing ARIA on custom code.
  3. Audit all modals and dialogs. These are the most complex ARIA patterns and the most commonly broken.
  4. Add aria-live regions for dynamic content. If your site has toast notifications, form validation, or real-time updates, these need to be announced.
  5. Test with a screen reader before launch. Automated tools cannot verify that ARIA is creating a good user experience. Only real screen reader testing can confirm that.

The four component types that account for most broken ARIA in the wild, each walked through pattern by pattern:

If your site was built with a component library or generated by an AI assistant, the ARIA mistakes that ship to production in React covers the ones that come pre-installed.

Need a real audit of your own site? Get an accessibility report.