About

WAI-ARIA defines 82 roles across 6 categories: landmark, widget, document structure, live region, window, and abstract. Misapplying a role - assigning role="button" without keyboard event handlers, or using role="tab" outside a tablist container - does not just fail WCAG 2.1 conformance. It actively harms users who depend on assistive technology by creating a semantic contract the interface cannot fulfill. This reference maps every role to its required properties, supported states, permitted child roles, and naming obligations so you can validate your markup before it ships.

Abstract roles (widget, roletype, structure, etc.) exist only in the taxonomy. They must never appear in authored content. The tool flags them distinctly. Note: ARIA is a repair mechanism. If a native HTML element conveys the same semantics - <button> instead of role="button" - prefer the native element. The first rule of ARIA: do not use ARIA if you do not have to.

Frequently Asked Questions

They are synonymous. The WAI-ARIA 1.1 specification introduced role="none" as an alias for role="presentation" because the latter was frequently misunderstood as hiding content from all users. Both roles strip the element's implicit semantics - a is no longer announced as a table by screen readers. Child elements retain their own semantics unless they are also presentational. Use role="none" in new code for clarity. Neither role hides content visually or from the accessibility tree entirely - that requires aria-hidden="true".

Abstract roles (roletype, structure, widget, command, input, composite, section, sectionhead, range, select, window) must never appear in authored content per the WAI-ARIA specification. Browsers and assistive technologies are required to ignore them. Your element will have no role semantics at all, which may be worse than the default implicit role. Automated accessibility testing tools like axe-core and WAVE will flag this as a violation.

A element without an accessible name (via aria-label, aria-labelledby, or title) is not exposed as a landmark region by assistive technologies per the HTML-AAM specification. This prevents every unnamed form on a page from cluttering landmark navigation. The same rule applies to

mapping to role="region". Providing a descriptive name like aria-label="Contact form" ensures the form appears in the landmarks list, aiding navigation for screen reader users.

Native HTML elements carry implicit ARIA roles. A

All interactive widget roles require keyboard support matching the ARIA Authoring Practices Guide (APG). Key examples: role="button" must respond to Enter and Space. role="tab" within a tablist requires Arrow keys for navigation, with Tab moving focus into the active tabpanel. role="combobox" requires a complex pattern: typing filters the popup listbox, Arrow keys navigate options, Enter selects, Escape closes. role="menu" expects Arrow key navigation with Home/End support. role="dialog" must trap focus within the dialog. Failing to implement these patterns creates a worse experience than not using ARIA at all.

Yes, landmark nesting is valid and sometimes expected. A navigation landmark inside a banner (header) landmark is common. Multiple navigation landmarks on a page are allowed if each has a unique accessible name (e.g., aria-label="Primary" vs aria-label="Footer"). However, nesting the same landmark type without distinct names creates confusion. Two unnamed role="navigation" regions are indistinguishable in a screen reader's landmark list. The main landmark should appear only once per page.

role="presentation" (or role="none") removes the semantic meaning of the element but keeps its content visible and accessible. Text inside a

is still read by screen readers - just not as a table. aria-hidden="true" removes the element and all its descendants from the accessibility tree entirely. Screen readers will not announce any of its content. Sighted users still see it. Critically, aria-hidden="true" must never be placed on focusable elements, as this creates a focus trap where keyboard users can reach an element that screen readers cannot announce.