Accessibility is a build gate, not an audit
Retrofitting WCAG conformance costs several times what designing for it does. Here is how we make it structural rather than a phase.
Amara Lindqvist
Design Director · 11 December 2025
The usual pattern: build the product, run an audit near the end, receive a document with 200 issues, fix the cheap ones, and ship with a remediation plan nobody funds.
This is expensive in the most avoidable way. Almost every issue in that document was decided months earlier, in a design file, by someone who was not thinking about it.
Where the cost actually sits
Accessibility problems fall into two groups.
Cheap ones are attributes. A missing label, an unlabelled icon button, an image without alternative text. These are minutes each, at any stage.
Expensive ones are structural. A colour palette whose brand accent fails contrast on white. A custom dropdown built on divs with no keyboard model. A layout whose reading order does not match its visual order. A flow whose only error feedback is a red border.
Structural problems are not bugs to fix. They are decisions to revisit, and revisiting them late means redesigning components that are already used in forty places.
Three gates
We handle it with three checks, none of which is an audit phase.
In design. Palettes are contrast-checked when they are created, not when they are implemented. If the brand accent fails at body-text size, we determine that on day two and define a darker variant for text — which is exactly why our own accent colours have separate text values from their graphic values.
In the component library. Interactive components are built once, correctly, with keyboard and screen-reader behaviour verified. Every subsequent use inherits it. A product team that uses the library's dropdown cannot ship an inaccessible dropdown.
In CI. Automated checks run on every pull request and fail the build. Automation catches maybe 40% of issues, which is not enough on its own but is enough to stop regressions in the categories that are easy to reintroduce.
The remaining 60% needs manual testing: keyboard-only traversal of core journeys, and a screen reader on anything involving custom interaction. We do this per release, not per project.
What it costs
Designing for AA from the start adds something in the region of 3–5% to a project. Retrofitting it afterwards, in our experience, runs to 15–25% — and produces a worse result, because the compromises are made under deadline.
The part people underrate
Accessible interfaces are better interfaces for everyone. Focus states that are actually visible help mouse users who lost their cursor. Error messages that explain what to do help everyone. Keyboard shortcuts get used by your power users. Adequate contrast helps anyone reading a laptop screen outdoors.
On one education platform we rebuilt to AA, course completion rose 47%. The population that specifically needed the accessibility improvements was a small fraction of that gain. The rest was that the interface simply became clearer.
We do not treat AA conformance as a compliance obligation to be survived. It is a design constraint that reliably makes the product better, which is a much easier thing to argue for in a planning meeting.