What can a prototype made of drawings never answer?
I spent years reviewing pictures of interfaces and calling it design review.
Imagine judging a chair by a photograph of a chair. You could say a great deal about proportion, about whether it suits the room, about whether the color works. You could not say whether it holds your weight.
We do this constantly, and we have built an entire craft around the photograph.
What does a drawing tell us?
A great deal, and I want to be fair about that. Layout, hierarchy, rhythm, tone, whether the eye lands where we intended. A static design answers all of it cheaply and fast, which is why the discipline organized itself around drawings in the first place.
What a drawing cannot answer is the set of questions that decide whether a person can actually use the result:
- What does the keyboard do? In what order?
- What does a screen reader say, not what do we hope it says, what does it say?
- What happens at 375 pixels, on a phone, on a weak signal?
- Does the spacing we chose exist in the system at all, or did we invent it?
Those are not aesthetic questions and they are not edge cases. They are the experience, for a large number of people, and none of them are visible in a picture.
Who pays when we defer them?
The deferral has a shape, and I want to name it, because it looks like process rather than exclusion.
The questions do not disappear. They get answered later, by someone else, as a finding: an audit result, a support ticket, a remediation sprint with a deadline attached. By then the answer is expensive, so it gets negotiated. And what gets negotiated away is almost never the layout. It is the focus order, the announcement, the behavior at a narrow width.
The person who meets the consequence is someone filling in a form on a phone between shifts, or navigating with a keyboard, or listening rather than looking. They do not experience it as a process artifact. They experience it as a product that does not work for them, shipped by people who never checked.
Nobody in that chain intended it. The tooling simply never made the question cheap enough to ask early.
What changes when the prototype is made of the real thing?
That is what I built CCDS (opens in a new tab) to test: a prototyping sandbox for product managers and designers, built on the real component package and the real design tokens. Not an approximation of the design system, the same material the product is made of, in a Vite and React app that runs on a laptop.
The usual alternative is a prototyping tool that approximates the system, and the approximation is the whole problem. Anything built in it has to be rebuilt to become real, and every rebuild is an opportunity to quietly drop the parts that were never visible in the drawing.
When the prototype is made of the shipped components, the accessibility questions stop being a separate activity. Tab through it: that is the real focus order. Turn on a screen reader: that is the real announcement. Narrow the window: that is the real behavior. The questions answer themselves, on the day, by the person asking them.
That is the whole of my argument. Not that designers should become engineers, but that the people making the decisions should be able to run the thing they are deciding about.
What does this look like without a sandbox?
Most teams do not have one, and building one is not required for the shift.
- Get the real component library runnable locally. Storybook, a scratch app, a branch, whatever makes it possible to press Tab on the actual component rather than a rectangle representing it.
- Ask the four questions in design review. Keyboard, screen reader, 375 pixels, does this spacing exist. Four questions, asked early, cost minutes.
- Prototype the state nobody draws. Empty, loading, error, too-long-name. These are where accessibility failures gather because they are where drawings stop.
- Make "I ran it" the standard for sign-off. Not "I reviewed the file."
- Treat an invented spacing value as a bug, not a preference. If it is not in the system, someone will hand-roll it, and hand-rolled things do not inherit the system's accessibility work.
None of that requires permission. It requires the thing to be runnable, which is a tooling problem our field has been strangely willing to live with.
The part I keep repeating
Exclusion is the default outcome of unexamined defaults, and a drawing is a very comfortable place for a default to go unexamined, because it looks finished.
WCAG 2.4.3 is about focus order. 1.4.10 is about reflow, which is how a page rearranges itself on a narrow screen. 4.1.2 is about name, role and value. Not one of them can be evaluated from a picture, which means that for as long as our primary artifact is a picture, we are systematically unable to see the things we are most responsible for.
Run the thing before the next review. Press Tab. Listen to it once. Whatever you find is cheap to change today and a finding in someone's report next quarter.