Definition: WAI-ARIA (Accessible Rich Internet Applications) is a W3C specification of roles, states and properties written into HTML as attributes. It tells assistive technology what an element is and what state it is in, where HTML alone cannot express it. ARIA changes meaning only, never behaviour [1].
German: ARIA · Also: WAI-ARIA, ARIA attributes, ARIA roles · Last reviewed: 27 September 2026
What ARIA does
ARIA supplies three kinds of information, which the browser writes into the accessibility tree:
- Roles say what an element is:
role="tab",role="dialog",role="switch". - States say what condition it is in:
aria-expanded="true",aria-checked,aria-selected. - Properties provide relationships and names:
aria-label,aria-labelledby,aria-describedby,aria-controls.
A screen reader turns that into, say, "Filter, button, collapsed". Without ARIA, a disclosure menu built from <div> elements would have no role and no state.
The first rule: no ARIA where HTML will do
The W3C's guidance on using ARIA opens with a clear rule: if a native HTML element already has the meaning and behaviour you need, use that element [2]. A <button> is focusable, responds to Enter and Space and is announced as a button – no ARIA required. The ARIA Authoring Practices Guide warns explicitly that bad ARIA does more harm than no ARIA [3].
ARIA is a promise to the user. role="button" announces a button; your code then has to deliver keyboard focus, Enter, Space and the current state itself.
In code
<!-- Promises a button, doesn't deliver -->
<div role="button" onclick="toggle()">
Filter
</div><!-- Better: native element, state set by JS -->
<button type="button" aria-expanded="false"
aria-controls="filter">
Filter
</button>
<div id="filter" hidden>…</div>The script that opens the filter sets aria-expanded to "true" and removes hidden. That is how a screen reader user learns that something changed.
Common mistakes
- A role without behaviour:
role="button"on a<div>with notabindexand no key handling. aria-hidden="true"on focusable elements. Focus lands on something that does not exist for the screen reader.- States that don't keep up:
aria-expandedstays"false"while the menu is open. - Application roles for site navigation:
role="menu"promises arrow-key behaviour like a desktop application. A main navigation is a<nav>containing a list of links. - Invented roles and typos such as
role="botton"oraria-labeledbywith one "l". Browsers ignore them silently.
How Reviseberg handles it
Reviseberg runs every axe-core rule on every page. For ARIA these include aria-roles, aria-allowed-attr, aria-required-attr, aria-valid-attr-value, aria-required-children and aria-hidden-focus, which find invalid, incomplete and contradictory attributes. The keyboard agent reports keyboard:unreachable when an element carries a control role such as button or tab but no Tab press reaches it – exactly the case in the example above. Whether a role fits how the widget actually behaves is a matter of judgement, which is why we count WCAG 4.1.2 as only partly automatable [4].
Related terms
Semantic HTML · Accessible name · Accessibility tree · Landmark · Live region