Timeouts

What it asks

If there is an inactivity timeout that could cause loss of user data, the user must be warned about its duration at the start of the process — not just as the timer is running out. The warning is unnecessary only when the data is preserved for more than 20 hours of inactivity.

This complements 2.2.1 (warning before timeout) and 2.2.5 (no data loss). 2.2.6 is specifically about informing the user up front so they can plan around it.

How to meet it

• At the top of any long-form flow, disclose the inactivity timeout: “Your information will be saved for 24 hours” or “If you don’t return within 30 minutes, your application will be discarded.”
• Make the disclosure programmatically associated with the form (so it appears in a screen-reader summary), not buried in a footer.
• If you persist data for more than 20 hours, no warning is required — but a reassurance (“Your draft is saved for 30 days”) still helps users with cognitive impairments who worry about losing work.

Common failures

• Multi-page applications that say nothing about timeout until the modal warning fires two minutes before logout.
• Tax-preparation portals where the timeout policy is in the help centre, not on the form itself.
• Healthcare patient portals that drop unsaved messages with no upfront warning.

Why it matters

A AAA criterion, rarely required for legal conformance — but the underlying principle is sound: users with cognitive disabilities, users who are interrupted by carers or medical appointments, and users who simply take longer to fill in forms all benefit from knowing the timeout up front. It lets them break a long task into safe chunks rather than discovering the limit by losing their work.