Why accessibility testing should begin before the first prototype

Overview

Accessibility as a research question, not a checklist

Accessibility is usually treated as a quality check. A design is finished, a build is nearly ready, and someone runs an audit against WCAG success criteria before launch. This approach catches some problems. It misses many more. The barriers that matter most to blind and low vision users, and to people relying on assistive technology, are often structural. They live in the information architecture, the interaction model, and the order in which content is exposed to a screen reader, not in surface level styling that an audit can catch after the fact.

This post draws on a study of the rideshare experience for blind and low vision riders. The research began with the assumption that accessibility problems were mostly about missing labels and poor color contrast. What the interviews and testing sessions actually surfaced was different. The most disruptive barriers were about trust, timing, and control: not knowing if a driver had arrived, not being able to confirm a vehicle without asking a stranger, not being certain the app had registered a cancellation. None of these problems would have been caught by a compliance audit run at the end of the project.

The Cost of Testing Late

What gets lost when accessibility comes last

When accessibility testing happens after key decisions are made, the fixes available are limited to what does not require rework. Teams add alt text, adjust contrast ratios, and confirm tab order. These changes matter, but they cannot repair a flow that assumes the user can visually confirm a car has arrived, or a notification pattern that depends on peripheral vision. By the time testing happens, the interaction model is fixed. Only the surface can change.

There is also a research cost. A late accessibility audit is typically conducted by an internal specialist or an automated tool, not by people who actually use assistive technology daily. Automated tools catch a narrow band of issues, such as missing alt attributes, insufficient contrast, and unlabeled form fields. They cannot tell a team whether a flow makes sense when navigated by voice, or whether a series of nested menus is exhausting to move through with a screen reader. That judgment only comes from people with lived experience of the barrier.

In Practice

What early testing actually looks like

Early accessibility testing does not require a finished prototype. It requires a testable concept: a flow sketch, a paper prototype, or a low fidelity wireframe walked through with a screen reader user. In the rideshare study, this meant recruiting blind and low vision participants during the discovery phase, before any interface decisions were locked in. Sessions combined semi structured interviews about current rideshare habits with think aloud walkthroughs of the existing app, so the barriers participants described were grounded in specific moments rather than general frustration.

This approach surfaces structural issues while they are still cheap to fix. If a proposed flow assumes visual confirmation of a vehicle, that assumption can be challenged in a sketch. Once it is built into a working prototype, replacing it becomes a much larger conversation involving engineering, product, and design leadership.

Framework

A simple framework for including accessibility earlier

Three shifts made the difference in this project. First, accessibility research questions were included in the discovery guide alongside general usability questions, rather than treated as a separate track. Second, participants who use assistive technology were recruited for the same early rounds of testing as everyone else, not a later specialized round. Third, findings were framed in terms of information architecture and interaction sequencing, not just interface details, so design and product could act on them before screens were built.

None of this requires a large research team or an extended timeline. It requires treating accessibility as a research question from the first round of discovery, rather than a compliance step near the end.

Takeaways

What to carry forward

References

Further reading