Designing Public Services People Can Actually Use

An online form can pass an automated accessibility scan and still be unusable for someone who needs the service. The person may not know whether they are eligible. The form may ask for a document they cannot obtain. A failed upload may erase half an hour of work. A successful submission may produce no useful information about what happens next.

These are not all failures of HTML. They are failures of the service around it.

For a public-service team, accessibility work should therefore follow two connected tracks: make the digital interface accessible, and make the whole task possible for people with different circumstances. Neither track replaces the other.

Define the outcome in a person’s terms

Start with the moment the person needs help and end with the outcome they need. For a permit, that could include finding the right application, understanding the requirements, supplying evidence, paying, receiving a decision, and correcting a mistake.

Map the steps outside the website as carefully as the steps inside it. A resident may need an email attachment, a scanner, a bank card, a reliable phone number, or a visit to another office. Each requirement can introduce a barrier.

The Digital Services Playbook emphasizes understanding users and the experience across online and offline encounters. Apply that idea by testing the entire task rather than showing someone a polished screen and asking whether they like it.

A useful research prompt is: “Show us how you would complete this using the information and equipment you actually have.”

Establish the technical foundation

WCAG 2.2 provides testable criteria for web accessibility. Its coverage includes text alternatives, keyboard access, understandable errors, contrast, reflow, and other aspects of interaction. Conformance is a defined technical claim; it cannot be inferred from one automated tool.

Build semantic HTML, visible labels, clear focus indicators, and predictable navigation into the first working version. Verify that a keyboard user can reach every control, understand where they are, and complete the task.

Use real text rather than putting essential instructions in an image. Connect error messages to the fields they describe. Test zoom and narrow screens. Where an interaction depends on dragging, consider how someone could complete the same action without it.

These are implementation checks to investigate, not a complete conformance checklist. The applicable WCAG criteria, the service’s requirements, and testing with disabled users should determine the full review.

Remove unnecessary demands

Every field should have a reason. Ask who uses the answer, what decision it supports, and whether the information is needed at this point.

“Our old form asked for it” is not sufficient. Neither is collecting information because a future feature might use it.

An application may genuinely need proof of an address. But there is still a design question about when to ask, what evidence is accepted, and how someone can resolve a mismatch. Eligibility rules and evidence policy often deserve attention before visual styling.

Treat these as design investigations. A requirement may be justified, but its purpose and consequences should be understood.

Design the failed attempt

Error recovery is part of the main journey. People mistype dates, upload large files, lose connectivity, and misunderstand unfamiliar terms. The interface should help them recover without starting over.

An effective error explains what happened, where it happened, and how to fix it. “Invalid input” offers very little help. “Enter the date as month, day, and year” provides a next step, though the field itself should make the expected format clear before an error occurs.

Preserve valid answers when another field fails. For file uploads, state permitted formats and limits before selection. Confirm when a file has arrived. Avoid exposing personal details in an error message or URL.

Consider the handover after submission as well. A receipt should say what was received, provide a reference if appropriate, explain the next step, and identify a way to seek help. A “success” banner is insufficient if the user still cannot tell whether their request entered the system.

Make assisted routes part of the service

The GOV.UK Service Standard includes a joined-up experience across channels. That matters because moving a form online does not remove the need for assistance.

A telephone or in-person route should not become an invisible second-class process. Staff need access to the same current guidance and a way to help resolve a case. Otherwise, the person must repeat their story while the organization loses the connection between contacts.

Plan what happens when a support worker completes a task with someone. Clarify consent, identity checks, and how confirmations are delivered. Test the process with the staff who will actually handle it.

The same principle applies to service requests: changing the reporting channel is useful only when the issue can still reach an accountable operational team.

Measure completion and friction together

A high submission count can coexist with a difficult service. Count the people who could not begin, the cases returned for correction, repeated contacts, and time spent waiting for missing information.

Useful measures depend on the task. A team might track completion by channel, abandonment at a demanding step, calls made to clarify instructions, and the proportion of submitted cases that staff can act on without further clarification.

Do not collect sensitive characteristics merely because a dashboard could display them. Choose proportionate research methods and explain the purpose of the data. Small-scale, carefully conducted usability sessions can identify problems that aggregate statistics hide.

Distinguish an interface improvement from a policy improvement. Clearer wording might reduce confusion while an evidence requirement still excludes some users. Recording both prevents a design team from claiming to have solved a barrier it only made more visible.

Review the service after launch

Accessibility can regress when an instruction changes, a new document is added, or a third-party payment step is replaced. Include content and external dependencies in the review process.

Give a named service owner responsibility for acting on feedback. A feedback address is useful only if someone can connect the report to a change.

The most useful standard is concrete: can someone understand the task, complete it with their available means, recover when something goes wrong, and learn what happens next? That is where public technology becomes a service people can rely on.