Understanding Success Criterion 2.2.1: Timing Adjustable

Success Criterion 2.2.1 Timing Adjustable (Level A): For each time limit that is set by the content, at least one of the following is true:

Turn off

The user is allowed to turn off the time limit before encountering it; or


The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or


The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

Real-time Exception

The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

Essential Exception

The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception

The time limit is longer than 20 hours.

This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.


The intent of this Success Criterion is to ensure that users with disabilities are given adequate time to interact with Web content whenever possible. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out on-line forms. If Web functions are time-dependent, it will be difficult for some users to perform the required action before a time limit occurs. This may render the service inaccessible to them. Designing functions that are not time-dependent will help people with disabilities succeed at completing these functions. Providing options to disable time limits, customize the length of time limits, or request more time before a time limit occurs helps those users who require more time than expected to successfully complete tasks. These options are listed in the order that will be most helpful for the user. Disabling time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs.

Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, page refresh), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.

This success criterion is generally not applicable when the content repeats or is synchronized with other content, so long as the information and data is adjustable or otherwise under the control of the end user. Examples of time limits for which this success criterion is not applicable include scrolling text that repeats, captioning, and carousels. These are situations which do include time limits, but the content is still available to the user because it has controls for accessing it, as specified in 2.2.2 Pause, Stop, Hide.

In some cases, however, it is not possible to change the time limit (for example, for an auction or other real-time event) and exceptions are therefore provided for those cases.

Notes regarding server time limits

In cases where timing is not an intrinsic requirement but giving users control over timed events would invalidate the outcome, a third party can control the time limits for the user (for example, granting double time on a test).

See also 2.2.3: No Timing.




Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If there are session time limits:

  1. G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit
  2. G198: Providing a way for the user to turn the time limit off

Situation B: If a time limit is controlled by a script on the page:

  1. G198: Providing a way for the user to turn the time limit off
  2. G180: Providing the user with a means to set the time limit to 10 times the default time limit
  3. SCR16: Providing a script that warns the user a time limit is about to expire AND SCR1: Allowing the user to extend the default time limit
  4. SL21: Replacing A Silverlight Timed Animation With a Nonanimated Element

Situation C: If there are time limits on reading:

  1. G4: Allowing the content to be paused and restarted from where it was paused
  2. G198: Providing a way for the user to turn the time limit off
  3. SCR33: Using script to scroll content, and providing a mechanism to pause it
  4. SCR36: Providing a mechanism to allow users to display moving, scrolling, or auto-updating text in a static window or area


The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

Key Terms


if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform