Level AAA

Session timeouts, idle warnings, and limited-time offers all fail 2.2.3 even when they pass 2.2.1

2.2.3 No Timing

In Plain Language

2.2.3 No Timing (Level AAA) is the strict form of 2.2.1 Timing Adjustable. Where 2.2.1 lets you keep a time limit as long as the user can turn it off, adjust it, or extend it, 2.2.3 removes the time limit entirely. The only carve-out is real-time events -- live auctions, multiplayer matches against human opponents, live broadcasts -- where the clock is the activity[1].

Session timeouts, "you have been idle for 15 minutes" warnings, soft-delete countdowns, and limited-time checkout holds all fail 2.2.3 even when they pass 2.2.1. If the task can be finished without a clock, the clock has to go.

Why It Matters

  • Users with cognitive and learning disabilities may need several times longer than the designer assumed to read, decide, and respond. An adjustable timer still makes the clock visible and adds anxiety; removing it removes the barrier[1].
  • Screen-reader users and switch users interact serially -- the interface is read out or stepped through one control at a time -- so wall-clock time to complete a form is a multiple of what a sighted mouse user needs. Timers calibrated to sighted mouse users systematically expire on assistive-technology users.
  • Users who step away from the screen for a medication, a caregiver, a translator, or a print magnifier return to a cleared form when a session timeout fires. 2.2.1 lets them extend; 2.2.3 says do not force the interruption in the first place.
  • 2.2.3 is Level AAA, so it is rarely mandatory for compliance. It is a strong inclusive-design default for content-heavy, forms-heavy, and assessment-heavy sites where the timer serves the operator, not the activity.

Examples

Do: Assessment with no time limit

Online assessment form:

<form aria-label="Accessibility knowledge check">

<!-- No timer -- users complete at their own pace -->

<p>Take as long as you need.</p>

✔ Assessment has no time limit -- users work at their own pace

<form aria-label="Accessibility knowledge check">
  <p>Take as long as you need.
     There is no time limit.</p>
  <fieldset>
    <legend>Question 1 of 10</legend>
    <!-- question content -->
  </fieldset>
  <button type="submit">Submit answers</button>
</form>
Do: Checkout flow with no session expiry

Multi-step checkout:

<!-- Cart persists indefinitely -->

<!-- No session timeout interrupts the purchase -->

<p>Your cart is saved. Complete checkout whenever you are ready.</p>

✔ Cart and checkout have no time-based expiration

<section aria-label="Checkout">
  <p>Your cart is saved. Complete checkout
     whenever you are ready.</p>
  <!-- No session timeout or countdown -->
  <!-- Cart contents persist until the
       user explicitly clears them -->
  <ol>
    <li>Shipping address</li>
    <li>Payment method</li>
    <li>Review and place order</li>
  </ol>
</section>
Don't: Quiz with countdown timer

Timed knowledge quiz:

<div class="timer">Time remaining: 4:32</div>

<!-- Quiz auto-submits when timer hits zero -->

✘ Timing is imposed on an activity that does not inherently require it

Don't: Form that expires after inactivity

Application form with session timeout:

<!-- Session expires after 15 minutes of inactivity -->

<!-- All entered data is lost on expiration -->

✘ Session timeout forces timing on a form that could be saved indefinitely

How to Fix It

  1. Distinguish real-time from operator-imposed timing. 2.2.3 exempts only events where the clock is the activity -- live auctions with other bidders, live multiplayer matches, live broadcasts, and non-interactive synchronized media[1]. A proctored exam, a training quiz, a checkout hold, or a "limited-time offer" is operator-imposed, not real-time, and fails AAA.
  2. Persist state server-side so sessions do not need to expire for UX reasons. Save cart contents, form progress, and multi-step wizard state under a durable key (user id, anonymous session cookie) so the user can close the tab and come back tomorrow. Session-cookie expiry is an implementation detail; the user-visible activity should not expire.
  3. Separate security session timeouts from user-visible timers. A bank or health portal will still rotate auth tokens for security -- that is required elsewhere, not governed by 2.2.3. The 2.2.3-conforming pattern is a silent re-auth prompt that preserves in-flight form data, not a countdown that wipes the form.
  4. Audit every timer that currently passes 2.2.1. For each adjustable, extendable, or dismissable timer, ask whether removing it entirely would change the activity. If the answer is no, removing it takes the page from 2.2.1 (A) to 2.2.3 (AAA) at zero functional cost.
  5. Do not substitute a "warning modal" for removing the timer. An "are you still there?" dialog is a 2.2.1 mechanism, not a 2.2.3 fix. It still forces the user to respond on the system's schedule.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.2.3: No Timing. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/no-timing.html ↩ ↩ ↩