Accessibility Is Not a Feature
Why WCAG compliance is the floor, not the ceiling — and how watching one usability test changed my entire design process.
I remember the exact moment accessibility stopped being an abstract principle and became a personal mandate. It was a Thursday afternoon in 2024, and I was sitting in a usability testing lab watching a blind user named David try to navigate the dashboard I had spent three months designing. He was using a screen reader, and the experience was catastrophic. The navigation announced every decorative icon as "image, image, image." The modal dialogs trapped his focus with no escape. The color-coded status indicators — red for error, green for success — conveyed nothing through audio. I had designed a beautiful, polished, award-submission-ready interface that was functionally useless for David. I sat behind the one-way mirror and felt a specific kind of shame: the shame of having never once considered his experience during the entire design process. That day changed my practice permanently.
The Web Content Accessibility Guidelines exist, and they are necessary, and they are not enough. WCAG compliance is the floor, not the ceiling. Meeting AA standards means your product clears a legal threshold, but it does not mean your product is good for people with disabilities. Compliance is about avoiding barriers. Accessible design is about creating genuinely inclusive experiences. The distinction matters because teams that treat WCAG as a checklist tend to do the minimum: add alt text, ensure contrast ratios, provide keyboard navigation. Then they declare victory and move on. But an accessible product should feel as considered and intentional for a screen reader user as it does for a sighted user with a trackpad. That requires empathy, testing, and iteration — the same things we invest in for every other dimension of design quality.
Accessibility audit results — 47 issues found on first pass
After the experience with David, I restructured my team's entire design process to embed accessibility from the beginning rather than bolting it on at the end. Every component in our design system now ships with accessibility annotations: focus order, ARIA labels, keyboard interaction patterns, and screen reader announcements. We run accessibility audits at the wireframe stage, not after visual design is complete. We include at least one participant with a disability in every round of usability testing. These changes were not expensive or time-consuming — they simply required making accessibility a first-class concern rather than an afterthought. The hardest part was not the process change; it was convincing the team that the process change was necessary.
Making the business case to my CEO was surprisingly straightforward once I had the data. Approximately 16% of the global population lives with some form of disability. In the United States alone, the spending power of people with disabilities exceeds $490 billion annually. Beyond market size, accessibility improvements benefit everyone: high contrast helps users in bright sunlight, keyboard navigation helps power users, clear language helps non-native speakers, and captions help people watching video in noisy environments. I presented a single slide with these numbers alongside the results of our accessibility audit — 47 issues on first pass, many of them trivial to fix — and the CEO approved a dedicated accessibility sprint the same day. The argument was never about charity or compliance. It was about building a better product for more people, which is the entire point of design.
"Accessibility benefits everyone. Curb cuts were designed for wheelchairs. Everyone uses them."
The most common accessibility failures I encounter are also the easiest to fix. Buttons without accessible labels. Images without alt text. Forms without associated labels. Focus indicators removed for aesthetic reasons. Low contrast text that fails at 4.5:1 ratio. These are not complex engineering challenges — they are oversights born from a design process that never considered disability as a use case. I now start every design with keyboard navigation first. Before I choose colors, before I select typography, before I lay out a single element, I ask: can a user complete every task in this interface without a mouse? That single constraint has made me a better designer across every dimension, because it forces me to think about information hierarchy, logical flow, and interaction clarity in ways that benefit all users.
My practice has evolved to the point where I cannot separate accessibility from design. They are the same discipline. A button that is not keyboard-accessible is not a finished button. A form that does not announce errors to a screen reader is not a finished form. A dashboard that relies solely on color to convey meaning is not a finished dashboard. If your product is not accessible, it is not finished — it is a rough draft that excludes a significant portion of humanity. I carry David's testing session with me into every project. Not as guilt, but as clarity. I know exactly who I am designing for now: everyone.
If your product isn't accessible, it isn't finished.
