WCAG 2.2.6: Timeouts

What This Rule Means

WCAG 2.2.6 Timeouts (Level AAA) requires that users are warned of the duration of any inactivity that could cause data loss, unless the data is preserved for more than 20 hours of user inactivity. In practical terms, this means that if your web application or service can lose a user's data — such as form entries, a shopping cart, or an in-progress transaction — because the user has been inactive for a period of time, you must inform users of exactly how long they have before that data is lost.

The criterion applies to any situation where a timeout results in data loss. Common examples include session expiry on banking or government portals that clears form data, shopping carts that empty after a period of inactivity, multi-step wizards or forms that reset when a session cookie expires, and online testing or booking systems that discard partial responses. The key trigger is the combination of inactivity (not a hard time limit on completing a task, which is covered by 2.2.1) and the consequence of data loss.

What counts as a pass: A page passes 2.2.6 if it clearly informs users at the start of a session — or before they begin entering data — of the specific inactivity timeout duration that will result in data loss. Alternatively, a page passes if no data loss can occur regardless of how long the user is inactive (for example, because the server persists all form data for more than 20 hours, or indefinitely). Displaying a warning only after the session has already expired does not satisfy the criterion.

What counts as a fail: A page fails if it silently loses user data after a period of inactivity without ever informing the user of this risk. It also fails if a warning exists but is presented only at the moment of data loss (too late to act), or if the warning is vague — for example, stating "your session may expire" without specifying the actual duration of inactivity that triggers the timeout.

Official exceptions: The criterion explicitly exempts situations where data is preserved for more than 20 hours of inactivity. The 20-hour threshold was chosen to accommodate users who begin a task one day and resume it the next. If your system reliably stores all entered data server-side for at least 20 hours with no action required from the user, you are not required to display a warning. Additionally, this criterion does not apply to timeouts that are essential to security — for example, a hard requirement by law or regulation that a session must terminate after a fixed period regardless of user action. In such cases, the criterion still encourages disclosure but acknowledges the legal constraint.

Why It Matters

Timeouts without adequate warning disproportionately affect people with cognitive disabilities, motor impairments, and those who are blind or have low vision. Users with cognitive disabilities such as dyslexia, ADHD, or traumatic brain injury may need significantly more time to read instructions, compose text, or review information before submitting a form. If a session times out silently while they are still working, they lose all their effort and must start over — a deeply discouraging experience that can cause them to abandon the task entirely.

People with motor disabilities who rely on switch access, eye-tracking devices, or other alternative input methods interact with interfaces at a much slower pace than a mouse user. Completing a lengthy insurance claim form or a multi-page government application may take them many times longer than the default session timeout assumes. Without knowing the countdown, they have no opportunity to take action — such as saving progress or requesting an extension — before their data disappears.

Screen reader users also face a compounded challenge: navigating complex forms takes longer when each field must be read aloud and confirmed by keyboard. A session that expires while a user is still methodically working through a long form is not merely inconvenient — it can represent hours of lost effort and a significant barrier to accessing essential services.

Consider this real-world scenario: A user with multiple sclerosis is applying for a disability benefit through a government portal. The form has 12 sections and requires uploading supporting documents. The session expires after 15 minutes of inactivity, but the user paused midway through section 7 to retrieve a document from another room. Upon returning, all data has been cleared and they must begin again — with no prior warning that this would happen. Under 2.2.6, the portal would be required to inform the user at the outset that inactivity for more than 15 minutes will result in data loss, enabling them to plan accordingly.

Beyond accessibility, proactively disclosing timeout behavior improves user experience for everyone and reduces abandonment rates on high-value conversion flows such as checkout, registration, and application forms. It also builds trust, as users are not left wondering why their data disappeared.

Related Axe-core Rules

WCAG 2.2.6 requires manual testing. There is no automated axe-core rule that can detect this violation, and understanding why is important for testers and developers alike.

• Manual testing required — Session timeout disclosure: Automated tools like axe-core can scan the DOM for the presence or absence of specific elements, attributes, and text patterns, but they cannot determine whether a web application will lose user data after a period of inactivity. The timeout behavior is typically governed by server-side session configuration (e.g., a PHP or Node.js session TTL), and the disclosure — if it exists — may appear in onboarding text, a modal dialog, a help page, or even a terms of service section. No static DOM analysis can reliably correlate a piece of informational text with the actual server-side timeout behavior. A tool cannot know whether a sentence like "For your security, sessions expire after 15 minutes" is accurate, applies to the current page's data, or is positioned early enough in the user journey to be actionable. Only a human tester who can interact with the application, observe its behavior over time, and evaluate the completeness and timing of any disclosures can determine compliance.
• Manual testing required — Data preservation verification: Axe-core also cannot verify the 20-hour exception. Whether data is actually stored server-side for more than 20 hours — and therefore whether a disclosure is required at all — depends entirely on backend logic that is invisible to a browser-based scanning tool. Testers must either review server configuration, speak with developers, or empirically test by leaving a partially completed form for an extended period and observing whether data persists.

How to Test

1. Automated pre-scan: Run axe DevTools or Lighthouse against the page containing the form, checkout flow, or other data-entry interface. While neither tool will flag a 2.2.6 violation directly, use this step to identify any timeout-related ARIA live regions or dialog components that may be part of the warning mechanism, and verify they are themselves accessible (correct roles, labels, focus management).
2. Identify timeout behavior: Speak with the development team or review server-side configuration to determine the inactivity timeout duration for the session. Common locations include web server configuration files, application session middleware settings, and authentication provider documentation. Record the exact duration in minutes.
3. Check for upfront disclosure: Load the page fresh and read all content presented to the user before any data entry begins. Look for a clear statement — in the page body, an introductory paragraph, a banner, or a modal — that specifies the exact inactivity timeout duration and states that data will be lost if the user is inactive for that period. The disclosure must name the duration explicitly (e.g., "15 minutes"), not vaguely (e.g., "a short time").
4. Test with a screen reader: Using NVDA with Firefox, VoiceOver with Safari, or JAWS with Chrome, navigate the page from the very beginning. Confirm that any timeout disclosure is reachable and read aloud by the screen reader without requiring the user to actively seek it out. If the disclosure is in a visually prominent banner, verify it is in the reading order before the first form field.
5. Simulate inactivity: Begin filling out the form. Then stop interacting with the page for a duration slightly less than the timeout period, and observe what happens. Then repeat, waiting until after the timeout period elapses. Record whether data is lost, whether a warning is displayed before data loss occurs, and whether that warning was communicated before the session began.
6. Test the 20-hour exception: If the team claims data is preserved for more than 20 hours, verify this empirically by partially completing a form, waiting at least 20 hours, and returning to the page to confirm the data is still present. Alternatively, review server-side session store configuration with the development team.
7. Keyboard and focus testing: If a timeout warning dialog or notification appears, verify using keyboard-only navigation that it receives focus automatically, that its content is fully readable, and that the user can dismiss it or take action (e.g., extend the session) without using a mouse.

How to Fix

Session with silent data loss — Incorrect

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Session with silent data loss — Correct

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Checkout session with vague warning — Incorrect

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Checkout session with vague warning — Correct

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Data preserved server-side for more than 20 hours — Correct (exception applies)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Common Mistakes

• Displaying the timeout warning only inside the browser console or in a server log entry that is invisible to end users — the warning must be presented in the user interface, in a location the user will encounter before data loss occurs.
• Placing the disclosure in a footer, privacy policy, or terms of service page that users are unlikely to read before beginning data entry, rather than directly on or immediately before the form itself.
• Using a modal dialog to warn users of an imminent session expiry but failing to move keyboard focus to the dialog — keyboard and screen reader users may never become aware the warning has appeared.
• Stating a session length (e.g., "your session lasts 30 minutes") rather than an inactivity timeout (e.g., "after 15 minutes of inactivity, your data will be lost") — these are different concepts, and only the inactivity-triggered data loss is governed by 2.2.6.
• Assuming that because a timeout warning modal exists for sighted users, the criterion is satisfied — if the modal is not accessible via keyboard, lacks an accessible name, or is not announced by ARIA live regions or focus management, screen reader users will not receive the warning.
• Setting the server-side session timeout to 25 hours and concluding no disclosure is needed, while failing to verify that the browser-side or application-level state (e.g., a Redux store or localStorage) is cleared sooner — the effective timeout is whichever mechanism loses data first.
• Disclosing the timeout duration in a tooltip triggered only by hover — users who rely on keyboard navigation or touch devices may never encounter the disclosure.
• Relying on a generic CMS or framework warning that says "session expired" displayed after data loss has already occurred, rather than proactively informing users before they begin entering data.
• Failing to account for users who open the form in a background tab: if the session timer runs while the tab is inactive, data may be lost before the user has had any opportunity to interact with the form at all. This is especially problematic on mobile browsers that suspend background tabs aggressively.
• Omitting the warning on mobile versions or progressive web app (PWA) contexts while displaying it on the desktop version, creating an inconsistent experience that fails 2.2.6 for a significant portion of users.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes binding web accessibility obligations for a broad range of public and private entities operating in Turkey. The circular mandates compliance with WCAG 2.2 as the technical standard, requiring covered entities to meet at minimum Level AA conformance. WCAG 2.2.6 Timeouts is a Level AAA criterion and is therefore not directly mandated by the circular's baseline requirements. However, the circular's scope and intent create strong practical reasons for covered entities to pursue AAA compliance on criteria such as 2.2.6.

The entities covered by Presidential Circular 2025/10 include public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and healthcare providers, telecommunications operators with more than 200,000 subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). Many of these sectors operate online portals that involve precisely the kinds of data-entry workflows that 2.2.6 is designed to protect: loan applications, patient intake forms, ticket booking systems, enrollment applications, and government benefit claims.

For banks and e-commerce platforms in particular, session timeouts are a routine security measure, and the interaction between security requirements and accessibility obligations is directly relevant. While a bank may have a regulatory obligation to terminate idle sessions after a fixed period, implementing WCAG 2.2.6 by disclosing the timeout duration upfront does not conflict with that security requirement — it complements it. Users are made aware of the constraint without the bank needing to weaken its session security posture.

Healthcare providers and hospitals covered by the circular handle some of the most high-stakes data-entry tasks imaginable — patient history forms, pre-authorization requests, and appointment scheduling systems. Patients with cognitive disabilities or motor impairments who lose their data mid-form in these contexts face not only frustration but potential delay in receiving care. Implementing 2.2.6 in these environments is a direct expression of the inclusive service mandate that underpins the circular.

Although Level AAA is not legally required, achieving it on criteria like 2.2.6 — which require relatively low implementation effort (adding a single, accurate disclosure statement to a form) while delivering significant benefit to vulnerable user groups — represents best-in-class accessibility practice. Organizations seeking to demonstrate their commitment to digital inclusion in the Turkish market, or those anticipating tighter future regulation, are well served by treating 2.2.6 as a practical implementation target rather than an optional aspiration.