2.2.6 Timeouts

WCAG 2.2 · 2.2.6 AAA Operable

What it requires

Whenever inactivity can cause a user to lose data, you must warn them up front how long that inactivity period is — before they start the task. The only exception is when the data is preserved for more than 20 hours of inactivity.

The point is predictability: people who work slowly should never be surprised by a silent session timeout that wipes out a half-finished form, an unsaved cart, or partly entered application data. Telling them the limit in advance lets them plan, save their progress, or arrange the time they need.

  • People with cognitive or learning disabilities who need extra time to read, decide, and enter information.
  • People with motor disabilities who type or navigate slowly, or who use switch access and assistive input.
  • Screen-reader and magnifier users, for whom completing a long form simply takes longer.
  • Anyone interrupted mid-task who returns to find their data silently discarded.

How to detect it

Concrete checks for 2.2.6 Timeouts
Check How What passes
Find data-loss timeouts Inventory sessions, forms, carts, and authenticated flows; ask where idle time discards user input. Each such timeout is identified.
Warning present Read the page/flow before starting the task — manually. The inactivity duration is stated to the user beforehand.
20-hour exception Confirm with engineering how long unsaved data survives inactivity. Data preserved > 20 h needs no warning.
Assistive tech Keyboard and screen-reader pass: is the warning reachable and announced? Warning is perceivable to AT users.
Automated tools axe and similar scanners. Cannot detect this — manual review only.

How to fix it

  1. Identify every timeout where inactivity can destroy user data.
  2. Where feasible, preserve the data for more than 20 hours so no warning is needed.
  3. Otherwise, state the inactivity limit in plain text before the user begins.
  4. Place the notice so keyboard and screen-reader users encounter it in reading order.
<p class="form-notice">
  For your security, this session ends after
  <strong>30 minutes</strong> of inactivity. Unsaved
  changes will be lost, so save before stepping away.
</p>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule for 2.2.6 Timeouts — a tool cannot know your inactivity timeout or whether users are warned. This criterion needs manual review using the console check and steps below.

Run this in the browser console

timeouts-audit.js 
// Read-only: surfaces likely data-loss timeout triggers for human review.
const suspects = [...document.querySelectorAll(
  '[data-timeout],[data-session-timeout],meta[http-equiv="refresh"]'
)];
suspects.forEach(el => { el.style.outline = '2px solid red'; });
console.table(suspects.map(el => ({
  tag: el.tagName,
  timeout: el.getAttribute('data-timeout')
    || el.getAttribute('data-session-timeout')
    || el.getAttribute('content'),
  text: (el.textContent || '').trim().slice(0, 60)
})));
console.log('Outlined %d possible timeout sources.', suspects.length);

What to check manually: Confirm any inactivity timeout warns users beforehand and lets them extend it, and verify unsaved data survives a timeout (or that the user is told it will be lost) — no script can confirm either.