ARIA Roles Reference & Validator

A searchable reference for every common WAI-ARIA role — grouped by category (widget, composite, landmark, document-structure, live-region), with required attributes, ownership constraints, keyboard interaction expectations, and common misuse notes. Type a role name in the validator below the table to see its required attributes and quick-check its usage.


How to use the ARIA Roles Reference & Validator

Type in the Search box to filter by role name or description — results update instantly. Columns explain:

  • Category — WAI-ARIA grouping: Widget (interactive controls), Composite (widget containers managing children), Landmark (page-region navigation), Document Structure (non-interactive content structure), or Live Region (dynamic update announcements).
  • Required Attrs — aria-* attributes that MUST be present for the role to be valid. Missing them produces an axe/Lighthouse violation.
  • Required Context / Children — the role must be owned by a specific parent, or must contain specific child roles.
  • Keyboard — the interaction pattern browsers and screen readers expect (you must implement this in JS).

Use the Role Validator below the table to type a single role name and get a focused view of its constraints — useful while writing component markup.

WAI-ARIA roles explained

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a W3C specification that lets you communicate semantic meaning to assistive technologies when native HTML elements don't cover your use case. An ARIA role overrides or supplements the element's implicit role. For example, <div role="button"> tells screen readers "this is a button", even though a <div> has no native interactive semantics.

The first rule of ARIA is: don't use ARIA if a native HTML element already does the job. <button> is better than <div role="button"> because the native element brings keyboard focus, click/enter activation, and styling hooks for free. ARIA roles must be paired with the correct implementation: a role="tab" without the companion keyboard handling (arrow-key navigation) and state management (aria-selected) is worse than no ARIA at all — it sets expectations that the AT user cannot fulfil.

Roles fall into two groups: abstract roles (like widget and structure) that exist only as base classes in the taxonomy and must never appear in markup; and concrete roles that you actually use. This reference covers the concrete roles most commonly needed in web UIs. For the complete taxonomy see the WAI-ARIA 1.2 specification.

Common use cases

  • Component library authoring — verify the correct role, required attributes, and keyboard contract for every new component before it ships.
  • Code review — quickly look up whether a peer\'s ARIA usage is correct without leaving your workflow.
  • Accessibility audit prep — understand what axe or WAVE will flag before running the scanner, so you can fix proactively.
  • Learning ARIA — the keyboard column shows which interaction patterns each role implies, helping developers understand what JS they need to write alongside the markup.
  • Role validator during debugging — type a role you\'re uncertain about into the validator to immediately see its required attributes and ownership constraints.

Frequently asked questions

What's the difference between role="presentation" and role="none"?

"none" is the modern name; "presentation" is the legacy alias. Both do the same thing: strip the element's native semantics so it becomes invisible to the accessibility tree. Use role="none" for images and tables used purely for layout (though layout tables are generally discouraged).

When do I need aria-required vs the HTML required attribute?

If you use a native or