Session times out without warning

What is this issue?

A page or application enforces a fixed session duration or inactivity window after which it logs the user out or discards unsaved input, and provides no mechanism to warn the user the deadline is approaching or to extend the session before it fires. WCAG 2.2.1 Timing Adjustable, a Level A criterion in place since the original WCAG 2.0, permits time limits to exist; what it requires is that the user be able to turn the limit off, adjust it, or extend it, with narrow exceptions for real-time or genuinely essential time limits, such as a live auction.

The failure isn’t the timeout’s existence, which is often a legitimate security or resource-management decision. It’s the absence of any warning-and-extend mechanism before the timeout takes effect.

Why does this matter?

A silent session timeout treats every user as though they can read, type, and navigate at a fixed, average pace, an assumption that’s wrong often enough to matter. Someone using a screen reader to work through a long form takes measurably longer per field than a sighted mouse user does, and a timeout calibrated to typical browsing speed can expire mid-task purely because assistive technology takes real time to operate, not because the user was inactive in any meaningful sense.

The cost compounds with what’s lost: a timed-out banking session might just require logging back in, but a timed-out multi-page application form can silently discard twenty minutes of careful data entry with no recovery path, forcing the user to start completely over. For someone who already found the task effortful the first time, a silent timeout can be the difference between completing it and giving up entirely.

Who is affected?

• Screen reader users: navigating and completing forms with a screen reader takes longer per interaction than visual, mouse-driven navigation, so a timeout calibrated to typical browsing pace can expire mid-task even though the user was actively working the entire time.
• Cognitive disabilities: some users need more time to read instructions, process what a form is asking, or recover from an error before continuing, and a silent expiry adds the burden of restarting the whole task with no warning it was about to happen.
• Motor impairments: users operating a keyboard, switch device, or other adaptive input complete the same interactions more slowly than mouse-driven navigation, and a fixed timeout window doesn’t account for that difference in interaction speed.

What users experience

Wendell has a motor impairment and navigates web forms using a single switch paired with on-screen scanning software, which selects each field and button through a slow, sequential scan rather than direct pointing. He’s most of the way through a lengthy insurance claim form when a 15-minute inactivity timeout, calibrated for a mouse-driven user completing the same form in a fraction of that time, logs him out with no warning. All of his entered information is gone, the form reloads to a blank state, and he has to restart the entire claim from the beginning using the same slow input method that made the first attempt take fifteen minutes in the first place.

How do I fix it?

Warn the user before the session expires, well ahead of the actual deadline, and give them a single, obvious action to extend it. This satisfies 2.2.1 directly, because the criterion doesn’t require removing time limits: it requires that the user retain control over them, and a timely warning with a one-click extension is the most broadly compatible way to provide that control.

Implement the warning as a dismissible, keyboard-accessible dialog or banner that appears with enough time remaining for a slower user to realistically notice and respond; the accepted technique is roughly the last 20-30 seconds of an inactivity window, though longer sessions with more consequential data loss warrant an earlier warning. Pair this with auto-saving in-progress form data as a second layer of protection, so even a missed warning doesn’t cause total data loss, though auto-save alone does not substitute for the warning-and-extend mechanism itself.

Code Examples

// Logs the user out silently after 15 minutes of inactivity - no warning
setTimeout(() => logOut(), 15 * 60 * 1000);

// Warns at 13 minutes, giving a 2-minute window to extend before logout
const WARNING_AT_MS = 13 * 60 * 1000;
const LOGOUT_AT_MS = 15 * 60 * 1000;

setTimeout(() => showExtendSessionDialog(), WARNING_AT_MS);
const logoutTimer = setTimeout(() => logOut(), LOGOUT_AT_MS);

function extendSession() {
  clearTimeout(logoutTimer);
  resetInactivityTimers(); // restarts both timers from now
}

The original code gives the user no signal at all before ending their session; from their perspective, the page simply stops working. The fixed version surfaces a dialog with two minutes still remaining, giving a keyboard or screen reader user real time to notice the warning and act, and extendSession() gives them a single action that resets the clock entirely rather than requiring them to re-authenticate from scratch.

Common Mistakes

Mistake: “Security policy requires a strict inactivity timeout, so we can’t add a warning.” A warning-and-extend mechanism doesn’t weaken the security timeout; it still logs the user out at the same deadline if they don’t respond. WCAG 2.2.1 doesn’t ask for a longer timeout, only that the user gets a chance to actively confirm they’re still present before it fires.

Mistake: “We auto-save form data, so a silent timeout isn’t really a problem.” Auto-save protects against data loss after a timeout happens, but it doesn’t address the actual requirement, which is a warning and an extension option before the interruption occurs. A user who’s logged out mid-task without warning still loses their place and has to figure out what happened, even if their draft data survives.

Mistake: “This is a new WCAG 2.2 requirement, so older products built before 2.2 released get a pass.” Timing Adjustable (2.2.1) is a Level A criterion from the original WCAG 2.0, not new in 2.2. It has applied to every conformance claim referencing any WCAG version to date. There’s no grandfathering based on when a product was originally built.

How RedFlag Detects This

AI-assisted: flagged by the optional Review Labels feature. Detecting a session timeout, and specifically whether it includes an adequate warning and extension mechanism, requires observing real session behavior over time, not a single static DOM snapshot. RedFlag’s Review Labels feature surfaces candidate session-timeout issues for a human reviewer to confirm or reject; no automated timer-detection logic runs against the page.

False negative: a session timeout implemented in a way the reviewer doesn’t happen to trigger during a review session (a very long inactivity window that would require an extended wait to observe, for example) can go unflagged even though it lacks a proper warning mechanism. False positive: a reviewer can occasionally flag a warning dialog that does exist but wasn’t immediately obvious during a quick pass, if the timing or visual presentation of the warning made it easy to miss during manual review. Manual step: deliberately wait out any session or inactivity timeout the product enforces, and confirm both that a warning appears with adequate time remaining and that a working, easy-to-find extension control is present before the deadline.

Manual Testing

1. Identify every session or inactivity timeout in the product: general session expiry, form-specific timeouts, and any step-up re-authentication windows.
2. Trigger each one by remaining inactive for its full duration, and confirm a visible warning appears before the deadline, not only after the session has already expired.
3. Confirm the warning is announced to screen readers (test with NVDA or VoiceOver) rather than appearing only as a silent visual change.
4. Confirm a single, keyboard-operable action extends the session, and that using it actually resets the timer rather than just dismissing the warning cosmetically.
5. Let the timer run out without responding to the warning, and confirm any in-progress work is either preserved (via auto-save) or that the user is warned clearly about what will be lost.

Related WCAG Success Criteria

2.2.1 Timing Adjustable: For any time limit set by content, the user must be able to turn it off, adjust it, or extend it, with limited exceptions for real-time events or essential time limits. A silent session timeout with no warning or extension mechanism is a direct failure of this requirement.

Related Issues

Meta refresh causes automatic page redirect and Page uses meta refresh with a time limit share this rule’s underlying concern (content changing automatically on a timer the user doesn’t control), applied to page navigation instead of session state.

Accessible authentication requires cognitive function test commonly compounds this rule’s harm directly: a session timeout that forces re-authentication through a cognitive-test-gated login flow makes both problems worse together than either is alone.

User must re-enter information already provided in the same process covers the related consequence of a poorly-recovered timeout: being forced to retype data the system already had, whether from a timeout or an ordinary multi-step form.

Form error is not clearly identified matters directly after a timeout-triggered logout: if re-authentication fails or a form resubmission errors, a clear, specific error message determines whether the user can recover or has to guess what went wrong.

References

• W3C Understanding 2.2.1: Timing Adjustable
• W3C Technique G133: Providing a checkbox on the first page of a multipage form that allows users to ask for more time
• WebAIM: WCAG 2 Checklist