Definition for WCAG 2.0 success criterion 2.2.1
2.2.1 Timing Adjustable: 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
- Adjust: 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
- Extend: 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.
Note: 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, automatic log-out/end of session), 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 user's ability to read content.
Not all timers/time-outs are immediately obvious to identify as a tester. While some can be quite upfront and visible (such as a countdown clock present on the page), others may be invisible/behind-the-scenes (for instance, a JavaScript based timer that silently redirects the user back to the login page after a set period of inactivity, or a server-based session timeout on a form submission which only becomes apparent once a user attempts to submit a form, proceed to the next step in a process, etc.). If possible, testers should consult with the content developers directly to ask whether or not any hidden or server timeouts have been implemented in the system they are testing.
Where content features a time limit, some mechanism needs to be available for the user to extend, adjust the length, or completely remove the timer. For instance, some form of control to turn off/pause timers, a global option in the site/application settings, or displaying a dialog to the user at a reasonable time before the timer runs out to ask if they need more time (and this dialog needs to allow the user sufficient time to read and react to the dialog - per WCAG 2.0, this "sufficient time" would be 20 seconds, but of course this will vary depending on how complex/long the dialog is). 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.
Lastly, there is an exception for time limits that are longer than 20 hours. This threshold has been chosen as a "reasonable" cut-off point after which timeouts (for instance, the expiration of a browser session) are acceptable.
Note: in the case of auto-updating/scrolling content, there is overlap between this success criterion and 2.2.2 Pause, stop, hide (level A). Note that content that does auto-update or automatically scroll based on a time limit has to be assessed against both of these success criteria independently (meaning that there can be situations where content receives a pass for 2.2.1 but a fail for 2.2.2, or vice-versa).
Note: if a website/application does not have any time limits, this criterion is marked as not applicable.
Testing success criterion 2.2.1
Input into spreadsheet
- Fail
- Time limits are not adjustable. Record the nature of the failure:
- The timing is not essential, tied to a real-time event, or set to be less than 20 hours.
- There is no mechanism for users to turn off, adjust, or extend the time limit.
- Pass
-
- The time limit is either essential, tied to a real-time event, or set to be longer than 20 hours.
- A mechanism is available for the user to turn off, adjust, or extend the time limit.
- N/A
- The sample does not have any time limits.
How to test
-
Verify if the page contains a time limit; as noted in the description, this could be an obvious/visible feature of the page, such as:
- A countdown timer.
- Auto-updating content.
- Content that automatically scrolls.
-
Verify if the page contains a "hidden" client- or server-side timeout:
- If possible, consult with the content developer to ascertain if the latter type of timeouts is present.
-
Otherwise, open the page, wait for just under 20 hours, and verify that in that period:
- No content changed or scrolled.
- The browser was not redirected (e.g. back to the login page of the web application).
- In the case of forms, form submission is still possible.
-
Verify if either:
- The use of a time limit is essential, particularly if it is tied to a real-time event (e.g. an auction with a defined end time), or
- The time limit is longer than 20 hours (see above on how to verify this).
-
If the time limit is not essential/tied to a real-time event, and is less than 20 hours, verify if either:
- A mechanism is available for the user to pause or stop the time limit - for instance, this could be a pause/stop control, a global option in the web application's settings, or
- A mechanism is available for the user to adjust the time limit - this could be a global option in the web application's settings, or an option given to the user before they start a particular activity/process, or
- A mechanism is available for the user to extend the time limit - for instance, a few minutes before a time-out, a dialog is shown to the user asking them if they require more time.