2.2.1 Timing Adjustable

WCAG 2.2 · 2.2.1 A Operable

What it requires

When content sets a time limit on a user's interaction, the user must be able to turn the limit off, adjust it, or extend it — unless one of a few narrow exceptions applies. For each time limit you must offer at least one of these:

  • Turn off the limit before encountering it; or
  • Adjust it before encountering it, over a wide range (at least up to ten times the default); or
  • Extend it — the user is warned before time expires, given at least 20 seconds to respond with a simple action (such as pressing the space bar), and can extend it at least ten times.

The exceptions where no control is required: the limit is part of a real-time event (e.g. an auction or live ticket sale) with no alternative; the limit is essential and extending it would invalidate the activity; or the limit is longer than 20 hours.

  • People with reading, cognitive, or learning disabilities who need more time to read and comprehend content.
  • People with motor or dexterity impairments who type, click, or navigate slowly, including switch and voice users.
  • Blind and low-vision users who explore a page with a screen reader or magnifier and need longer to locate and complete tasks.
  • Anyone who is interrupted mid-task and returns to find a session timed out, a form cleared, or content auto-advanced.

How to detect it

Concrete checks for Timing Adjustable
Check What to look for
Session timeouts Log in, leave the page idle, and confirm you are warned and offered a way to extend before being logged out or losing entered data.
Auto-redirects & refresh Look for <meta http-equiv="refresh"> or scripted redirects that move the user after a delay with no control.
Form & checkout timers Booking, payment, or OTP flows that count down — verify you can turn off, adjust, or extend the limit.
Auto-advancing UI Carousels, toasts, or quizzes that advance on a timer (note: continuously moving content is also covered by 2.2.2).
Automated tools axe and similar can flag meta refresh, but most timing failures are script-driven and require manual testing — automation alone is not sufficient.

How to fix it

  1. Inventory every time limit your content imposes (sessions, redirects, countdowns).
  2. Remove limits that are not essential — prefer no timeout at all.
  3. Where a limit must stay, warn the user before it expires and offer at least 20 seconds and a simple action to extend it, repeatable at least ten times.
  4. Preserve user data across a timeout so re-authenticating does not discard work.
  5. Never use timed meta refresh to redirect; redirect server-side instead.

Example of an accessible session-expiry warning the user can dismiss to stay signed in:

<div role="alertdialog" aria-labelledby="to-title" aria-describedby="to-desc">
  <h2 id="to-title">Your session is about to expire</h2>
  <p id="to-desc">You'll be signed out in 2 minutes. Stay signed in?</p>
  <button type="button">Stay signed in</button>
  <button type="button">Sign out now</button>
</div>

Copy-paste tests

Automated coverage

The axe-core rule meta-refresh flags time-delayed <meta http-equiv="refresh"> redirects, a common failure of this criterion. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools only catch SOME failures — script-driven timeouts and countdowns still need manual testing.

Run this in the browser console

timing-2-2-1.js 
// Read-only: surfaces likely time limits for review. Nothing is changed.
const suspects = [...document.querySelectorAll(
  'meta[http-equiv="refresh" i], [aria-live], [role="timer"], [data-countdown], [data-timeout]'
)];
suspects.forEach(el => { el.style.outline = '3px solid magenta'; });
console.table(suspects.map(el => ({
  tag: el.tagName.toLowerCase(),
  role: el.getAttribute('role') || '',
  content: (el.getAttribute('content') || el.textContent || '').trim().slice(0, 60)
})));
console.log('Review %d candidate(s):', suspects.length, suspects);

What to check manually: idle the page and confirm any session timeout warns you and lets you extend before logging out or clearing data; no script can verify a real-world countdown is actually adjustable, turn-off-able, or essential.