ARIA Roles & Attributes

Also Known As

TL;DR

Explanation

ARIA (role, aria-label, aria-describedby, aria-expanded, aria-hidden, aria-live) enhances accessibility for non-semantic HTML. The first rule of ARIA: don't use ARIA if native HTML provides the semantics. role='button' on a div is inferior to a real <button>. aria-label provides a text alternative for elements without visible text. aria-expanded signals the open/close state of accordions and dropdowns. aria-hidden='true' removes decorative elements from the accessibility tree. Never remove focus without providing an alternative.

Diagram

flowchart TD
    HTML[Semantic HTML<br/>button input nav main] -->|native semantics| ACC[Accessibility Tree]
    ARIA[ARIA attributes<br/>role aria-label aria-expanded] -->|supplement| ACC
    ACC --> SR[Screen Reader<br/>NVDA JAWS VoiceOver]
    subgraph First Rule of ARIA
        NATIVE[Use native HTML first<br/>button not div with role=button]
        KBRD[Add keyboard handlers<br/>if using role=button on div]
    end
    BAD[div onclick] -.->|missing keyboard nav| BROKEN[Inaccessible]
    GOOD[button type=button] -->|built-in keyboard| WORKS[Accessible]
    style BROKEN fill:#f85149,color:#fff
    style WORKS fill:#238636,color:#fff

Watch Out

Common Misconception

Why It Matters

Common Mistakes

• role='button' on a div without keyboard handlers — screen reader announces button but Enter/Space don't work.
• aria-hidden='true' on focusable elements — removes from accessibility tree but keyboard can still focus it.
• aria-label on every element — not needed on elements with visible text; use aria-labelledby instead.
• Not updating aria-expanded when opening/closing components — screen reader never announces state changes.

Avoid When

• Using ARIA to replace native HTML elements that already provide correct semantics.
• Adding ARIA attributes without implementing required keyboard interaction and state updates.
• Applying aria-hidden to interactive or focusable elements.

When To Use

• Building custom UI components like modals, dropdowns, tabs, and sliders.
• Enhancing non-semantic HTML where native elements cannot provide required accessibility.
• Communicating dynamic state changes to assistive technologies.

Code Examples

<!-- Custom dropdown — inaccessible:
<div class="dropdown" onclick="toggle()">Menu</div>
<div class="dropdown-items" style="display:none">
    <div onclick="select('home')">Home</div>  <!-- Not keyboard accessible -->
</div>

<!-- Accessible dropdown with ARIA:
<button
    aria-haspopup="true"
    aria-expanded="false"
    aria-controls="nav-menu"
    id="nav-trigger"
>Menu</button>
<ul id="nav-menu" role="menu" hidden>
    <li role="none">
        <a href="/" role="menuitem">Home</a>
    </li>
</ul>
<!-- JS: toggle aria-expanded and hidden; manage focus -->
<!-- Enter/Space/Escape/Arrow keys handled -->

References

• ↗ https://www.w3.org/TR/wai-aria-1.2/
• ↗ https://www.w3.org/WAI/ARIA/apg/

Tags

Related Terms