For each time limit that is set by the content, at least one of the following is true:
The purpose of this checkpoint is to ensure that users with disabilities have adequate time to interact with Web content when possible. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations, may require additional time to read content or to perform functions, such as completing online forms. When faced with time-dependent Web functions, these users have difficulty performing the required action before reaching a time limit, which makes the service potentially inaccessible to them. By designing functions that are not time-dependent, developers can help people with disabilities complete these functions. By providing options to disable time limits, customize the length of time limits, or request more time before reaching a time limit, you can enable those users who require more time to successfully complete tasks. These options are listed with the most impactful appearing first: disabling time limits has a larger impact than customizing the length of time limits, which has a larger impact than requesting more time before reaching a time limit.
A time limit includes any process that occurs without user initiation after a set amount of time or on a periodic basis, such as 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. In addition, time limits include content that is advancing or updating at a rate beyond the user's ability to read and/or understand it, such as animated, moving or scrolling content that introduces a time limit on a user's ability to read content.
In some cases, however, changing the time limit is not possible (for example, during an auction or other real-time event) and, as a result, these cases are eligible for an exception.
To comply with this checkpoint, you must meet all of the following techniques. These techniques are defined in WCAG 2.0 Level A Success Criterion 2.2.1 (link resides outside of ibm.com).
- Change default time limit: Provide a means for the user to turn off, adjust, or extend the default time limit.
Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.
To comply with this technique, you must implement at least one of the following examples.
General example 1
Provide a means for the user to turn off the time limit. It is essential for the user to have a mechanism for turning off the time limit without a time limit itself and before the time at which the page expires. To accomplish this, place a mechanism at or near the top of the page to enable people with disabilities to find and activate it quickly.
An example is a Web page that contains a listing of news headlines that automatically update each minute and has a link that turns off the updating at the top of the page.
General example 2
Provide the user with a means to set the time limit up to 10 times the default time limit. An example is a Web-based email application that automatically logs users out after 30 minutes of inactivity. The application should include a preference that enables users to adjust the amount of time to any value.
General example 3
Provide a checkbox on the first page of a multipart form that enables users to set a longer session time limit or no session time limit. An example is a Web page that contains the first part of a five-part form. Immediately following the general instructions for completing the form, the Web page has a checkbox with the label, "Allow an additional 15 minutes to complete each part of this form."
General example 4
Allow the user to pause the content and restart from the point at which it was paused. Provide this mechanism either through interactive controls that conform to WCAG standards or through keyboard shortcuts. If using keyboard shortcuts, they must be documented.
An example is a Web site that contains a scrolling news banner at the top of the page. Users can press the Escape key to pause the scrolling and press Escape again to restart it.
General example 5
Do not cause a page to redirect to a new URL after a delay. When a redirect occurs after a time delay, it is an unexpected change of context that can confuse or interrupt the user.
The following code example is a failure of this checkpoint:
<title>Old page. Go to new URL</title>
content="10; url=http://w3-03.ibm.com/NewURL" />
If you are not automatically redirected to the new URL in 10 seconds select the link below.
<a href="url=http://w3-03.ibm.com/NewURL">New URL</a>
The following code example is the correct way to implement this technique:
<p>“This page has been moved to a new location: <a href=”url=http://w3.03.ibm.com/NewURL”>New URL</a></p>
For additional information, refer to WCAG 2.0 F40: Failure of Success Criterion 2.2.1 due to using meta redirect with a time limit (link resides outside of ibm.com).
Required unit tests for general development technique 1
Change default time limit: Provide a means for the user to turn off, adjust, or extend the default time limit.
To comply with this technique, you must implement all of the following examples.
Script example 1
Provide a dialog box that appears three minutes before the page access time limit expires and enable the user to extend the time by selecting a button.
For additional information, refer to the WCAG 2.0 examples for using scripts to warn users of an expiring time limit (link resides outside of ibm.com).
Note for iOS platform: Mobile Safari/VoiceOver does not currently support the WAI-ARIA
alertdialogroles. Therefore, VoiceOver does not announce dialogs when they are rendered. Additionally, Dojo mobile dialogs are not accessible because they do not contain the required WAI-ARIA dialog markup to make them accessible.
If teams choose to use the Dojo mobile dialogs without the required WAI-ARIA dialog markup, this checklist checkpoint must be answered “no” and a deviation must be filed.
After the Dojo team implements the proper WAI-ARIA markup in the mobile dialogs, teams may answer this checkpoint with a “yes” and are not required to file a deviation. Teams may want to follow the status of the Dojo mobile defect that addresses this issue. You may have to register as a member of the IBM Dojo Toolkit community at csnext in order to see the defect.
Note that when the proper WAI-ARIA markup is added to the Dojo mobile dialogs, VoiceOver will still not announce a dialog until Apple implements a fix for WAI-ARIA based dialogs. However, after the Dojo team implements WAI-ARIA in the Dojo dialogs, IBM will have fulfilled its responsibility to provide an accessible widget.
Script example 2
Provide a mechanism that enables users to display moving, scrolling, or auto-updating text in a static window or area. For example, an information box or marquee on ibm.com that scrolls a large block of text. A button allows the user to stop scrolling and display the entire block of text.
For additional information, refer to the WCAG 2.0 examples of using scripts to allow users to scroll or pause content (link resides outside of ibm.com).
Perform the following unit tests.
Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them because they can improve the accessibility and usability of the application. Refer to the WCAG 2.0 Additional Techniques (Advisory) for Success Criterion 2.2.1 (link resides outside of ibm.com) for a list of techniques and examples.
©2013 IBM Corporation
Last updated January 1, 2013.
W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com)
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.