You have felt this one, even if you have never thought of it as an accessibility problem. You start filling out a form, step away for a phone call, come back, hit submit - and the page has quietly logged you out or wiped what you typed. "Your session has expired." For most people that is a small annoyance, a lost two minutes. For someone who reads the screen one line at a time, types with a switch or head pointer, or needs to look away to manage a tremor or a cognitive task, that same countdown can make a form, a checkout, or an account page genuinely impossible to complete. They are not slow. Your clock is just faster than the way they have to work. WCAG has a rule for exactly this, it is one of the oldest in the standard, and it sits inside the version Ontario actually enforces.
Key facts
- WCAG (Web Content Accessibility Guidelines) Success Criterion 2.2.1 Timing Adjustable is Level A - the most basic conformance tier - and has been part of the standard since WCAG 2.0 (W3C).
- If your content sets a time limit, 2.2.1 says at least one of these must be true: the user can turn it off, adjust it over a range that is at least ten times the default, or get a warning with at least 20 seconds to extend it by a simple action, and extend at least ten times (W3C).
- The rule has three narrow exceptions: a real-time event (like an auction), a limit that is essential to the activity, or any limit longer than 20 hours (W3C).
- Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11) s.14 requires organizations with 50 or more employees to meet WCAG 2.0 Level AA on public websites, and Level AA includes every Level A criterion (ontario.ca).
- The next ACR (Accessibility Compliance Report) for organizations with 20 or more employees is due December 31, 2026 (ontario.ca).
What does "Timing Adjustable" actually require?
Less than owners fear, and it is squarely about giving control back to the user. The rule does not ban time limits. Sessions can still expire, security logouts still make sense, a booking hold on an event seat can still tick down. What 2.2.1 says is that when your content imposes a clock on the user, you have to offer them one of three ways out.
The cleanest is to turn the limit off before it ever bites - let the user disable it in advance. The second is to let them adjust it up front, to something at least ten times longer than your default. The third, and the one most sites can retrofit fastest, is the warning-and-extend pattern: before the session dies, show a clear prompt - "You will be signed out in one minute. Stay signed in?" - give the person at least 20 seconds to respond with one simple action, and let them do that at least ten times. Any one of the three satisfies the rule.
Where do hidden time limits hurt real users?
The trap is that these limits are usually invisible to the person who built the site, because they never hit them. You test the checkout by filling it in thirty seconds. The user who needs the rule is filling it in ten minutes, and your idle timer fired at minute five.
The pattern shows up in the places that matter most commercially. A multi-step checkout that drops the cart after a few idle minutes. A long intake or application form that clears on timeout with no warning and no recovery, which is where this rule overlaps hard with getting the form itself accessible. An account or banking session that ends mid-task. Even the login screen can carry a hidden clock - a code or a challenge that expires before someone using assistive tech can get to it, which ties straight into accessible authentication. Notice these are the same high-value, conversion-critical pages you least want anyone abandoning - accessibility and completed sales are pulling in the same direction here.
2.2.1 lives under WCAG's Guideline 2.2, "Enough Time," the same guideline as the pause, stop, hide rule for autoplay and moving content. The through-line is simple: the user, not the page, should decide how much time they need.
Which timeouts are exempt - and which aren't?
This is where the rule is fairer than it first sounds. Three exceptions mean you are not obligated to make every clock adjustable. A real-time event where the timing is the point - a live auction, a limited-inventory sale - is exempt, because there is no honest way to give one bidder more time. A limit that is essential, where extending it would break the activity, is exempt. And any limit longer than 20 hours is exempt, on the sensible logic that a day-long window is not the barrier we are worried about.
What is not exempt is the ordinary idle session timeout - the fifteen-minute logout, the "for your security" auto sign-out on a form. Security is a legitimate reason to have the timeout; it is not a reason to skip the warning and the chance to extend. You can keep the security posture and still meet the rule by warning the user and letting them stay in with one click. The two are not in conflict.
How do you check it, and what's the risk if you don't?
You can sanity-check your own site in a few minutes:
- Find every page that can log you out or clear your input - checkout, account, long forms, anything behind a login.
- Start a task, then wait. Leave the page idle past your session length. Did anything warn you before it expired? Could you extend or stay signed in with a single action? If it silently logged you out or wiped the form, that is the failure.
- Time the warning, if there is one. The prompt has to give at least 20 seconds and a simple way to act - not a two-second flash you can miss while reading with a screen reader.
An automated scanner will almost never catch this. A timeout lives in server and session logic, not in the static markup a crawler reads, so it sails past the automated pass looking clean. This is a textbook case of why a scan is not an audit - and why a bolt-on widget cannot help either, since an overlay cannot rewrite the session logic behind your checkout.
On stakes, the honest picture is the one that applies to every barrier. In Ontario the AODA (Accessibility for Ontarians with Disabilities Act) has no private right of action, so no one sues you under it directly; the live route for an individual is a complaint to the HRTO (Human Rights Tribunal of Ontario) under the Ontario Human Rights Code, and that is how a single complaint actually unfolds. If you sell into the United States, a checkout that times people out is the kind of barrier that shows up in ADA (Americans with Disabilities Act) web claims. The durable answer is not a disclaimer - it is documented remediation: a dated record of what you found and fixed, which is what an honest ACR should reflect by December 31, 2026.
The reassuring part: for most sites this is a small change with an outsized payoff. Adding a "you are about to be signed out - stay in?" prompt is a modest bit of front-end work, and it rescues the exact abandoned sessions that were quietly costing you completed forms and sales.
See whether your forms and checkout time people out, and check for other accessibility issues - free Vayle Report, about 30 seconds: vayle.art. It detects overlay widgets, surfaces real WCAG failures, and tells you exactly what legally applies to your organization in Ontario. No obligation.
Vayle is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.
