ARIA Roles Cheatsheet — When to Use Each (And When to Skip)

ARIA roles tell assistive technology what an element is. Native HTML elements have implicit roles; custom widgets need explicit ones. Pick the right role for the right job — or skip ARIA entirely and use native HTML.

The first rule of ARIA

If a native HTML element does the job, use it. A already has the implicit role `button`. Adding `role="button"` to a recreates the worst version of what HTML gives you free.

Reach for ARIA roles only when (a) HTML has no equivalent, or (b) you need to communicate state HTML cannot express.

The 8 roles you actually need

role="dialog"

For modal popups. Pair with aria-modal="true" for true modal behavior. Also requires focus trap, Escape-to-close, focus return on close.

## Confirm delete

  ...

role="alertdialog"

Like dialog, but more urgent — usually for destructive confirmations. Screen readers handle this with higher priority.

role="alert"

For urgent, time-sensitive notifications. Implicit aria-live="assertive". Use for form submission errors, system failures.

role="status"

For non-urgent status updates. Implicit aria-live="polite". Use for "Saving...", "Loaded 12 items", cart count updates.

role="navigation"

Same as . Use the HTML element. Only fall back to `role="navigation"` on a when you cannot change the markup.

role="combobox"

For autocomplete fields with a dropdown of suggestions. Required pattern is complex — use react-aria or headlessui instead of hand-rolling.

role="tabpanel" + role="tablist" + role="tab"

The classic tabs widget. Each tab toggles a tabpanel. Arrow keys move between tabs; Tab moves into the panel. Implement the WAI-ARIA Authoring Practices pattern exactly.

role="region"

For an arbitrary content section that needs to be a landmark. Pair with aria-label or aria-labelledby. Sparingly — too many regions clutter screen reader landmark navigation.

Roles to almost never use

• role="button" on anything other than form-submitting buttons styled as "fake" buttons. Use ``.
• role="link" on anything other than CSS-styled spans that act as links. Use ``.
• role="list" + role="listitem" — same as and ``. Use HTML.
• role="banner", role="contentinfo" — same as and . Use HTML.

Common ARIA mistakes

• Adding role="button" to a div without keyboard handler. Use a ``.
• role="dialog" without focus management. Implementing the focus trap is the hard part. Use a library.
• aria-hidden="true" on focusable elements. Screen reader users hear nothing; keyboard users can still tab to a "hidden" element. Trap.
• Nested landmarks of the same type. Multiple without aria-label = screen reader lists them all without context.
• aria-label on a `` with role="button" instead of visible text. Voice-control users say "click Submit" and miss the button.

How to verify ARIA is correct

axe-core (and AccessProof) catches most static ARIA issues — invalid roles, required attributes missing, redundant roles. Manual screen reader testing catches the dynamic ones — focus management, announcement timing, role-vs-state mismatches.

Search WCAG criteria related to ARIA with our free lookup tool, or run a free WCAG scan to find every ARIA issue on your site.

---

Originally published on access-proof.com.