Accessibility Wins: WCAG 2.2 Made Practical for Designers
Accessibility documents are dense and easy to ignore. The practical version is short: get six things right and you cover the vast majority of users with disabilities and most legal exposure. The six practical wins…
Accessibility documents are dense and easy to ignore. The practical version is short: get six things right and you cover the vast majority of users with disabilities and most legal exposure.
The six practical wins
- Colour contrast — body text at least 4.5:1, large text 3:1. Use the Stark plugin in Figma or Chrome’s built-in checker.
- Focus indicators — visible, high-contrast, not removed.
outline: nonewithout a replacement is a bug. - Target sizes — minimum 24×24 px for any interactive control; WCAG 2.2 made this a clear rule.
- Alt text for meaningful images — describe the function or content, not “image of…”.
- Keyboard navigation — every action reachable by Tab, logical order, no traps.
- Form labels — every input has a programmatically associated label, not just placeholder text.
What changed in WCAG 2.2
Drag-and-drop now needs a pointer alternative. Authentication must be possible without solving cognitive puzzles (no captchas as the only mechanism). Dragging interactions need single-pointer alternatives. These three are most likely to bite an audit on a modern web app.
Testing in 30 minutes
Tab through the entire page. Try the page with a screen reader (VoiceOver on Mac, NVDA on Windows — both free). Run axe DevTools to catch automated issues. Most accessibility wins come from doing this once per quarter, not from a special project.
The business angle
Accessibility improves SEO, reduces support tickets, and is increasingly mandatory for any government, healthcare, or fintech client in India. Designers who can talk about accessibility in business terms get into more strategic conversations.
