The intent of this success criterion is to allow all users to complete authenticated transactions that have inactivity time limits or other circumstances that would cause a user to be logged out while in the midst of completing the transaction.
-For security reasons, many sites implement an authentication time limit after a certain period of inactivity. These time limits may cause problems for persons with disabilities - because it may take longer for them to complete the activity. + because it may take longer for them to complete the activity.
-Other sites will log a person out of a session if a person logs in on the website from another computer or if other activities arise that make the site suspicious of whether the person is still the same legitimate person who logged in originally. When users are logged out while still in the midst of a transaction - it is important that they be given the ability to re-authenticate and continue with the transaction without the loss of any data already entered. -
- - +Sites that implement session time limits and re-authentication requests are + still subject to the requirements of other criteria, such as + 2.2.1 Timing Adjustable. +
- Providing options to continue without loss of data using one of the following techniques: -
- +Providing options to continue without loss of data using one of the following techniques:
-Refer to +
Refer to Techniques for Addressing Success Criterion 2.2.1 for techniques related to providing notifications about time limits. -
-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 @@ -34,37 +33,30 @@
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. + 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.
- +Content that operates on a timer does not need to be time adjustable if there is an alternative that does not rely on a timer. For example, a web application such as an email client provides notification of new email arriving with a temporary message (such as a 'toast' message) in the lower right-hand side of the interface, and the message disappears after 5 seconds. Users are able to identify the arrival of email through other means, such as viewing the Inbox, so the disappearance of the message does not set a time limit on the their ability to determine if new mail has arrived. If the user has no other means of discovering the same information (or performing the same function), then each message would need to meet this success criterion in order to provide users with sufficient time to access the information.
-- - 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. -
- - + for the user (for example, granting double time on a test). + +See also 2.2.3: No Timing.
+