FSD Frontend System Design

Part IV — The Reach · Lesson 8.1

Accessibility Overview

In one linePerceivable, operable, understandable, robust — four principles that cover every rule you'll ever be given.

Where you've seen it<div onClick={…}> styled to look like a button. Perfect with a mouse, invisible to a keyboard and a screen reader.

  • Time13 min
  • DiagramPOUR principles mapped to real failures
  • Chapter8 · Accessibility

Diagram

diagram
POUR — every WCAG rule descends from one of these

  ┌─────────────────────────────────────────────────────────────┐
  │ PERCEIVABLE   can they SENSE it?                            │
  │   fails: no alt text · 2:1 contrast · info by colour alone  │
  ├─────────────────────────────────────────────────────────────┤
  │ OPERABLE      can they USE it?                              │
  │   fails: mouse-only controls · focus traps · 3s timeouts    │
  ├─────────────────────────────────────────────────────────────┤
  │ UNDERSTANDABLE  can they FOLLOW it?                         │
  │   fails: "Error" with no cause · labels that vanish on typing│
  ├─────────────────────────────────────────────────────────────┤
  │ ROBUST        does it work with THEIR tools?                │
  │   fails: custom widgets with no roles · div soup            │
  └─────────────────────────────────────────────────────────────┘
diagram
WHO THIS IS ACTUALLY FOR — permanent is the small share

  permanent    blind · deaf · one arm · motor impairment
  temporary    broken wrist · eye surgery · ear infection
  situational  bright sunlight · holding a baby · noisy train
               · slow network · a trackpad that just died

  Designing for the first column improves the product for everyone
  in the other two — which is most of your users, some of the time.
diagram
CONFORMANCE LEVELS — what teams actually target

  A     bare minimum        keyboard access, alt text
  AA    the normal target   4.5:1 contrast, visible focus, labels
                            ← what laws and contracts usually require
  AAA   rarely required     7:1 contrast, sign language

How it works

  1. Use semantic HTML first. <button>, <a href>, <label>, <nav>, <main> come with roles, keyboard behaviour, and focus for free.
  2. Reach for ARIA only when HTML has no equivalent — and remember the first rule of ARIA is not to use ARIA.
  3. Test with a keyboard on every feature. It takes thirty seconds and catches the majority of real defects.
  4. Treat it as a definition-of-done item, not a pre-launch audit — retrofitting accessibility costs many times more than building it in.

Trade-offs

Semantic HTMLCustom + ARIA
Roles, keyboard, focus built inEvery behaviour hand-written
Works across assistive techNeeds testing per screen reader
Less styling controlFull styling control
Almost no bugsWhere most a11y bugs live

The business case, briefly: it's a legal requirement in many markets, it's a large addressable audience, and the same semantic markup that helps screen readers helps search engines and your own test queries (4.8).

Interview angle

"How do you approach accessibility in a component library?"

  • Start from semantic elements and only build custom widgets when the platform genuinely lacks one.
  • Bake keyboard interaction and focus management into each component, so consumers get it by default.
  • Automate what's automatable (axe in CI), and keep a manual keyboard-and-screen-reader pass for new patterns.

Recap

  • POUR: perceivable, operable, understandable, robust.
  • Semantic HTML solves most of it before ARIA is needed.
  • Permanent disability is the smallest share of the people this helps.