Session Timeouts and Time Limits, Done Properly
Time limits on tasks, such as sessions that expire, forms that time out and offers that reset, and how people are warned and given more time.
Marcus Adeyemi
What is at stake
People who read, type or move more slowly lose work when sessions expire without warning, and WCAG requires time limits to be adjustable at level A.
The playbook
- Warn users before a session expires
- Let users extend with a single action
- Save form progress so it survives a timeout
- Tell users about time limits before they start
- Make warnings accessible to screen readers
Where it goes wrong
Avoid:
- Silent session expiry that discards form data
- Countdown warnings that are not announced
- Short limits on multi-step forms
- Requiring users to start over after a timeout
The numbers behind it
| Measure | Figure |
|---|---|
| WCAG 2.2.1 Timing Adjustable, A | users can turn off, adjust or extend time limits, with at least 20 seconds to extend |
| Extension | users must be able to extend at least ten times with a simple action |
| Exceptions | real-time events and limits longer than 20 hours |
| WCAG 2.2.6 Timeouts, AAA | users are warned about inactivity timeouts that could cause data loss |
Getting outside help
When to hand it over: Bring in help when banking, government or checkout flows use strict timeouts, or when users report losing work.
Where this comes from
- W3C Web Accessibility Initiative — Understanding SC 2.2.1 Timing Adjustable
- W3C Web Accessibility Initiative — Understanding SC 2.2.6 Timeouts
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
