FSD Frontend System Design

Part IV — The Reach · Lesson 8.7

How to fix accessibility

In one lineAudit, triage by user impact, fix at the component level, then gate it so it can't come back.

Where you've seen itA design-system Button missing its focus ring — one commit repairs every page in the product.

  • Time15 min
  • DiagramFix workflow + impact-based triage
  • Chapter8 · Accessibility

Diagram

diagram
THE WORKFLOW

  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐
  │  AUDIT   │─►│  TRIAGE  │─►│   FIX    │─►│  VERIFY  │─►│  GATE  │
  │ automated│  │ by user  │  │ at the   │  │ keyboard │  │ CI +   │
  │ + manual │  │ impact   │  │ component│  │ + SR     │  │ DoD    │
  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └────────┘
                                    ▲
                     fix the SOURCE, not the instance:
                     one Button component > 400 page patches
diagram
TRIAGE BY IMPACT — not by how many the scanner found

  P1  BLOCKS a task entirely
      keyboard trap · unlabelled submit · form errors not announced
      → fix this sprint

  P2  MAKES a task much harder
      poor focus order · low contrast on body text · vague link text
      → next sprint

  P3  ANNOYS
      redundant announcements · missing landmarks · decorative alt
      → backlog

  200 "missing alt on decorative icons" ranks below
  ONE unlabelled checkout button.
diagram
WHERE THE FIX BELONGS

  design system component   ← 80% of issues, fixed once
  page composition          ← heading order, landmarks
  content                   ← alt text, link text, error copy
  design tokens             ← contrast, focus ring colour

  If you're patching the same issue on the third page,
  you're fixing it in the wrong layer.

How it works

  1. Audit in two passes: automated across all routes for breadth, manual keyboard-and-screen-reader on the top flows for depth.
  2. Triage by blocked tasks, not by violation count. Scanner counts flatter decorative issues and hide blockers.
  3. Fix in the design system wherever possible — components carry the fix everywhere at once.
  4. Verify the way users experience it: Tab through it, then listen to it. A green scanner is not verification.
  5. Gate it: jest-axe in unit tests, Lighthouse in CI, and accessibility in the definition of done so new work doesn't reopen old issues.

Trade-offs

ApproachResult
Fix in componentsOne change, product-wide
Fix per pageEndless, regresses immediately
Big-bang audit before launchExpensive, always late
Continuous, in DoDCheap, permanent

Accessibility statement and feedback path: publish what conformance level you meet, what's known-broken, and how users can report problems. In several jurisdictions this is a requirement, not a courtesy (3.8).

Interview angle

"You inherit a product with 300 accessibility violations. Where do you start?"

  • Triage by blocked tasks first: anything that stops a keyboard or screen-reader user completing a core flow.
  • Map violations to components — a handful of design-system fixes usually resolves the majority of instances.
  • Then gate it in CI and add it to the definition of done, so the backlog shrinks instead of refilling.

Recap

  • Triage by user impact, never by scanner count.
  • Fix at the component and token layer — patching pages is a treadmill.
  • Verify with keyboard and screen reader, then gate in CI.