Understanding docs
This page provides the framework for the review and revision of the new additions to the Understanding WCAG 2.1 documents
Overview
The Understanding documents are often the first thing that people look at related to the success criteria. It is therefore critically important that they be clear and easy to read. EOWG edit support has been requested and participation by EO is encouraged.
Since the Understanding documents are no longer maintained in TR space they can be revised more easily. There is opportunity to make these more clear and to simplify the language. Links to the documents are posted below and edit suggestions will be prioritized, processed by the group, and maintained on GitHub pages according to the schedule described below.
Norah is leading the small edit team and will establish priorities and timelines for review and edit of the documents. She will compile comments and make suggested revisions to GitHub on a weekly basis that will provide review time for participants from AGWG and EOWG.
View the full Revision Process
Reminder: WAI Style Guide
List of Documents for Revision
Low vision requirements in WCAG 2.1
Understanding 1.4.10 Reflow (Level AA)
The intent of this success criteria is to allow the low vision users to use increase browse zoom up to 400% without the loss of most content when scrolled in any one direction.
- Review document here: SC 1.4.10 reflow
- Post comments and suggested revisions at github issue 1.4.10 reflow
Understanding 1.4.11 Non-Text Contrast (Level AA)
In WCAG 2.0, certain user interface elements are not clearly defined with color contrast requirements. The states and boundaries of user interface components those defined by author, parts of graphics that are required to understand the content must have a contrast ratio of 3 : 1.
- Review document here: SC 1.4.11 Non-text contrast.
- Post comments and suggested revisions at github issue 1.4.11 Non-Text Contrast
Understanding 1.4.12 Text Spacing (Level AA)
The intent of this success criteria is to provide enough flexibility for users who want to increase spacing between paragraphs, lines, words or characters can still be able to read the page without the loss of content. Users may use author defined styles or browser bookmarklets or any other features to achieve the required spacing. In addition to low vision users, users who are dyslexic will also benefit with this success criteria.
- Review document here: SC 1.4.12 Text Spacing
- Post comments and suggested revisions at github issue 1.4.12 Text Spacing
Understanding 1.4.13 Content on hover or focus (Level AA)
The intent of this requirement is to avoid unintended interference of content such as tooltips, modals, popups when user interface element receives keyboard focus or hovered by pointing device. The accessibility problems caused due to these kind of content can be either user is not at all aware of the displayed content or user is not intended for the interaction or the new content may interfere user’s current task.
- Review document here: SC 1.4.13 Content on focus or hover
- Post comments and suggested revisions at github issue 1.4.13 Content on hover or focus
Understanding 4.1.3 Status Messages (Level AA)
Status messages must be made available for blind and low vision users without interrupting their current task. Status messages must be programmatically defined such that the assistive technologies can identify them and present to the user in most convenient way.
- Review document here: SC 4.1.3 Status messages.
- Post comments and suggested revisions at github issue 4.1.3 Status Messages
Cognitive requirements in WCAG 2.1
Understanding 1.3.5 Identify input purpose (Level AA)
The intent of this success criteria is to provide an easy and personalized solutions when a page have input elements. By providing a meaningful additional information user agents or assistive technologies can provide simplest ways to fill in the data.
- Review document here: SC 1.3.5 Identify input purpose.
- Post comments and suggested revisions at github issue 1.3.5 Identify input purpose
Understanding 1.3.6 Identify Purpose (Level AAA)
The intent of this success criterion is to support personalization and preferences in order for more people to use the web, communicate, and interact with society.
- Review document here SC 1.3.6 Identify Purpose
- Post comments and suggested revisions at github issue 1.3.6 Identify Purpose
Understanding 2.2.6 TimeOuts
The intent of this Success Criterion is to ensure that when a timeout is used, users know what duration of inactivity will cause the page to time out and result in lost data. The use of timed events can present significant barriers for users with cognitive disabilities, as these users may require more time to read content or to perform functions, such as completing an online form.
- Review document here: SC 2.2.6 Timeouts
- Post comments and suggested revisions at github issue 2.2.6 Timeouts
Understanding 2.3.3 Animation from Interactions
The intent of this Success Criterion is to allow users to prevent animation from being displayed on Web pages. Some users experience distraction or nausea from animated content. For example, if scrolling a page causes elements to move (other than the essential movement associated with scrolling) it can trigger vestibular disorders. Vestibular (inner ear) disorder reactions include dizziness, nausea and headaches. Another animation that is often non-essential is parallax scrolling. Parallax scrolling occurs when backgrounds move at a different rate to foregrounds. Animation that is essential to the functionality or information of a web page is allowed by this Success Criterion.
- Review document here: SC 2.3.3 Animation from Interactions.
- Post comments and suggested revisions at github issue 2.3.3 Animation from Interactions
Mobile requirements in WCAG 2.1
Understanding 1.3.4 Orientation (Level AA)
In the realm of mobile, many applications provide content different in different orientations. Some content or elements that are available in portrait are not available in landscape or vice versa. Content authors must be aware that some users lock the display orientation of their devices or the devices may be fixed on a specific place such as on the arm of power wheelchair. This success criteria requires content authors to provide the content and elements available in both orientations. The placement or the sequence can be changed but the content and functionality must be made available.
- Review document here: SC 1.3.4 Orientation.
- Post comments and suggested revisions at github issue 1.3.4 Orientation
Understanding 2.1.4: Character Key Shortcuts (Level A)
The shortcut keys should not be character dependent. Having characters with only a combination of upper or lower case letters or punctuation may not be useful for users who depend on voice input and keyboard only users. Keyboard users may accidentally activate the keys. This success criteria does not prohibit the use of access keys.
- Review document here: SC 2.1.4 Character key shortcuts.
- Post comments and suggested revisions at github issue SC 2.1.4 Character key shortcuts
Understanding 2.5.1 Pointer Gestures (Level A)
The intent of this success criteria is to provide simple gestures to interact with the content. Multi pointing gestures and path based gestures will not be easy for many users and hence may not be benefit with content dependent on these type of gestures. This success criteria does not restrict the gestures supplied by user agents or assistive technologies.
- Review document here: SC 2.5.1 Pointer gestures.
- Post comments and suggested revisions at github issue SC 2.5.1 Pointer gestures
Understanding 2.5.2 Pointer Cancellation (Level A)
The intent of this success criteria is to avoid accidental pointer inputs. Users with disabilities may accidentally focus on an user interface element accidentally that may cause in unwanted results.
- Review document here: SC 2.5.2 Pointer Cancellation.
- Post comments and suggested revisions at github issue SC 2.5.2 Pointer Cancellation
Understanding 2.5.3 Label in Name (Level A)
The intent of this success criteria is to enable users who depend on voice commands to interact with the user interface components. Often the voice commands used by the user will be the visible labels. If the text on the visible label does not match with the accessible label where the accessible label is assigned as voice command the interaction will not be performed. Providing the visible label and accessible name as the same for text and images of text that have visible label will benefit not only mobile users but also users with cognitive difficulties.
- Review document here: SC 2.5.3 Label in name.
- Post comments and suggested revisions at github issue SC 2.5.3 Label in name
Understanding 2.5.4 Motion Actuation (Level A)
Motion actuations such as shaking or tilting should not be the only way of doing a function on the web. Additionally user interface components also should be available on the application to perform the same action. Sometimes the device may be fixed to a table or a wheel chair and motions cannot be performed. A mechanism should also be in place to switch off the motion actuating functions. People who have tremors may accidentally shake the device which can cause in performing unintended action.
- Review document here: SC 2.5.4 Motion Actuation.
- Post comments and suggested revisions at github issue SC 2.5.4 Motion Actuation
Understanding 2.5.5 Target Size (Level AAA)
The intent of this success criteria is to ensure that target sizes are large enough for users to easily activate them, even if the user is accessing content on a small handheld touch screen device, has limited dexterity, or has trouble activating small targets for other reasons. For instance, mice and similar pointing devices can be hard to use for these users, and a larger target will help them activate the target.
- Review document here: SC 2.5.5 Target Size.
- Post comments and suggested revisions at github issue SC 2.5.5 Target Size
Understanding 2.5.6 Concurrent Input Mechanisms (Level AAA)
The intent of this Success Criterion is to ensure that people can use and switch between different modes of input when interacting with web content. Users may employ a variety of input mechanisms when interacting with web content. These may be a combination of mechanisms such as a keyboard or keyboard-like interfaces and pointer devices like a mouse, stylus or touchscreen.
- Review document here: SC 2.5.6 Concurrent Input.
- Post comments and suggested revisions at github issue SC 2.5.6 Concurrent Input
Participation
Those who volunteered for the editorial review team are listed below. If you would like to participate, please add your name to the wiki and we will be sure your receive notification of the review schedule. Thank you!
- Norah Sinclair - lead
- Sylvie Duchateau
- Robert Jolly
- Chris O'Brien
- Brent Bakken
- Victoria Menezes Miller
- Lewis Phillips
- Amanda Mace
- Rachel Comerford