№ 19 Accessibility
Why Accessibility Compliance Without User Voices Falls Short
Passing an automated accessibility audit is not the same as being accessible. Why real users with disabilities must be part of your accessibility program.
Here’s a pattern I see too often in accessibility work: an organization invests significant time and resources to meet Web Content Accessibility Guidelines (WCAG) compliance standards, passes an automated audit, and considers the job done. Their website technically checks the boxes—every box, on every page, by every measure that matters to a scanner. But when someone using a screen reader actually tries to complete a task on the site, the experience is confusing, frustrating, or outright broken—and the gap between those two facts is the entire problem.
The gap between technical compliance and real-world usability is where most accessibility programs fall short. And the root cause is almost always the same: the people who actually rely on accessible experiences weren’t involved in creating them.
The Compliance Trap
Compliance is necessary. Meeting WCAG 2.1 AA standards, preparing for the European Accessibility Act, and staying ahead of Americans with Disabilities Act (ADA) litigation are all legitimate and important goals. But compliance is a floor, not a ceiling—and too many organizations treat it as the destination rather than the starting point.
Automated accessibility testing tools catch somewhere between 30-40% of accessibility issues—the mechanical, machine-readable ones. They’ll flag missing alt text, low-contrast color ratios, and form labels that aren’t properly associated. What they won’t catch is the meaningful stuff—whether that alt text actually describes the image in a useful way, whether the page’s navigation flow makes logical sense when you can’t see it, or whether a multi-step form is manageable using only a keyboard and a screen reader.
These are the kinds of issues that only surface when real people with real disabilities interact with your product. No amount of automated scanning or manual code review will reveal what a user testing session with someone who navigates by voice command can reveal in fifteen minutes.
What “Involving Users” Actually Looks Like
When I talk about bringing user voices into accessibility programs, I don’t mean a one-time usability study at the end of a project. I mean embedding the perspectives of people with disabilities throughout your design and development process.
Include users with disabilities in research. When you’re conducting user research to inform a new feature, product, or redesign, ensure your participant pool includes people who use assistive technologies. This isn’t a separate accessibility study—it’s part of your standard research practice. Include screen reader users, keyboard-only navigators, voice command users, and people with cognitive and motor disabilities—in the same research, alongside the same questions, that informs your broader design decisions.
Test with assistive technologies as part of QA. Don’t wait for a dedicated accessibility audit at the end of a sprint or project—by then, the cheap fixes have hardened into structural ones. Build assistive technology testing into your regular QA process. Have testers navigate your product using JAWS, NVDA, VoiceOver, and keyboard-only navigation as a standard part of acceptance testing. Better yet, include testers who rely on these tools daily—they’ll catch issues that someone testing with a screen reader for the first time won’t notice.
Create feedback channels. Make it easy for users to report accessibility issues. A dedicated accessibility feedback mechanism—whether it’s an email address, a form, or a reporting tool—signals that you take accessibility seriously and gives you a continuous stream of real-world input. More importantly, close the loop: let users know when their reported issues have been addressed.
Engage accessibility consultants and advocates. Organizations like disability advocacy groups, accessibility consulting firms, and professional associations like the International Association of Accessibility Professionals (IAAP) can connect you with experienced users and advisors who can evaluate your products from perspectives your internal team may lack.
The Curb-Cut Effect of User-Centered Accessibility
There’s a well-documented phenomenon in accessibility work—improvements designed for people with disabilities almost always benefit everyone. Closed captioning was created for deaf and hard-of-hearing users; it’s now used by the majority of video viewers. Voice interfaces were developed for people with motor disabilities—they’re now mainstream consumer features. Curb cuts were advocated for by wheelchair users; they benefit parents with strollers, delivery workers with carts, and travelers with luggage.
The same principle applies to digital accessibility. When you involve users with disabilities in your design process, you don’t just make your product work better for them—you make it work better for everyone. A navigation structure that makes sense to a screen reader user is a clearer navigation structure, period. A form that’s easy to complete with keyboard-only input is a faster, less frustrating form for every user—not just the ones who relied on the constraint. Content that’s written clearly enough for someone with a cognitive disability is content that communicates more effectively with your entire audience.
User-centered accessibility doesn’t just solve accessibility problems. It surfaces usability problems that affect everyone but that able-bodied testers have learned to work around without noticing.
Making It Sustainable
The biggest challenge isn’t starting user-centered accessibility work—it’s sustaining it. Here’s how to build it into your operations rather than treating it as a one-time initiative.
Build it into your design system. Ensure your component library is built with accessibility as a core requirement, informed by user testing with assistive technologies. When developers pull components from the system, accessibility comes baked in rather than bolted on.
Train across roles. Accessibility isn’t just a developer responsibility. Designers need to understand how their layout and interaction decisions affect screen reader users. Content creators need to know how to write effective alt text, heading structures, and link text. Product managers need to prioritize accessibility alongside other requirements. Role-specific training ensures every contributor understands their piece of the puzzle.
Set meaningful metrics. Move beyond “number of WCAG violations” as your primary accessibility metric—it measures the floor, not the experience. Track user satisfaction among assistive technology users. Measure task completion rates across different interaction modes. Monitor the volume and resolution time of accessibility-related feedback. These metrics tell you whether your accessibility efforts are actually improving the user experience—not just whether your code passes a scanner.
Budget for it. User research with participants with disabilities, assistive technology testing, accessibility consulting, and ongoing training all require investment. Organizations that treat accessibility as an unfunded mandate will always be playing catch-up. Those that budget for it as a core part of their design and development process build it into their DNA.
Conclusion
Technical compliance is the baseline. It’s where accessibility work begins, not where it ends. The organizations creating genuinely inclusive digital experiences are the ones that go beyond the checklist—bringing the voices of people with disabilities into their design process, testing with real assistive technologies, and measuring success by whether their products actually work for everyone who uses them.
The gap between “technically accessible” and “genuinely usable” is where the real work happens. And closing that gap starts with listening to the people your accessibility program is meant to serve.
