WCAG 2.2.6: Timeouts
Inactivity timeouts are invisible until they strike. A user pauses to find a document, help a child, or rest — and returns to a cleared form. This criterion offers a simple bargain: either warn users up front how long they can be inactive before losing data, or keep their data safe for more than 20 hours. Warn, or preserve. Pick one.
The success criterion, in full
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.
Two conforming routes, one criterion. The scope is specifically inactivity that causes data loss — a timeout that logs you out but keeps your work (see 2.2.5 Re-authenticating) does not lose data and needs no warning under this criterion.
Who this helps
This criterion was added in WCAG 2.1 largely for people with cognitive and learning disabilities, and it protects anyone whose pace does not match the developer’s timeout constant:
People with cognitive disabilities
Locating documents, processing instructions, or taking a needed break can consume an entire inactivity window. Knowing the limit in advance lets them prepare — or choose a better moment.
People with attention or memory disabilities
Task-switching is common and returning takes time. An undisclosed timeout converts a normal pause into lost work and a restarted task.
People with motor disabilities
Pauses for rest or repositioning are part of operating a device. 'Inactivity' often just means 'recovering'.
Anyone gathering information mid-form
Passport numbers, insurance details, bank statements — forms routinely demand documents users must go and find.
The damage from a surprise timeout is not just repeated work — it is the erosion of trust that makes people abandon essential online tasks like benefits applications and medical forms.
The two conforming routes
Route 1: Warn up front
State the inactivity duration at the start of the task, in plain language, where it cannot be missed:
“For your security this form times out after 15 minutes of inactivity, and unsaved information is deleted.”
The number must be accurate and cover the whole flow. A countdown dialog near expiry is a good companion (and helps with 2.2.1), but on its own it is not the up-front warning this criterion intends.
Route 2: Preserve for > 20 hours
Keep everything the user entered for more than 20 hours of inactivity — server-side drafts keyed to the account are the reliable version. Then the exception applies and no warning is needed at all.
The session may still expire for security; what must survive is the data. Pair with 2.2.5 so re-login restores it seamlessly.
Route 2 is strictly better for users and increasingly cheap to build — which is why “auto-save everything” has become the default recommendation for long transactional flows.
Pass and fail examples
✓ Passes 2.2.6
- A tax filing service that auto-saves every entry to the account and keeps drafts for weeks — no warning needed.
- A visa application whose first page states: “Your session ends after 25 minutes of inactivity and unsaved answers are lost.”
- A checkout that keeps the cart and address data for 30 days, even though the login session lasts 20 minutes.
- A kiosk form that explains at the start: “For privacy, this screen clears after 2 minutes without input.”
✗ Fails 2.2.6
- A 40-field insurance form that silently discards everything after 20 minutes idle, with no mention anywhere.
- A warning that exists only as a 60-second countdown modal — users who stepped away never see it.
- “Drafts are saved” — but purged after 12 hours of inactivity, short of the 20-hour bar, with no disclosed duration.
- A stated limit of 30 minutes while the real limit is 10 — an inaccurate warning is not a warning.
Code examples
An up-front, unmissable timeout disclosure
Put the disclosure in the natural reading order at the top of the task, not in a tooltip or footer.
<form aria-describedby="timeout-note">
<h2>Apply for a parking permit</h2>
<p id="timeout-note" class="notice">
<strong>Heads up:</strong> for security, this form times out after
<strong>15 minutes of inactivity</strong> and unsaved information is
deleted. You can save a draft at any point with the “Save and continue
later” button.
</p>
<!-- fields… -->
</form>Route 2 in practice: durable server-side drafts
Persist continuously with a retention comfortably past 20 hours; the security session can stay short.
// Client: debounce-save every change
form.addEventListener("input", debounce(async () => {
await fetch("/api/drafts/permit-application", {
method: "PUT",
body: JSON.stringify(Object.fromEntries(new FormData(form))),
});
}, 1000));
// Server: retention policy is the conformance point
// ✓ Keep drafts for 30 days — comfortably > 20 hours,
// so the 2.2.6 exception applies and no warning is required.
await db.drafts.upsert({
userId,
formId: "permit-application",
data,
expiresAt: daysFromNow(30),
});Companion countdown warning (supports 2.2.1 as well)
<!-- Announced immediately: imminent data loss is emergency-grade -->
<div role="alertdialog" aria-labelledby="to-title" aria-describedby="to-desc">
<h2 id="to-title">Still there?</h2>
<p id="to-desc">
Your session ends in 2 minutes. Unsaved changes will be kept for
30 days in your drafts.
</p>
<button type="button">Stay signed in</button>
<button type="button">Save and sign out</button>
</div>Common failures
- No disclosure at all: the inactivity limit exists only in server config, and users discover it by losing work.
- Warning only at the last minute — a countdown modal cannot warn the user who already walked away, which is the very scenario the criterion targets.
- Vague wording ('your session may expire') without the duration; the criterion explicitly requires the duration of inactivity.
- Understating or misstating the limit, including forgetting that intermediate saves reset some timers but not others.
- Draft preservation that quietly expires at 4, 8, or 12 hours — short of 20 — while the team believes the exception applies.
- Preserving only part of the data (form fields but not uploads, or answers but not the user's position in a long wizard).
- Burying the disclosure in terms of service or a help page that the task flow never references.
How to test for 2.2.6
- 1
Establish the real timeout behavior
For each flow that accepts user input, determine from the team or by observation: how long can the user be inactive before entered data is discarded? Include client-side clears, session expiry, and draft purge policies.
- 2
Check the exception first
If data provably survives more than 20 hours of inactivity — verify the retention policy end to end, including uploads and wizard position — the criterion is satisfied and you are done.
- 3
Otherwise, find the up-front warning
Look at the start of the task, before meaningful effort is invested. The warning must state the duration of allowable inactivity, in visible text (not a tooltip, footer, or buried policy).
- 4
Verify the stated duration is accurate
Time it. Enter data, go idle, and confirm the data survives until the stated limit and the warning matches reality across the whole flow, not just the first page.
- 5
Test perception with assistive technology
Confirm a screen reader encounters the disclosure in reading order, and that any countdown dialog is announced (role='alertdialog'), focusable, and operable by keyboard.
Like the rest of the 2.2.x AAA criteria, this is behavioral testing that no scanner can perform. Keep it in your manual audit script and the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 2.2.6 Timeouts require?
It requires that 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. You have two ways to conform: tell users at the start of a task how long they can be inactive before their work is discarded (for example, 'Your information is kept for 30 minutes of inactivity'), or simply preserve their data for more than 20 hours so no warning is needed. It is a Level AAA criterion added in WCAG 2.1.
Why 20 hours specifically?
The Working Group chose 20 hours so that a user can step away for a full day — sleep included — and return to find their work intact. If data survives more than 20 hours of inactivity, an inactivity timeout effectively cannot ambush anyone mid-task, so the warning becomes unnecessary and the exception applies. Anything shorter, even 'generous' windows like 8 or 12 hours, still requires the up-front warning.
Where and when should the warning appear?
At the start of the process, before the user invests effort — not only in a last-minute countdown dialog. The W3C's intent is that users can decide in advance whether they can complete the task in the available rhythm, and plan around it. Good placements: a note at the top of the form or checkout ('You can be inactive for up to 15 minutes without losing your progress'), on the login page for session-based apps, or in a persistent help area referenced from the flow.
How is 2.2.6 different from 2.2.1 Timing Adjustable?
2.2.1 (Level A) is about controlling time limits: users must be able to turn off, adjust, or extend them, but security-essential session limits often fall under its exceptions. 2.2.6 (AAA) attacks the residual harm: whatever timeout remains must be disclosed up front if it can destroy data — or defused entirely by preserving data for more than 20 hours. 2.2.5 Re-authenticating (AAA) then covers restoring data across the re-login itself. The three together: control the limit, disclose the limit, survive the limit.
Does auto-saving data satisfy 2.2.6 without any warning?
Yes, if the saved data genuinely persists for more than 20 hours of inactivity. Auto-saving drafts server-side keyed to the account is the cleanest route: the timeout can still log the user out for security, but their work waits for them past the 20-hour mark, so the exception applies and no warning is required. Watch the details: the preservation must cover everything the user entered, not just some fields, and purge policies shorter than 20 hours void the exception.
Does 2.2.6 apply to privacy-driven timeouts, like clearing a screen on a shared kiosk?
The criterion still applies — inactivity that discards the user's entered data is exactly its subject — but conformance can be achieved with the warning route: state clearly at the start that, for privacy, the form clears after N minutes of inactivity. The W3C notes that privacy regulations or genuine security constraints may shape how data can be retained; where retention is inappropriate, disclosure is the conforming path.
Related Success Criteria
Users can turn off, adjust, or extend time limits.
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Timing is not an essential part of the event or activity.
Interruptions can be postponed or suppressed by the user.
User data is preserved when a session expires and re-authentication is required.