WCAG 2.2.1 Timing Adjustable is a Level A rule that says: whenever your website sets a time limit, you must give users a way around it. Specifically, let them turn the limit off, adjust it to at least ten times its default length, or warn them before it expires and let them extend it with a simple action. A handful of narrow exceptions apply.

What WCAG 2.2.1 actually requires

The official wording from the W3C Web Accessibility Initiative is precise. For each time limit your content sets, at least one of the following must be true:

  • Turn off — the user can switch the time limit off before they hit it.
  • Adjust — the user can adjust the limit before they hit it, across a range that is at least ten times the default (so a 2-minute default must stretch to at least 20 minutes).
  • Extend — the user is warned before time runs out, given at least 20 seconds to extend it with a simple action (for example, “press the space bar”), and allowed to extend it at least ten times.

You only need one of those three. The criterion is also satisfied automatically if the limit fits one of four exceptions:

  • It is part of a real-time event (like a live auction) where no alternative to the limit is possible.
  • It is essential, and extending it would invalidate the activity (for example, a timed exam).
  • It is longer than 20 hours — W3C chose 20 hours because it is longer than a full waking day.
  • Security-driven limits, such as time-limited two-factor authentication tokens, may count as essential — though W3C still encourages a warning where feasible.

That order is deliberate: turning the limit off is best, adjusting is next, extend-on-warning is the fallback.

Who this protects

A time limit that feels generous to you can be impossible for someone else. WCAG 2.2.1 exists for people who simply need more time than a default timer allows:

  • People with motor disabilities who type or click slowly, or use a switch, head pointer, or eye-tracking — every keystroke costs effort.
  • Screen reader users (JAWS, NVDA, VoiceOver) who must listen through page structure linearly before they can find and operate a control.
  • People with low vision using magnification, who see only a fraction of the screen at a time and pan to read.
  • People with cognitive, learning, or language disabilities who need longer to read, process, and respond.
  • Deaf users relying on sign-language interpretation of timed content, which takes longer than reading.

For these users, an unannounced logout or a carousel that won’t hold still doesn’t just annoy — it ends the task.

Concrete failures and how to fix them

Inactivity session timeouts with no warning

A checkout or account page silently logs the user out after, say, 15 minutes of inactivity, discarding a half-filled form. This is the single most common 2.2.1 failure, and it punishes exactly the people who take longest to fill forms. The fix is a warning dialog before expiry that offers a simple extension:

// Warn ~60s before a 15-minute idle logout; let the user extend.
const IDLE_MS = 15 * 60 * 1000;
const WARN_MS = 60 * 1000;          // warn 60s before expiry
let warnTimer, logoutTimer;

function startTimers() {
  clearTimeout(warnTimer);
  clearTimeout(logoutTimer);
  warnTimer = setTimeout(showStayLoggedInDialog, IDLE_MS - WARN_MS);
  logoutTimer = setTimeout(logout, IDLE_MS);
}

function showStayLoggedInDialog() {
  // Focus a real, keyboard-operable dialog with role="alertdialog".
  // "Stay signed in" must give the user >= 20s and reset the timers.
  dialog.show();
}

// "Stay signed in" button:
stayBtn.addEventListener('click', startTimers); // extend, repeatable

['mousemove', 'keydown', 'pointerdown'].forEach(evt =>
  document.addEventListener(evt, startTimers, { passive: true })
);

The warning must be programmatically announced — use role="alertdialog" and move focus to it so screen reader and keyboard users actually learn the session is about to end, with well over the 20-second minimum to respond.

Meta refresh redirects (failures F40 and F41)

A timed refresh that redirects or reloads can’t be turned off or extended, so it fails outright. W3C catalogs this as failures F40 — meta redirect with a time limit and F41 — meta refresh to reload the page.

<!-- FAILS 2.2.1 — user cannot stop or extend this -->
<meta http-equiv="refresh" content="5; url=/new-page/">

Replace it with a server-side redirect (an HTTP 301/302), which is instant and imposes no timer on the user, or — if you must show an interstitial — a plain link the user clicks when ready:

<!-- PASSES — no client-side time limit -->
<a href="/new-page/">Continue to the new page</a>

Server-side auto-redirects after a timeout are the related failure F58 — using server-side techniques to automatically redirect after a time-out, and they fail for the same reason: the clock isn’t under the user’s control.

Auto-rotating carousels and moving text

A hero slider that advances every few seconds is a reading time limit. If a slow reader can’t catch up, it fails (and overlaps with 2.2.2 Pause, Stop, Hide). Give it a visible, keyboard-reachable pause control, and respect users who prefer reduced motion:

@media (prefers-reduced-motion: reduce) {
  .carousel { animation: none; } /* don't auto-advance */
}

“Offer expires in 02:00” countdown buttons

A booking page that holds a seat for two minutes and then drops it is a content-set time limit. A live event may qualify for the real-time exception — but a manufactured “hurry up” timer on a normal checkout does not. Warn before expiry and let the user extend the hold, or remove the artificial deadline.

How to test for 2.2.1

Automated scanners catch some of this (meta refresh, for instance), but timing failures are best confirmed by hand:

  1. Inventory every timer. List session timeouts, carousels, countdowns, auto-redirects, and any animation on a clock. Search your code for meta http-equiv="refresh", setTimeout, and setInterval.
  2. Sit on a page and wait. Leave an authenticated form idle past its timeout. Did you get a warning? Could you extend with one simple action and at least 20 seconds to react?
  3. Test the warning with a keyboard and a screen reader. The extend prompt is useless if a keyboard-only or screen reader user can’t reach or hear it. Confirm focus moves to the dialog.
  4. Try to pause moving content. Every carousel and ticker needs a working pause that holds.
  5. Check the math. If you offer “adjust,” confirm the range really reaches 10x the default. If you offer “extend,” confirm it’s repeatable at least 10 times.

This stateful, time-based behavior is exactly what automated tools miss, which is why it belongs in hands-on keyboard navigation and assistive-technology testing rather than a quick scan alone.

Why it matters legally

A timing failure is unusually damaging in a complaint because the harm is concrete and reproducible: a tester loads an authenticated form, walks away, comes back to a forced logout, and can screenshot the discarded work and the absence of any warning. Unlike a subjective “this is distracting” argument, a silent session timeout produces a clean before/after record of data loss — which is why account, checkout, and multi-step form flows are repeat targets, since that is exactly where timers live.

The volume is real and rising. UsableNet’s tracking counted 4,187 digital accessibility lawsuits filed in 2024, and federal policy now names the standard explicitly: in April 2024 the Department of Justice finalized a Title II rule adopting WCAG 2.1 Level AA as the technical benchmark for state and local government websites — the same WCAG 2.1 AA bar that private-sector courts treat as the practical measure of an accessible site. Crucially, 2.2.1 is a Level A criterion — it sits in the most basic tier that every conformance target (A, AA, and AAA) must include — so an unextendable session timeout or a meta refresh isn’t a borderline AA judgment call. It is a failure of the floor, and that makes it hard to explain away in a demand letter.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way

Timing is the one place an overlay is structurally incapable of helping, and it’s worth being precise about why. The session clock that logs a user out lives on your server — in the auth token’s expiry, the framework’s session middleware, the idle-timeout config. A meta refresh fires from the HTML the browser parsed before any third-party script ran, so a widget that injects itself afterward arrives too late to cancel it. And a server-side timeout redirect (F58) never touches the DOM at all. A “high contrast” or “bigger text” toolbar can’t reach into any of those layers, which is why a bolt-on widget leaves every one of this criterion’s failures in place. (See why overlays don’t work.)

Conformant remediation means editing the code that owns the clock: replacing timed <meta refresh> and server redirects with instant HTTP redirects or user-clicked links, raising or removing manufactured countdowns, and wrapping unavoidable session expiries in an accessible role="alertdialog" warning that lets users extend with one action and well past the 20-second floor. Each fix then has to be proven the way the failure shows up — by sitting on a page until the timer fires and confirming the warning is reachable and announced to keyboard and screen reader users.

Not sure where your time-limit traps are? Start with a free scan and we’ll inventory every session timeout, meta refresh, and countdown that fails 2.2.1 — then [EXPERT_NAME] at [AGENCY_NAME] will remediate them by hand so the default experience passes for everyone.