The usual shape is this. A service is designed, built, and then — a few weeks before launch — sent for an accessibility audit. A report comes back with a list of issues, some trivial and some structural, and a difficult conversation follows about which ones can be fixed in the time remaining.
Everybody involved wanted an accessible service. The process guaranteed a compromise.
Late findings are the expensive ones
Cosmetic issues are cheap whenever they are found. Contrast, missing labels, focus styles — an afternoon each.
The expensive findings are structural: a component library with keyboard traps used on forty screens, a page built as a sequence of divs with no heading structure, a custom control that assistive technology cannot operate at all. Those are not fixes, they are rewrites, and they arrive when there is no time to do one.
The audit did not create that cost. It revealed it, months after the decision that caused it.
Move the checks earlier
None of this requires ceremony. It requires the checks to happen while the code is cheap to change:
- Semantic markup as the default, so structure is right before styling starts.
- Keyboard operation tested on every component as it is built, by the person building it. This takes seconds and catches most of what audits find.
- Automated checks in the pipeline. They catch perhaps a third of issues, which is not enough on its own and is a third you never discuss again.
- A screen reader used in development, not only in testing. Ten minutes a fortnight changes how people build.
- Accessibility in the definition of done, so it is not a phase that can be descoped when a phase gets tight.
The audit still matters
None of this replaces an independent assessment. Automated tooling misses most real problems, and a team checking its own work has predictable blind spots — testing with actual assistive technology users finds things nothing else does.
The difference is what the audit is for. Done this way it confirms and refines rather than discovering, and its findings fit in the time available.
Why this matters more in public services
Two reasons. There is a legal duty and an accessibility statement that has to be accurate — a statement claiming conformance a service does not have is its own problem, separate from the barriers themselves.
The more important one is that people cannot go elsewhere. A retailer with an inaccessible checkout loses a customer. A public service with an inaccessible form leaves someone unable to do a thing they are required to do, often the people with least capacity to work around it.
How we build
Accessibility is part of the work as it proceeds rather than a stage at the end, for the practical reason that retrofitting is more expensive and produces a worse result. It is the same argument as audit trails and security: things that shape a build cannot be added to a finished one.
Building a service that will be assessed? Get in touch, or read about our public sector work.