accessibility-and-inclusive-design
Accessibility & Inclusive Design
Accessibility is not a feature toggle or a final-pass audit — it is a property of correct UI construction. Build it in or rebuild it later. This is the bar for production: WCAG 2.2 Level AA, every screen, every platform. Automated tools catch ~30% of issues; the rest is keyboard, screen reader, and judgment. Treat this document as the working reference, not an aspiration.
1. WCAG 2.2 structure — POUR
WCAG is organized under four principles. Memorize them; every requirement maps to one.
| Principle | Means | Failure example |
|---|---|---|
| Perceivable | Users can perceive the content (sight, sound, touch) | Image with no alt; 2:1 contrast text |
| Operable | Users can operate the UI (any input method) | Control reachable by mouse only |
| Understandable | Content and operation are predictable | Error says "invalid input" with no fix |
| Robust | Works with current and future assistive tech (AT) | Custom <div> widget with no role/state |
Conformance levels: A (must — basics, keyboard, alt text), AA (the legal/industry target — contrast, reflow, focus, names), AAA (aspirational, not required wholesale — 7:1 contrast, sign language). Ship AA. Conformance is per-page and all-or-nothing: a page conforms only if every applicable success criterion (SC) at that level is met, with no AT-blocking content anywhere in the page or in any process (e.g. checkout) it belongs to.
The new WCAG 2.2 success criteria (added Oct 2023)
These are the ones teams miss because they post-date most a11y muscle memory. All are AA unless noted.