Beyond the Checklist: Getting Accessibility Right for UK Public Sector Services in 2026

For several years, the accessibility conversation in UK public sector digital delivery has been framed around a single question: does the service meet WCAG 2.1 at level AA? That question remains necessary, and the answer still matters. But it has become a floor rather than a target, and organisations that continue to plan against it as though it were the finish line are building in a retrofitting cost they have not yet budgeted for.

What is actually being asked of public bodies

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require reasonable adjustments to be made so that services are perceivable, operable, understandable and robust, with a published accessibility statement and a route for users to report problems. Monitoring by government has moved beyond the presence of a statement to the substance behind it.

Two further pressures shape the picture in 2026. The first is the technical baseline itself. Success criteria introduced in WCAG 2.2 address focus visibility, dragging movements, consistent help and accessible authentication, and these have a habit of catching out otherwise well-built services. The second is market expectation. The European Accessibility Act, whose obligations for many products and services took effect in June 2025, has shifted supplier behaviour across the continent, and UK organisations procuring from international vendors increasingly find accessibility terms written into contracts as a matter of course.

The Equality Act 2010 sits underneath all of this. It does not reference WCAG, and it does not need to. It asks whether a service placed unreasonable barriers in someone's way. That is a question about outcomes, and it is answered with evidence about users, not with a certificate.

Where the checklist stops working

Automated scanning tools are genuinely useful. They catch missing alternative text, insufficient contrast, unlabelled form fields and structural errors at a speed no human reviewer can match. What they cannot do is judge whether the alternative text is any good, whether the reading order makes sense to someone using a screen reader, or whether a multi-step form is comprehensible when encountered linearly rather than visually.

There is a familiar pattern in audits: a service scores well on the automated scan, passes a manual review of the obvious flows, and then falls apart when a real user attempts a real task. A date picker that cannot be operated by keyboard. A validation message that appears visually but is never announced. A session timeout that ends without warning while someone is composing a lengthy application. None of these will register in a scan.

There is also an organisational failure mode worth naming. Accessibility work is often commissioned as a final quality gate, weeks before launch, from a supplier whose contract did not include it. At that point the findings are correct but unwelcome, and the pressure is to fix the cheapest items and defer the rest. That is how services end up with an accessibility statement that describes a level of conformance the team privately doubts.

Testing with disabled users as an engineering discipline

User research with disabled people is sometimes treated as a reputational gesture. It should be treated as a form of technical testing, with the same rigour applied to recruitment, scripting and the handling of findings.

In practice this means recruiting participants who use the assistive technology relevant to the tasks being tested, not a generic panel. It means testing against authentic tasks, such as applying for a concession, updating an address or checking an entitlement, rather than browsing a homepage. It means recording findings as defects against named requirements, with severity and owner, so they enter the same backlog as everything else. And it means repeating the exercise after remediation, because an untested fix is an assumption.

Organisations that do this well tend to report a secondary benefit: the defects raised are frequently usability problems for everyone, not only for disabled users. Accessible authentication, clear error messaging and predictable navigation improve completion rates across the whole audience.

Procurement is where the leverage sits

The most cost-effective accessibility intervention is a contract clause written eighteen months before launch. Frameworks and tender documentation should require conformance with WCAG 2.2 at level AA as a contractual obligation, not an aspiration. They should require a published accessibility statement that is accurate at the point of publication, an audit carried out by a suitably qualified third party, and remediation obligations with timescales attached to them.

It is equally important to require evidence of research with disabled users at defined points in the delivery lifecycle, and to make accessibility defects a category that can block acceptance. Suppliers that invest in this work will not object. Suppliers that do not will either decline the work or price it properly, and either outcome is preferable to discovering the gap after the budget has been spent.

The commercial arithmetic of retrofitting

Remediation late in a build is not simply a matter of adjusting markup. Design decisions, component libraries, content models and third-party integrations can all embed inaccessible patterns that are expensive to unpick. A component library that was never built with focus management in mind may need replacing rather than patching. Content written without structure may need rewriting by subject matter experts who are already at capacity.

The reputational exposure is harder to quantify and rarely smaller. Public sector services are used by people who have no alternative, and failures tend to surface in complaints, in casework raised through elected representatives, and occasionally in litigation. Those are poor venues for discovering a problem that a testing session in month three would have caught.

Practical steps for the months ahead

• Treat WCAG 2.2 at level AA as the contractual baseline, with conformance testing embedded at each release rather than performed once.
• Commission manual and assistive technology testing on every service that handles a transactional or information-critical journey.
• Schedule research with disabled users during design and again before launch, and route findings into the backlog with owners.
• Review accessibility statements for accuracy, including known issues and the process for reporting problems.
• Add accessibility obligations, audit requirements and remediation timescales to procurement documentation.
• Brief content and design teams on structure, plain language and interaction patterns, since a large share of defects originate there.

The direction of travel is clear and has been for some time. Services that embed accessibility in design, build and procurement will spend less, launch with more confidence, and reach more of the people they were funded to serve. Those that wait for an audit to tell them what is wrong will pay for the same work twice.