How to fix: session timeouts without warning

What it looks like in the wild

Form data is lost when an idle session expires without warning.

The screen-reader user, keyboard user, or low-vision user encountering this issue does not get an error message. The page just stops working for them. Which is why this kind of bug rarely shows up in your error tracker; it shows up in support tickets, lawsuits, and abandoned conversions.

Why it fails WCAG

Cognitive accessibility users need warning + extension.

The wrong pattern (avoid)

setTimeout(() => location.href = '/logout', 600000);

The right pattern (copy this)

// 9 minutes: warn
// 10 minutes: log out (unless extended)
showWarningDialog({ extend: () => resetTimer() });

Notes from real audits

• Warn at 80% of the timeout window — at 4 minutes into a 5-minute session, for example.

• The warning dialog itself must be keyboard accessible and focusable, or users with motor disabilities may not reach it in time.

• Authentication timeouts for security reasons are exempt, but you should still warn and offer a re-authentication path.

• Store form data in sessionStorage during the session so users do not lose input even when a timeout occurs.

How to verify the fix

Shipping the change is not the same as passing 2.2.1. Re-run these checks against the page you edited before you close the ticket.

• Trigger every time limit; verify warning + extension or off-switch.

What 2.2.1 requires

2.2.1 Timing Adjustable (Level A, Operable): For each time limit set by the content, the user must be able to turn it off, adjust it, or extend it. Banking and government forms commonly time out aggressively. Without warning and a way to extend, users with cognitive disabilities or motor impairments lose work.

• Banking sessions timing out at 5 minutes with no warning

  2.2.1

Priority: Serious

This is one of the findings that shows up in demand letters, because the barrier it creates is total rather than inconvenient: the affected user cannot complete the task at all. Treat it as a release blocker, not a backlog item.

Because the cause is almost always a shared component rather than a single page, fix it where the component is defined and re-scan the whole site. Record 2.2.1 on the ticket verbatim: that string is what an auditor, a procurement questionnaire or a regulator will search for.