The conversation around accessibility in product design still too often starts with legal risk. WCAG compliance is framed as a defensive posture—something you do to avoid lawsuits, not something you do to build a better product. This framing is both practically wrong and strategically short-sighted.
Accessibility as a proxy for design quality
Every WCAG criterion that's difficult to meet is a signal that something in the design is fragile. Insufficient colour contrast usually means colours were chosen for aesthetics alone, without a systematic token layer. Keyboard navigation failures almost always indicate that interactive states weren't fully specified. Missing alt text reflects content workflows that never accounted for non-visual access.
When we worked on Helio Health's patient scheduling platform, accessibility wasn't a retrofit—it was a design constraint from the first wireframe. The discipline of specifying focus states, error messages, and touch targets early produced a tighter, more consistent component library. The third-party WCAG 2.1 AA audit we commissioned before launch found zero critical issues—not because we were lucky, but because we'd been building to that standard throughout.
Where to start if you're not yet accessible
- 1.Audit your colour system first. Run every foreground/background pair through a contrast checker. This is the fastest, highest-impact fix.
- 2.Specify focus styles in your design system, not as an afterthought. Every interactive element needs a visible focus indicator that meets 3:1 contrast against the background.
- 3.Test with a keyboard before any user testing. Tab through every flow. If you get stuck, your users will too.
- 4.Write error messages for humans. "Field invalid" tells no one anything. "Please enter a date after today's date" is accessible and useful.
- 5.Add skip navigation links. They're invisible to mouse users, essential to keyboard users, and take ten minutes to implement.
The cheapest accessibility fix is the one you make in the design file before it reaches engineering. The most expensive is the retrofit after launch.
The business case beyond compliance
Approximately 1 in 4 adults in the UK and US has some form of disability. Globally that's over a billion people. An inaccessible product excludes a significant fraction of your potential users before they've encountered your core value proposition. The business case is not hypothetical.
Beyond direct reach, accessible products perform better in search. Screen readers and search crawlers share many of the same access patterns—semantic HTML, meaningful alt text, logical heading hierarchy. An accessible product is, by definition, a more crawlable one.
Team practices that make accessibility stick
- Include accessibility criteria in your definition of done. A feature isn't done until it passes keyboard and screen reader review.
- Run automated accessibility checks in CI—tools like axe-core can catch 30–40% of issues before a human reviewer touches the PR.
- Commission an external audit before major launches. Internal teams develop blind spots.
- Involve users with disabilities in research. Lived experience surfaces issues that automated tools and checklists cannot.
Accessibility is not a constraint that limits great design. It's a discipline that produces it.
