Understanding WCAG SC 2.2.6: Timeouts (AAA)

Introduction: The Critical Role of Time in Digital Accessibility

In the architecture of digital experiences, time is a foundational, yet often unforgiving, constraint. For many users, time-based interactions—from session expirations on banking websites to timeouts on complex application forms—are minor inconveniences. However, for a significant portion of the population, particularly individuals with disabilities, these same time limits can constitute insurmountable barriers. Unexpected data loss resulting from an expired session is not merely frustrating; it can render a digital service entirely unusable, penalizing users for needing more time to read, comprehend, or interact with content. This penalty for pausing introduces a significant cognitive load, a measure of the mental effort required to use a system, which disproportionately affects users with cognitive, learning, and motor impairments.

The Web Content Accessibility Guidelines (WCAG) address this challenge directly through several criteria, culminating in the rigorous standard set by Success Criterion (SC) 2.2.6: Timeouts. As a Level AAA criterion, it represents the highest echelon of accessibility conformance, moving beyond minimum compliance to advocate for a more humane, forgiving, and resilient design philosophy. Conformance with SC 2.2.6 is not simply about extending a timer; it is about fundamentally re-evaluating the relationship between the user, their data, and the passage of time. It encourages a shift from designing ephemeral, session-based interactions to building persistent, user-centric experiences where progress is protected and the user is empowered to complete tasks at their own pace.

This report provides a definitive technical analysis of SC 2.2.6. It will deconstruct the criterion's normative requirements and underlying intent, explore the two primary paths to conformance—robust data preservation and proactive user warnings—and offer detailed technical implementation strategies for both server-side and client-side architectures. Furthermore, it will examine the critical intersection of this criterion with security and privacy regulations, its relationship to other key WCAG criteria, and provide a framework for effective auditing and verification. This analysis is intended for senior technical professionals, including architects, developers, and accessibility leads, who are tasked with implementing accessibility standards at an expert level.

Section 1: Deconstructing Success Criterion 2.2.6

A thorough understanding of any technical standard begins with a precise deconstruction of its formal requirements and the intent that underpins them. SC 2.2.6 is deceptively simple in its phrasing but carries significant architectural and legal implications that must be carefully unpacked.

1.1 Normative Text and Core Requirements

The normative, or official, text of Success Criterion 2.2.6 is as follows:

"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."

This single sentence establishes a clear bifurcation for conformance. To understand its application, a precise definition of its key terms is essential:

• User Inactivity: This refers to any continuous period where no user actions are detected. The specific method of tracking user activity—such as monitoring keyboard inputs, mouse movements, or touch events—is determined by the website or application itself.
• Data Loss: This specifically concerns the loss of information that the user has already entered and that is within the control of the content provider. A critical distinction is that this criterion does not apply to data loss outside the provider's control, such as when a user intentionally closes their browser window or their device powers down. The focus is on system-initiated data loss due to a timeout.
• Preserved for more than 20 hours: This clause defines the primary exception. If the system ensures that user-entered data is saved and remains available for at least 20 hours of inactivity, the requirement to provide a warning is entirely waived.

The structure of the normative text itself reveals a strong architectural preference. By framing the 20-hour data preservation as an exception ("unless..."), the W3C positions it as the superior path to conformance. It is not presented as one of two equal options but as the solution that completely obviates the need for the alternative. This implies a design philosophy that prioritizes systemic resilience—where the system is responsible for safeguarding user effort—over user-managed mitigation, where the user must be vigilant and heed a warning. The guideline is therefore not just about providing "enough time" but about removing the cognitive burden of time management from the user and placing the responsibility for data integrity squarely on the system.

Furthermore, SC 2.2.6 is accompanied by a crucial and frequently repeated note that distinguishes it from many other WCAG criteria:

"Privacy regulations may require explicit user consent before user identification has been authenticated and before user data is preserved. In cases where the user is a minor, explicit consent may not be solicited in most jurisdictions, countries or regions. Consultation with privacy professionals and legal counsel is advised when considering data preservation as an approach to satisfy this success criterion."

This explicit directive to consult legal and privacy experts is a significant signal. While most WCAG criteria focus on technical implementation, this note highlights that the recommended best practice for SC 2.2.6—data preservation—directly intersects with a complex landscape of legal risks outside of accessibility law, including regulations like the General Data Protection Regulation (GDPR) in Europe or the Health Insurance Portability and Accountability Act (HIPAA) in the United States. This creates a fundamental tension: the push for accessibility (save the data to help the user) can conflict with the principles of privacy and data minimization (do not store data unnecessarily). Consequently, achieving Level AAA conformance for this criterion is not merely a development task; it is a cross-functional strategic decision that requires careful consideration of technical feasibility, user experience, and legal compliance.

1.2 The Intent Behind the Guideline: Preventing the Penalty for Pausing

The core intent of SC 2.2.6 is to prevent users from being forced to restart tasks if they are interrupted or simply need more time than anticipated. The W3C's "Understanding" documents clarify that timed events can present significant barriers, particularly for users who may need additional time to read content, process complex instructions, or perform functions like completing a lengthy online form for taxes, travel bookings, or government services.

Many users, especially those with certain disabilities, cannot complete a complex process in a single, uninterrupted sitting. They may become overwhelmed and need to take a break to manage cognitive fatigue, or they may need to locate physical documents or consult with another person. The guideline is designed to ensure that users can leave a process and return later without losing their current position or the data they have already painstakingly entered. The inability to take a break, check one's work, or manage interruptions without penalty often prevents users from completing tasks correctly, if at all.

By either preserving data for an extended period or providing a clear upfront warning about time limits, the criterion empowers users. It allows them to make informed decisions about their engagement, reduces the frustration and anxiety associated with unexpected data loss, and ultimately enables many individuals to complete online tasks that they would otherwise be unable to do.

1.3 The Human Impact: Beneficiary User Groups

While the principles of SC 2.2.6 offer universal benefits by creating more forgiving digital products, the criterion is specifically designed to address severe barriers faced by particular user groups.

• Cognitive and Learning Disabilities: This is the primary community the criterion seeks to support. Unexpected timeouts create profound difficulties for individuals with a range of cognitive differences:
  • Memory-related disabilities: For users who may have difficulty remembering where they left off, an unexpected timeout that erases their progress can be disorienting and force a complete, often frustrating, restart.
  • Focus-and-attention-related disabilities (e.g., ADHD): Strict time limits impose unnecessary stress and pressure, making it difficult to maintain focus and complete tasks that require sustained concentration. The constant threat of a timeout can be a significant distraction in itself.
  • Language and processing disorders (e.g., dyslexia): Individuals may require substantially more time to read and comprehend instructions, labels, and complex information presented in forms. Time limits penalize this need for additional processing time.
  • Disabilities affecting executive function and decision-making: Complex, multi-step processes can be overwhelming. The ability to take a break is not a luxury but a necessity to manage cognitive load, review information, and make considered decisions. Timeouts remove this essential coping strategy.
• Motor Impairments: Users who rely on assistive technologies such as switch controls, head wands, voice recognition software, or on-screen keyboards often require more time to navigate and input data than users of a standard keyboard and mouse. Keystrokes and pointer movements can be slower and more deliberate. Abrupt session timeouts can prematurely end a user's session before they have had a chance to complete their input, effectively locking them out of the application.
• Users of Screen Readers and Screen Magnifiers: Navigating content without visual cues takes time. Screen reader users often navigate sequentially to build a mental model of the page layout, and screen magnifier users see only a small portion of the screen at once, requiring them to pan around to find information. For both groups, locating form fields, understanding their context, and entering data is a more time-consuming process. An unexpected timeout that erases their work is particularly disorienting, as they lose not only their data but also their place within the page's structure.
• Situational Limitations (Universal Benefit): The criterion also provides a significant benefit to all users who may face temporary or situational limitations. This includes a parent interrupted by a child, an employee who receives an urgent phone call, a user who needs to locate a credit card or passport to complete a form, or anyone who simply decides to take a coffee break during a long online task. By designing for the needs of users with disabilities, SC 2.2.6 creates a more robust and user-friendly experience for everyone.

Section 2: The Primary Conformance Path: Data Preservation Beyond 20 Hours

As established, the most robust and preferred method for conforming to SC 2.2.6 is to preserve user-entered data for more than 20 hours of inactivity. This approach eliminates the risk of data loss and removes the need to warn the user about a timeout, thereby reducing cognitive load and creating a more seamless experience.

2.1 Rationale for the 20-Hour Threshold

The 20-hour duration is not an arbitrary figure. It is a deliberately chosen timeframe intended to accommodate common user behaviors and needs. The W3C's guidance suggests this duration is based on the scenario of a user starting a task on one day and wishing to resume it the following morning. A 20-hour window comfortably covers an entire waking day, allowing for extended breaks, overnight pauses, and other significant interruptions without the risk of data loss. This long duration is particularly beneficial for users with disabilities and the aging community, who may need to approach complex tasks in smaller, more manageable segments over a longer period. By adopting this threshold, organizations signal a commitment to a user-centric model where the system adapts to the user's schedule, rather than forcing the user to adapt to the system's limitations.

2.2 Server-Side Implementation Strategies (W3C Technique G105)

For applications that handle authenticated sessions or sensitive information, server-side persistence is the most secure and reliable implementation strategy. This approach aligns with W3C's sufficient technique G105: "Saving data so that it can be used after a user re-authenticates". The core principle involves the server intercepting user data, storing it securely, and re-associating it with the user's session upon their return.

The choice between server-side and client-side data preservation represents a direct trade-off between implementation simplicity and security robustness. While client-side methods may appear easier for simple forms, they introduce significant security vulnerabilities. Server-side persistence, though more architecturally complex, provides the necessary security controls for any application handling sensitive or personally identifiable information. The decision should be based on a thorough risk assessment of the data being handled.

Furthermore, implementing a 20-hour data preservation policy fundamentally redefines the concept of a "session." A traditional web session is a transient, server-managed state with a short expiry (e.g., 20-30 minutes) for security and resource management reasons. This model is incompatible with the requirements of SC 2.2.6. A compliant system must therefore decouple the "authentication session" from the "data-in-progress state." The authentication token can and should remain short-lived, while the user's task data is persisted independently. This architectural shift favors patterns common in modern applications, such as the automatic saving of drafts, treating any long or multi-step form as a document with a persistent state that can be resumed at a later time.

2.2.1 Database Persistence

A highly durable method for server-side persistence is to use a relational (e.g., PostgreSQL, SQL Server) or NoSQL (e.g., MongoDB) database.

• Workflow:
  1. A user submits a form or navigates away from a page with unsaved data.
  2. The application logic first validates the user's authentication session. If the session has expired or is invalid, the server does not discard the incoming request data.
  3. Instead, the server serializes the form's payload (e.g., as a JSON object) and saves it to a dedicated "drafts" or "temporary_data" table in the database.
  4. This database record must be linked to a unique user identifier (e.g., user_id) and should include a timestamp to facilitate data lifecycle management.
  5. The user is then redirected to the login page.
  6. Upon successful re-authentication, the application logic queries the temporary data table for any pending data associated with that user_id.
  7. If data is found, it is retrieved, deserialized, and used to repopulate the form or restore the application state. The temporary record is then deleted or marked as processed to prevent reuse.
• Data Lifecycle Management: Storing incomplete user data indefinitely creates privacy risks and can violate data minimization principles under regulations like GDPR. An automated process, such as a scheduled cron job or a database trigger, must be implemented to periodically purge stale data that has exceeded its retention period (e.g., 24 hours).

2.2.2 Server-Side Caching

For applications where high performance is critical and absolute data durability is a lesser concern (e.g., a shopping cart), an in-memory cache like Redis or Memcached provides a faster alternative to a disk-based database.

• Workflow: The process is analogous to database persistence, but the serialized data is stored in the cache. Caching systems are well-suited for this purpose due to their efficient key-value structure and native support for setting a Time-To-Live (TTL) on each entry.
• Implementation: A key can be structured with a clear naming convention, such as pending_data:{user_id}. The TTL for this key should be set to a duration greater than 20 hours (e.g., 24 hours or 86,400 seconds). This not only satisfies the WCAG requirement but also provides a built-in, highly efficient mechanism for automatic data purging, reducing the need for separate cleanup scripts.

2.3 Client-Side Implementation Strategies

For non-sensitive data, such as an anonymous contact form or user interface preferences, client-side storage offers a simpler implementation path that does not require backend architecture changes.

2.3.1 Leveraging localStorage and sessionStorage

The Web Storage API provides two mechanisms for storing data in the user's browser: localStorage and sessionStorage.

• sessionStorage: Data stored in sessionStorage is tied to the page session and is cleared when the browser tab or window is closed. It is suitable for temporarily persisting form data during a single session, for example, to recover from an accidental page refresh.
• localStorage: Data in localStorage persists even after the browser is closed and reopened. It has no expiration time and is the appropriate choice for meeting the 20-hour requirement for non-sensitive data.

A common pattern is to save the state of a form to localStorage on every input change and then check for this saved data when the page loads.

Example JavaScript Implementation for localStorage:

document.addEventListener('DOMContentLoaded', function() {  
  const form = document.querySelector('\#myForm');
  const formId = form.id;

  // Function to save form data to localStorage
  function saveFormData() {
    const formData = new FormData(form);
    const formObject = Object.fromEntries(formData.entries());
    localStorage.setItem(formId, JSON.stringify(formObject));
  }

  // Function to load form data from localStorage  
  function loadFormData() {  
    const savedData = localStorage.getItem(formId);
    if (savedData) {
      const data = JSON.parse(savedData);
      for (const key in data) {
        if (form.elements[key]) {
          const element = form.elements[key];
          if (element.type === 'radio' || element.type === 'checkbox') {
            // Handle radio buttons and checkboxes
            if (element.value === data[key]) {
              element.checked = true;
            }
          } else {
            element.value = data[key];
          }
        }
      }
    }
  }

  // Load any saved data when the page loads  
  loadFormData();

  // Save data on any input event  
  form.addEventListener('input', saveFormData);

  // Clear saved data on successful form submission  
  form.addEventListener('submit', function() {  
    localStorage.removeItem(formId);  
  });  
});

This script automatically saves the content of a form with the ID myForm to localStorage whenever a user types into a field. Upon page load, it restores this data. When the form is successfully submitted, the stored data is cleared.

2.3.2 IndexedDB for Complex Data

For more complex client-side storage needs involving large datasets or structured data, the IndexedDB API provides a transactional, client-side database. While significantly more powerful than localStorage, its implementation is also more complex and is generally overkill for simple form state persistence.

2.4 Critical Security and Privacy Considerations

The decision to preserve user data, especially on the client side, must be accompanied by a rigorous security analysis.

2.4.1 The Dangers of localStorage for Sensitive Data

It is imperative to understand that localStorage is not a secure storage mechanism.

• Vulnerability to Cross-Site Scripting (XSS): Any JavaScript code running on a page has full read and write access to localStorage for that origin. If an attacker can inject a malicious script onto a page—a common XSS attack—they can easily exfiltrate all data stored in localStorage.
• Supply-Chain Attacks: This vulnerability extends to third-party scripts. If a trusted third-party library, such as an analytics service, ad network, or customer support chat widget, is compromised, the malicious code it serves can steal localStorage data from your application. This makes your application's security dependent on the security of all your third-party vendors.
• Data to Never Store in localStorage: Due to these risks, sensitive information must never be stored in localStorage. This includes, but is not limited to:
  • JSON Web Tokens (JWTs)
  • Session identifiers
  • API keys
  • Personally Identifiable Information (PII) such as names, addresses, or government IDs
  • Financial data, including credit card information
  • Any other data you would not want to be publicly exposed.

2.4.2 Secure Data Handling Practices

To mitigate these risks while still achieving conformance, organizations must adopt secure data handling practices.

• Server-Side Encryption at Rest: When using server-side persistence, all temporarily stored user data must be encrypted at rest in the database or cache. This protects the data in the event of a direct breach of the storage system.
• Use HttpOnly Cookies for Session Tokens: Session tokens and other authentication credentials should be stored in cookies with the HttpOnly flag set. This flag prevents client-side JavaScript from accessing the cookie, providing a strong defense against token theft via XSS attacks.
• Data Minimization: Adhere strictly to the principle of data minimization. Only store the data that is absolutely necessary for the user to resume their task, and ensure it is purged automatically after the required retention period has passed.
• Principle of Least Privilege: Access to temporarily stored data on the server must be strictly controlled through the application layer to prevent unauthorized access or leakage.

Section 3: The Alternative Conformance Path: Providing Proactive Warnings

While data preservation is the preferred method for conformance, there are scenarios where it may not be practical, feasible, or desirable. In such cases, SC 2.2.6 allows for an alternative path: warning the user of the inactivity timeout duration at the beginning of the task.

3.1 When to Warn Instead of Preserve

The decision to use a warning instead of preserving data is typically driven by security concerns or technical constraints.

• High-Security Applications: For platforms handling highly sensitive data, such as online banking or healthcare portals, preserving unsubmitted transaction data for 20 hours could be deemed an unacceptable security risk. In these contexts, shorter, more aggressive session timeouts are a deliberate security measure to protect users in case they leave a session open on a public or shared computer. Providing a clear upfront warning about a 15-minute inactivity timeout, for example, balances security needs with accessibility requirements.
• Technical or Legacy Constraints: Implementing a robust server-side data preservation system can be a significant architectural undertaking. For legacy systems or applications with limited development resources, retrofitting such a system may be prohibitively complex or costly. In these situations, adding a clear warning is a more pragmatic approach to achieving conformance.

It is important to recognize that choosing the "warning" path is a weaker form of compliance that shifts the burden of responsibility from the system back to the user. The data preservation path makes the system responsible for remembering the user's progress, allowing the user to operate without the cognitive load of a time constraint. In contrast, the warning path forces the user to internalize the time limit and plan their actions accordingly. This adds a layer of mental effort, which is precisely what accessibility guidelines often aim to reduce, particularly for users with cognitive disabilities. Therefore, an organization choosing this path should understand that it is providing a minimum viable accessible experience for this specific issue, not the ideal one.

3.2 Best Practices for Effective Timeout Warnings

To conform via this path, the warning itself must be implemented correctly and accessibly. Simply having a timeout is not enough; the user must be proactively informed.

• Placement and Timing: The most critical requirement is that the warning must be provided at the beginning of the task or process. A warning that appears only 20 seconds before the session expires does not satisfy this criterion (though it may help satisfy SC 2.2.1). The purpose of the upfront warning is to allow users to make an informed decision before they invest time and effort into entering data. It enables them to prepare any necessary materials in advance and to assess whether they can complete the task within the given time frame. The warning should be placed in a prominent location, such as at the top of the form or page where the task begins.
• Clarity and Content: The message must be clear, unambiguous, and explicitly state the duration of inactivity that will trigger the timeout. Vague warnings are not sufficient.
  • Good Example: "For your security, this application will time out after 15 minutes of inactivity. Any unsaved data will be lost."
  • Bad Example: "Please be aware that sessions may time out."
• Accessibility of the Warning: The warning message itself must be accessible. It should be part of the page's content and programmatically discernible by assistive technologies like screen readers. It should not be conveyed solely through color or an image without a text alternative. The text should have sufficient color contrast to be easily readable.

Section 4: SC 2.2.6 in the WCAG Ecosystem: Relationships and Distinctions

Guideline 2.2, "Enough Time," contains several related Success Criteria that address time limits from different angles. Understanding the specific scope of SC 2.2.6 in relation to its neighbors—SC 2.2.1 (Timing Adjustable) and SC 2.2.5 (Re-authenticating)—is crucial for correct implementation and auditing. Confusion between these criteria is a common source of implementation errors.

4.1 SC 2.2.6 (Timeouts) vs. SC 2.2.1 (Timing Adjustable) (Level A)

The primary distinction lies in the type of time limit and the required user control.

• SC 2.2.1 (Timing Adjustable): This Level A criterion applies to any time limit set by the content, whether it is based on user activity or not. This includes active timers, such as a countdown on a quiz, a page that automatically refreshes, or a session timeout. It mandates that the user must be given a mechanism to either turn off, adjust (to at least ten times the default), or extend the time limit (with a simple action, at least ten times). An exception is made for real-time events like an auction where the time limit is essential.
• SC 2.2.6 (Timeouts): This Level AAA criterion is more specific. It applies only to time limits triggered by user inactivity that could result in data loss. It does not require a mechanism to adjust or extend the time; instead, it requires either a proactive warning at the start of the task or data preservation for over 20 hours.

Clarifying Example:
Consider a secure banking portal with a 15-minute inactivity timeout.

• To meet SC 2.2.1 (Level A), the site must provide a warning before the 15 minutes expire (e.g., at the 13-minute mark) with an option for the user to easily extend the session.
• To meet SC 2.2.6 (Level AAA), the site must also display a message at the beginning of any data-entry task (e.g., at the top of a "Transfer Funds" form) stating, "For your security, this session will expire after 15 minutes of inactivity." Alternatively, if the bank preserved the user's incomplete transfer details for over 20 hours (a highly unlikely scenario for security reasons), it would meet SC 2.2.6 without needing any warning.

4.2 SC 2.2.6 (Timeouts) vs. SC 2.2.5 (Re-authenticating) (Level AAA)

These two Level AAA criteria are highly complementary and often work in tandem to create a seamless user experience.

• SC 2.2.5 (Re-authenticating): This criterion focuses specifically on the moment an authenticated session expires. It requires that the user can re-authenticate and continue their activity from where they left off without any loss of data. The emphasis is on preserving the user's state across the re-authentication boundary.
• SC 2.2.6 (Timeouts): This criterion is broader. It applies to any data loss from inactivity, including for unauthenticated users. For instance, a user adding items to a shopping cart without being logged in is covered by SC 2.2.6 if the cart is cleared due to inactivity.

The Synergistic Relationship: When dealing with authenticated users, these criteria are closely linked. Implementing the 20-hour data preservation path for SC 2.2.6 effectively satisfies the data preservation requirement of SC 2.2.5. If a user's authenticated session expires due to inactivity and their form data is preserved for 20+ hours, they will be able to log back in and resume their task, thus meeting both criteria. Together, they ensure that neither simple inactivity nor the formal expiration of a login token results in a punitive loss of user effort.

4.3 Comparative Analysis of Time-Related Criteria

To provide a clear, at-a-glance reference for developers and auditors, the key distinctions between these three related success criteria are summarized in the table below.

Section 5: Verification, Auditing, and Common Failures

Verifying conformance with SC 2.2.6 requires a nuanced approach that combines manual testing with, in many cases, a review of system architecture and code. Unlike many other WCAG criteria, it cannot be reliably assessed through automated tools alone.

5.1 A Framework for Manual Testing

Auditors and quality assurance teams should follow a systematic process to evaluate conformance with SC 2.2.6.

• Step 1: Identify Potential Data-Loss Scenarios.
  The initial step is to perform a comprehensive review of the application to identify all areas where users input data and where inactivity could plausibly lead to data loss. This includes:
  • Multi-page or long, single-page forms (e.g., registration, applications, tax returns, checkout processes).
  • Shopping carts or wishlists.
  • Content creation interfaces (e.g., blog post editors, forum posts).
  • Any authenticated dashboard or wizard that requires user input.
• Step 2: Test for Conformance Path 1 (Data Preservation).
  This path requires testing the system's ability to retain data over time.
  1. Navigate to an identified data-loss scenario.
  2. Enter a significant amount of unique, identifiable data into the form fields.
  3. Leave the browser tab open and inactive for a period that is longer than a typical session timeout (e.g., 30-60 minutes).
  4. Return to the tab and observe the state. If the data is still present in the form fields, the system has some form of data preservation.
  5. To fully verify Level AAA conformance, this test would need to be repeated with a 20+ hour period of inactivity. As this is often impractical in a standard testing cycle, this step highlights a critical aspect of auditing this criterion: behavioral testing must often be supplemented by systemic verification. Auditors should request and review documentation, server configurations, or code that confirms the 20-hour data preservation policy. This may involve inspecting cache TTL settings or database schemas and associated data purging scripts.
• Step 3: Test for Conformance Path 2 (Warning).
  If data is lost during the test in Step 2, the auditor must then check for the alternative conformance path.
  1. Navigate to the beginning of the task or process (e.g., the first page of the form).
  2. Carefully inspect the content for a clear and prominent warning message.
  3. Verify that this message explicitly states the duration of inactivity that will cause a timeout (e.g., "30 minutes," "1 hour").
  4. If no such warning is present at the start of the task, the success criterion is failed.

5.2 The Role and Limitations of Automated Tooling

Automated accessibility scanning tools are an invaluable part of a comprehensive testing strategy, but they are fundamentally incapable of definitively testing for SC 2.2.6 conformance. The reasons for this limitation are inherent to the nature of the criterion:

• Lack of Contextual Understanding: An automated tool cannot comprehend the purpose of a form or determine whether a timeout would actually result in "data loss" in a meaningful way. It cannot distinguish between a search form where losing input is a minor inconvenience and a multi-page application where it is a critical failure.
• State and Time Dependency: Verifying this criterion requires maintaining a state of inactivity over a prolonged period. Standard automated scanners analyze a page's state at a single point in time and are not designed to conduct longitudinal tests that span minutes or hours.
• Subjectivity of Warnings: A tool cannot algorithmically determine if a warning is "clear," "prominent," or appropriately placed at the "beginning of a task." These are qualitative judgments that require human evaluation.

Therefore, reliance on automated scans alone will produce a false negative for this criterion. Manual testing, combined with code and architecture review, is non-negotiable for accurate verification.

5.3 Documenting Common Pitfalls and Non-Conformance Examples

To make the requirements tangible, it is useful to document clear examples of common failures.

• Failure 1: The Ephemeral Shopping Cart. An e-commerce site allows an unauthenticated user to add items to their shopping cart. The user gets distracted by a phone call and returns to the site two hours later to find their cart is empty. The site did not preserve the cart data for more than 20 hours, nor did it provide any warning when the user first added an item that the cart would be cleared after a certain period of inactivity.
• Failure 2: The Unforgiving Application Form. A user is applying for a job on a corporate website. The application form is lengthy and requires information from their resume. The user navigates to another tab to look up a date, spends 25 minutes reviewing their resume, and returns to the application tab. The form has reset to its initial blank state, and all previously entered data has been lost. The site had a 20-minute inactivity timeout but failed to either preserve the data or warn the user about the time limit at the start of the application.
• Failure 3: The Silent Server Timeout. A user is logged into their insurance portal to file a complex claim. The server has a hard 15-minute session timeout for security. The user spends 20 minutes carefully composing a detailed description of the incident. When they click "Submit," they are unexpectedly redirected to the login page. Upon logging back in, they are returned to a blank claim form. The system failed to preserve the data across the re-authentication boundary (a failure of SC 2.2.5) and also failed to warn them at the outset about the 15-minute inactivity limit (a failure of SC 2.2.6).
• Failure 4: The Misplaced Warning. A financial services website has a 30-minute inactivity timeout on its forms. Two minutes before the timeout occurs, a modal dialog appears, warning the user and giving them an option to extend the session. While this action helps conform to SC 2.2.1 (Timing Adjustable), the site fails SC 2.2.6 because it did not provide a warning about the 30-minute limit at the beginning of the form-filling process.

Conclusion: Embracing Asynchronous Interaction as a Design Principle

Success Criterion 2.2.6: Timeouts, while a Level AAA guideline, encapsulates a design principle that is fundamental to creating truly user-centric and inclusive digital products. It challenges developers and architects to move beyond the traditional, ephemeral model of web sessions and embrace a paradigm of asynchronous, interruption-tolerant user journeys. The core message of the criterion is that users' time and effort are valuable and should be protected by the system they are interacting with.

The analysis reveals two distinct paths to conformance, with a clear preference for robust data preservation. By preserving user data for more than 20 hours, organizations can create a superior user experience that eliminates the cognitive load and anxiety associated with time limits. This approach, however, is not without its complexities. It demands a sophisticated back-end architecture and introduces a critical intersection with privacy and security regulations. The repeated admonitions within the WCAG documentation to consult with legal and privacy counsel underscore that implementing this criterion is a strategic, cross-functional endeavor, not merely a technical task.

The alternative path—providing a proactive warning—remains a valid means of conformance, particularly for high-security applications or legacy systems. However, it should be recognized as a lesser solution that shifts the burden of managing time constraints back onto the user, a practice that is antithetical to the broader goals of reducing cognitive load for users with disabilities.

For organizations committed to achieving the highest standards of digital accessibility, the following actionable recommendations emerge from this analysis:

1. Prioritize Data Preservation: Whenever feasible, architect systems to preserve user data for more than 20 hours of inactivity. Treat this as the default approach for any form or multi-step process that requires significant user input.
2. Engage Legal and Privacy Teams Early: The decision to preserve user data has significant legal implications. Involve legal and privacy experts at the design stage to ensure that the chosen implementation strategy complies with all relevant regulations, such as GDPR and HIPAA, particularly concerning user consent and data minimization.
3. Adopt a "Draft State" Model: Reframe the concept of long forms. Instead of treating them as a single, transient interaction, design them as documents with an implicit "draft" state that is automatically saved, either on the server or, for non-sensitive data, on the client.
4. Invest in Secure Back-End Architecture: A commitment to Level AAA conformance for this criterion necessitates investment in the back-end infrastructure required to support secure, persistent user state. This includes encrypted databases or caches for temporary data, robust data lifecycle management policies, and secure authentication mechanisms that use HttpOnly cookies.

Ultimately, SC 2.2.6 is a forward-looking principle. As digital interactions become increasingly complex and integral to daily life, designing systems that respect a user's time, protect their effort, and accommodate interruptions will no longer be a niche accessibility requirement but a hallmark of high-quality, inclusive design for everyone.