WCAG 2.2.3: No Timing

What This Rule Means

WCAG 2.2.3 — No Timing sits at the AAA conformance level under Guideline 2.2: Enough Time. Its requirement is direct: timing must not be an essential part of any event or activity presented to the user. In other words, if your content or functionality involves a time limit, deadline, or time-sensitive interaction of any kind, that time dependency must either be removable or must be completely irrelevant to the task at hand — unless one of the narrow exceptions applies.

This criterion goes further than the Level A criterion 2.2.1 (Timing Adjustable) and the Level AA criterion 2.2.2 (Pause, Stop, Hide). While those earlier criteria allow for adjustable or pausable time limits, 2.2.3 demands that timing simply not exist as a meaningful constraint at all. A user who takes ten seconds or ten minutes to fill out a form, navigate a menu, or complete a workflow must arrive at the same outcome as a user who finishes instantly.

What counts as a pass: Content where no time limit exists, or where any time limit present is purely cosmetic and has no bearing on the outcome (for example, an animation that loops but does not prevent interaction). Content that is fully functional regardless of how long the user takes passes this criterion.

What counts as a fail: Session timeouts that log users out after inactivity; timed quizzes or assessments where the score or completion depends on finishing within a window; shopping cart expiry timers that delete items; auction bid interfaces with countdown clocks that close bidding; one-time password (OTP) fields that expire; CAPTCHA challenges with time limits; and any interactive element that becomes unavailable or submits automatically based on elapsed time.

Official exceptions defined by WCAG: The criterion explicitly exempts two categories. First, real-time exceptions — events where timing is absolutely inherent to the activity, such as a live auction, a live broadcast, or a real-time multiplayer game. Second, essential exceptions — situations where removing the time limit would fundamentally alter the activity. For example, a speed-typing proficiency test inherently measures speed, so timing is essential. However, developers and product owners must be rigorous: convenience, technical legacy, or business preference do not qualify as "essential." The bar is whether the activity would lose its core meaning or purpose without the time constraint.

It is important to note that synchronized media — such as a pre-recorded video with captions — is also excluded, because timing in media playback is controlled by the user's own media player and does not impose a constraint on the user's ability to interact with the rest of the page.

Why It Matters

Time limits on the web disproportionately harm users across a broad range of disabilities. The impact is not abstract — for many users, a timed interface is effectively an inaccessible one.

Users with motor impairments — including those who use switch access devices, mouth sticks, eye-tracking software, or other alternative input methods — operate at a fundamentally different pace than mouse-and-keyboard users. Completing a multi-step form or navigating a dropdown menu can take several times longer. A session timeout or an auto-expiring cart can erase minutes of careful, effortful work in an instant.

Users with cognitive disabilities, including dyslexia, ADHD, processing disorders, and acquired brain injuries, may need significantly more time to read instructions, understand options, or compose responses. Research compiled by the Web Accessibility Initiative estimates that cognitive and learning disabilities affect roughly 15–20% of the global population in some form. For these users, a countdown timer is not just stressful — it actively impairs the cognitive processing needed to complete the task.

Screen reader users who are blind or have low vision navigate content linearly and must listen to or read through interface elements sequentially. Understanding the structure and options on a complex page takes more time than a sighted user skimming visually. A timed checkout flow that expires while a blind user is carefully reviewing their order summary is a direct barrier to commerce.

Users with anxiety disorders may find that the mere presence of a countdown timer creates enough cognitive and emotional load to prevent task completion, even if they technically have enough time. Removing timing as a factor removes this barrier entirely.

A concrete real-world scenario: Consider an online banking portal that uses a five-minute inactivity timeout combined with an OTP that expires in sixty seconds. A user with Parkinson's disease who needs assistive input technology to type, or an elderly user unfamiliar with quickly switching between apps, may find it physically impossible to receive the SMS, switch applications, read the code, switch back, and enter it within the allotted window. They are locked out of their own account — not by security necessity, but by an arbitrary time constraint. Designing the OTP to remain valid for a longer period (or eliminating the hard expiry in favour of a resend mechanism) resolves the issue without compromising security.

Beyond accessibility, removing unnecessary time constraints improves general usability and reduces abandonment rates. An e-commerce checkout that does not expire mid-flow retains more customers, increases conversion, and reduces support burden — making this a business-positive change as well as an ethical imperative.

Related Axe-core Rules

WCAG 2.2.3 requires manual testing. No automated axe-core rule directly maps to this criterion, and this is an important architectural reality to understand.

• Manual testing required — Session and interaction timing: Automated tools cannot detect whether a web application enforces a time limit because timing logic is implemented in server-side session management, JavaScript timers, or back-end API responses — none of which are visible in static DOM analysis. A tool like axe-core inspects the rendered HTML and accessible tree; it cannot observe that a fetch request will return a 401 after five minutes of inactivity, or that a JavaScript setTimeout will redirect the user to a logout page. Only a human tester who interacts with the application slowly and observes what happens can determine whether timing constraints exist and whether they affect task completion.
• Manual testing required — OTP and CAPTCHA expiry: One-time passwords and time-limited verification challenges appear in the DOM as ordinary input fields. The countdown timer, if visible, might be a simple text node or a CSS-animated element. Axe cannot infer that entering a value in this field after ninety seconds will result in an error state. A tester must deliberately wait beyond the expiry window and attempt to submit to confirm whether timing is enforced.
• Manual testing required — Auto-submitting and auto-advancing forms: Some interfaces automatically advance to the next step or submit a form after a period of inactivity or after a set duration (for example, a survey that moves to the next question after thirty seconds). Axe-core will not flag this because the DOM structure appears valid; the problematic behaviour only manifests during actual interaction over time.
• Manual testing required — Commerce and reservation expiry: Shopping cart reservation timers, ticket booking holds, and appointment slot locks are implemented via server logic and reflected in the UI only as a countdown display. Automated tools see a number updating on screen but cannot determine whether it causes data loss or access denial when it reaches zero.

How to Test

1. Automated baseline scan: Run axe DevTools or Lighthouse on the page to identify any related lower-level timing violations (such as those covered by 2.2.1 or 2.2.2) that may point you toward areas requiring deeper manual inspection. While no axe rule directly tests 2.2.3, findings around time limit warnings or auto-refresh can guide your manual audit scope. In Lighthouse, review the "Accessibility" section for any time-related flags.
2. Inventory all time-dependent features: Before testing, systematically catalogue every feature in the application that might involve timing. This includes: session management and inactivity timeouts; OTP and verification code fields; shopping cart or reservation holds; timed quizzes, assessments, or surveys; auction or bidding interfaces; CAPTCHA challenges; auto-saving mechanisms with submission windows; and any visible countdown or progress timers.
3. Test session timeout behaviour: Open the application and begin a task that spans multiple steps (for example, filling out a multi-page form or completing a checkout). Do not interact for a period exceeding the suspected timeout window. Then attempt to continue. Observe whether your progress is preserved, whether you are warned and given the ability to extend your session, or whether you are logged out or lose data. A pass requires that either no timeout exists, the timeout is purely precautionary and data is preserved on re-authentication, or the user is given adequate warning and control.
4. Test OTP and code expiry: Trigger an OTP or verification code flow. Wait until after the code's stated expiry time (or longer if no time is displayed). Attempt to enter the code. If the system rejects it solely due to time, this is a failure of 2.2.3. Note: a "resend" mechanism alone does not fix 2.2.3 — the original code expiry still imposes timing.
5. Screen reader testing (NVDA + Firefox): Using NVDA with Firefox, navigate through any timed interface using only the keyboard and screen reader. Note how long each step takes with assistive technology navigation overhead. Deliberately proceed at a slow pace — pause to listen to all instructions, explore all options via virtual cursor — then attempt to submit or proceed. Verify that slow navigation does not trigger a timeout or loss of state.
6. Screen reader testing (VoiceOver + Safari on macOS): Repeat the same slow-navigation test using VoiceOver on macOS with Safari. Pay particular attention to dynamic countdown timers: does VoiceOver announce time remaining in a way that creates urgency, and does the interface fail when time runs out?
7. Screen reader testing (JAWS + Chrome): Using JAWS with Chrome, test the same flows. JAWS users represent a significant portion of professional screen reader users; timing issues that affect NVDA users will typically affect JAWS users equally.
8. Verify exception legitimacy: For any timing that the development team claims is "essential" or "real-time," document the justification and assess whether the timing is truly inherent to the activity's purpose, or whether it could be relaxed, extended, or removed without changing the fundamental nature of the task.

How to Fix

Session Timeout — Incorrect

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Session Timeout — Correct

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Expiring OTP Field — Incorrect

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Expiring OTP Field — Correct

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Timed Quiz — Incorrect

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Timed Quiz — Correct

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Common Mistakes

• Assuming session security requires a hard timeout: Many teams implement short inactivity timeouts citing security requirements, but most security standards (including PCI-DSS and OWASP) allow for user-controlled session extension. A hard logout without warning or extension opportunity is an accessibility failure, not a security necessity.
• Displaying a countdown timer without providing a way to stop or extend it: Adding an aria-live region to a countdown makes it worse for screen reader users — it announces every second — without fixing the underlying timing problem. The fix is to remove the constraint, not to announce it more accessibly.
• Treating "resend code" as a fix for OTP expiry: Providing a resend button allows users to get a new code but does not address the fact that the original code expired due to timing. The time limit is still present. The correct fix is to extend the validity window to eliminate time pressure.
• Auto-advancing carousel or wizard steps after inactivity: Multi-step forms or wizards that automatically proceed to the next step after a set time impose a timing constraint. Users who are reading instructions or considering their answer are penalised. Steps must only advance on explicit user action.
• Shopping cart timers that delete items without preserving them: Reservation timers in e-commerce ("Your cart expires in 15 minutes") fail 2.2.3 when items are permanently lost at expiry rather than simply released from reservation. At minimum, items should be saved to a wishlist or the session should be restorable.
• Applying the "real-time exception" too broadly: Labelling an interface as "real-time" to justify timing constraints when it is not genuinely live. A pre-recorded auction replay, a static bidding interface, or a quiz that merely resembles a game show does not qualify for the real-time exception.
• Ignoring timing in back-end API responses: Teams fix front-end timers but overlook that the API itself rejects requests made after a certain window. The user sees no countdown but their submission fails silently. Back-end session management must align with front-end experience.
• Using setTimeout for auto-logout without persisting form state: When an automatic logout is unavoidable (for example, due to regulatory requirements), failing to save the user's form data before redirecting means all work is lost. At minimum, draft state should be saved and restored after re-authentication.
• Conflating 2.2.1 compliance with 2.2.3 compliance: Providing a "turn off, adjust, or extend" control (as required by 2.2.1 Level A) does not satisfy 2.2.3. Level AAA requires that timing is not essential — not just manageable. A time limit with a generous extension is still a time limit.
• Overlooking timing in third-party embedded components: Embedded chat widgets, payment processors, identity verification SDKs, and map services may introduce their own timing constraints. Third-party origin does not exempt these from WCAG applicability when they are integrated into your interface.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes a national web accessibility framework that references WCAG 2.2 as its technical baseline. The Circular mandates compliance across a broad range of entities operating digital services in Turkey.

The entity types covered include public institutions and government bodies, e-commerce platforms, banks and financial services, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). These organisations are required to meet the accessibility standards defined in or referenced by the Circular when providing digital services to the public.

WCAG 2.2.3 — No Timing is a Level AAA criterion, and the Presidential Circular 2025/10, like the European EN 301 549 standard it aligns with, mandates Level A and Level AA conformance as the legal minimum. Level AAA compliance is not a direct legal obligation under this framework. However, achieving Level AAA — and specifically implementing 2.2.3 — is recognised as a marker of best-in-class accessibility maturity and demonstrates a genuine commitment to inclusive design beyond minimum legal thresholds.

For certain covered entity types, particularly banks and financial services operating under BDDK oversight, and e-commerce platforms with high transaction volumes, timing constraints such as OTP expiry, session management, and checkout flow timers are pervasive features. Even where 2.2.3 is not legally required, failing to address timing barriers in these flows creates real discrimination risk — particularly as Turkish accessibility enforcement mechanisms mature and complaint procedures become more established.

Public institutions and healthcare providers serving users with disabilities, elderly users, and users with low digital literacy have a particularly strong ethical case for eliminating timing constraints entirely. Removing time limits from digital government services and healthcare portals aligns with Turkey's broader e-government inclusion goals and reduces the risk of future regulatory exposure as AAA adoption in public sector procurement becomes more common.

Organisations seeking to position their digital products as fully inclusive — whether for domestic leadership, international market access, or procurement advantages in European Union contexts (where EN 301 549 and the European Accessibility Act apply) — should treat WCAG 2.2.3 compliance as a strategic investment rather than an optional enhancement.