WCAG 2.2.3 No Timing: When Time Limits Create Accessibility Barriers

WCAG 2.2.3 No Timing — plain meaning

WCAG 2.2.3 No Timing explains when time limits create accessibility barriers and what authors must do. The goal is simple. If a user needs more time to read, interact, or complete a task, the content must either remove the time limit or give a reliable way to turn it off or extend it.

Why this success criterion matters

Time limits can exclude people with motor impairments, cognitive differences, low vision, or fluctuating conditions. They also block people using assistive technology, people on slow connections, and anyone who is interrupted during a task. Removing or adapting time limits preserves access to forms, tests, purchases, and interactive tools.

Where WCAG 2.2.3 No Timing applies

• Forms that expire session data
• Online tests, quizzes, timed exercises
• Shopping carts and checkout timeouts
• Interactive tools with built-in countdowns
• Authenticated sessions that log users out after inactivity

It applies whenever the author sets a time limit that can prevent a user from completing a task.

Common failures and straightforward fixes

• Failure: A form clears after 10 minutes with no warning.
  Fix: Save draft automatically and provide a clear control to extend or disable the timeout.
• Failure: A quiz ends when the countdown hits zero and answers are lost.
  Fix: Allow users to pause or request more time. Persist answers during the extension.
• Failure: Session logout without notice during a long task.
  Fix: Show an accessible warning that allows users to stay signed in or extend the session.

How to meet WCAG 2.2.3 No Timing — a step-by-step checklist

1. Find all time limits. Search code, product flows, and third-party components for timeouts and countdowns.
2. Classify each limit. Decide whether it is essential for safety or function, or whether it is arbitrary.
3. Remove non-essential limits. If the time limit is not strictly necessary, stop enforcing it.
4. Provide controls. For limits that must remain, give a clear option to turn them off or to request a reasonable extension.
5. Preserve user work. Auto-save and restore state so users do not lose input when time is extended or paused.
6. Give an accessible warning. Warn users with text that can be read by screen readers and provide an easy action to extend time.
7. Document decisions. Record why any remaining limit is essential and what compensating measures exist.

What counts as a reliable control

• Simple toggle in the UI to turn off the timer for that session
• Button labelled clearly, such as “Extend time” or “Pause timer”
• Server-side acknowledgement so the setting survives navigation and reloads

Design patterns and suggested wording

Use short, direct text for warnings. Examples of accessible phrases include:

• “Your session will end in 2 minutes. Click Stay signed in to continue.”
• “Time remaining: 10:00. Click Extend time to add more time.”
• “This activity uses a time limit. Click Request more time if you need it.”

Ensure buttons have clear accessible names and that focus moves predictably to the warning dialog. Do not rely on color alone to convey the message.

Technical considerations

Implement both client and server support. Client-side countdowns are fine for display, but the server must honour the user’s choice to extend or disable time limits. Auto-save regularly and keep tokens valid so users do not lose progress when they ask for more time.

Be careful when removing time limits that are part of security controls. If a time limit is needed for fraud prevention, combine it with other measures such as rate limiting, multi-factor checks, or manual review rather than hard expiry that blocks users without recourse.

Testing WCAG 2.2.3 No Timing

Automated tools rarely catch timing issues. Test manually with these steps:

• Start each timed flow and observe warnings and controls.
• Use a screen reader and keyboard only to ensure warnings are announced and actionable.
• Interrupt the flow (simulate a phone call) and return to confirm state is preserved.
• Try the extend or disable control and confirm the server honors it across pages.

Include users with disabilities in testing. They will reveal real-world problems automated tests miss.

Decision flow: is the time limit essential?

Use these questions when deciding whether a time limit must stay:

• Does the activity involve safety that depends on strict timing? If yes, document why.
• Can fraud or abuse be prevented with another control that does not block legitimate users? If yes, prefer that control.
• Can work be auto-saved and resumed if time runs out? If yes, avoid hard expiry.

If you still need the limit, require a persistent option to extend or turn it off for users who need more time.

Documentation and procurement notes

When writing requirements or procurement specs, list time limits explicitly and require:

• Controls to extend or disable limits
• Accessible warnings with keyboard and screen reader support
• Server-side enforcement that respects user choices
• Evidence from testing with people who need extra time

Audit checklist for WCAG 2.2.3 No Timing

• All timed flows identified and logged
• Non-essential limits removed
• Controls exist to extend or disable limits where needed
• Warnings are accessible and actionable via keyboard and assistive tech
• User data is preserved when time is extended
• Decision records kept for any remaining essential time limits

Where to read the official text

Find the authoritative wording and examples in the WCAG 2.2 specification on the W3C website. Use the spec when you need exact test conditions and normative language.

Practical tip: treat time limits as a usability problem first and a security problem second. Often the accessibility fix improves both user satisfaction and conversion.