Intent of Timing Adjustable
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.
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
- Timed server redirects can be found below under Common Failures.
- Non-timed server redirects (e.g., 3xx response codes) are not applicable because there
is no time limit: they work instantly.
- This Success Criterion applies only to time limits that are set by the content itself.
For example, if a time limit is included in order to address security concerns, it
would be considered to have been set by the content because it is designed to be
part of the presentation and interaction experience for that content. Time limits
set externally to content, such as by the user agent or by factors intrinsic to the
Internet are not under the author's control and not subject to WCAG conformance requirements.
Time limits set by Web servers should be under the author's/organization's control
and are covered. (Success Criteria
2.2.3,
2.2.4 and
2.2.5 may also apply.)
- Ten times the default was chosen based on clinical experience and other guidelines.
For example, if 15 seconds is allowed for a user to respond and hit a switch, 150
seconds would be sufficient to allow almost all users to hit a switch even if they
had trouble.
- 20 seconds was also based on clinical experience and other guidelines. 20 seconds
to hit 'any switch' is sufficient for almost all users including those with spasticity.
Some would fail, but some would fail all lengths of time. A reasonable period for
requesting more time is required since an arbitrarily long time can provide security
risks to all users, including those with disabilities, for some applications. For
example, with kiosks or terminals that are used for financial transactions, it is
quite common for people to walk away without signing off. This leaves them vulnerable
to those walking up behind them. Providing a long period of inactivity before asking,
and then providing a long period for the person to indicate that they are present
can leave terminals open for abuse. If there is no activity the system should ask
if the user is there. It should then ask for an indication that a person is there
('hit any key') and then wait long enough for almost anyone to respond. For "hit any
key," 20 seconds would meet this. If the person indicates that they are still present,
the device should return the user to the exact condition that existed before it asked
the question.
- 20 hours was chosen as an upper limit because it is longer than a full waking day.
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.1: No Timing.