Who Gets In? Rethinking Sign-In Accessibility Across UK Services

Accessibility work often stops at the front door. Teams audit the homepage, the service finder, the form and the accessibility statement. Then the resident is asked to sign in, and the quality of the experience falls away. A council portal demands a password that meets a long list of rules, followed by a one-time code that must be copied from an email within a few minutes. A retail account blocks paste into the password field. A utility company presents a grid of images as a security check. These are not minor irritations. They are authentication gates that can decide whether a disabled person completes a task at all.

The part everyone forgets to test

Authentication is frequently owned by a different team, supplied by a third party or inherited from a legacy system. It may sit outside the design system and outside the accessibility statement. Yet it is often the point of highest cognitive load: remembering a password, transcribing a code, recognising a pattern, solving a puzzle, keeping within a timeout and recovering an account when something goes wrong. For people with memory impairments, dyslexia, tremor, low vision, attention difficulties or limited dexterity, each step compounds the last.

The UK context makes this urgent. Council tax portals, housing repairs, benefits and blue badge services increasingly depend on accounts. Retailers and utilities push customers towards digital self-service. GOV.UK One Login has raised expectations for reusable government identity, but it does not cover every local service or commercial account. The result is a patchwork of sign-in patterns, each with its own rules and its own failure modes.

What WCAG 2.2 actually requires

WCAG 2.2 introduced Success Criterion 3.3.8 Accessible Authentication (Minimum) at AA level. The principle is straightforward: an authentication step should not require a cognitive function test unless an alternative or an assistance mechanism is available. A cognitive function test includes remembering a password, solving a puzzle, transcribing a code or recognising content under pressure. Mechanisms that assist include allowing password managers, permitting paste and not blocking autofill. The criterion does not ban passwords, but it does challenge the habit of making them harder to use than necessary.

The enhanced criterion, 3.3.9, tightens the position further by removing some of the allowances available at AA. Even teams working only to AA should read both criteria together, because they point in the same direction: do not make memory and puzzle-solving the only route through the door. Success Criterion 3.3.7 Redundant Entry is also relevant. A user who has already supplied information should not have to supply it again simply because a form has been split into stages.

Why sign-in remains a weak point

Security policy is often the obstacle. Rules that block paste are intended to stop careless behaviour, but they also stop password managers and make long, unique passwords impractical for disabled users. Forced password composition rules create memory burden without reliably improving security. CAPTCHAs are presented as a neutral test, yet they can be impossible for people with visual or cognitive impairments, and audio alternatives are not always usable. One-time codes add a second transcription task, often under a countdown. Account recovery may rely on security questions whose answers are forgettable, changeable or culturally specific.

Error handling makes matters worse. A vague message such as an invalid login does not tell the user whether the password, the username or the one-time code was wrong. Fields may clear on failure. Timeouts may arrive without warning. None of these issues is confined to public services, but the consequences are sharper when the account is the only route to a council service or a payment.

Passkeys: promise and pitfalls

Passkeys are the most interesting development in authentication for years. They replace a shared password with a credential held on a device, unlocked by a biometric or a device PIN. For many users they reduce memory load and offer strong protection against phishing. They can be excellent for disabled users when implemented well, because the user is not asked to invent, remember and type a complex secret.

But passkeys are not a universal solution. They depend on device and platform support. Syncing between devices may be opaque. Shared devices, older hardware, locked-down work machines and corporate policies can all complicate the experience. Recovery remains a design problem: if the device is lost, what happens next? The interface must explain clearly where the passkey is stored and what alternatives exist. A passkey prompt that assumes a fingerprint sensor, or that offers no understandable fallback, can exclude people just as effectively as a password field.

The sensible position is to offer passkeys as one good route, not as a compulsory test of modernity. Keep a usable fallback. Let users choose. Test the whole flow with screen readers, switch access, keyboard-only navigation and people with cognitive impairments. Security and inclusion are not opposing goals, but neither is achieved by assuming that a new technology is accessible because it is new.

Practical patterns that reduce load

Start with the basics. Allow password managers and autofill. Permit paste into password fields. Provide a show-password control. Explain requirements before the user starts typing, not after a failed attempt. Use clear, specific error messages and preserve entered data. Allow long passwords and avoid arbitrary composition rules that force users into predictable patterns. Warn before a session expires and offer a way to extend it without losing work.

For one-time codes, allow copy and paste, avoid very short expiry windows and do not require transcription from an image. For recovery, avoid security questions as the only route. Offer a support channel that a disabled user can actually reach. Where identity checks are necessary, explain why the information is needed and what will happen next. Progressive disclosure can help, but only if it does not hide essential requirements or create a trail of steps with no clear progress indicator.

Most importantly, test the entire authentication journey: account creation, first sign-in, forgotten password, one-time code, passkey enrolment, passkey removal, recovery and timeout. Include the error states. A login page that looks accessible in its default state may still fail at the first mistake.

Put authentication inside accessibility governance

Sign-in is not a technical side quest. It is part of the service. Accessibility statements should cover authentication where the organisation controls it, and procurement should ask suppliers about WCAG 2.2 conformance in login, registration and recovery flows. Design systems should include accessible authentication patterns, not just buttons and form fields. Security teams and accessibility teams need to talk to each other before policy becomes a barrier.

The question is not whether a service has a login. It is who can get through it. In 2026, with WCAG 2.2 available and passkeys entering the mainstream, UK organisations have a chance to make authentication the next accessibility priority rather than the next forgotten corner.