Time limits are one of the most common Level A failures we find. They are also among the least noticed, because whoever built the site never came close to hitting one.
The people who hit them are already slower, for reasons outside their control. Somebody scanning a form with a switch device. Somebody reading each field with a screen reader. Somebody with a tremor correcting mistyped characters, or with a cognitive disability re-reading an instruction before answering.
What WCAG Actually Requires
2.2.1 Timing Adjustable sits at Level A, and it is satisfied by any one of six things being true. Three are things you provide, and three are exceptions. Take the three you provide first.
- The user can turn it off before they run into it.
- The user can adjust it over a wide range, to at least ten times the default.
- The user is warned before it expires, given at least twenty seconds to respond, allowed to extend it with a simple action, and allowed to do that at least ten times.
Then the three exceptions, and this is where teams talk themselves into a failure. A real-time event such as an auction, where no alternative to the limit is possible. A limit that is essential, meaning extending it would invalidate the activity itself. And any limit longer than 20 hours, which the rule leaves alone entirely, on the reasoning that 20 hours is longer than a full waking day.
There is no security exception, and that matters more than any other sentence on this page. "Our security team asked for it" is not one of the six routes, and neither is "our session handling works that way". An ordinary logged-in session does not become invalid because somebody extended it, so the essential test does not reach it either. The criterion was written with session timeouts squarely in view.
The Version That Is not Forgivable
A timeout that loses the data somebody entered. That one is unforgivable.
Filling a long form takes longer for a lot of people. Coming back to find it empty means starting again from nothing, and the second attempt runs into the same limit. That is not an inconvenience. It is an interface that cannot be completed at all by the people it affects, no matter how many times they try.
There is a criterion that says so directly, and it is the one nobody quotes. 2.2.5 Re-authenticating asks that when an authenticated session expires, the user can carry on without loss of data once they have logged back in. No exceptions and no notes attached. It sits at Level AAA, so it is not required at AA, and it is the cleanest thing in the whole timing guideline to adopt voluntarily.
Its scope is wider than an inactivity clock too. Plenty of sites log somebody out because they signed in from another machine, or because something looked odd. Those cases are in scope as well, so the data question is not only about people who went to make a cup of tea.
3.3.7 Redundant Entry is often mentioned alongside this, and it is worth being precise about what it does. It says do not ask for the same information twice in one process, and it is scoped to a process rather than to data loss as such. Whether a session expiry keeps somebody inside the same process is a judgment call W3C has not settled. So lean on the re-authentication rule for a timeout that wipes a form, and keep redundant entry for what it actually covers.
The fix that costs least, and the caution attached to it
Preserve the data across re-authentication. If a session expires, log the person back in and return them to where they were with what they typed intact. That satisfies the rule and it stops annoying everybody else too. One caution goes with it, and it comes from W3C rather than from us. Holding a half-finished form for more than 20 hours means storing whatever somebody typed, possibly before they authenticated and possibly about a child. W3C's own note says to talk to privacy counsel before choosing data preservation as your route, and for anyone under the GDPR that is advice worth taking rather than a footnote.
Where Time Limits Hide, and Which Rule Catches Each
Most teams think of the session timeout and stop there. The others catch people out, and each one has a rule behind it, which is what turns a list of places to look into an argument you can put in a backlog ticket.
| Where it hides | The rule that reaches it | Level |
|---|---|---|
| Booking and ticketing holds | 2.2.1, with the essential exception genuinely in play | A |
| Checkout inactivity timers | 2.2.1 for the limit, 2.2.5 for the basket | A, AAA |
| One-time passcodes that expire | 2.2.1, and 3.3.8 where you have to transcribe the code | A, AA |
| Carousels and auto-advancing content | 2.2.2 Pause, Stop, Hide | A |
| Auto-refreshing pages | 2.2.2's auto-updating half, and 3.2.5 Change on Request | A, AAA |
| Toasts that disappear on a timer | 2.2.1, because you set a time limit on reading | A |
| CAPTCHA challenges that expire and reset | 2.2.1, and 3.3.8 | A, AA |
The toast row is the one people get wrong, so it is worth a sentence of its own. A toast is usually a status message, and the status message rule says nothing at all about how long a message stays on screen. It only asks that the message be announced without stealing focus. So a toast that announces properly and then vanishes satisfies that rule completely. What it breaks is the time limit rule, because four seconds of reading time is a limit your content imposed. If the message matters, make it persist until dismissed.
What Good Looks Like
- Warn before expiry, with at least twenty seconds and an obvious way to extend, so nobody loses a session while reaching for the mouse.
- Announce the warning, not just display it. A modal that appears silently is invisible to a screen reader user, who then loses the session mid-sentence with no idea why.
- Preserve entered data across expiry and re-authentication, and the person comes back to their work rather than to an empty page.
- Let people extend repeatedly rather than once, because a single extension just moves the cliff edge.
- Give a way to turn it off wherever your security posture allows it, and the whole problem stops existing on those pages.
- Do not time out reading. Content somebody is reading should not move or clear on a timer, whatever the marketing team wants the carousel to do.
Why This Keeps Happening
There is a structural reason timing problems outlive every other category, and it is visible in how the guideline is built. Guideline 2.2 Enough Time has six criteria. Two of them sit at Level A. The other four, covering no timing at all, postponing interruptions, surviving re-authentication, and warning about data loss, are all Level AAA.
So a team working to Level AA, which is what every law that names WCAG asks for, is obliged to do two things and free to skip four. The four it can skip are the ones that would actually fix the experience. That is not an argument for chasing AAA across your whole site. It is an argument for picking the two or three from that list that fit what you sell, which is what our Level AA versus AAA guide is about.
One honest limit
Timeouts are close to invisible to automated testing. A scanner would have to sit on the page long enough to trigger one, and then know what should have happened instead. Finding these means a person deliberately waiting, which is exactly the kind of thing a human pass is for.