ARIA Labels: The Complete Guide for Web Developers

What Is ARIA?

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes defined by the W3C that provide additional semantic information to assistive technologies. ARIA was created to bridge the gap between modern, interactive web applications and assistive technologies like screen readers that were originally designed for static HTML documents.

ARIA attributes do not change the visual appearance or behavior of your website — they only affect how assistive technologies interpret and present content to users. When used correctly, ARIA makes complex web applications accessible. When used incorrectly, it can make things worse.

The First Rule of ARIA

The most important thing to know about ARIA is the first rule of ARIA use: "If you can use a native HTML element with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so."

In other words, always prefer native HTML elements over ARIA. A <button> element is always better than <div role="button">. A <nav> element is always better than <div role="navigation">. Native elements come with built-in keyboard support, focus management, and semantics that ARIA attributes alone cannot fully replicate.

Key ARIA Labeling Attributes

aria-label

The aria-label attribute provides an accessible name for an element when no visible text label exists. It is read by screen readers but not displayed visually.

When to use:

• Icon buttons without visible text (e.g., a close button with only an × symbol)
• Navigation landmarks when multiple nav elements exist on a page
• Form inputs where a visible label is not feasible (though visible labels are always preferred)

Example:

<button aria-label="Close dialog">×</button>
<nav aria-label="Main navigation">...</nav>
<nav aria-label="Footer navigation">...</nav>

aria-labelledby

The aria-labelledby attribute references the ID of another element that serves as the label. Unlike aria-label, it uses existing visible text on the page, which is generally preferred because sighted users and screen reader users receive the same information.

When to use:

• When a visible heading or text element serves as the label for a section
• To associate a dialog with its title
• When combining multiple text elements into a single label

Example:

<h2 id="billing-heading">Billing Address</h2>
<section aria-labelledby="billing-heading">
  ...form fields...
</section>

aria-describedby

The aria-describedby attribute references elements that provide additional descriptive text for a component. Unlike labels, descriptions are supplementary — they provide extra context but are not the primary identifier.

When to use:

• To associate help text or instructions with a form field
• To connect error messages with their fields
• To provide additional context for complex UI elements

Example:

<label for="password">Password</label>
<input type="password" id="password" aria-describedby="password-help">
<p id="password-help">Must be at least 8 characters with one number.</p>

ARIA Roles

ARIA roles define what type of element something is. They tell assistive technologies how to treat and present the element.

Landmark Roles

Landmark roles help screen reader users navigate the page structure:

• role="banner" — equivalent to <header>
• role="navigation" — equivalent to <nav>
• role="main" — equivalent to <main>
• role="contentinfo" — equivalent to <footer>
• role="complementary" — equivalent to <aside>
• role="search" — equivalent to <search> (HTML5.2+)

Remember the first rule: use the native HTML elements when possible instead of applying these roles to div elements.

Widget Roles

Widget roles communicate the type and behavior of interactive components:

• role="button" — for clickable elements that are not native buttons
• role="dialog" — for modal dialog windows
• role="alert" — for important messages that need immediate attention
• role="tab", role="tablist", role="tabpanel" — for tab interfaces
• role="menu", role="menuitem" — for application-style menus (not navigation menus)
• role="tooltip" — for tooltip popups

ARIA States and Properties

Common States

• aria-expanded="true/false" — indicates whether a collapsible section is open or closed
• aria-selected="true/false" — indicates the selected state of tabs, options, etc.
• aria-checked="true/false/mixed" — indicates the checked state of checkboxes
• aria-disabled="true" — indicates an element is visible but not interactive
• aria-hidden="true" — hides an element from assistive technologies
• aria-pressed="true/false" — indicates the pressed state of toggle buttons

Live Regions

Live regions announce dynamic content changes to screen readers:

• aria-live="polite" — announces changes when the user is idle (most common)
• aria-live="assertive" — interrupts the user to announce changes (use sparingly)
• role="status" — implicit aria-live="polite"
• role="alert" — implicit aria-live="assertive"

Common ARIA Mistakes

1. Overusing ARIA

Adding ARIA everywhere "just in case" often causes more problems than it solves. Redundant ARIA on native elements can confuse screen readers. For example, <button role="button"> is redundant and should simply be <button>.

2. Using aria-label on Non-Interactive Elements

Not all elements support aria-label. Using it on generic elements like <div> or <span> without a role may be ignored by assistive technologies. Apply aria-label to interactive elements, landmarks, and elements with explicit roles.

3. aria-hidden on Focusable Elements

Setting aria-hidden="true" on an element that can receive keyboard focus creates a serious accessibility issue: the element is hidden from assistive technologies but the user can still tab to it, creating a confusing experience.

4. Using role="menu" for Navigation

The role="menu" is for application-style menus (like right-click context menus), not for website navigation. Navigation menus should use <nav> with a list of links.

5. Not Updating ARIA States

ARIA states must be dynamically updated via JavaScript when the state changes. Setting aria-expanded="false" on an accordion header but never updating it to "true" when opened is worse than having no ARIA at all, because it provides incorrect information.

Testing ARIA Implementation

To verify your ARIA implementation is correct:

1. Automated scanning: Use EAAPass to catch common ARIA errors like missing labels, invalid roles, and accessibility issues across your entire site.
2. Screen reader testing: Test with NVDA (Windows), VoiceOver (Mac/iOS), or TalkBack (Android) to hear how your ARIA attributes are interpreted.
3. Browser accessibility tree: Use Chrome or Firefox DevTools to inspect the accessibility tree and verify that elements have the correct roles, names, and states.
4. axe DevTools: The browser extension catches many ARIA misuse issues.

ARIA Quick Reference

Here is a quick reference for the most common accessibility needs:

• Icon button needs a name: Use aria-label
• Section needs a label from visible heading: Use aria-labelledby
• Form field needs extra help text: Use aria-describedby
• Collapsible content: Use aria-expanded on the trigger
• Dynamic content updates: Use aria-live on the container
• Hide decorative elements: Use aria-hidden="true"
• Required form field: Use the HTML required attribute (not aria-required)

Start Auditing Your ARIA Usage

ARIA is powerful but easy to misuse. Run your website through EAAPass to identify ARIA issues alongside all other WCAG 2.1 AA requirements. Our audit will flag incorrect ARIA usage and guide you toward proper implementation. Get your free audit now.