Services · Design-stage reviews
A Prototype Review Asks the Keyboard Questions Before the Build
For the product team clicking through a prototype who'd like proof the flow will survive a keyboard and a screen reader before a sprint gets spent building it. You get a written review of the patterns, flow by flow, and wherever a native element already does the job, the name of the element to use instead.
What We Keep Finding
Interaction patterns are the decisions that set hardest. Once the checkout lives inside a stack of modals, once the only way to reorder a list is to drag it, once the menu opens on hover, that pattern is load-bearing and everything after it gets built on top. Unwinding one of those after launch is not a *fix*, it is a renovation.
The truth is, the answer to most of them is older than the problem. A native dialog element opened with showModal() moves focus in, keeps Tab inside, closes on Escape, makes the background inert to screen readers, and hands focus back to whatever opened it, without a line of your JavaScript. What is left for you is deciding where focus lands first. So a prototype that plans a hand-built modal is choosing to rebuild five browser behaviors and to own the bugs in all five.
Which makes a prototype the last cheap moment for the unglamorous questions. How does a keyboard get here? Where does focus land after this step? What does this flow sound like when you cannot see the progress bar? And when this step goes wrong, does it say so in text, or does it only announce it, or does it do both and say it twice? We ask them while the answer is still a drawing.
What We Check
- Walk every flow by the keyboard question, which is simply how you get there without a mouse
- Flag the patterns with known debt, so modal stacks, hover menus, and drag-only controls
- Give every drag a route that does not drag, since rule 2.5.7 asks for one unless the dragging is essential or the browser is the thing doing it
- Compare each custom component against the native element that already behaves, starting with the dialog
- Check each step plans for errors, progress, and empty states, not only for the run where nothing goes wrong
- Settle where focus lands on every transition, and whether a step announces its change or moves focus to it, because doing both says it twice
What You Get
A prototype review is one pass rather than three. A trained reviewer clicks the flows the way a keyboard user would have to, and hands back a written review keyed to your screens. No automated scan, because there is no page to scan. No screen-reader session, because a prototype has nothing underneath it to read.
Each pattern comes back with a verdict, the rule behind it, and where a native element or a published pattern already solves it, the exact thing to copy. The full three-pass audit, blind tester included, starts once there is a real build to point it at.
The Honest Limit
One honest limit, and a warning about the library everyone reaches for. A clickable prototype cannot host a screen-reader session, so this is an expert review of the patterns rather than the three-pass audit. And W3C's own ARIA Authoring Practices publishes 30 patterns, none of which covers pagination, drag and drop, site search, toasts, or date pickers, while every example page on it carries a note that the code is not meant for production. So for some of what your prototype contains there is no canonical answer to copy, and we will tell you which parts those are rather than point you at a page that does not exist.
What It Costs
This one is quoted rather than packaged. The two prices on our pricing page buy an audit of a built site, and a prototype has no built site in it. Tell us how many flows it covers and roughly how many screens, and you get a number back you can put in a budget, with no call in the middle.
Worth Reading Next
Related on this site
Guides, checklists, tools, and terms that go with this service.