Assessed services are built differently
Most software is judged by whether people use it. A public service is judged by that and by whether it can be examined — for accessibility, for how a decision was reached, for whether it can be handed to another team.
Those properties cannot be added at the end. This paper covers the three that most often arrive too late.
Part one: accessibility
The audit-at-the-end pattern
A service is designed, built, then audited a few weeks before launch. A report returns with a list, and a difficult conversation follows about what can be fixed in the time remaining.
Everyone wanted an accessible service. The process guaranteed a compromise.
Cheap findings and expensive findings
Cosmetic issues — contrast, missing labels, focus styles — cost an afternoon whenever they are found.
The expensive ones are structural: a component library with keyboard traps used on forty screens, pages built as anonymous containers with no heading structure, a custom control assistive technology cannot operate. Those are rewrites, and they arrive when there is no time for one.
The audit did not create that cost. It revealed it, months after the decision that caused it.
Move the checks to where the code is cheap
- Semantic markup by default, so structure is right before styling starts.
- Keyboard operation tested on every component as it is built, by the person building it. Seconds each, and it catches most of what audits find.
- Automated checks in the pipeline. They find perhaps a third of issues — not enough alone, and a third you never discuss again.
- A screen reader used during 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.
What the audit is then for
Independent assessment still matters — 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 that it confirms and refines rather than discovering, and its findings fit the time available.
The accessibility statement
A statement claiming conformance the service does not have is a separate problem from the barriers themselves. Statements should be generated from what was actually tested, dated, and specific about known issues and when they will be addressed. Vagueness reads as either carelessness or concealment.
Part two: audit trails
Recording the change is not recording the decision
A typical audit record says a field changed from one value to another, at a time, by a user ID.
What gets asked is different:
- What information was in front of the person when they decided?
- Which rule, or version of policy, applied at that moment?
- Was this automatic, or did somebody choose it?
- If automatic, what did the system take into account?
- Who could see this record, and did they?
None of that is reconstructable from a field-level change log, and some of it is not reconstructable at all after the fact.
Capture the inputs, not just the output
Record the state that produced the decision, at the moment it produced it: values as they stood, the version of the logic that ran, contributing factors and weights where a model was involved, and what a person did with the result — accepted, overrode, escalated.
Overrides are the most useful signal a service produces about itself. A pattern of them says something no design review will.
Read access counts
For services holding personal data, who read a record often matters more than who changed it. Unauthorised access leaves no trace in a change log, because nothing changed.
Read logging is unfashionable — high volume, no visible feature — and it is the only thing that answers a question which does get asked.
Retention applies to the trail too
An audit trail is useful only while it is kept, and keeping personal data forever is neither lawful nor sensible. Retention has to be decided per category and enforced automatically. A rule depending on someone running a script each quarter is not a rule.
The test
Take a decision the service made six months ago. Without asking the team who built it, reconstruct why it came out that way. If that takes more than a few minutes, the trail records activity rather than accountability.
Part three: handover
Lock-in is rarely deliberate
It accumulates: infrastructure configured by hand over three years and understood by two people; deployment that works from one engineer’s laptop; documentation describing the original plan rather than the current system; business rules existing only in code, with no record of which were policy and which were guesses nobody challenged.
Nobody set out to build a hostage. Everyone was busy.
What makes a service transferable
- Infrastructure as code, so the environment rebuilds from a repository. This is also what makes disaster recovery real rather than a document.
- Contract-first APIs, so a component can be replaced without renegotiating with everything that touches it.
- Documentation aimed at the next team, explaining why: why this rule, why this exception, why this deviates from the pattern. What the code does can be read from the code.
- Decision records kept with the code. The highest-return habit here, and it takes minutes.
- Deployment anyone can run. If releasing needs a specific person, the service has a dependency nobody has priced.
Why it must be continuous
At handover the incentives are wrong. The outgoing supplier is winding down with people reassigned; the incoming one is pricing work it cannot see. Documentation written then is written under pressure by people leaving. Written throughout, it costs almost nothing and is accurate.
What to require contractually
- Source, infrastructure definitions and pipeline in a repository the buying organisation owns from day one, not delivered at closure.
- Documentation as a continuous deliverable, not a closure milestone.
- A named exit approach, reviewed periodically rather than written when notice is served.
- Data export in a documented format that has been tested at least once.
Why this matters more here
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 something they are required to do — often the people least able to work around it. The same asymmetry applies to a decision nobody can explain and a service nobody can maintain.
Building a service that will be assessed? Get in touch, or read about our public sector work.