Session timeout needs a warning beforehand

What it is

A signed-in session, a cart, a half-filled application will be voided by the server after some idle time. Before that voiding, a warning must appear, with enough time to extend the session or save first. Discovering only at submit that the page is now a login screen — and that the in-progress input was dropped with the timeout — is not something “the time limit can be turned off” can repair afterwards. The data is already gone.

Warning is the dedicated exit for this kind of limit. Security often forbids turning idle lock off forever; it can, and must, still warn before the cut.

Why it happens

The session clock runs on the server; the person in the browser cannot see it. Reading a notice, listening through a terms page, going to fetch an ID all look like idle. When the clock hits, the next request returns with an expired cookie, the page is swapped for login, and unsaved fields die with the document. Without a prior warning, the user cannot tell “I clicked wrong” from “time ran out”. A warning so short that assistive technology cannot reach Continue is equivalent to none.

The warning must itself be reachable. It is often a timed dialog. If focus does not enter, a screen reader does not speak, and the countdown is a few seconds, the extend action is eaten by the same limit. Operability of session time lives or dies on that beat.

Studying it

Enter a long form with a real or test account and sit still until near the idle cap. Record: does a warning appear, how much lead time, is it keyboard-operable, does choosing extend actually renew the session, does a draft survive if extend is skipped or missed.

Contrast: after timeout, sign in again — are the fields still there? Many implementations warn and still do not save, so the user loses data anyway. The floor for this leaf is warning plus an extend that works; data loss upgrades the failure from “could not confirm in time” to “the work is void”.

Where it stops holding

Hard idle locks in banking, health and kiosks may be short and still need a warning — industry sensitivity does not remove lead time; it scales lead time to the lock (a short lock still has to leave time to operate the warning). A no-account browsing session with nothing to lose can skip the warning; a cart, a submission or a survey once started is not “nothing”. In multiple tabs, if one tab times out while another is still being filled, the warning should appear on a still-visible page, not only on the tab already left.

Applying it

• Before the server cuts the session, show an operable warning that states roughly how much time remains, with Continue session and, where needed, Save first.
• Move focus into the warning when it appears, and make it speakable by a reader. The countdown must outlast one activation via assistive technology.
• Extend must actually renew the server session, not only dismiss the dialog.
• How to check: stop halfway through a form and wait for the warning. Continue from the keyboard only, then submit. If no warning ever appeared, or fields are still gone afterwards, session timeout did not warn in time.

Related

• Same group: J3.06.1 Time limits must be turn-offable, adjustable, or extendable · J3.06.2 Auto-advancing carousels must be pausable
• Nearby: J4.09 Reducing memory load · J3.02 Focus order and focus traps · J5.12 Live regions and dynamic announcements
• Search terms: session timeout · idle warning · extend session