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 ecommerce
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:
- Find every custom JavaScript component (modals, dropdowns, carousels, tabs, accordions)
- Test each with keyboard navigation
- Test each with a screen reader (NVDA or VoiceOver)
- Verify that state changes (open/closed, selected/unselected) are announced
Most ecommerce 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.