A Countdown to Nothing: Auditing Session Expiry on UK Benefits Portals

Session timeouts are rarely the first thing an accessibility team examines. They sit in authentication logic, are owned by security, and are justified by a familiar phrase: we have to protect user data. That justification is sound. The difficulty begins when protection is implemented without considering the people who need more time to read, understand, and respond.

For a claimant completing a Universal Credit journal entry, a council tax reduction form, or a housing benefit review, an unexpected logout is not a minor inconvenience. It can mean re-entering dozens of fields, losing uploaded evidence, and abandoning the task altogether. The cost falls disproportionately on people with cognitive disabilities, people using screen readers, people with motor impairments who type slowly, and anyone reading in a second language.

This audit routine is intended for teams responsible for UK benefits portals, local authority self-service forms, and related citizen-facing services. It is not a security review. It is a practical test of whether a time limit respects the person using the service.

What the standards actually require

The relevant success criteria are WCAG 2.2.1 Timing Adjustable and WCAG 2.2.2 Pause, Stop, Hide. The first governs the time limit itself: for each time limit set by content, the user must be able to turn it off, adjust it, or extend it before it expires, with at least twenty seconds of warning and a simple way to extend — for example, pressing the space bar. There are exceptions, including real-time events and limits that are essential, but a benefits form is rarely one of them.

WCAG 2.2.2 is often overlooked in this context. It applies to moving, blinking, scrolling, or auto-updating content that starts automatically, lasts more than five seconds, and is presented alongside other content. A warning banner that disappears after a few seconds, before a screen reader has finished announcing it, is a failure under 2.2.2. The two criteria work together: one addresses the countdown, the other addresses the warning.

A claimant journey under test

Begin with a realistic task rather than a synthetic one. Ask a colleague who uses a screen reader to complete a council tax reduction form from start to finish. Use a keyboard only. Set browser zoom to 200 per cent. Read at a measured pace. Record every point at which the service behaves unexpectedly.

In a recent walkthrough of a district council portal, the inactivity period was fifteen minutes. The warning appeared at two minutes, in a modal dialog that had no accessible name. Focus remained on the form field behind the dialog. The only control was labelled ‘OK’. When pressed with a keyboard, it dismissed the warning but did not extend the session. The extension control was a separate link below the dialog, reachable only by tabbing past the dialog’s close button. A screen reader user would not know it existed.

At expiry, the form cleared. The browser’s back button returned to a blank page. The claimant had spent thirty-eight minutes entering income details and uploading a payslip. There was no draft saved and no explanation of what had happened.

That is not an edge case. It is a common pattern.

Common failures that penalise slow readers

Several recurring issues emerge across UK benefits and council tax portals. Warning periods are often shorter than twenty seconds, or the warning appears but the extension control is not keyboard operable. Modal dialogs are used without focus management, so screen reader users hear neither the warning nor the countdown. Timer resets depend on mouse movement, which excludes keyboard-only users. Draft answers are held only in the browser session, so a timeout destroys them. Re-authentication returns the claimant to a dashboard rather than the point of interruption.

A further problem is the language of extension controls. A button labelled ‘Continue’ or ‘More time’ without context is ambiguous. A control labelled ‘Stay signed in for another fifteen minutes’ is clear. The difference matters for people with cognitive disabilities, who may not infer what the button does under time pressure.

A plain-English checklist

1. Publish the inactivity period before the form begins, in plain language, alongside an explanation of what will happen if the session expires.

2. Warn at least sixty seconds before expiry. Twenty seconds is the WCAG minimum; sixty is a more humane default for complex forms.

3. Use a modal dialog with an accessible name and description. Move focus to the dialog when it opens. Announce the warning through a live region if the dialog approach is not used.

4. Label the extension control explicitly: ‘Stay signed in for another fifteen minutes’. Make it the first focusable element in the dialog.

5. Do not auto-dismiss the warning banner. Let the user close it or act on it.

6. Save draft answers server-side at each step. Restore the claimant to the exact point of interruption after re-authentication.

7. Allow the session to be extended by keyboard, screen reader, and switch access — not by mouse movement alone.

8. Test with a screen reader, keyboard-only navigation, 200 per cent zoom, and a deliberately slow reading pace. Record the actual time taken to complete each step.

9. Provide a route to request a longer session for people with cognitive disabilities, without requiring a phone call or written evidence. A simple checkbox at sign-in is sufficient for most services.

10. Treat timeouts that cause data loss as incidents. Log them, review them quarterly, and report them alongside other accessibility defects.

Designing for the person, not the server

Security is not the enemy of accessibility. Poorly designed security is. A session timeout can protect data without discarding a claimant’s work. It can warn without ambushing. It can extend without requiring a mouse. The technical work is modest; the cultural work is larger. It requires teams to stop treating the countdown as a fixed constraint and start treating it as a design decision with consequences.

For UK benefits portals, the stakes are plain. The people most likely to need more time are often the people least able to absorb a setback. A timeout that clears a form is not a neutral security measure. It is an exclusion, delivered on a timer.