Episode 1 — Fundamentals / 1.5 — Semantic HTML and Browser Rendering

1.5.e — Accessibility and ARIA

In one sentence: Accessibility means your UI works for people with diverse abilities and environments; ARIA is a supplement to HTML when native elements cannot express roles, states, and relationships — and the first rule of ARIA is to avoid it when native HTML already solves the problem.

Navigation: ← 1.5.d — SEO & semantics · 1.5.f — Headings →

1. Inclusive design — more than “screen readers”

Permanent, temporary, and situational disabilities affect how people use the web:

Motor: keyboard-only, voice control, tremor
Vision: low vision, color blindness, blindness (screen readers, braille displays)
Auditory: captions for audio, visual alternatives
Cognitive: clear language, predictable navigation
Environment: bright sunlight (contrast), one-handed mobile use, slow networks

Accessible pages are better for everyone — clearer structure, better keyboard flows, less fragile layouts.

2. Native HTML first

Need	Prefer	Avoid
Button	`<button>`	`<div onclick>` with `role="button"`
Link	`<a href>`	`<span tabindex="0">` faking links
Text field	`<input>` / `<textarea>`	`contenteditable` for forms
Checkbox	`<input type="checkbox">`	custom div toggles without semantics
Expandable	`<details>` / `<summary>`	hand-rolled unless requirements block native

Why native wins: browsers ship built-in keyboard behavior, focus rings, name/role/value exposure to assistive tech, and validation hooks.

3. ARIA in three buckets

Roles (`role="…"`)

Expose element purpose to the accessibility tree — e.g. role="navigation" — but do not duplicate native roles (<nav> already maps to navigation landmark).

States & properties (`aria-*`)

aria-expanded, aria-selected, aria-checked — live state
aria-labelledby, aria-describedby — relationships to other nodes by id
aria-live — polite/assertive announcements for dynamic updates

The first rule of ARIA (WAI-ARIA)

If you can use a native HTML element with the needed semantics and behavior, do.

Second rule: do not change native semantics unless you know exactly why (<button role="heading"> is a crime).

4. Keyboard basics every developer should test

Tab / Shift+Tab move focus between focusable elements.
Enter activates buttons and links in focus.
Space toggles buttons/checkboxes (native).
Escape closes many dialogs if implemented — not automatic for custom modals.

Visible focus: never remove outlines with outline: none unless you replace them with equally clear focus styles.

5. Testing workflow (practical)

Unplug your mouse — complete primary tasks with keyboard only.
Zoom to 200% — does layout break critical flows?
Screen reader smoke test (VoiceOver on macOS, NVDA on Windows): landmarks rotor, headings list, form labels.
Automated checks: axe DevTools / Lighthouse accessibility — catch obvious issues; not sufficient alone.
Color contrast check for text vs background (WCAG targets: 4.5:1 for normal text as a common baseline).

5b. Skip links, focus order, and “invisible” content

Skip to main content — a first-focus link (<a href="#main">) that jumps past repetitive chrome helps keyboard and screen-reader users; the target region needs id="main" (often on <main>).
Tab order follows the DOM order — tabindex values > 0 are almost always a mistake; prefer logical markup order.
aria-hidden="true" removes a subtree from the accessibility tree — never put it on focusable content users might still reach via keyboard. Decorative icons next to visible text often need aria-hidden="true" on the icon element only.

5c. Motion and preferences

Some users experience vestibular discomfort from large parallax or zoom animations. CSS prefers-reduced-motion is the respectful hook: reduce non-essential motion rather than stripping all feedback.

6. `aria-label` vs visible text

Prefer visible labels (<label for> tied to inputs). aria-label overrides the accessible name and can diverge from visible text — confusing for voice control users (“click Submit” vs different ARIA name).

7. Key takeaways

Semantics + keyboard + focus are the engineering core of accessibility.
ARIA patches gaps — it does not fix bad HTML.
Test with keyboard + one screen reader + automated tools.
Dynamic UI needs aria-live discipline — avoid noisy chatter.

Explain-It Challenge

Explain without notes:

State the first rule of ARIA and give one example of obeying it.
Why fake links (<span> + click handler) are worse than <a href>.
What aria-expanded communicates on a disclosure control.