← All criteria

Operable · Level A · 2.2.1

Timing Adjustable

A time limit on completing something — a session timeout, a form that expires — has to be turn-off-able, adjustable to at least 10× the default, or extendable with a warning, unless the limit falls into one of a few narrow exceptions.

  • Blind
  • Low vision
  • Motor
  • Cognitive
  • Deaf / hard of hearing
The problem, in practice — select the image to enlarge it
An online application form, comparing a hard session timeout with no way to adjust it against three compliant alternatives. In the problem example, a 'Session expired' message appears after a 5-minute countdown reaches 05:00, discarding the user's step 2-of-5 progress with only a 'Start over' button — there was no way to turn the limit off, extend it, or set it longer in advance. The three solutions shown, in a settings panel, are: (1) Turn it off — a 'Time limit' setting with an 'Off (no time limit)' option selected instead of the 20-minute default; (2) Adjust it — a custom time field allowing the user to set the limit to at least 10 times the default (here, 200 minutes minimum for a 20-minute default); (3) Extend it — a warning banner reading 'Your session will expire in 1 minute. Do you need more time?' with 'Extend session' and 'Add 20 minutes' buttons. A row of icons below lists example time limits (session timeouts, expiring forms, reservations, timed quizzes, live webinars) and the narrow exceptions where time limits are allowed (real-time events, essential security, physical safety, legally required limits).

How to recognize it

Look for anything on a timer that the user didn't set themselves: a session that logs someone out after a fixed period of inactivity, a checkout form that expires and discards entered data, a quiz with a countdown. The failure is a hard timeout with no way to turn it off, extend it, or get a warning before it expires. This is a wide-reaching problem: people with motor disabilities who type slowly, blind and low-vision users navigating with a screen reader who need more time to locate and process content, people with cognitive or language-related disabilities who need more time to read and decide, and deaf users relying on sign language who may need more time working through text in a second language, are all disadvantaged the same way by a limit built around an average-speed sighted user. A few situations are legitimately exempt: real-time events like a live auction where the timing is the actual point, and cases where extending the limit would actually invalidate what's happening — like a countdown for a genuinely time-limited ticket sale. Limits longer than 20 hours are also exempt outright.

How to fix it

Best option: don't impose a time limit unless the activity genuinely needs one. If a limit exists, give the user a way to turn it off entirely before they hit it, or let them adjust it to at least 10 times the default duration. If neither is feasible, warn the user at least 20 seconds before the limit expires and give them a simple way to extend it — and let them do that repeatedly, not just once.

Example

Avoid

setTimeout(() => { logOutUser(); }, 5 * 60 * 1000);
/* hard 5-minute session timeout, no warning, no way to extend or disable it */

Prefer

setTimeout(() => { showExtendWarning(); }, 4.5 * 60 * 1000);
/* warns 20+ seconds before the 5-minute limit and offers a one-click extension, repeatable */

Resources

  • 2.2.2 Pause, Stop, Hide

    Different kind of timing: this criterion is about time limits for completing a task (a session that expires, a form that times out); 2.2.2 is about moving, blinking, scrolling, or auto-updating content that plays on its own and needs to be pausable.