WCAG 2.2.1: Timing Adjustable

What This Rule Means

WCAG 2.2.1 Timing Adjustable is a Level A success criterion under Principle 2: Operable. It states that for each time limit set by content, at least one of the following must be true: the user can turn off the time limit before encountering it; the user can adjust the time limit over a wide range (at least ten times the default setting); or the user can extend the time limit with a simple action — such as pressing a key or clicking a button — before time expires, and is warned at least 20 seconds in advance, with the option to extend at least ten times.

In practical terms, this criterion applies to any web interface that imposes a session timeout, an auto-advancing carousel with timed slides, a form that clears or submits automatically, a countdown timer on a checkout page, a media player with timed captions that cannot be paused, or any other mechanism that restricts the time a user has to complete a task. If your page or application sets a timer that, once expired, removes content, logs the user out, or advances them to a new state without their consent, you must offer a way to adjust or extend that limit.

The criterion also defines three important exceptions that may allow a time limit to remain without the adjustment mechanisms described above. First, the real-time exception: if the time limit is a required part of a real-time event (such as a live auction or a synchronous online exam), adjusting time would invalidate the activity itself, and no alternative is feasible. Second, the essential exception: if the time limit is essential and extending it would invalidate the activity — for example, a timed skills test where measuring response speed is the purpose. Third, the 20-hour exception: if the time limit is longer than 20 hours, the burden on users is considered minimal and adjustment controls are not required.

A pass occurs when a time-limited interaction provides a clear mechanism — ideally presented before the limit is encountered — that allows the user to disable, extend, or adjust the time constraint. A fail occurs when content automatically expires, redirects, logs out the user, or advances without offering any of the three adjustment options above, and none of the three exceptions apply.

Why It Matters

Time limits disproportionately affect people with disabilities. Users who rely on screen readers often navigate pages more slowly than sighted users, because they listen to content linearly and must explore unfamiliar interfaces sequentially. Users with motor impairments — including those using switch access devices, eye-tracking software, mouth sticks, or voice control software — may take significantly longer to fill in a form field, confirm a purchase, or navigate to the next step. Users with cognitive or learning disabilities, including dyslexia, attention-deficit conditions, or memory impairments, may need additional time to read, understand, and respond to instructions. Older adults also commonly need more time for the same tasks, and they represent a rapidly growing segment of the global internet population.

Consider a concrete real-world scenario: a person with cerebral palsy is completing a flight booking on a Turkish airline website. The checkout session automatically expires after five minutes of inactivity. The user, typing slowly with a head-pointer device, has entered their name, passport number, and payment details — and then the page reloads, clearing all data and returning them to the homepage. Not only has their effort been lost, but their confidence in the site is shaken, and they may be unable to complete the purchase at all. This is a direct barrier to equal participation in digital commerce.

The impact is broader than individual users. According to the World Health Organization, approximately 1.3 billion people globally live with some form of significant disability. In Turkey alone, official statistics from TÜİK indicate that over 8.5 million people have a disability that affects daily activities. Time-limited interfaces exclude a measurable portion of the potential user base of any web application.

Beyond accessibility, removing arbitrary time limits or making them adjustable also benefits users in low-bandwidth environments, users with temporarily impaired motor function (such as a broken arm), and users who are simply interrupted during a task. The usability improvements are broad and can reduce form abandonment rates, increase conversion rates on e-commerce sites, and lower customer support volumes.

Related Axe-core Rules

WCAG 2.2.1 requires manual testing. Automated tools — including axe-core, Lighthouse, and similar engines — cannot reliably detect timing violations because time limits are often implemented in server-side session logic, JavaScript that runs asynchronously, or third-party integrations. The tool has no way to observe that a page will expire in five minutes, or that a carousel will advance without user input, simply by inspecting the DOM or running static analysis. The following considerations explain what testers must evaluate manually.

• Session timeouts (manual): Testers must wait for or simulate a session timeout to determine whether the page presents an advance warning, offers an extension option, and provides at least 20 seconds for the user to respond. No automated rule can determine the session duration or whether a warning dialog appears in time without actually waiting through the timeout.
• Auto-advancing carousels and sliders (manual): Testers must observe whether carousels advance automatically and, if so, whether a pause or stop control is present and reachable by keyboard. Axe-core can detect some missing ARIA attributes on carousel components, but it cannot determine whether the timed advancement itself is adjustable.
• Auto-submitting or auto-clearing forms (manual): If a form submits or clears its content after a period of inactivity, a tester must identify this behavior by observation or code review. The DOM alone does not reveal this behavior to an automated scanner.
• Countdown timers in transactional flows (manual): Checkout pages, ticket-booking flows, and exam environments frequently include countdown timers. Whether these timers are essential (and thus exempt) or whether they require an extension mechanism is a judgment call requiring human review of both the implementation and the business context.

How to Test

1. Automated scan baseline: Run axe DevTools or Lighthouse against the page to identify any known ARIA or interactive element violations that might compound timing issues. Note that these tools will not flag the timing limit itself, but they help establish a baseline of other accessibility issues. In Chrome DevTools, open the Lighthouse panel, select Accessibility, and run the audit. In axe DevTools, activate the browser extension, click Analyze, and review results — no timing-specific rule will appear, confirming manual testing is required.
2. Identify all time limits: Review the page's JavaScript source, network requests, and server-side session configuration to identify every time limit. Common locations include setTimeout and setInterval calls in JavaScript, session expiry settings in backend frameworks, cookie expiration values, and third-party widget configurations such as payment processors or chat widgets.
3. Test session timeout warning with NVDA + Firefox: Open the site in Firefox with NVDA running. Navigate through a multi-step form or authenticated section. Wait for the session warning dialog (or the timeout itself if no warning appears). Verify that NVDA announces the warning automatically — ideally via a live region — and that the user can extend the session by pressing Enter or Space on a focused button without losing form data.
4. Test session timeout warning with VoiceOver + Safari (macOS/iOS): Repeat the above test on Safari with VoiceOver enabled. Use the rotor to navigate interactive elements and confirm that the timeout warning is announced and that the extension control is reachable within the 20-second window.
5. Test session timeout warning with JAWS + Chrome: Repeat with JAWS on Chrome. Confirm that focus is moved to the warning dialog, that JAWS reads the remaining time and the extension option, and that activating the extension button keeps the session alive without requiring a page reload.
6. Test with keyboard only (no screen reader): Disable your mouse and navigate entirely with Tab, Shift+Tab, Enter, and Space. Confirm that any warning dialog is reachable by keyboard, that the extension button is focusable, and that focus is returned to the correct location in the form after the session is extended.
7. Test carousel and media timing: Identify any auto-advancing carousels. Navigate to the carousel using Tab. Verify that a pause or stop button is present and reachable without a mouse. Activate it and confirm that advancement stops. If the carousel resumes after user interaction, confirm it does not resume automatically.
8. Verify exception applicability: For each time limit found, determine whether the real-time, essential, or 20-hour exception applies. Document your reasoning. If none of the exceptions apply and no adjustment mechanism exists, record this as a failure of WCAG 2.2.1.

How to Fix

Session Timeout Without Warning — Incorrect

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Session Timeout With Warning and Extension — Correct

<!-- Warn user 60 seconds before expiry; offer extension; announce via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Auto-Advancing Carousel Without Controls — Incorrect

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Auto-Advancing Carousel With Pause Control — Correct

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Timed Checkout Countdown With No Extension — Incorrect

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Timed Checkout Countdown With Extension Option — Correct

<!-- Warn before expiry and offer a one-click extension -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Common Mistakes

• Showing a timeout warning with no keyboard focus management: The warning dialog appears visually but focus is never moved to it, so keyboard-only and screen reader users never discover they can extend the session before it expires.
• Providing fewer than 20 seconds to respond to a timeout warning: Showing a "Session expiring" alert only 10 seconds before logout does not meet the criterion, which requires at least 20 seconds to be available for the extension action.
• Using role='alert' on a timeout dialog that requires interaction: An alert role is for read-only announcements; a dialog requiring user input should use role='alertdialog' with aria-modal='true' and aria-labelledby so that screen readers treat it as a modal requiring a response.
• Claiming the essential exception for a standard e-commerce cart timer: Reserving items in a shopping cart for 10 minutes is a business convenience, not a true essential activity where measuring speed is the purpose. Applying the essential exception here is incorrect; an extension mechanism is required.
• Auto-advancing a carousel without a visible, keyboard-reachable pause button: Adding a pause button that is only visible on hover, or that is absent from the Tab order, does not meet the criterion. The control must be reachable without a pointing device.
• Resetting the timeout counter on any mouse movement but not on keyboard events: JavaScript that extends the inactivity timer on mousemove events but ignores keydown or focus events will silently expire sessions for keyboard-only users who are actively working in the page.
• Extending the session via a full page reload: When a user clicks "Stay logged in," reloading the page clears any data the user had entered in forms. The extension should occur via an API call or cookie refresh in the background, preserving the DOM state.
• Using setTimeout values that are not configurable or exposed to the user: Hardcoding a session length of five minutes with no UI control for the user to choose a longer duration violates the criterion unless one of the three adjustment mechanisms (turn off, adjust, or extend) is available.
• Failing to test the timeout flow with actual assistive technologies before launch: Developers who test only with a mouse may not notice that the warning dialog is inaccessible to screen reader users, because sighted testing does not reveal focus management failures.
• Assuming third-party embedded widgets comply automatically: Payment processors, live chat widgets, and booking engines embedded via iframes or scripts often impose their own time limits. The responsibility for WCAG conformance of the full page — including embedded content you control — rests with the page owner.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements aligned with WCAG 2.2 Level AA for a broad range of public and private entities operating digital services in Turkey. WCAG 2.2.1 Timing Adjustable is a Level A criterion, which means it sits at the foundational layer of conformance — it is among the first requirements that covered entities must satisfy.

Under the circular, public institutions and agencies — including ministries, municipalities, universities, and state-owned enterprises — are required to achieve full conformance within one year of the circular's publication date. Private sector entities covered by the regulation have a two-year window to comply. The private sector scope is explicitly broad: it covers e-commerce platforms, banks and financial institutions, private hospitals and health service providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private passenger transport companies, and private schools operating under a Ministry of National Education (MoNE) authorization.

For organizations in these categories, a failure of WCAG 2.2.1 is not merely a best-practice shortcoming — it is a legal non-conformance that may attract regulatory scrutiny, complaints through official channels, and reputational harm. Consider the specific business flows most likely to trigger this violation: an e-commerce checkout with a timed cart reservation, an online banking session that silently expires while a customer fills in a payment form, a hospital appointment system that times out before a user with motor impairment can complete their registration, or a telecom provider's self-service portal that auto-logs users out of a contract management flow. Each of these is a plausible failure scenario within an entity type that is explicitly named in the circular.

Organizations should treat WCAG 2.2.1 compliance not as a technical checkbox but as a design requirement that must be addressed at the architecture level — in session management policies, third-party widget procurement requirements, and UI component standards — rather than retrofitted as an afterthought. Audit programs should include manual testing of all timed interactions, not just automated scans, precisely because automated tools cannot detect this class of violation without human observation.