WCAG compliance has become a checkbox exercise for many teams: run an automated audit, fix the flagged issues, declare victory. This is not accessibility. It is the minimum legal defence against accessibility.
Real accessibility starts from a different question. Not 'what do we need to fix?' but 'who are we excluding, and how do we stop?'
The business case is stronger than most teams realise
Approximately one in five people globally has some form of disability. Permanent disabilities are the visible end of a spectrum that includes temporary and situational disabilities too. The person using your product one-handed because they are holding a baby. The person in bright sunlight who cannot see their screen clearly.
When you design for the edges, you improve the experience at the centre. Captions help non-native speakers. High contrast helps users in poor lighting. Keyboard navigation helps power users who prefer the keyboard.
Where most products fall short
Automated tools catch roughly 30 percent of accessibility issues. The rest require human judgment — testing with real assistive technology, involving users with disabilities in research, and making design decisions that prioritise clarity over cleverness.
The most common failures: interactive elements that are too small to tap accurately, form errors that are not communicated to screen readers, colour combinations that fail contrast ratios, and focus states that have been disabled because they look ugly.
Building it in, not bolting it on
Accessibility is hardest to retrofit. It is cheapest and most effective when it is a design constraint from the start — when contrast ratios are checked during the design phase, when keyboard navigation is tested during development, when screen reader compatibility is part of the definition of done.
Teams that treat accessibility as a design principle rather than a compliance requirement produce consistently better products. Not just for users with disabilities — for everyone.
Accessibility is not a checkbox, it is a commitment to stop excluding people.
Treating WCAG as a pass/fail audit misses the point: compliance is a legal baseline, not a usable experience. The real question is, who can’t use this, and why?
When teams design for the edges, they improve the centre. Captions, contrast, keyboard support, generous tap targets, clear language, predictable flows — these are not niche features. They are core usability for everyone, especially in real-world conditions: bright light, noisy environments, fatigue, injury, distraction.
Most products fail not because teams don’t care, but because they rely on automation and treat accessibility as a late-stage fix. Automated tools catch a fraction of issues. The rest require:
- Testing with real assistive tech
- Involving disabled people in research as standard participants
- Designing with semantics, focus, and clarity in mind from the start
Retrofitting is where the real cost lies. A design system without accessible colours, focus states, or semantic components becomes technical debt. Adding accessibility at the end of the roadmap is always slower, more expensive, and more fragile than baking it into the definition of done.
Inclusive teams:
- Write briefs with accessibility requirements alongside functional ones
- Test components with screen readers and keyboards before calling them done
- Consider cognitive load, not just visual polish
- Treat accessibility checks as routine, minutes-per-component work — not a special project
The shift is cultural, not just technical. Accessibility moves from project to practice: a standard of quality that compounds over time. Products built this way are more resilient, more usable, and more competitive — not because they passed an audit, but because more people can actually use them.
Accessibility is not a checkbox; it is a commitment to stop excluding people.
Treating WCAG as a pass/fail audit misses the point: compliance is a legal baseline, not a usable experience. The real question is, who can’t use this, and why?
When teams design for the edges, they improve the centre. Captions, contrast, keyboard support, generous tap targets, clear language, predictable flows — these are not niche features. They are core usability for everyone, especially in real-world conditions: bright light, noisy environments, fatigue, injury, distraction.
Most products fail not because teams don’t care, but because they rely on automation and treat accessibility as a late-stage fix. Automated tools catch only a fraction of issues. The rest require human judgment:
- Testing with real assistive technology (screen readers, switch devices, voice control)
- Involving disabled people in research as standard participants, not edge cases
- Designing with semantics, focus management, and clarity in mind from the start
Retrofitting is where the real cost lies. A design system without accessible colours, focus states, or semantic components becomes technical debt. Adding accessibility at the end of the roadmap is always slower, more expensive, and more fragile than baking it into the definition of done.
