Timeouts ensure that users are informed when inactivity may cause them to lose data or progress. If a session or task will expire after a period of inactivity, users must be warned about the duration so they can decide how and when to proceed.
This criterion exists because many users need more time to read, understand, and complete tasks, and unexpected timeouts can cause significant disruption or data loss.
WCAG Success Criterion
2.2.6 Timeouts (Level AAA)
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 action.
Why This Matters
Timeouts are commonly used for security, resource management, or session handling. When users are unaware of how long they can remain inactive, they may lose:
- Entered form data
- Progress in multi-step workflows
- Draft content or selections
- Their place in a process
For many users, especially those who need breaks or more time to process information, losing work due to an unknown timeout can make tasks difficult or impossible to complete.
Unexpected data loss can also increase anxiety, reduce confidence, and discourage users from attempting complex tasks again.
Intent of the Criterion
This success criterion intends to ensure that users are informed in advance when inactivity could result in data loss.
This criterion does not prohibit timeouts. Instead, it requires that users know:
- That a timeout exists, and
- How long can they remain inactive before data may be lost
The criterion works alongside SC 2.2.1 Timing Adjustable (Level A), but focuses specifically on notification, not adjustment. Users must be warned of inactivity limits even if no extension mechanism is provided.
Data Preservation as an Alternative
The most robust way to meet this criterion is to preserve user data for at least 20 hours without requiring user action.
When data is preserved for this duration, warnings about inactivity timeouts are not required because users will not lose information due to inactivity.
However, long-term data preservation may not always be possible due to security, privacy, or regulatory constraints. In those cases, clear and early warning is required.
Privacy and Regulatory Considerations
Some privacy and security regulations may restrict how long user data can be retained, especially before authentication or when dealing with sensitive information.
Examples include:
- Payment Card Industry Data Security Standard (PCI DSS)
- Health Insurance Portability and Accountability Act (HIPAA)
When data preservation is limited by regulation or policy, authors must rely on clear timeout warnings rather than extended storage.
Scope of This Criterion
This success criterion applies only to timeouts that are within the content provider’s control or knowledge.
It does not apply when data is lost because:
- The user closes their browser or device
- The user navigates away intentionally
- The browser crashes or loses connectivity
In these cases, the timeout is not initiated by the content itself.
Who This Helps
This criterion primarily supports users who:
- Have cognitive or learning disabilities and need more time to read or decide
- Have memory-related or attention-related disabilities
- Use screen readers and require additional time to navigate
- Have motor impairments that slow interaction
- Need to take breaks during complex tasks
Knowing how long a session can remain inactive allows these users to plan, pause, and complete tasks successfully.
Common Failure Patterns
Timeout-related failures often occur when:
- Users are not informed that a timeout exists
- The timeout duration is disclosed only after data is lost
- Warnings appear too late to act on
- Timeouts are reset silently without user awareness
- Data is cleared without advance notice
In these cases, users are unable to make informed decisions about continuing or pausing their activity.
Examples
Extended data storage
An e-commerce site stores in-progress checkout data for more than 20 hours. Users can return later and continue without losing information, even if they were inactive.
Timeout warning
A tax-filing application displays a notice at the start of the process explaining that inactivity longer than one hour will trigger a session timeout.
No timeout
An online contact form does not implement inactivity timeouts. Users may take as long as they need, and data is only lost if they close the browser.
Rule Description
If user inactivity can cause data loss, users must be informed of the duration of inactivity that will trigger the timeout, unless user data is preserved for more than 20 hours without user action.
The Algorithm
- Identify tasks where user inactivity can cause data loss
- Determine whether the entered data is preserved for more than 20 hours
- If data is preserved:
- No timeout warning is required
- If data is not preserved:
- Verify that users are clearly informed of the inactivity duration that causes a timeout
- Confirm the warning appears early in the process
- If users are not warned, and data can be lost, the criterion fails
Wrapping Up
Timeouts at Level AAA are about predictability and informed choice. Users must either be protected from data loss through extended preservation or clearly informed about how long inactivity is allowed. When users know the limits, they can plan their time, take breaks, and complete tasks without fear of losing their work.
Unexpected timeouts are not just frustrating, they create real accessibility barriers for users who need more time to interact with content.
