A design review proves design decisions, and it cannot prove behaviour nobody has built yet. Both halves of that need saying, because the two popular positions are both wrong. One says a mockup review is theatre. The other sells a prototype review as an audit with a shorter timeline. The truth sits between them, and the boundary is precise enough to draw.
The precise version is that some WCAG criteria are properties of a decision and some are properties of a running thing. Contrast is a decision. Focus management is a running thing. A design file can settle the first kind outright, because the file contains the whole answer, and it can only make promises about the second, because the answer does not exist until code does.
The short version
Contrast, target size, focus indicator design, error wording, reading order and whether a label exists are all decided in the design and can be checked there. Accessible names, roles, states, keyboard operation, live announcements and whether anything interferes with the rest of the page are runtime properties and cannot. A design review is real evidence about the first list. It is a plan, not evidence, about the second.
What a Design File Actually Settles
Start with the good news, because it is a longer list than sceptics expect and it covers some of the most expensive failures to fix late. If a decision is fully visible in the artboard, it can be measured in the artboard, and measuring it there costs a fraction of what changing it after launch does.
- Contrast, everywhere it applies. Text against its background, and the interface parts and states that carry their own contrast requirement. These are ratios between two colours, and both colours are in the file.
- Target size and spacing. A control's dimensions and the gaps around it are drawn, so the measurement is available before anything is built.
- Focus indicator design. Whether a visible indicator was designed at all, and whether it has enough contrast and area to satisfy the criterion, is a question about the design.
- Reading order as intended. The sequence a sighted reader is meant to follow is a layout decision, and mismatches between visual order and intended order show up as design problems before they become markup problems.
- Labels, instructions and error wording. Whether a field has a persistent visible label rather than a placeholder, and whether the error text says what to do rather than that something is wrong, are both editorial decisions made in the file.
- Whether an accessible route exists at all. A drag-only interaction, a colour-only status, a hover-only disclosure. Each is a design choice that no amount of good engineering rescues afterwards.
One of these deserves a separate mention because it is where design evidence is unusually strong. A full page includes each variation the page presents automatically at different screen sizes, and every variation has to conform on its own. A design file with the desktop, tablet and mobile artboards side by side contains exactly the material that requirement is about, which is a check you can run before a single breakpoint has been written.
What Only Exists Once Something Is Running
Now the other list, and the reason it is not a matter of trying harder. Two of WCAG's five conformance requirements are about behaviour under conditions, and neither can be evaluated against a picture. Only accessibility-supported ways of using technologies may be relied upon, and support is established by testing for interoperability with real assistive technology. There is nothing to test that against in a design file, because no technology is being used yet.
Non-interference is harder still. It asks whether the page as a whole keeps meeting the requirements when technologies that are not relied upon are turned on, turned off, and unsupported. That is three runtime configurations of a thing that does not exist, and no review of a static artboard reaches any of them.
- Name, role and value. A button drawn as a button is a rectangle. Whether it announces as a button, with a name that means anything, is decided by markup nobody has written.
- Keyboard operation. Whether every control can be reached and operated without a mouse, and whether focus ever gets trapped, are properties of the implementation.
- Focus management. Where focus lands when a dialog opens, and where it returns when the dialog closes, is behaviour rather than layout.
- Announcements. Whether a status message reaches a screen reader without stealing focus depends on live region markup and on timing, both invisible in a design.
- Everything the browser does for you. Native semantics, form validation, autofill behaviour. A design cannot tell you whether the build used them or reimplemented them badly.
Prototype and Pilot, a Distinction Worth Borrowing
The clearest framing of this we have found comes from the US federal accessibility programme, which needed the line drawn for procurement reasons and drew it well. It separates a prototype from a pilot, and treats them completely differently.
A prototype is described there as an early, experimental version used to explore concepts and test feasibility, which may be a mockup, a wireframe or a minimally functional interface, and which is typically discarded. The accessibility expectation set for it is unusually well judged. A prototype may not be fully conformant, but it has to demonstrate that conformance is possible. So the interactive elements, navigation structures and interface components are present at least in rough form, to show they can be made accessible.
That is a real test rather than a formality, and it is the right thing to ask of a design review. Not whether the prototype passes, but whether anything in it makes passing impossible later. A pilot is treated as the opposite case. It is a final or near-final version released to a limited audience under real conditions, and because it is considered a production product it is expected to conform fully and to pass formal testing before rollout. A small launch is a launch.
The Two Stages Side by Side
Put the criteria families in one column and the two stages in the next two, and the shape of the argument becomes something you can hand a product manager. The point of the table is not the individual rows. It is that the pattern is consistent and predictable, so you can place a criterion you care about without asking anyone.
| The question | Design or prototype review | Production audit |
|---|---|---|
| Does this text have enough contrast? | Settled. Both colours are in the file. | Confirmed against what actually rendered, including states nobody drew. |
| Is this control big enough, with enough space around it? | Settled, at the drawn breakpoints. | Confirmed at real viewport sizes, after CSS did what CSS does. |
| Is there a visible focus indicator? | Whether one was designed, yes. Whether it survives the build, no. | Both, on every focusable thing including the ones nobody designed. |
| Does this control announce a useful name and role? | Not answerable. There is no markup yet. | Answerable, and this is the half of the standard a production audit exists for. |
| Can the whole task be completed on a keyboard? | A prototype can show the intended path. It cannot show the built one. | Answerable, end to end, in the states the task really passes through. |
| Does anything interfere with the rest of the page? | Not answerable. Non-interference is tested in three runtime configurations. | Answerable, which is why it is a conformance requirement rather than advice. |
Why Early Findings Expire, and What That Means for Your Claim
There is one more limit, and it is about time rather than about capability. W3C's evaluation methodology addresses evaluating during development directly. It says the guidance is still useful at those stages with some adaptation, and then adds the caution that matters. Evaluations carried out during design and implementation can quickly become obsolete through even minor changes, and so should not be used for making statements or conformance claims about the finished product.
Read that as two separate statements, because collapsing them is where the overselling happens. The findings are not wrong. A contrast failure found in a mockup is a real contrast failure, and fixing it in the file is the cheapest fix you will ever make. What the finding cannot do is travel into a sentence about the shipped product, because between the file and the ship date, things moved.
So a design review is bought for a different reason than an audit. You buy the review to stop expensive mistakes being built, and you buy the audit to find out what the built thing does. Neither substitutes for the other, and a proposal offering the first while describing the second is worth reading twice. Our design and mockup review and wireframe and prototype review are the first kind, and the WCAG 2.2 audit is the second.
Where This Page Stops
A design review produces no conformance claim, so most of the legal weight people attach to accessibility work is not present at this stage at all. Where it does start to matter is in contracts, because a supplier agreement that names accessibility as an acceptance condition needs to say which artefact satisfies it, and a design review usually does not.
Whether a specific clause is met by a specific deliverable is a question about that contract, and it belongs to a lawyer rather than an auditor. What this page can settle is the technical half. If the clause is about the built product, a design review will not discharge it, whatever the review found. Our guide to briefs and contracts covers how to write the requirement so the question does not arise late.