Session Timeouts, Cart Timers, and Countdown Banners: What WCAG 2.2.1 Requires for E-Commerce

Quick answer: WCAG SC 2.2.1 Timing Adjustable (Level A) says that for any time limit set by your content, you must let the user turn it off, adjust it to at least ten times the default, or warn them before it expires and let them extend it — unless a narrow exception applies (a real-time event, an essential time-bound activity, or a limit longer than 20 hours). It applies to a checkout session that logs a shopper out mid-form, a cart-hold countdown that releases reserved inventory, and a “sale ends in” banner alike. Most e-commerce sites get the checkout-session part half right and the countdown-banner part not at all.

This article covers technical accessibility practice, not legal advice — it explains what WCAG requires and how to meet it, not whether a specific site carries legal risk.

SC 2.2.1 Timing Adjustable (Level A), in the W3C’s own words

The Understanding doc states the criterion as a choice of one of five conditions:

For each time limit that is set by the content, at least one of the following is true: Turn off The user is allowed to turn off the time limit before encountering it; or Adjust The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or Extend The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or Real-time Exception The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or Essential Exception The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception The time limit is longer than 20 hours.

The doc’s own Intent section is explicit about ranking the three fixes: disabling a time limit outright is the best option, adjusting its length is the next best, and warning-plus-extending is the minimum acceptable fallback — in that order, not interchangeably.

Where this shows up on an e-commerce site

Three timers show up on almost every storefront, and each hits SC 2.2.1 differently:

1. Checkout session timeout. A shopper who steps away mid-checkout gets logged out and loses their cart, shipping details, or payment entry.
2. Cart-hold / inventory countdown. “Items in your cart are reserved for 10 minutes” — a real time limit tied to inventory logic, not just a display.
3. Promotional countdown banners. “Sale ends in 04:59” — usually cosmetic urgency copy, but still content-set timing under the SC’s plain wording.

Pattern 1: checkout session timeout — warn, then extend

For a script-controlled session limit, the Understanding doc’s own listed techniques are G198 (provide a way to turn the time limit off), G180 (let the user set the limit to 10x the default), SCR16 (warn the user before a time limit expires), and SCR1 (allow the user to extend the default time limit), used together. A minimal version:

const SESSION_LIMIT_MS = 15 * 60 * 1000;
const WARNING_BEFORE_MS = 60 * 1000; // warn at least 20s before expiry; 60s gives more headroom
let expiresAt = Date.now() + SESSION_LIMIT_MS;

function scheduleWarning() {
  const delay = expiresAt - WARNING_BEFORE_MS - Date.now();
  setTimeout(showExtendDialog, Math.max(delay, 0));
}

function showExtendDialog() {
  // Accessible modal dialog (see our focus-management guide for the pattern):
  // "Your session will expire in 60 seconds. Extend it?" [Stay signed in] [Log out]
  extendDialog.hidden = false;
  extendDialog.querySelector("button").focus();
}

function extendSession() {
  expiresAt = Date.now() + SESSION_LIMIT_MS;
  extendDialog.hidden = true;
  scheduleWarning();
}

Two details the technique pages call out that are easy to miss: G198’s own description warns that the mechanism to turn off or extend a limit “must be available at or near the top of the page” and “can be completed without a time limit itself” — an extend button that’s itself unreachable before the countdown hits zero doesn’t satisfy the criterion. And the SC text requires the user be able to extend at least ten times, not just once — a dialog that offers one extension and then logs the user out regardless doesn’t meet the bar.

Pattern 2: cart-hold countdown timers

A cart-hold timer is a genuine time limit “set by the content” in the SC’s terms, not just cosmetic copy — it changes what happens to the user’s cart. The Understanding doc’s own named technique for this exact shape of problem is G133: providing a checkbox on the first page of a multipart form that lets users ask for a longer or no session time limit. Applied to a cart, that’s a visible, reachable “Need more time? Extend your hold” control next to the countdown itself — not a hidden setting, and not something that requires restarting the checkout flow to access.

If the hold genuinely can’t be extended (inventory is being released to other shoppers on a fixed schedule), that may fall under the Essential Exception — but only if extending the hold would actually invalidate the activity, i.e., the underlying inventory-release logic, not merely because extending the timer is inconvenient to implement.

Pattern 3: “sale ends in” countdown banners

This is the one most sites get wrong, and it’s worth being precise about why. A promotional countdown is still “a time limit that is set by the content” under the SC’s plain language — the fact that it’s marketing copy rather than a security or inventory mechanism doesn’t exempt it. In our own reading (this is our applied analysis, not a W3C-stated example — their own named Real-time Exception example is a live auction, not a scheduled promotion), a fixed-end-time sale doesn’t fit the Real-time Exception cleanly: nothing about a promotion that ends at a pre-determined clock time requires the countdown widget itself to be non-adjustable the way a live auction’s bidding window does.

A second, separate criterion often applies to the same banner: if the countdown’s numbers auto-update, SC 2.2.2 Pause, Stop, Hide (Level A) requires a way to pause, stop, or hide any “auto-updating information” that “starts automatically” and “is presented in parallel with other content,” unless the auto-updating “is part of an activity where it is essential.” A ticking countdown next to a product grid is exactly that shape of content.

The practical fix isn’t removing urgency messaging — it’s making the display dismissible or pausable (satisfies 2.2.2) and making sure the actual sale eligibility isn’t silently tied to a timer the shopper had no way to see or extend (satisfies 2.2.1). A static “Sale ends August 31, 11:59pm” is simpler to make accessible than a live ticking clock and often converts just as well.

SC 2.2.6 Timeouts (Level AAA) — an above-the-floor option

Outside the Level AA scope this site’s audits are built around, SC 2.2.6 Timeouts (new in WCAG 2.2, Level AAA) adds one more layer:

Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

That’s not required for a WCAG 2.1 AA-scoped audit, but it’s a cheap, concrete add-on: telling a shopper up front — “your session stays active for 15 minutes of inactivity” — rather than only warning them once the clock is already running out.

FAQ

Does a countdown timer automatically fail WCAG? No. SC 2.2.1 doesn’t ban time limits — it requires one of turn-off, adjust, or warn-and-extend, unless a real exception applies. A timer with none of those three, and no exception, is what fails.

Is a “your session is about to expire” message enough on its own? Only if it gives at least 20 seconds’ notice and lets the user extend the session at least ten times with a simple action — a warning with no extend mechanism, or one that only works once, doesn’t meet the SC.

What about a payment gateway’s own session timeout, which we don’t control? Worth raising with the payment provider directly rather than assuming it’s out of scope — the same “a process can run across different domains” reasoning that applies to WCAG 2.2’s Redundant Entry rule for third-party checkout steps applies to timing limits imposed mid-process too.

An automated scan won’t catch most of this

A scanner can’t tell you how long your session timeout is set to, whether a warning appears before it fires, or whether the “extend” button on that warning actually works more than once — all of that requires setting a clock, waiting, and watching what happens, not parsing markup. That’s the kind of check Quietramp’s manual review pass covers alongside the automated scan. See a sample report or check pricing — $890 for a one-time audit, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG does not guarantee legal compliance with the ADA or any other law. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.