WCAGvsTEITACvs2010ANPRM



***************NOTICE************************************************ 
                                                                                                       
  This work space is being phased out and is no longer kept        
  updated with the latest task force agreements. Please refer to  
  the most recent WCAG2ICT public draft at                                 
  http://www.w3.org/TR/wcag2ict/                                                  
                                                                                                       
************************************************************************* 


Side-by-side comparison of WCAG 2.0 Success Criteria and provisions from TEITAC report and U.S. Access Board 2010 ANPRM text.
Source WCAG 2.0 Success Criteria (11 December 2008) Teitac Report (3 April 2008) 2010 ANPRM Text (22 March 2010) IBM comments on 2011 ANPRM, Appendix A (p. 21, 6 March 2012)
Disclaimer:  Section 508 authorizes the Access Board to provide technical assistance to individuals and Federal departments and agencies concerning the requirements of this section.  This technical assistance is intended solely as informal guidance and is not a determination of the legal rights or responsibilities of entities subject to section 508.
URL http://www.w3.org/TR/WCAG20/ http://www.access-board.gov/sec508/refresh/report/ http://www.access-board.gov/sec508/refresh/draft-rule2010.htm http://www.regulations.gov/#!documentDetail;D=ATBCB-2011-0007-0047
1.1.1 Non-text Content:  All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.  (Level A)
  • Controls, Input:  If non-text content is a control or accepts user input, then it has a name that describes its purpose.  (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media:  If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content.  (Refer to Guideline 1.2 for additional requirements for media.)
  • Test:  If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory:  If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA:  If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible:  If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
3-F: Non-text Objects
All NON-TEXT OBJECTS that are presented to the user must have a TEXT alternative that presents equivalent information, except for the situations listed below.
  1. Controls-Input: If a NON-TEXT OBJECT is a control or accepts user input, then it must have a name that describes its purpose.  (See also User Interface Components provisions.)
  2. Media: If a NON-TEXT OBJECT is SYNCHRONIZED MEDIA, live audio-only or live video-only CONTENT, then text alternatives must at least provide a descriptive LABEL that identifies the NON-TEXT OBJECT.  (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
  3. Test: If a NON-TEXT OBJECT is a test or exercise that must be presented in non-text format, then text alternatives must identify at least the NON-TEXT OBJECT with a descriptive text LABEL.  (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
  4. Sensory: If a NON-TEXT OBJECT is primarily intended to create a specific sensory experience, then text alternatives must identify at least the NON-TEXT OBJECT with a descriptive text LABEL.  (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
  5. CAPTCHA: If the purpose of a NON-TEXT OBJECT is to confirm that CONTENT is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the NON-TEXT OBJECT must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
  6. DECORATION, Formatting, Invisible Objects: If a NON-TEXT OBJECT is pure DECORATION, or used only for visual formatting, or if it is not presented to users, then it must be implemented such that it can be ignored by ASSISTIVE TECHNOLOGY.
Note:  In order to satisfy this provision, non-text objects in data operated on by the software would need to be associated with textual equivalents that the software can obtain as readily as it can obtain the non-text object itself. Where a non-text object is a scanned image of text, textual equivalents would need to allow for the inclusion of the text of the scanned image of text. Where a non-text object is a dynamic presentation, graphs, or other derived information from a data source, textual equivalents would need to allow for the inclusion of the data used.
502 Non-Text Content
502.1 General.  When ICT provides non-text content, the non-text content shall conform to 502.
502.2 Text Alternatives.  When non-text content is provided, text alternatives for the non-text content shall conform to 502.2.1 or 502.2.2.
502.2.1 Equivalent Purpose.  When non-text content is provided, text alternatives for the non-text content shall serve the equivalent purpose.
502.2.1.1 Images of Text.  When non-text content is images of text, the text alternative shall be the text in the image.
502.2.1.2 Controls or Inputs.  When non-text content is a control or accepts user input, the non-text content shall have a name that describes its purpose.
502.2.1.3 Decoration, Formatting, or Invisible.  When non-text content is pure decoration, is used only for visual formatting, or is not presented to users, the non-text content shall be implemented in a way that can be ignored by assistive technology.
502.2.2 Descriptive Identification.  When non-text content is provided, text alternatives for the non-text content shall conform to 502.2.2.1 through 502.2.2.4, as applicable to the type of non-text content.
502.2.2.1 Audio or Video.  When non-text content is audio or video content, text alternatives shall provide descriptive identification of the non-text content.
502.2.2.2 Test or Exercise.  When non-text content is a test or exercise that would be invalidated if presented in text, text alternatives shall provide descriptive identification of the non-text content.
502.2.2.3 Sensory Experience.  When non-text content is primarily intended to create a specific sensory experience, text alternatives shall provide descriptive identification of the non-text content.
502.2.2.4 CAPTCHA.  When the purpose of non-text content is to confirm that the content is being accessed by a person rather than a computer, text alternatives that identify and describe the purpose of the non-text content shall be provided.
402.3 Alternate CAPTCHA.  When a CAPTCHA is provided, an alternative form of CAPTCHA using an output mode for a different type of sensory perception shall be provided.

1.2.1 Audio-only and Video-only (Prerecorded):  For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:  (Level A)
  • Prerecorded Audio-only:  An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
  • Prerecorded Video-only:  Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
5-A: Captions and Transcripts
Materials containing video and/or audio, regardless of format, that contain speech or other audio information necessary for the comprehension of the CONTENT, must comply with the following:
  1. Materials containing prerecorded audio information, and no original video or other additional time-based CONTENT must provide a separate transcript of the audio information.
  2. Materials containing prerecorded video with concurrent audio information must provide synchronized CAPTIONS.
  3. Materials containing real-time audio, with or without video, must provide synchronized real-time CAPTIONS.
Note:  At the time of playback, captions must be either (a) capable of being turned on and off (“closed”), or (b) visible or audible to all users (“open”).
603 Captions and Transcripts for Audio Content
603.1 General.  Regardless of format, materials containing audio content, or video with audio content, shall conform to 603.
603.2 Pre-recorded Audio Content with No Video Content or User Interaction.  Materials containing pre-recorded audio content, and no video content or user interaction, shall provide a transcript of the content.
603.2.1 Transcript.  When a separate transcript is provided, the text shall conform to Chapter 5 (Electronic Documents).
604 Video Description and Transcripts for Video Content
604.1 General.  Regardless of format, materials containing video content, with or without audio content, shall conform to 604.
604.2 Pre-recorded Video Content with No Audio Content or User Interaction.  Materials containing pre-recorded video content and no audio content or user interaction, shall provide either a separate transcript or an equivalent audio alternative.
604.2.1 Transcript.  When a separate transcript is provided electronically, the text shall conform to Chapter 5 (Electronic Documents).

1.2.2 Captions (Prerecorded):  Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.  (Level A) See 5-A above corresponding to SC 1.2.1. 603.3 Pre-recorded Audio Content with User Interaction.  Materials containing pre-recorded audio content with user interaction shall provide synchronized captions.
603.4 Pre-recorded Video Content with Synchronized Audio Content.  Materials containing pre-recorded video content with synchronized audio content shall provide synchronized captions.

1.2.3 Audio Description or Media Alternative (Prerecorded):  An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.  (Level A) 5-B: Video Description
Materials containing video and/or audio, regardless of format, that contain visual information necessary for the comprehension of the CONTENT, must comply with the following:
  1. Materials containing prerecorded video and no original audio or other additional time-based CONTENT must provide either a separate TEXt description of the video or provide an additional audio track to convey the informational CONTENT of the video.
  2. When the visual informational CONTENT is not conveyed through other means, materials containing prerecorded video with concurrent audio must provide synchronized VIDEO DESCRIPTIONS, or when space is not available in the main program audio for synchronized VIDEO DESCRIPTIONS, a separate TEXT description of the video CONTENT must be provided.
  3. Materials containing live video must provide synchronized VIDEO DESCRIPTIONS in real time to convey any informational CONTENT of the video that is not conveyed through other means.
Note:  At the time of playback, video descriptions must be either (a) capable of being turned on and off (“closed”), or (b) visible or audible to all users (“open”).
604.3 Pre-recorded Video with Synchronized Audio Content.  Materials containing pre-recorded video with synchronized audio content shall provide video description.
1.2.4 Captions (Live):  Captions are provided for all live audio content in synchronized media.  (Level AA) See 5-A above corresponding to SC 1.2.1. 603.5 Real-Time Video Content.  Materials that contain real-time video content with audio information shall provide synchronized captions.
EXCEPTION:  When real-time video is unattended and has the primary purpose of conveying a visual experience, and a text alternative that provides descriptive identification is provided, synchronized captions shall not be required.

1.2.5 Audio Description (Prerecorded):  Audio description is provided for all prerecorded video content in synchronized media.  (Level AA) See 5-B above corresponding to SC 1.2.3.  N.B., at Level AA, SC 1.2.5 superceeds SC 1.2.3. See 604.3 above corresponding to SC 1.2.3.  N.B., at Level AA, SC 1.2.5 superceeds SC 1.2.3.
1.3.1 Info and Relationships:  Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.  (Level A) 3-O: Information and Relationships
Information and relationships conveyed through presentation of electronic documents must be either PROGRAMMATICALLY DETERMINABLE or available in TEXT, and notification of changes to these must be available to user agents, including assistive technologies.
For example:
  1. Row and column headers are identified for data tables.
    Note:  In order to achieve this provision, table objects in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table, that the software can obtain as readily as it can obtain the table itself.
  2. In data tables that have two or more logical levels of row or column headers, data cells are associated with header cells.
    Note: In order to achieve this provision, cells in table objects with multiple logical levels of headers in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table cell, that the software can obtain as readily as it can obtain the table cell itself.
  3. Section headings are identified.
  4. Form element LABELS are associated with form fields.
503 Adaptable Presentation of Content
503.1 General.  Content shall conform to 503.
503.2 Information, Structure and Relationships.  Information, structure, and relationships presented visually to the user shall be programmatically determinable or be available in text.
503.2.1 Data Tables.  When data tables are provided, data tables shall conform to 503.2.1.1 and 503.2.1.2.
503.2.1.1 Data Tables.  Row and column headings shall be programmatically determinable.
503.2.1.2 Multi-Level Tables.  When data tables have two or more logical levels of row or columns headings, associations between data cells and heading cells shall be programmatically determinable.
503.2.2 Forms.  When forms are provided, labels associated with form fields shall be programmatically determinable.
503.2.3 Section Headings.  When content is divided into sections, section headings shall be programmatically determinable.

1.3.2 Meaningful Sequence:  When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.  (Level A) 3-M: Reading Sequence
When the sequence in which information is presented affects its meaning, a reading sequence that conveys the intended meaning must be PROGRAMMATICALLY DETERMINABLE. The navigation sequence must be consistent with the reading sequence.
Note 1:  In order to achieve this provision, objects in data operated on by the software that can be presented in 2 dimensions, would need to be associated with sufficient information to identify a logical one dimensional presentation of the same objects, that the software can obtain as readily as it can obtain the 2 dimensional objects themselves.
Note 2:  For products with closed functionality the visual and (linear) audible presentation should match navigation
503.3 Logically Correct Reading Sequence.  When the sequence in which content is presented affects its meaning, a logically correct reading sequence shall be programmatically determinable. Software that is a part of a closed product shouldn’t have any requirement for programmatic information, as there is no assistive technology that can be attached to or installed on this class of ICT.  In this case, the information a user needs to know to operate the closed product must be presented to the user through a means that meets the Functional Performance Criteria.
1.3.3 Sensory Characteristics:  Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.  (Level A)
Note:  For requirements related to color, refer to Guideline 1.4.
3-C: Size, Shape, Location
Instructions provided for understanding information and operating on-screen user interfaces must not rely solely on shape, size, visual location, or orientation of components.
Note:  Object information provided per the “Information and Relationships”, “User Interface Components”, or “AT interoperability” provision that describes the necessary visual cues or relationships can be used to meet this provision.
Example:  Rather than saying “When done press the button to the right,” say “When done press the Submit button.”
503.4 Sensory Characteristics.  Instructions provided for understanding and operating content shall not rely solely on those characteristics of components perceived through the senses of hearing or vision, such as shape, size, visual location, orientation, or sound. For closed products, physical buttons used in the user interface (UI) often need to be explained according to their size, shape, visual location and/or orientation.  This is often the only means of providing the user with the appropriate information to use the physical buttons on the ICT.  Therefore, this requirement would need clarification for how it would only be applicable to the software portions of the closed product’s user interface.
1.4.1 Use of Color:  Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.  (Level A)
Note:  This success criterion addresses color perception specifically.  Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
3-A: Color
Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Example:  A conforming example is mandatory form fields are identified with colored TEXT and labeled as “Required.”
305 Color
305.1 Not Only Color.  ICT shall not use color as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

1.4.2 Audio Control:  If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.  (Level A)
Note:  Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
3-L: Audio Turnoff
When any audio plays automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume that can be set to be a different level from the system volume level. This provision does not apply to emergency messages regarding risk of personal injury or loss of property or data, or to audio messages required by law.
Note 1:  This provision may be met with a mechanism in a product, user agent or platform.
Note 2:  For web and software applications, if the total duration of the audio does not exceed 3 seconds, including any repeats of the audio, this provision does not apply.
403 Distinguishable Content
403.1 General.  ICT that contains audio or text content shall conform to 403.
403.2 Audio Control.  ICT containingaudio that plays automatically for more than three seconds shall conform to either 403.2.1 or 403.2.2.
403.2.1 Pause or Stop Audio.  A mode of operation shall be available to pause or stop audio.
403.2.2 Independent Volume Control.  A mode of operation shall be available to control audio volume independently from the overall platform volume.

1.4.3 Contrast (Minimum):  The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:  (Level AA)
  • Large Print:  Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental:  Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes:  Text that is part of a logo or brand name has no minimum contrast requirement.
3-B: Contrast
Presentation of TEXT, and images of TEXT, in electronic documents must have a CONTRAST RATIO of at least 5:1, except for the following:
  1. Large Print:  LARGE SCALE TEXT and images of LARGE SCALE TEXT must have a CONTRAST RATIO of at least 3:1;
  2. Incidental:  TEXT or images of text that are part of an inactive user interface component, that are pure DECORATION, that are incidental TEXT in an image, or that are not visible to anyone, have no minimum contrast requirement.
504 Distinguishable Presentation of Text Content
504.1 General.  Text content or images of text content shall conform to 504.
504.2 Text and Images of Text Contrast Ratio.  The visual presentation of text and images of text shall conform to 504.2.1 or 504.2.2.
Exception:  When the visual presentation of text or images of text are part of an inactive user interface component, are pure decoration, are not presented to users, are part of a picture that contains significant other visual content, or are part of a logo or brand name, there is no contrast requirement.
504.2.1 Large-Scale Text Contrast Ratio.  Large-scale text and images of large-scale text shall have a contrast ratio of at least 3:1.
504.2.2 Text Contrast Ratios.  Text and images of text that are not large scale text shall have a contrast ratio of at least 4.5:1.

1.4.4 Resize text:  Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.  (Level AA) N/A 403.3 Resizable Text.  ICT shall support the ability to resize text content up to 200 percent without loss of content or functionality and without relying upon assistive technology.
EXCEPTION:  Images of text, including text used for captioning, are not required to support the ability to be resized.

1.4.5 Images of Text:  If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:  (Level AA)
  • Customizable:  The image of text can be visually customized to the user’s requirements;
  • Essential:  A particular presentation of text is essential to the information being conveyed.
Note:  Logotypes (text that is part of a logo or brand name) are considered essential.
N/A N/A
2.1.1 2.1.1 Keyboard:  All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.  (Level A)
Note 1:  This exception relates to the underlying function, not the input technique.  For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note 2:  This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
3-S: Keyboard Operation
Where products have a KEYBOARD or a KEYBOARD INTERFACE, or run on a device that has a KEYBOARD or KEYBOARD INTERFACE, all functionality of the product operable through the electronic user interface must be operable through the KEYBOARD, or a KEYBOARD INTERFACE.  Specific timing for individual keystrokes must not be required.  This provision does not apply where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints.
Note 1:  This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.
Note 2:  The exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note 3:  Keyboard interface can be either a hardware keyboard interface, a wireless interface or a software keyboard interface where AT can generate keystrokes that would be seen by software.
Note 4:  For platform software, this includes the ability to move the keyboard focus into and out of applications.
404 Keyboard Operation
404.1 General.  ICT that accepts user input shall conform to 404.
404.2 Keyboard Interface.  All functionality of the ICT shall be operable through a keyboard interface without requiring specific timings for individual keystrokes.
EXCEPTIONS:  1.  When the underlying function requires input that depends on the path of a user’s movement, and not just the endpoints of the movement, a keyboard interface shall not be required.
2.  When the underlying function requires voice input, and voice operation that does not require user vision is provided, a keyboard interface shall not be required.
This provision needs significant interpretation on mobile platforms where the keyboard interface is not the common device independent method for operating user interfaces.

The difficulty is in native software on platforms that don’t have keyboards such as the latest generation of smart phones and tablets.  These devices have on-screen keyboards for entering data and most support data entry via some type of external physical keyboard.  They fall short, however, in providing a keyboard interface for full operation of an application.  For
example, they don't support the concept of moving keyboard focus to an object in order to interact with it. Rather, operation is via gestures – touch, swipe, pinch, etc.  Accessibility for users who can't see or can’t physically perform the gestures may be supported by providing an alternative to the gesture based mode of operation.  For example, blind users are provided an alternative interface that, combined with audio output, allows them to explore the objects and data displayed on the screen without activating them and then to use special gestures to activate or interact with them.  Users with physical impairments may be able to redefine the gestures to something that they can perform.
2.1.2 No Keyboard Trap:  If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.  (Level A)
Note:  Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.  See Conformance Requirement 5: Non-Interference.
Level A WCAG guidelines not included:
  • 2.1.2 No Keyboard Trap
404.3 No Trapping of the Keyboard Focus Cursor.  When the keyboard focus can be moved to a component of ICT using a keyboard interface,  a mode of operation shall be provided to move the keyboard focus away from that component using only a keyboard interface.
404.3.1 Exit Method.  The ICT shall provide an exit method that conforms to either 404.3.1.1 or 404.3.1.2 for moving the keyboard focus away from a component.
404.3.1.1 Standard Exit Method.  ICT shall use the standard exit method or standard navigation keys for the platform.
404.3.1.2 Non-standard Exit Method.  The ICT shall provide instruction of the non-standard exit method to the user.

2.2.1 Timing Adjustable:  For each time limit that is set by the content, at least one of the following is true:  (Level A)
  • 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.
3-R: Timing
For each time limit that is set by the product, at least one of the following must happen:
  1. Turn off: the user is allowed to turn off the time limit before encountering it; or
  2. 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
  3. 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, "hit any key"), and the user is allowed to extend the time limit at least ten times.
There are three exceptions:
  1. 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
  2. Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
  3. 20 Hour Exception: the time limit is longer than 20 hours.
405 Time Limits
405.1 General.  ICT that contains time based content shall conform to 405.
405.2 Control over Time Limits.  ICT shall provide a mode of operation that conforms to one of 405.2.1 through 405.2.3.
EXCEPTIONS:  1.  When the time limit is essential and user modification of the time limit would invalidate the activity, no user control over the default time limit is required.
2.  When the time limit is a required part of a real-time event and no alternative to the time limit is possible, no user control over the default time limit is required.
3.  When the time limit is at least eight hours, no user control over the default time limit is required.
405.2.1 Turn Off.  Before encountering a time limit, a mode of operation shall be provided for the user to turn off the time limit.
405.2.2 Adjust.  Before encountering a time limit, a mode of operation shall be provided for the user to adjust the time limit to at least ten times the length of the default time limit.

2.2.2 Pause, Stop, Hide:  For moving, blinking, scrolling, or auto-updating information, all of the following are true:  (Level A)
  • Moving, blinking, scrolling:  For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
  • Auto-updating:  For any auto-updating information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Note 1:  For requirements related to flickering or flashing content, refer to Guideline 2.3.
Note 2:  Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.  See Conformance Requirement 5: Non-Interference.
Note 3:  Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
Note 4:  An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users, and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
3-I: Pausing
A mechanism must be provided to pause moving, BLINKING, or scrolling information that lasts for more than three seconds unless it is part of an activity where the moving, BLINKING, or scrolling is essential.
A mechanism must be provided to pause auto-updating information, or allow the user to control the frequency of the update, unless it is part of an activity where auto-updating is essential.
A mechanism must be provided to either pause, stop, or hide moving or BLINKING CONTENT that is pure DECORATION.
405.3 Control over Moving, Blinking, or Scrolling Information, and Automatic Updates.  Moving, blinking, or scrolling information, and automatically updating information shall conform to 405.3.1 or 405.3.2 as applicable.
EXCEPTIONS:  1. Moving, blinking, or scrolling information, and automatically updating information that is an essential part of an activity shall not be required to conform to 406.4.
2.  Moving, blinking, or scrolling information, and automatically updating information that does not start automatically shall not be required to conform to 405.3.
3.  Moving, blinking, or scrolling information, and automatically updating information that is not presented at the same time and in the same location as other content  shall not be required to conform to 405.3.

2.3.1 Three Flashes or Below Threshold:  Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.  (Level A)
Note:  Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.  See Conformance Requirement 5: Non-Interference.
3-J: Flashing (Content and User Interfaces)
CONTENT or user interfaces must not contain anything that FLASHES more than 3 times in any one second period or the FLASHING must be below the GENERAL FLASH AND RED FLASH THRESHOLDS FOR CONTENT AND USER INTERFACES.
306 Flashing
306.1 Flash Threshold.  When ICT emits lights in flashes, there shall be no more than three flashes in any one second period.
EXCEPTION:  Flashes that do not violate the general flash or red flash thresholds are not required to conform to 306.

2.4.1 Bypass Blocks:  A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.  (Level A) Level A WCAG guidelines not included:
  • 2.4.1 Bypass Blocks
406 Navigation
406.1 General.  ICT shall conform to 406.
406.2 Bypass Blocks of Content.  A mode of operation shall be provided for the user to bypass blocks of content that are repeated within an ICT product.
How can this be applied to a software application or to a platform?  Is “content” to be interpreted to mean “user interface components”, where things like toolbars/ribbons are considered “blocks” that one should be able to skip over (e.g. with a hot-key for bringing focus to the content region when focus might be on a specific toolbar item)?

How can this requirement be applied to documentation content such as help text or other display of content where there may be blocks of content repeated among sets of documents?  Is there some other meaning?
2.4.2 Page Titled:  Web pages have titles that describe topic or purpose.  (Level A) Level A WCAG guidelines not included:
  • 2.4.2 Page Titled
505 Navigation and Orientation
505.1 General.  Content shall conform to 505.
505.2 Document Titles.  Documents shall have titles that describe topic or purpose.
What should a “web page” mean in the context of a software application; should it mean a window or dialog box?  In the case of a mobile application would a “web page” be interpreted as a screen? Alternatively, does it mean that blocks of user interface components (e.g. radio button groups) have to have titles?  If the latter, is
this required in all cases, or only when there are a sufficient number of items in the group?  In addition, must titles always be visible on the screen, or is it sufficient to make them available to assistive technologies (so as to not consume precious screen real estate on small screens like mobile phones)?
2.4.3 Focus Order:  If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.  (Level A) Level A WCAG guidelines not included: 
  • 2.4.3 Focus Order
406.3 Focus Order.  When content can be navigated sequentially and the navigation sequences affect meaning or operation, components that are capable of receiving focus shall receive focus in an order that preserves meaning and operation.
2.4.4 Link Purpose (In Context):  The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.  (Level A) 3-N: Link Purpose
On Web pages, it must be possible to determine the purpose of each link from the link TEXT or the link TEXT together with its PROGRAMMATICALLY DETERMINABLE link context.
Note:  In order to meet this provision, links encoded in data operated on by the software would need to be associated with link text that the software can obtain as readily as it can obtain the link itself.
505.3 Link Purpose.  The purpose of each link shall be determinable from the link text alone, or from the link text together with its programmatically determined link context.
EXCEPTION:  When the purpose of a link is ambiguous to users in general, the purpose of that link shall not be required to conform to 505.3.
Should this criterion only apply to hyperlinks in software applications, or should it also be applied to other UI components (e.g. menus, buttons, edit text fields, checkboxes)? If the latter, which situations with UI components should it apply to?
2.4.5 Multiple Ways:  More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.  (Level AA) 3-W: Multiple Ways
There must be more than one way available to locate CONTENT within a set of Web pages where CONTENT is not the result of, or a step in, a process.  For example, providing a site map, index, table of contents, or search would be sufficient.
406.4 Multiple Ways to Locate Content.  More than one way shall be provided for a user to locate content within ICT.
EXCEPTION:  When the content is the result of, or a step in a process, more than one way for a user to locate content is not required.
What does this mean in the context of a software application?  Is a “Web page” equivalent to an application, a window within the application or some text in a window?  Does “a set of Web pages” mean the application, a suite of applications (e.g. an office suite), or the entire set of applications on the computer?  If this is about finding an individual application among a set of applications (e.g. using Windows -> Start menu -> Find as one way and locating it underneath the Programs folder being another way), how can an individual application be seen as meeting or not meeting this criterion?  Is this requirement instead more along the lines of applying only to a feature within an application, or maybe a specific window within an application?
2.4.6 Headings and Labels:  Headings and labels describe topic or purpose.  (Level AA) 3-BB: Headings and Labels
Headings and LABELS must describe the topic or purpose.
Note:  Labels and headings do not need to be lengthy. A word or even a single character may suffice if it provides an appropriate cue to finding and navigating content.
505.4 Descriptive Headings and Labels.  When supported by the technology and appropriate to the task, headings and labels shall describe topic or purpose.
2.4.7 Focus Visible:  Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.  (Level AA) 3-T: Focus Indicator
Any KEYBOARD operable user interface must support a mode of operation where the indication of KEYBOARD focus has a high degree of visibility.
Note 1:  The presence of a highly visible text insertion point is sufficient for a text area.
Note 2:  A focus cursor that is visually locatable at 3.5 times the typical viewing distance without moving the cursor by people who have unimpaired vision and are familiar with what the focus cursor looks like is sufficient. For example, when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, a focus cursor that is visually locatable at 2.5 meters without moving the cursor by people who are familiar with what the cursor looks like and have unimpaired vision is sufficient.
Note 3:  This can be provided by the interface itself or by the interface in combination with focus services provided by the platform.
404.5 Visible Keyboard Focus Indicator.  A mode of operation shall be provided so  the keyboard focus indicator is visible.
3.1.1 Language of Page:  The default human language of each Web page can be programmatically determined.  (Level A) 3-G: Human Language
When supported in the technologies of electronic documents, the default human language of electronic document must be PROGRAMMATICALLY DETERMINABLE.
Note:  In order to achieve this provision, text encoded in data operated on by the software would need to be associated with sufficient information to identify both the primary language of the text, and the language of any sections or the text that are in another language from the primary language, that the software can obtain as readily as it can obtain the text itself.
506 Readability
506.1 General.  Text content shall conform to 506.
506.2 Language of Document.  The default human language of each document shall be programmatically determinable.

3.1.2 Language of Parts:  The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.  (Level AA) 3-H: Language of Parts
When supported in the technology of electronic documents, the human language of each passage or phrase in electronic documents must be PROGRAMMATICALLY DETERMINABLE.
506.3 Language of Passage or Phrase.  When supported by the technology, the human language of each passage or phrase in the content shall be programmatically determinable.
EXCEPTION:  The human language for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text, shall not be required to be programmatically determinable.

3.2.1 On Focus:  When any component receives focus, it does not initiate a change of context.  (Level A) 3-Y: On Focus
When any component in CONTENT or electronic documents receives focus through navigation by KEYBOARD or other keypads, it must not initiate a change of context.
407 Predictability
407.1 General.  ICT shall conform to 407.
407.2 No Change of Context from Focus.  When any component receives focus, the component shall not initiate a change of context.

3.2.2 On Input:  Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.  (Level A) 3-Z: On Input
Changing the setting of any user interface component in web pages must not automatically cause a change of context unless the user has been advised of the behavior before using the component.
407.3 No Change of Context from Change of Settings.  Changing the setting of any user interface component shall not automatically cause a change of context.
EXCEPTION:  When advance notice of a potential change in context is provided before a user activates any component which will change user interface settings, conformance with 407.3 shall not be required.

3.2.3 Consistent Navigation:  Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.  (Level AA) N/A 407.4 Consistent Navigation Order.  When navigation mechanisms are repeated within an ICT product, they shall occur in the same relative order each time they are repeated.
Exception:  When a change to the navigation mechanism is initiated by the user, conformance to 407.4 shall not be required.
What does this mean in the context of a software application?  Is a “set of Web pages” the different windows of a single application or of a suite of applications (e.g. an office suite)?  What constitutes a “navigation mechanism” - a menu, a table of contents, the keystrokes for operating the same kinds of UI components?  Should this be applied to the conventions for opening/closing windows such as ESC to close a window, ENTER to dismiss a dialog using the default action, having the default action be consistent (the default always being OK vs. Cancel)?
3.2.4 Consistent Identification:  Components that have the same functionality within a set of Web pages are identified consistently.  (Level AA) 3-K: Consistent Identification
Components from a single source that have the same functionality within a product must be identified consistently.
407.5 Consistent Identification.  Components that have the same functionality within an ICT product shall be identified consistently.
3.3.1 Error Identification:  If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.  (Level A) 3-AA: Error Identification
If an input error is automatically detected in CONTENT or electronic documents, the item that is in error must be identified and described to the user in TEXT.
408 Input Assistance
408.1 General.  ICT shall conform to 408.
408.2 Input Error Identification and Description.  When an input error is automatically detected, the item that is in error shall be identified, and the error shall be described to the user in text.

3.3.2 Labels or Instructions:  Labels or instructions are provided when content requires user input.  (Level A) 3-X: Labels or Instructions
LABELS or instructions must be provided when CONTENT requires user input.
408.3 Labels or Instructions.  When content requires user input, labels or instruction shall be provided.
3.3.3 Error Suggestion:  If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.  (Level AA) Recommendations for Additional Advisory Notes:
Add an advisory note regarding the input from SSA on 3-AA regarding a best practice for a method to navigate to the error should be provided.  This is also a reference to WCAG 2.0-3.3.3 Error suggestion (Level AA).
N/A
3.3.4 Error Prevention (Legal, Financial, Data):  For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:  (Level AA)
  1. Reversible:  Submissions are reversible.
  2. Checked:  Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  3. Confirmed:  A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
Advisory Note 3. Interaction Guidelines:
Applications should include user interactions that are accessible for people with disabilities including:
  1. Provide a means to undo actions, such as by resetting the form to the original information.
  2. Provide a way to move backwards one step in a process to fix mistakes or check answers or cancel actions before final submission.
N/A
4.1.1 Parsing:  In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.  (Level A)
Note:  Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.
Advisory Note 4. Parsing:
CONTENT implemented using markup languages should have elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.
508 Compatible Technologies
508.1 General.  Content shall conform to 508.
508.2 Markup Language Used According to Specification.  Content that is implemented using markup languages shall conform to 508.2.1 through 508.2.4.
508.2.1 Tags.  Elements shall have complete start and end tags.
508.2.2 Nesting.  Elements shall be nested according to their specifications.
508.2.3 No Duplicate Attributes.  Elements shall not contain duplicate attributes.
508.2.4 Identity.  When identity attributes are used, identity values shall be unique unless the specifications allows for duplication.

4.1.2 Name, Role, Value: For all user  interface components (including but not limited to:  form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.  (Level A)
Note:  This success criterion is primarily for Web authors who develop or script their own user interface components.  For example, standard HTML controls already meet this success criterion when used according to specification.
3-P: User Interface Components (no consensus)
Version 1
For all user interface components, including form elements and those generated by scripts, the name and role must be PROGRAMMATICALLY DETERMINABLE.  States, properties, and values that can be set by the user must be PROGRAMMATICALLY DETERMINABLE and can be programmatically set.  Any notification of changes to these items must be available to user agents, including ASSISTIVE TECHNOLOGIES.
Example:  Frames must be titled with text that facilitates frame identification and navigation.
Version 2
For all user interface components, including form elements and those generated by scripts, the name, role, states, properties, and values must be PROGRAMMATICALLY DETERMINABLE.  States, properties, and values that can be set by the user can also be programmatically set.  Any notification of changes to these items must be available to user agents, including ASSISTIVE TECHNOLOGIES.
Example:  Frames must be titled with text that facilitates frame identification and navigation.
411 Compatible Technologies
411.1 General.  ICT content shall conform to 411.
411.2 User Interface Components.  User interface components found in content shall conform to 411.2.1 through 411.2.4.
411.2.1 Name and Role.  For all user interface components, the name and role shall be programmatically determinable.
411.2.2 States, Properties and Values.  States, properties, and values shall conform to 412.2.2.1 and 412.2.2.2.
411.2.2.1 Programmatically Determinable.  When states, properties, and values are conveyed to the user, they shall be programmatically determinable.
411.2.2.2 Set Programmatically.  When states, properties, and values can be set by the user, they shall be capable of being set programmatically.
411.2.3 Change Notification.  Notification of changes to states, properties, and values shall be available to user agents, including assistive technologies.

Comments