2.2.1 Timing Adjustable

Time limits punish anyone who needs longer than the designer assumed: screen reader users navigating a form field by field, people with motor impairments who type slowly, people with cognitive or reading disabilities, and anyone interrupted mid-task. When a session expires, a checkout hold lapses, or a message vanishes before it can be read, the product has quietly decided how fast its users are allowed to be. This criterion (Level A, unchanged since WCAG 2.0) says the content may not make that decision unilaterally: every time limit the content sets must be one the user can turn off, adjust to at least ten times the default, or extend, unless a narrow exception applies.

The auditor's mental model is a two-step filter. First, inventory every time limit the content itself sets: session timeouts (including server-side expiry, which the content sets even though the browser never shows a timer), checkout and booking countdowns, timed redirects, quizzes, one-time codes, and messages or controls that disappear on a timer. Second, run each limit through the six options in order: turn off, adjust, extend, real-time, essential, over 20 hours. One satisfied option is a pass. The extend option is by far the most common compliant pattern in practice: a warning before expiry, at least 20 seconds to respond, a simple action such as pressing one button, repeatable at least ten times. Grade the exceptions sceptically; "essential" means extending would invalidate the activity itself, not that the business would prefer urgency.

Passes:

• A banking session that shows a modal two minutes before expiry with a "Stay signed in" button, gives well over 20 seconds to respond, and can be extended indefinitely.
• An account setting, available before any timeout is encountered, that lets the user lengthen the default 15 minute session to at least 150 minutes or disable the timeout entirely: the adjust and turn off options.
• A ticket checkout that holds contested seats for 10 minutes and releases them to other live buyers on expiry: real-time exception, because the limit is a required part of a genuinely live allocation.
• An SMS one-time code valid for 5 minutes, with a one-tap "resend code" available: essential exception, since a long-lived code would defeat the security purpose.
• A saved application form whose session lasts 24 hours: the 20 hour exception.

Fails:

• A session that expires with no warning at all, discarding the user to the login screen mid-task.
• A timeout warning that gives 10 seconds before logging the user out: a warning exists, but the 20 second floor is not met.
• A warning dialog whose only extension route is re-entering the account password within the warning window: not a simple action.
• An extension mechanism capped at two uses before forcing logout: the extend option requires at least ten extensions.
• A "your basket is reserved for 10 minutes" countdown that voids the checkout, where nothing is held against other buyers and no extend, adjust, or turn off option exists: urgency theatre, not a real-time event.
• A snackbar with an "Undo" action that disappears after four seconds with no way to recover the action.
• A timed quiz with no adjust or extend option where speed is not part of what is being assessed, so the essential exception does not hold.

Not a fail under this criterion:

• An auto-advancing carousel whose slides all remain reachable through visible controls: grade the motion under SC 2.2.2 Pause, Stop, Hide; it lands here only if timed disappearance stops the user completing a task.
• The device lock screen engaging, or a browser's own behaviour, during idle testing: platform and user agent limits are not set by the content.
• Entered form data being wiped after the user re-authenticates within the same process: that is a data persistence finding under SC 3.3.7 Redundant Entry, provided the timeout itself was properly warned and extendable.
• A short-lived one-time code with a simple resend path: essential exception, however brief the lifetime feels.

• SC 2.2.2 Pause, Stop, Hide. The standard split for carousels and other moving content: motion, blinking, and auto-updating are graded there. File under 2.2.1 only when content disappearing on a timer prevents a task from being completed, such as an actionable message that vanishes before it can be activated. One behaviour can earn both findings, but they need separate evidence.
• SC 3.3.7 Redundant Entry. 2.2.1 governs the timeout itself; 3.3.7 governs whether previously entered data survives re-authentication within the same process. A compliant, extendable timeout can still produce a 3.3.7 fail if the restored session comes back with fields emptied. Remember the house position: platform autofill rescuing the user does not satisfy 3.3.7.
• SC 2.2.3 No Timing. The Level AAA sibling removes timing entirely except for real-time events and essential limits. An auditor demanding that a properly extendable timeout be abolished is applying 2.2.3 to a Level A or AA audit.
• SC 2.2.6 Timeouts. Also Level AAA: it requires warning users that inactivity will cause data loss. Do not import its data-loss framing into 2.2.1, which asks only whether the limit can be turned off, adjusted, or extended.
• SC 2.2.4 Interruptions. Covers postponing or suppressing interruptions such as pop-ups and auto-updates. An interruption that arrives at a bad moment is a 2.2.4 (AAA) concern; an interruption that gives you no time to respond before acting is a 2.2.1 concern.

AUDITSU's audit walkthrough covers timing on every screen and flow you review. Where a screen belongs to a signed-in session or contains a countdown, the walkthrough prompts you to identify the time limit, idle through it, and grade what happens: was there a warning, how long did the warning window last, was the extension a single simple action, and how many times could it be repeated. Where you claim an exception, the walkthrough asks you to record why it holds (what is genuinely live, or why extending would invalidate the activity), so the justification travels with the finding. For session warnings, the walkthrough has you repeat the idle test with the screen reader running, because a warning that is never announced fails the people the criterion most protects.

Each check records a pass, fail, or not applicable result per screen with evidence attached, typically a capture of the warning dialog and the timing you observed, so the report ties every timing finding to the exact flow that produced it. For the full guided workflow, see the audit platform.