The five rules of ARIA use
- The first rule of ARIA: don't use ARIA if a native HTML element exists (button, nav, details).
- Don't change native semantics unnecessarily (e.g. <button role="heading">).
- Every interactive element with an ARIA role must be keyboard operable.
- Don't hide focusable elements with role="presentation" or aria-hidden="true".
- Every interactive element must have an accessible name.
Most common mistakes
The WebAIM Million report (2025) shows a correlation: pages that use ARIA have on average more detected accessibility errors than those without it. That is not proof that ARIA causes errors — more often, misused ARIA actively breaks the screen reader experience. Typical problems are roles without required attributes, conflicting states and “ARIA instead of HTML”.
Example
A button that expands a panel — aria-expanded communicates open/closed state to the screen reader. A native <button> already works with the keyboard (Enter/Space). The script still needs to toggle the panel and update aria-expanded.
HTML
<button type="button" aria-expanded="false" aria-controls="panel-faq">
Show answer
</button>
<div id="panel-faq" hidden>
Answer content…
</div>HTML
<div role="button" tabindex="0" aria-expanded="false">
Show answer
</div>