WCAG 2.2.6 — Timeouts

What this requires

Users must be warned about the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours. The warning has to be visible early — on the page where the activity takes place — and it has to be specific about the inactivity threshold.

How AI coding tools fail this

When asked to "log the user out after 15 minutes of inactivity", AI tools wire up a timer and a warning modal, but the user discovers the timeout existed only when the warning appears. The criterion asks for the warning before the timeout becomes relevant — on the form page itself, before the user is deep into the work.

The second pattern: timeouts buried in security policy pages or terms-of-service documents. The user never reads those, and so never knows until their data is gone.

The third: inactivity counters that don't reset on certain types of activity. A long-form essay being typed continuously is "activity"; a writer who pauses for two minutes to think is "inactive". The warning UI must reflect what counts.

Passing examples

State the timeout up front, on the same page as the work, with explicit numbers:

function ApplicationForm() {
  return (
    <>
      <aside role="note" className="rounded-md border bg-muted p-3">
        <strong>Session timeout:</strong> if you don't interact with
        this page for 30 minutes, your draft is saved and you'll be
        signed out. You can sign back in and continue.
      </aside>
      <form>{/* fields */}</form>
    </>
  );
}

For data that genuinely is destroyed (a session-scoped survey, a temporary holding cart), be explicit about the loss:

<aside role="note" className="rounded-md border bg-muted p-3">
  <strong>Session timeout:</strong> if you don't interact with this
  page for 15 minutes, your responses will be discarded and you'll
  need to start over.
</aside>

Edge cases

20-hour exemption. If data survives more than 20 hours of inactivity, the criterion doesn't apply. Most session models meet this bar.
Auto-save removes the need for a "data loss" warning entirely — data isn't lost.
The warning is in addition to the extend-prompt from 2.2.1. 2.2.1 is about being able to extend; 2.2.6 is about knowing the timeout exists.
Banking and financial apps that need short security timeouts should pair the warning with auto-save for in-progress work.
Multi-tab and cross-device sessions complicate the warning text. State the per-session behaviour and don't promise more than the architecture can deliver.

How Jeikin handles this

The scanner flags pages with associated inactivity timers but no detected warning text on the page. The dashboard captures the warning copy when present and lets the reviewer confirm it is specific and findable. Pages with auto-save infrastructure are marked exempt with a note.

References

W3C — Understanding 2.2.6 Timeouts (opens in new tab)