# Accessibility Walkthrough — Learn by Doing

## Before We Begin

Accessibility isn't a checklist—it's about whether people can perceive, operate, and understand your interface. WCAG organizes this as POUR: Perceivable, Operable, Understandable, Robust.

**Diagnostic question:** Think of a site you use often. What happens when you can't use a mouse? When you zoom to 200%? When images don't load? Which of those experiences have you designed for?

**Checkpoint:** You can name at least one barrier someone might face and connect it to one POUR principle (perceivable, operable, understandable, or robust).

---

## Step 1: Check Color Contrast

<!-- hint:diagram mermaid-type="flowchart" topic="POUR principles" -->
<!-- hint:embed url="https://webaim.org/resources/contrastchecker/" -->

**Embed:** https://webaim.org/resources/contrastchecker/

**Task:** Pick a webpage or design. Use a contrast checker (WebAIM, DevTools, or axe) to verify that body text meets 4.5:1 (AA) and that buttons/links meet 3:1 against their backgrounds.

**Question:** What would you change if the contrast failed? How does this affect users with low vision or in bright light?

**Checkpoint:** The user can state the contrast ratio for at least one text/background pair and identify fixes if it fails.

---

## Step 2: Navigate with Keyboard Only

<!-- hint:terminal -->

**Task:** Unplug your mouse (or pretend). Use only Tab, Enter, Space, and arrow keys to complete a task on a site (e.g., submit a form, open a menu). Note any traps, missing focus, or confusing order.

**Question:** Where did focus go that surprised you? What would improve the experience?

**Checkpoint:** The user completes the task keyboard-only and identifies at least one improvement.

---

## Step 3: Audit a Page for Accessibility

**Embed:** https://www.w3.org/WAI/WCAG21/quickref/

**Task:** Run axe DevTools or Lighthouse on a page. Fix the top 3 issues (or document why you can't). Re-run the audit to confirm.

**Question:** Which issues were quick to fix vs. requiring design/structural changes? What would you prioritize?

**Checkpoint:** The user runs an audit, addresses issues, and can explain the impact of the fixes.

---

## Step 4: Use a Screen Reader

**Task:** Enable VoiceOver (macOS: Cmd+F5) or NVDA (Windows). Navigate a simple form or list. Don't look at the screen—listen only.

**Question:** What was announced that you didn't expect? What was missing or confusing?

**Checkpoint:** The user completes a short task using a screen reader and can describe what they heard.

---

## Step 5: Fix Semantic HTML and ARIA

**Task:** Find a page or component that uses `<div>` for buttons or non-labeled form fields. Rewrite it with semantic HTML (`<button>`, `<label>`) or add ARIA only where HTML isn't enough.

**Question:** When did native HTML solve the problem without ARIA? When did you need ARIA?

**Checkpoint:** The user produces accessible markup and can justify when ARIA was necessary.

---

## Step 6: Design an Accessible Flow

**Task:** Sketch or describe an accessible checkout flow. Include: skip link, heading hierarchy, form labels, error handling, focus management for a success message, and keyboard access to all controls.

**Question:** Which decisions were driven purely by accessibility, and which also improved the experience for everyone?

**Checkpoint:** The user's design addresses keyboard, screen reader, contrast, and focus, and they can explain the rationale.

<!-- hint:celebrate -->