What is ARIA and when should I use it?

ARIA (Accessible Rich Internet Applications) adds accessibility context to HTML that native elements can’t convey alone. The first rule of ARIA: don’t use ARIA if native HTML will do the job. Misused ARIA makes sites less accessible, not more.

What ARIA is for

ARIA is a set of HTML attributes defined by the W3C that adds semantic information to elements. Screen readers and other assistive technologies use this information to present a meaningful interface to users who can’t see the visual design.

The need for ARIA emerged because JavaScript-heavy applications build interface components — modals, accordions, tabs, carousels, autocomplete fields — that native HTML doesn’t have tags for. A <div> can be styled to look like a dropdown, but it doesn’t carry any information that tells a screen reader what it is or how to interact with it.

ARIA bridges this gap: <div role="listbox"> tells a screen reader this is a list of options. <div aria-expanded="false"> communicates that this element is collapsed and can be expanded.

The five rules of ARIA

Rule 1: Don’t use ARIA if native HTML does the job. If you need a button, use <button>. If you need a text input, use <input type="text">. Native HTML elements have built-in accessibility semantics and keyboard behavior that ARIA-on-a-div must replicate manually. Using native elements is less code, less risk, and better supported.

Rule 2: Don’t change native semantics unless required. Adding role="button" to an <a> tag creates a confusing element that’s announced as a button but behaves like a link. If you need button behavior, use a button element.

Rule 3: All interactive elements must be keyboard operable. If you use ARIA to make a custom component interactive, you must also implement the keyboard interactions manually. A custom dropdown with role="listbox" that can only be operated with a mouse is worse than no ARIA at all — it implies keyboard support that doesn’t exist.

Rule 4: Don’t hide focusable elements. Using aria-hidden="true" removes an element from the accessibility tree. If the element is also focusable (a button, link, or input), keyboard users can still reach it — but screen reader users get no information about it. Only apply aria-hidden to elements that are also tabindex="-1" or genuinely non-interactive.

Rule 5: All interactive elements need accessible names. Every button, link, and form control needs a name that screen readers can announce. This comes from visible text content, aria-label, aria-labelledby, or an associated <label>. An icon-only button (a magnifying glass for search, a shopping cart icon) has no visible text — it needs aria-label="Search" or aria-label="View cart".

Common ARIA patterns in e-commerce

Modal dialogs (size guides, quick-view product windows): Use role="dialog", aria-modal="true", aria-labelledby pointing to the modal title. Trap focus inside the dialog when open. Return focus to the triggering element when closed.

Navigation dropdowns: Use role="navigation" on the nav landmark, aria-haspopup="true" on items with submenus, aria-expanded to reflect open/closed state. Submenus should be operable with keyboard.

Product image carousels: Use role="region" with aria-label="Product images", aria-live="polite" to announce slide changes, and visible previous/next buttons with descriptive labels.

Tabs (for product specifications, reviews, etc.): Use the ARIA tab pattern: role="tablist" on the container, role="tab" on each tab, role="tabpanel" on each content area. Keyboard: Arrow keys move between tabs, Enter/Space activates.

Form error messages: Use aria-describedby to link the error message element to the input field. Use role="alert" on dynamically injected error messages to ensure they’re announced immediately.

How to audit ARIA usage

Run axe or WAVE on your site to find obvious ARIA misuse. Then do a manual audit:

1. Find every custom JavaScript component (modals, dropdowns, carousels, tabs, accordions)
2. Test each with keyboard navigation
3. Test each with a screen reader (NVDA or VoiceOver)
4. Verify that state changes (open/closed, selected/unselected) are announced

Most e-commerce ARIA failures fall into four categories: custom dropdowns without keyboard support, modals that don’t trap focus, carousels that don’t announce slide changes, and icon-only buttons with no accessible name.

If your development team hasn’t tested their custom components with a screen reader, assume ARIA is being misused somewhere. A UX audit includes assistive technology testing to surface these issues.