The Interrupted Form: A Practical Audit for UK Session Timeouts
Photo: Unknown, Public domain, via Wikimedia Commons
Consider a familiar UK scene. Someone starts a council form on a laptop in the kitchen. The doorbell rings. A delivery needs signing for. A child needs attention. The kettle boils. Ten minutes later, the user returns to a screen that has quietly ended the session and erased the last half hour of work. The security clock did its job. The service did not.
Session timeouts are usually set for good reasons. They limit exposure on shared devices and reduce risk on sensitive accounts. But many timeout designs assume a continuous, uninterrupted user. That assumption is poor for UK households, where caring responsibilities, deliveries, shared devices and unreliable connections are ordinary conditions. For people with cognitive, motor or visual impairments, the assumption is even weaker.
The household is part of the interface
A timeout is not only a security control. It is an interaction. It decides whether a user can pause, answer the door and continue. It decides whether a screen-reader user hears a warning in time to act. It decides whether a keyboard-only user can reach the extend control before the countdown ends.
WCAG 2.2.1 requires that time limits can be turned off, adjusted or extended, with exceptions. That is the baseline. It is not the whole test. A service can meet the letter of a success criterion and still fail the household.
Audit the pause, not just the clock
Start by recording the timeout duration, but do not stop there. Test realistic interruptions. Ask participants to begin a multi-step form, then pause for two minutes, five minutes and fifteen minutes. Observe what happens. Does a warning appear before expiry? Is it visible without scrolling? Is it announced to assistive technology? Can the user extend the session with a keyboard alone?
Measure the warning window. A message that appears five seconds before expiry is technically a warning but practically useless. WCAG guidance for timing adjustable suggests at least 20 seconds to extend, but the right figure depends on the task. A payment form and a simple newsletter sign-up do not carry the same risk.
Warning visibility and accessible controls
Warning dialogs are often built as visual overlays with poor focus management. Check that the dialog has an accessible name and description. Confirm that focus moves into it and returns to a sensible place when it closes. Ensure the extend control is reachable by Tab and operable with Enter or Space. Do not rely on a mouse-only countdown.
For screen-reader users, the warning should be announced once, clearly. Repeated announcements can be disorienting. The text should say what is happening and what to do: for example, your session will end in two minutes; select extend to continue. Avoid unexplained jargon. Avoid colour alone to signal urgency.
Test at 200 per cent zoom and on a small screen. A dialog that pushes the extend button off-screen is not an accessible warning.
Saved progress and legitimate interruption
The decisive question is whether work survives. Fill a multi-step form, wait beyond the timeout, then return. Can the user re-authenticate and resume? Is a draft saved? If data is lost, was that made clear before the user started?
Saving progress is not always simple. It raises privacy and data protection questions, especially in public services. But the absence of any recovery path is a design choice. A service can offer a short-lived draft, a reference number, a callback or a clear explanation that work will be lost. What it should not do is surprise the user after the fact.
A small, repeatable protocol
Recruit five to eight participants, including at least two who use assistive technology. Use a staging environment and a realistic task. Script an interruption: a doorbell, a phone call, a child needing help. Record whether the warning is noticed, whether extension succeeds, whether data is preserved and how long recovery takes. Repeat on mobile and desktop.
The results are usually less about the timeout length than about the recovery design. Teams often discover that the warning is invisible to screen readers, the extend button cannot be reached by keyboard, or the form loses data even when the user re-authenticates.
Designing for the interrupted user
Set timeouts by risk, not by habit. Give generous limits on long public-service forms. Warn early and make the warning accessible. Preserve progress where lawful and sensible. Explain what will happen if the user pauses. Test the whole path with people who are interrupted, not only with people who are focused.
Interruptions are not edge cases in UK homes. They are the normal rhythm of using a service. A timeout audit that ignores them measures the clock but misses the experience.
