Free community resource
WCAG 4.1.2

ARIA Roles

ARIA roles tell assistive technologies what an element is — its type and purpose.
When native HTML semantics are insufficient or unavailable, roles bridge the gap
between the DOM and the accessibility tree.
[1]


The first rule of ARIA

Before using ARIA, always check whether a native HTML element already provides
the semantics you need. The first rule of ARIA use is: do not use ARIA if a
native HTML element or attribute with the required semantics exists.
[2]

A button is better than a div with role="button" every time. The native element
is keyboard accessible, correctly announced, and requires no additional scripting.


Role categories

Landmark roles define page regions. Examples: main, navigation, banner,
contentinfo. See the ARIA Landmarks article for full details.

Widget roles describe interactive controls:
[1]

Role Purpose
button A clickable control that triggers an action
checkbox A two or three-state toggle
dialog A modal or non-modal dialog
listbox A widget allowing selection from a list
menu / menuitem Application menu patterns
slider A range input
tab / tabpanel / tablist Tab interface components
tooltip A popup label

Document structure roles describe content organisation. Examples: heading,
list, listitem, table, row, cell, img, figure.

Live region roles announce dynamic content changes. Examples: alert, status,
log, timer.


Applying roles correctly

Roles must match the element's actual behaviour. Applying role="button" to an
element creates the expectation that it responds to Enter and Space key presses.
If your JavaScript only handles click events, keyboard users will find it broken.
[3]

When you apply a widget role, you take on the responsibility of implementing all
expected keyboard interactions for that pattern. Refer to the ARIA Authoring
Practices Guide (APG) for the keyboard expectations of each role.


Roles that carry no semantics

role="presentation" and role="none" remove an element's native semantics from
the accessibility tree. Use these only when an element is purely decorative or
when its native semantics would interfere with an ARIA pattern.


Common mistakes

Redundant roles. Adding role="button" to a button element is unnecessary
and adds noise to the accessibility tree.

Invalid role on element. Some roles are only valid on certain elements.
role="option" must be inside an element with role="listbox". Misuse of role
hierarchy breaks screen reader announcements.

Role without required states. Many roles require associated ARIA states and
properties. A checkbox without aria-checked, or a combobox without aria-expanded,
is incomplete.
[2]


References

  1. W3C. WAI-ARIA 1.2 — Role Definitions. https://www.w3.org/TR/wai-aria-1.2/#role_definitions
  2. W3C Web Accessibility Initiative. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/
  3. W3C Web Accessibility Initiative. Understanding Success Criterion 4.1.2: Name, Role, Value. https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html

Last edited Apr 5, 2026, 5:26 PM · P**** J****