WCAG 2.2.3: No Timing
Level A says time limits must be adjustable. Level AAA asks a sharper question: why is there a clock at all? Under 2.2.3, timing must not be an essential part of any event or activity your content presents — users get as long as they need, whether that is thirty seconds or three days. Only two things escape: media that is inherently temporal, and events happening in real time.
The success criterion, in full
Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events.
Notice what is missing compared with 2.2.1 Timing Adjustable: there is no “essential exception” you can invoke for your own design. If the timing is not imposed by a real-world event or the nature of synchronized media, it must go.
Who this helps
Every interaction on the web takes different people wildly different amounts of time. A form that takes one user ninety seconds can take another user forty-five minutes — same form, same intent, different body and tools:
Screen reader users
Content is consumed linearly, one element at a time. Skimming a page under time pressure is not an option.
People with motor disabilities
Switch access, eye gaze, and on-screen keyboards make each input action slower — sometimes by an order of magnitude.
People with cognitive disabilities
Reading, comprehension, and decision-making can take longer; a ticking clock also actively worsens performance through stress.
People who are deaf or hard of hearing
Users whose first language is a sign language may read written language more slowly — timed reading tasks penalize them directly.
Adjustable limits (2.2.1) help, but they still put the burden on the user to notice the warning and act on it. Removing timing entirely removes the burden.
The two exceptions
1. Non-interactive synchronized media
A film, a narrated animation, a recorded lecture — audio and video synchronized on a timeline. Timing is the medium; it cannot be removed. The moment the media demands interaction on a deadline (“answer within 15 seconds or the video restarts”), that interaction is an activity again and the exception no longer covers it.
2. Real-time events
Events that happen at the same time as viewing and are not created by the content: a live auction closing, a webcast, competitive multiplayer play among live opponents, tickets for a show that starts at 8 p.m. The world sets the clock, not the designer. A marketing countdown (“offer ends in 09:59!”) that you control does not qualify — although note that a purely decorative urgency timer that gates nothing is not making timing essential either.
The test for both is the same: does the timing originate outside the content’s control, or is it a design choice? Design choices must be removed at AAA.
The 2.2.x ladder: from adjustable to absent
Guideline 2.2 Enough Time escalates through the conformance levels. Understanding where 2.2.3 sits makes it easy to apply:
- 2.2.1 Timing Adjustable (A) — Time limits may exist, but users must be able to turn them off, adjust them to at least 10× the default, or extend them — with exceptions for real-time events, essential limits, and limits over 20 hours.
- 2.2.3 No Timing (AAA) — This criterion. Timing must not be essential to the activity at all. The 'essential' escape hatch of 2.2.1 disappears; only synchronized media and real-time events remain exempt.
- 2.2.5 Re-authenticating (AAA) — When a secure session does expire, users can continue where they left off — with all data intact — after logging back in.
- 2.2.6 Timeouts (AAA) — If inactivity can cause data loss, users are told the duration up front (unless data is kept for more than 20 hours).
A practical way to design for the whole ladder at once: build every task so it can be paused indefinitely and resumed without loss. Auto-save plus no deadlines satisfies 2.2.3 directly and makes 2.2.5 and 2.2.6 almost free.
Pass and fail examples
✓ Passes 2.2.3
- A checkout that holds the cart indefinitely and auto-saves the address form as the user types.
- An online quiz with no time limit — completion is judged on answers, not speed.
- A word game that offers an untimed mode alongside its timed “challenge” mode.
- A live auction page — real-time event exception — that clearly shows the auction close time.
- A training video (non-interactive synchronized media) with pause, and untimed knowledge checks afterwards.
✗ Fails 2.2.3
- A ticket checkout that releases your seats after 8 minutes when no genuine scarcity forces it.
- A timed certification exam — its “essential” time limit can pass 2.2.1 but fails 2.2.3.
- A form that discards everything after 15 minutes of inactivity with no way to recover it.
- A CAPTCHA or verification code that expires so fast that slower users must restart repeatedly.
- An e-learning module where each question must be answered within 30 seconds by design.
Common failures
- Manufactured urgency: countdowns that gate a purchase or price purely as a conversion tactic, making timing essential where nothing real requires it.
- Session-expiry designs where the timer effectively becomes part of the task — the user must finish before an arbitrary clock runs out or lose all progress.
- Timed tests and quizzes where speed is not the skill being measured, penalizing users who need assistive technology or more processing time.
- One-time codes and CAPTCHAs with expiry windows too short for users of screen readers or switch access to complete entry.
- Interactive media that pauses and demands a response within a deadline, assuming the media exception covers it — it does not, because the interaction is an activity.
- Auto-advancing multi-step wizards that move on after a fixed delay whether or not the user has finished the current step.
- Claiming the real-time exception for a timer the site itself created, like a self-imposed 'flash sale' clock that could simply be removed.
How to test for 2.2.3
- 1
Inventory every clock
List everything time-driven on the page or in the flow: session timers, countdowns, expiring codes, auto-advancing steps, timed questions, carousels that gate content, games. Include timers that are invisible until they fire.
- 2
Classify each against the two exceptions
For each timer ask: is this a real-time event whose clock the content does not control, or non-interactive synchronized media? If neither, timing must not be essential to the activity.
- 3
Walk away mid-task
Start each key task, then stop interacting — for ten minutes, an hour, longer if feasible. Return and continue. If the task failed, reset, expired, or lost data, timing was essential and the criterion fails.
- 4
Complete tasks at assistive-technology speed
Run the flow with a screen reader or keyboard-only, deliberately slowly. Any point where slowness alone causes failure — an expired code, a released reservation, a skipped question — is a defect.
- 5
Check timed modes have untimed equivalents
Where time pressure is part of the fun or the pedagogy, verify an untimed mode offers the same content and completion credit. An untimed alternative that covers the same functionality satisfies the requirement for that activity.
No automated tool can find these failures — timers usually live in application logic, not markup. Pair this review with the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 2.2.3 No Timing require?
It requires that timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events. In plain terms: at Level AAA, users should be able to take as long as they need for anything the content asks of them. Where 2.2.1 Timing Adjustable (Level A) lets you keep time limits as long as users can turn them off, adjust them, or extend them, 2.2.3 says the activity itself should not depend on time at all.
How is 2.2.3 different from 2.2.1 Timing Adjustable?
2.2.1 (Level A) accepts that time limits exist and regulates them: the user must be able to turn off, adjust to at least ten times the default, or repeatedly extend each limit, with several exceptions including 'essential' limits. 2.2.3 (Level AAA) goes further: it removes the premise. Timing must not be essential to the activity in the first place, and there is no 'essential exception' — only non-interactive synchronized media and real-time events are exempt. A timed certification exam can pass 2.2.1 under its essential exception, but it fails 2.2.3.
What counts as a 'real-time event' under the exception?
A real-time event is one that occurs at the same time as viewing and is not generated by the content itself — an online auction that genuinely closes at a fixed moment, a live webcast, a ticket sale for a physical event, or a multiplayer game synchronized among live participants. The timing there comes from the real world, not from a design decision, so the content cannot remove it. A countdown you invented to create urgency is not a real-time event.
Why is non-interactive synchronized media exempt?
A movie or a narrated animation is inherently temporal — video frames and audio are synchronized on a timeline, and 'removing timing' from them is meaningless. The exemption covers only the non-interactive kind: content the user watches rather than operates. If media becomes interactive — say, a training video that pauses and demands an answer within 15 seconds — that interaction is an activity, and its time limit is subject to the criterion.
Does 2.2.3 forbid session timeouts for security?
Not exactly. Session timeouts driven by security policy are about the session, not about making timing part of the activity. The W3C's guidance treats untimed activities as compatible with sessions that expire, provided the user does not lose data or progress — which is exactly what 2.2.5 Re-authenticating (AAA) and 2.2.6 Timeouts (AAA) govern. The clean AAA combination is: no task is time-pressured (2.2.3), users are warned about inactivity limits (2.2.6), and re-authenticating never loses their work (2.2.5).
Who benefits from removing time limits entirely?
Anyone who needs more time than a designer guessed: people using screen readers who navigate content linearly, people with motor disabilities using switch access or on-screen keyboards, people with cognitive or learning disabilities who read and process more slowly, people with anxiety for whom countdowns degrade performance, and users of magnification who see a small window of the page at a time. Time pressure multiplies the difficulty of every other barrier — removing it is one of the most powerful accessibility improvements available.
Related Success Criteria
Users can turn off, adjust, or extend time limits.
Moving, blinking, or auto-updating content can be paused, stopped, or hidden.
Interruptions can be postponed or suppressed by the user.
User data is preserved when a session expires and re-authentication is required.
Users are warned of the duration of inactivity that could cause data loss.