Try this today: start filling out a long form on your own site — shipping address, payment details, whatever your longest one is. Then stop. Go read a slow email, take a call, refill your coffee. Give it two minutes.
If a popup shows up, gives you a handful of seconds to react, and logs you out the moment you miss the window — with no button to just... extend it — you haven't found a quirky default setting. You've found a real, named, testable accessibility failure. It has a number. It has a fix. And it's probably costing you completed forms, abandoned carts, and support tickets from people who assume they did something wrong.
This one's a quick fix once you know what "compliant" actually looks like, so let's get into it.
The Stat: WCAG SC 2.2.1 (Timing Adjustable, Level A) requires that for any time limit set by your content, at least one of the following is true: the user can turn the limit off, adjust it to at least 10 times the default length, or extend it via a warning that gives at least 20 seconds and lets them extend the session at least 10 times — unless an exception applies, such as the limit being essential (a real-time auction), a security-related authentication timeout, or the session simply lasting longer than 20 hours. (Source: W3C WCAG 2.2.1 Understanding document)
Why a 20-second countdown is a legal and usability problem, not just a UX nitpick
Session timeouts exist for good reasons — security on shared devices, server load, sensitive data exposure. Nobody's arguing you should never time people out. The problem is how most timeout warnings are built: a modal appears, a countdown ticks down from 20 or 30 seconds, and if the user doesn't click a tiny "Stay logged in" button in time, everything they typed is gone.
That design fails a huge range of real users before it fails anyone else:
- Someone using a screen reader who needs time to have the popup announced, understand it, and locate the button.
- Someone with a motor impairment who needs more time to physically move a cursor or switch device to reach the button.
- Someone with a cognitive or attention-related disability who needs a moment to process what's happening.
- Literally anyone who stepped away, got a phone call, or was reading a long paragraph on your form.
WCAG 2.2.1 doesn't ask you to remove timeouts. It asks you to build in one of three legitimate escape hatches, and it's specific about the minimums.
The three ways to pass SC 2.2.1
Per the WCAG 2.2.1 Timing Adjustable success criterion, you only need one of these to be true:
- Turn it off. The user can disable the time limit before encountering it (rare in practice for session security, but common for things like auto-advancing content).
- Adjust it. The user can extend the limit to at least 10 times the default length before it starts.
- Extend it with a warning. The user is warned before time expires, given at least 20 seconds to respond, and can extend the session — and this extension option must be available at least 10 times (so someone can effectively work for a long time by repeatedly hitting "extend").
There are also documented exceptions worth knowing so you don't over-engineer things that don't need it: real-time events like a live auction, and time limits that are part of an essential security mechanism (like a banking session that must expire), are exempt — as is any time limit longer than 20 hours, since that's considered long enough not to be a barrier.
What a compliant timeout warning actually looks like
Here's the checklist version of the fix, in the order you'd typically implement it:
- Warn the user before the session expires — not after.
- Give at least 20 seconds between the warning appearing and the session actually ending.
- Provide a clearly labeled, keyboard-reachable button to extend the session.
- Allow that extension to happen at least 10 times, not just once.
- Announce the warning to assistive technology the moment it appears — a silent modal that only sighted users notice is its own failure.
- Alternatively (or additionally), let users set their own timeout length up front, at least 10x your default.
That fifth point matters more than most teams realize. A modal that pops up visually but doesn't get announced to a screen reader user is functionally invisible to them — the countdown could hit zero while they have no idea anything happened. This is exactly the kind of dynamic content that MDN's guide to ARIA live regions covers: wrapping your warning in a live region (or firing focus to it) means assistive technology announces it the instant it renders, not only if the user happens to be focused there already.
| Approach | Meets SC 2.2.1? | Notes |
|---|---|---|
| Fixed 20-second popup, no extend button | No | Warns, but gives no way to extend — fails outright |
| "Stay logged in" button, but only usable once | No | One extension isn't enough — needs at least 10 |
| Warning + extend button, reusable 10+ times | Yes | Meets the "extend" path of 2.2.1 |
| User can set session length to 10x the default in account settings | Yes | Meets the "adjust" path — no warning modal even required |
| Session simply lasts longer than 20 hours | Yes (exempt) | Falls under the built-in exception |
Don't forget the form data itself
A timeout that logs someone out silently mid-form is a double failure: it's a timing violation, and it usually destroys unsaved input, which pushes it into general usability territory too. If you're auditing your timeout warning, it's worth auditing the surrounding form at the same time — WebAIM's guide to accessible forms and timing is a solid reference for making sure error messages, validation, and field labels hold up for the same users who are most affected by aggressive timeouts.
A practical pattern that solves both problems at once: auto-save form state locally as the user types, so even if a session does expire, nothing is lost when they log back in. It's not required by 2.2.1, but it's the kind of belt-and-suspenders fix that turns a compliance checkbox into an actual trust signal.
A word on the security-exception exception
Teams sometimes reach for the "essential security mechanism" exception to justify a genuinely too-short timeout, and it's worth being honest about how narrow that exception actually is. It's meant for cases like a banking session where a shorter window is a deliberate, load-bearing security control — not a default excuse for any login-gated page. If your session timeout exists mainly to reduce server load or nudge inactive users out, that's a UX and infrastructure decision, not a security-essential one, and it still needs a real extend-or-adjust path under SC 2.2.1. When in doubt, ask whether a longer timeout would meaningfully increase real risk, or just feel less tidy from an ops perspective — those are very different justifications.
The quick audit you can do right now
Open your site in a new tab, log in, and just wait. Time how long the warning gives you, check whether you can extend more than once, and check whether a screen reader (or even just your browser's accessibility inspector) picks up the alert the moment it appears. If any of those checks fail, you've found a real Level A gap — not a hypothetical one.
If you'd rather not do that page by page across your whole site, that's exactly the kind of thing worth automating. Get a free scan that flags timing barriers across your site, and see exactly where your session timeouts — and everything else on the timing-sensitive side of WCAG — currently stand.