ARIA: When and When Not to Use It
🏷️ ARIA: When and When Not to Use It
The First Rule of ARIA
No ARIA is better than bad ARIA. If a native HTML element already provides the semantics and behavior you need, use that instead of recreating it with a <div> plus ARIA attributes. Critically: ARIA only announces information — it provides none of the automatic keyboard behavior Chapter 2 covered. Adding role="button" to a <div> does not make it keyboard-operable; nothing about tab order or Enter/Space activation happens automatically just because a role was declared.
Three Categories of ARIA
| Category | What It Describes | Example |
|---|---|---|
| Roles | What an element IS | role="dialog", role="tablist" |
| States | Current condition, can change | aria-expanded, aria-checked |
| Properties | Relatively static characteristics | aria-label, aria-describedby |
✅ Safe, High-Value ARIA
Icon-Only Button
aria-label for Icon Buttons
A button with only an icon and no visible text has no accessible name at all without something providing one — aria-label fills exactly that gap.
aria-live Regions
Lets a screen reader announce a content change — a chat message count, a toast — without requiring the user's focus to move there first.
⚠️ The Danger of ARIA Misuse
Adding role="button" to a <div> without also adding tabindex="0" and keydown handlers doesn't just fail to help — it actively makes things worse than no ARIA at all:
Announced as a Button, But Not One
role="button" Alone
A screen reader announces "button," creating an expectation of tab-focus and Enter/Space activation — neither of which actually works. Worse than saying nothing.
Just Use <button>
Chapter 2's own point, restated: the native element gives you everything correctly, with far less code and no way to get it half-wrong.
Redundant and Conflicting ARIA
<button role="button"> is pointless — the native element already has that role. <a href="#" role="button"> is actively harmful — the browser and assistive technology now receive contradictory signals about whether this is a link or a button.
💻 Coding Challenges
Challenge 1: Add an Accessible Name to an Icon Button
Given <button>🔍</button> used as a search trigger with no visible text, add the correct ARIA attribute so a screen reader announces its purpose.
Goal: Practice the most common, safest real-world use of ARIA.
Challenge 2: Fix a Broken Custom Toggle
A custom accordion toggle is written as <div role="button" aria-expanded="false">Show more</div> with a click handler but no keyboard support. Identify what's missing and fix it, or recommend a simpler alternative.
Goal: Practice recognizing and repairing the exact ARIA-without-behavior gap this chapter warns about.
Challenge 3: Identify Redundant or Conflicting ARIA
For each of (a) <nav role="navigation">, (b) <a href="/settings" role="button">, and (c) <div role="tablist">, state whether the ARIA is redundant, conflicting, or genuinely necessary, and why.
Goal: Practice distinguishing pointless, harmful, and correct ARIA usage.
The real skill this chapter teaches isn't memorizing ARIA attributes — it's knowing when not to reach for them. Before adding any ARIA role, state, or property, ask whether a native element already provides it: a custom "button" is almost always better as <button>; a custom "link" is almost always better as <a href>. ARIA is the correct, necessary tool specifically when no native element covers the pattern at all — there's no native tab interface, so role="tablist"/role="tab"/role="tabpanel" genuinely earn their place there (Chapter 8 builds exactly this). Reach for ARIA last, not first.
🎯 What's Next
With markup and ARIA covered, the next chapter goes hands-on with the interaction model that matters most for motor disabilities: Keyboard Navigation — tab order, focus management, and correctly trapping focus in modals.