Services · Design-stage reviews
A Design Review Catches Contrast and Missing States in Figma
For the team with a redesign in Figma that wants the accessibility problems found now, while each one is still a color swap instead of a sprint. What comes back is a written review of the file, pair by pair and frame by frame, with the actual thresholds attached rather than a general instruction to go and check your contrast.
What We Keep Finding
The cheapest accessibility fix in existence is the one made before any code exists. In a design file, low contrast is a new hex value and a missing focus state is one more frame. After launch, those same two things are tickets, a regression test, and a sprint nobody budgeted for. Same finding, wildly different invoice.
And design files hide the same gaps over and over. Every hover state drawn and not one focus state. Gray placeholder text that reads beautifully on a designer's monitor and nowhere else. Heading levels picked by font size rather than by structure. Those decisions get built faithfully, which is exactly the problem, because a developer treats the file as the answer rather than as a guess.
The thresholds are easy to get wrong in both directions, too. Large text drops from 4.5:1 to 3:1, and the standard defines large in points rather than pixels, at 18 point or 14 point bold, which works out near 18.5px and 24px. Text inside a switched-off control carries no contrast requirement at all, so the grayed-out button somebody flagged was never a failure. Placeholder text has no such excuse and stays one. Getting those three right is the difference between a palette your team can build on and a week spent repainting things that already passed.
What We Check
- Test every text and control color pair against the threshold that applies to it, so 4.5:1 for body text and 3:1 for large text and interface parts
- Hunt the states a mockup skips, meaning focus, error, disabled, empty, and loading
- Measure the focus indicator against the 3:1 non-text rule, because rule 2.4.7 asks only that focus be visible and sets no ratio at all
- Review the type hierarchy, so the visual levels can map onto real heading levels in the build
- Flag every place the design says something with color and nothing else
- Measure target sizes against rule 2.5.8's 24 by 24 CSS pixels, which is about half of what Apple's and Android's own guidelines already ask of you
What You Get
A design review is one pass rather than three. A trained reviewer works your file frame by frame and hands back a written review. There is no automated scan, because there is no page to scan, and no screen-reader session, because a file has nothing under it for a screen reader to read.
Every finding names the frame it sits on, the rule behind it, and the change that clears it, whether that is a shade, a state nobody drew, or a control that has to get bigger. Findings arrive in the same shape our audit findings do, one per problem, ranked by who it locks out.
The Honest Limit
One honest limit. A design file cannot be run past a screen reader, so this is an expert review and nothing else, with no blind tester on it. A file also cannot be tested for whether it survives a reader turning up their own text spacing, because rule 1.4.12 measures what a built page does under pressure rather than the numbers a designer typed in. The three-pass audit starts the day there is a build to point it at.
What It Costs
A design review is not one of the two audit packages, so it is not $499 or $1,499. Send us the file, or just a note of how many screens it covers, and a fixed number comes back by email. No discovery call, and the price is set before we open anything, which is the same rule the audits run on.
Worth Reading Next
Related on this site
Guides, checklists, tools, and terms that go with this service.