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
Typical errors include aria-expanded disagreeing with panel visibility, an accessible name that does not match the visible label, and aria-hidden on a focusable element. Inspect the accessibility tree and component behavior, not merely attribute presence.
Example
A complete panel toggle: the native button supports Enter and Space, while the script keeps hidden and aria-expanded synchronized. Inspect the accessibility tree for the button name, expanded state and controls relationship.
<button id="faq-toggle" type="button" aria-expanded="false" aria-controls="faq-panel">
Show answer
</button>
<div id="faq-panel" hidden>Answer content.</div>
<script>
const toggle = document.querySelector('#faq-toggle');
const panel = document.querySelector('#faq-panel');
toggle.addEventListener('click', () => {
const expanded = toggle.getAttribute('aria-expanded') === 'true';
toggle.setAttribute('aria-expanded', String(!expanded));
panel.hidden = expanded;
});
</script>ARIA (Accessible Rich Internet Applications), formally WAI-ARIA, is a W3C standard and a set of aria-* attributes that describe interface roles, names and states to assistive technologies. ARIA complements semantic HTML but does not replace native elements or keyboard and screen-reader testing.
It can help when native HTML does not express a custom component, such as a combobox or live region. Incorrect ARIA roles, states and names can make accessibility worse, so prefer native elements first and test the component automatically and manually.
No. Native HTML elements usually provide semantics, focus and basic keyboard behavior. ARIA complements custom components but does not add behavior automatically or replace accessibility testing.
ARIA is a technical standard for describing component semantics to assistive technologies. WCAG is a broader accessibility guideline with success criteria covering keyboard use, contrast, content structure, multimedia and more.