The Adjustments Gap: A 2026 Audit for UK Services That Pass WCAG and Still Exclude People

A service can pass every automated check, publish an accessibility statement, and still leave a disabled customer unable to complete the transaction. That gap is not a technical failure so much as a governance one. Accessibility standards describe how a page should behave; equality law describes what a service must do for the person who cannot use the page in its current form. UK product teams need to audit both, and most currently audit only the first.

Two obligations, one service

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 set WCAG 2.2 AA as the technical benchmark for public sector sites, with an accompanying statement and a published contact route for reporting problems. The Equality Act 2010 operates differently: it places a duty on service providers to make reasonable adjustments, and that duty is anticipatory. An organisation cannot wait for an individual to ask; it must think in advance about the barriers its service creates and remove or mitigate them.

Reasonable adjustments are wider than the interface. They can mean an alternative format, a different channel, additional time, staff assistance on the phone, or a documented decision to waive a policy in defined circumstances. No overlay widget supplies any of that. Nor does a conformance report, however thorough.

Stage one: sign-up and identity

Registration is where adjustments are most often needed and least often designed.

• Do the name fields accept single names, hyphens, apostrophes and non-Latin scripts without error?
• Does address lookup recognise new-build properties and non-standard formats?
• Can identity verification be completed without a smartphone, and without a live selfie check that excludes people unable to hold a device steady?
• Is there an alternative to the automated route — a branch visit, a posted form, a telephone verification — and is it signposted before the user fails, not after?
• Do session timeouts accommodate someone using a screen reader, a switch or speech recognition at a fraction of typical speed?
• Are verification codes readable by screen readers, and does the code expire before a slower user can enter it?

Stage two: checkout and payment

Payment journeys combine third-party components, strict time limits and high emotional stakes, which makes them the most common site of failure.

• Can the whole purchase be completed by keyboard alone, including any card iframe and the strong customer authentication step?
• Does the bank authentication redirect return the user to a focused, announced position, or silently to the basket?
• Are saved-card and Open Banking routes each independently accessible, rather than one being an accessible fallback for the other?
• Does the countdown timer warn, pause or extend on request, and is that documented?
• Can invoices and receipts be obtained in an alternative format without a support ticket?
• Are error messages specific, programmatically associated with the field, and written in plain English?

Stage three: support and redress

A service is only as accessible as its complaints route.

• Is there a contact method that does not require a form, a smartphone app or a queue longer than a reasonable person would tolerate?
• Can webchat escalate to a human, and is that escalation reachable by keyboard and screen reader?
• Do front-line staff know how to record an adjustment request, and is there a named owner for the resulting action?
• Are complaint processes available in easy read, large print, Braille and audio, and are those formats offered rather than extracted?
• Is the accessibility statement honest about known gaps, with a working contact and a stated response time?

Stage four: content and alternative formats

Plain English is an adjustment in its own right. Review reading age across the five most-used journeys, and check that critical information is not buried in PDFs that fail to tag headings or reading order. In Wales, Welsh-language provision is a legal expectation for many public bodies, not a nicety. Elsewhere, consider translation need across the languages most used by the communities you serve.

Also examine assumptions. A date field that only accepts one format, an upload control that permits only JPEG, a form that requires a mobile number for a delivery notification: each is a small design decision that becomes somebody else's barrier.

Stage five: assistive technology testing beyond the checklist

Manual, task-based testing remains irreplaceable. A workable 2026 matrix for a UK product team:

• NVDA with Chrome on Windows; JAWS with Edge for the enterprise estate.
• VoiceOver on macOS and iOS; TalkBack on Android.
• Dragon or platform voice control for a form-heavy journey.
• Keyboard only, at 400% zoom, with reflow and no horizontal scrolling.
• Windows High Contrast and forced-colours modes; reduced motion enabled.
• Switch access or a head pointer for at least one core journey each quarter.

Test complete journeys rather than isolated pages, and record where the participant needed assistance. Assisted completion rate is a more honest metric than a pass count.

Documenting the decision

Maintain a reasonable adjustments register with five fields: the barrier identified, the adjustment offered, the channel through which it is available, the owner, and the review date. Distinguish anticipatory adjustments, designed in before anyone asks, from reactive ones triggered by an individual request. A healthy service should show a rising proportion of the former.

A sustainable cadence

Audit five complete journeys each quarter, rotating one into an assisted session with a disabled participant every sprint. Review the register at the same meeting as the defect backlog, so that adjustments compete for engineering time on equal terms. Update the accessibility statement annually and whenever a material change ships.

Conformance work will keep a service legally defensible. Only the adjustments audit will make it usable by the people the law was written to protect.