WCAG 2.1: Exploring the New Success Criteria

This blog was created before the release of WCAG 2.2. For information on the most up-to-date WCAG standards, visit our WCAG Compliance page.

The Web Content Accessibility Guidelines (WCAG) has been a part of digital accessibility since 1999. WCAG 2.0 was published in 2008 and of course, technology evolved quickly and our standards needed to catch up in order to ensure that people with disabilities are able to access today’s systems. The accessibility community has been eagerly awaiting the release of WCAG 2.1.—created by the W3C—a private organization made up of a cross section of stakeholders from government, industry, and consumer groups that creates standards. WCAG 2.1—like 2.0—is a voluntary consensus standard. The standard is then adopted for use by organizations at their choosing or referenced in procurement or litigation.

This is the second of a three-part series about WCAG 2.1. Previously, we covered WCAG 2.1 in AMP (Accessibility Management Platform). Coming up: How the WCAG 2.1 changes will apply to you. 

Quick Facts about WCAG 2.1

• WCAG 2.1 is now the official recommendation of the World Wide Web Consortium (W3C).
• WCAG 2.1 builds on and extends WCAG 2.0, but does not supersede or replace 2.0.
• All WCAG 2.0 success criteria are in WCAG 2.1 with their same numbers.
• If content is WCAG 2.1 conformant at a given level (e.g., AA) the content is also WCAG 2.0 conformant at the same level.
• WCAG 2.1 adds 17 new success criteria:
  • 5 level A criteria
  • 7 level AA criteria
  • 5 level AAA criteria
• The success criteria primarily address items related to mobile (small screens and touch screens) that accommodate users with motor and dexterity disabilities, users with low vision, and users with cognitive disabilities. In addition, there are success criteria that benefit users of voice input, users with vestibular disabilities, and users of screen readers.
• WCAG 2.1 also adds a new guideline (input modalities) and a new conformance requirement note (added to the Full Page Conformance Requirement).
• AMP (Accessibility Management Platform) supports WCAG 2.1 success criteria should our clients wish to use them.

Now that we’ve reviewed the basics, let’s dig in.

The New WCAG 2.1 Success Criteria

I’ve arranged the new success criteria by the user groups that they (most) accommodate. All of the success criteria related to motor and dexterity disabilities are also beneficial for use of mobile devices (those with touch screens or small screens). Most of the mobile related success criteria have benefits for users beyond the mobile environment. Keep in mind that and success criteria may benefit multiple user groups and have benefits for all users.

Cognitive and Learning Disabilities

SC 1.3.5 Identify Input Purpose (AA)

Summary: For content created with markup languages, the purpose of specific input fields indicated in WCAG 2.1 needs to be communicated programmatically such as via the autocomplete attribute in HTML. The purpose can then be transformed by personalization tools to communicate this in different ways such as via icons or symbols to assist users with cognitive and learning disabilities.

SC 1.3.6 Identify Purpose (AAA)

Summary: This builds on SC 1.3.5 and includes communicating purpose for icons, regions, links, buttons, and other user interface elements, to support personalization for people with cognitive and learning disabilities.

SC 2.2.6 Timeouts (AAA)

Summary: When a timeout is used, advise users of the duration of inactivity that will cause the timeout and result in loss of data. Users with cognitive disabilities or other focus/memory related disabilities may require more time to read content or to complete interactions, such as completing an order form. The use of timed events can present barriers for people who need to take breaks. Providing the duration of inactivity before a timeout occurs will help users plan for breaks.

Low Vision

SC 1.4.10 Reflow (AA)

Summary: Text and other content on a page should reflow without requiring scrolling in two dimensions when the horizontal width is 320 CSS pixels and vertical height is 256 CSS pixels. The reflow must not cause loss of content or functionality, although content and functionality may be presented in different ways, such as via a pop-up menu rather than a navigation bar.

Users with low vision use the browser zoom function to increase the size of content. When zoom causes the page to require scrolling in multiple directions, a much greater effort is required to read the content. This particular criterion is aimed to support users with zoom on the desktop and is not so much about mobile.

SC 1.4.11 Non-Text Contrast (AA)

Summary: Visual details needed to identify graphics and active user interface controls and their states need to have a contrast ratio of at least 3:1 contrast with adjacent colors. This includes, but is not limited to: buttons, form fields, focus indicators, and selected state indicators. This requirement is necessary to ensure that identifying features of controls and states (non-text) are distinguishable by people with low vision. Low contrast controls are more difficult to perceive and may be completely missed by people with a visual impairment.

Any identifying parts of the control need to have sufficient contrast with the adjacent background. In practice, this means that not allparts of a control must have sufficient contrast. For example, if an input has a shaded background and a bottom border line, it may only be necessary to ensure that the bottom line has sufficient contrast.

In addition, the indicators of states (hover, focused, checked, selected, current item, etc.) need to also provide the minimum 3:1 contrast with the colors adjacent to the control.

SC 1.4.12 Text Spacing (AA)

Summary: People with low vision or dyslexia may override text spacing to enable readability or increased reading speed. Ensure that when users override text spacing via style sheet or another browser setting, there is no loss of content or functionality — text must not be cut off or missing. When the content cannot adapt to user settings, users may not be able to use their preferred text spacing or may not be able to access content that is cut off or overlaps.

Only specific spacing settings are required to meet this standard and languages or technologies that do not support a particular setting only have to meet the settings that apply to that circumstance.

This standard may also have benefits for users with cognitive and learning disabilities.

SC 1.4.13 Content on Hover or Focus (AA)

Summary: If content appears on focus/hover (and disappears when focus/hover is removed), three things must occur to make sure this content is accessible to users with low vision.

1. The additional content must be dismissible with the keyboard without moving focus/hover. This is generally implemented via the escape key and allows users to dismiss content that blocks other content in a zoomed area.
2. The additional content itself must be hoverable, so users that are zoomed in can inspect the additional content.
3. The content must be persistent to give users time to read the content without it disappearing until focus/hover is removed or the user dismisses it.

This does not apply to standard tooltips created by the user agent such as those created with the title attribute.

Speech Input

SC 2.1.4 Character Key Shortcuts (A)

Summary: When a page has shortcuts that can be activated using a single key, such as a letter, number, punctuation, or symbol key without a modifier key, the user should have the option to reconfigure (remap to use a modifier) or deactivate (turn off) the shortcut. This standard is not applicable when the control that has the shortcut is focused. This standard does not apply to access keys, as those shortcuts require a modifier key.

Impact: When key shortcuts without modifiers are used, speech users may accidentally activate shortcuts while navigating a page or dictating. Users with mobility issues may accidentally hit keys and unintentionally activate shortcuts.

SC 2.5.3 Label in Name (A)

Summary: The accessible name for a control needs to include the text of its visual text label. Speech input users often navigate by speaking text from a control’s visible label. When the accessible name does not match the visible text label or includes the text from the visible label, users will not be able to easily access that interface control.

Vestibular

SC 2.3.3 Animation from Interactions (AAA)

Summary: Motion animation can cause negative side effects for people with vestibular disorders, including nausea, migraines, or other symptoms. Examples of motion animation include moving, growing, or shrinking content or parallax scrolling that is triggered by user interaction. When an option is not available to turn off this user-generated motion animation, some users may not be able to use the content and may have negative health effects.

Motion animation that is essential or not presented based on user interaction is not covered by this criterion.

This requirement may also have benefits for users with cognitive and learning disabilities that may be distracted by motion.

Motor and Dexterity

SC 2.5.1 Pointer Gestures (A) #mobile

Summary: Functionality on a page needs to be operated using a single pointer, such as a single-click/tap, click/tap-and-hold, or double-click/tap. Content requiring complex multi-point or path-based gestures, such as swiping, dragging, pinching, or drawing should have equivalent single-point activation methods unless the gesture is essential, such as signing your name, or part of the user agent, such as scrolling the screen.

This requirement is beneficial for users who lack the accuracy, dexterity, or tools to perform complex gestures in a precise manner.

SC 2.5.2 Pointer Cancellation (A) #mobile

Summary: People with motor disabilities can accidentally trigger touch or mouse events with unwanted results. Activation can occur when someone touches a screen (down-event) or when they remove their finger (up-event). In mouse interaction, activation can occur when pressing (down-event) or when releasing the mouse button (up-event).

When activation occurs only when the pointer is down, users may trigger the wrong item when they put their finger down, but then move it to the correct target. There are several ways this requirement can be met such as by only responding on the up-event, providing alternative means, or allowing the up-event to cancel a response from the down-event, or by allowing undo or cancel actions that are completed on the up-event, such as drag and drop. Essential use exceptions apply.

SC 2.5.4 Motion Actuation (A) #mobile

Summary: When device motion or user motion (e.g., shaking, tilting, or gestures picked up by the device’s camera) are used for interaction or functionality, an alternative input method should be provided to perform an equivalent action unless the action is essential. When alternatives are not provided, users with motor impairments or users who are unable to perform gestures or actuate sensors on the device will not be able to access the functionality on the page.

SC 2.5.5 Target Size (AAA) #mobile

Summary: The target size for pointer input needs to be at least 44×44 CSS pixels. When a target is too small, users with hand tremors, limited dexterity or other limitations may have trouble activating coarse targets, such as when users touch a smartphone or mobile device with a small touchscreen.

A target may have less than 44×44 CSS pixels when one of the following applies:

1. There is an equivalent link or control on the same page that is at least 44×44 CSS pixels.
2. The target (link, button, interactive icons, etc.) is in-line in a sentence or block of text.
3. The target size is controlled by the user agent and not the author. That is, if the size of the target is not modified by the author through CSS or other size properties, then the target does not need to meet the target size of 44×44 CSS pixels.
4. The target size is essential to use of the target. For example, the target has to be a certain size.

SC 2.5.6 Concurrent Input Mechanisms (AAA) #mobile

Summary: 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, or speech input. The user may prefer using one input device for certain tasks or interactions and other input devices for different interactions. When a page does not allow users to switch input mechanisms, some users with disabilities may have difficulty interacting with a page.

This also has benefits for users with low vision who may use a pointer or touch in some situations and the keyboard in others.

SC 1.3.4 Orientation (Level AA) #mobile

Summary: Web content should not prevent the user from changing the display orientation to either portrait or landscape. Content must be operable in either orientation, but equivalent functionality is not covered by this criterion. This criterion addresses restrictions imposed by the content and does not address settings enforced by the platform or device.

Impact: When content requires a particular orientation, users who have a mounted device, such as those with devices mounted to wheelchairs or those who are otherwise unable to change the orientation of the device, will be unable to interact with or access content in a particular orientation. Changes of orientation may also be beneficial to users with low vision who may change the orientation of a device to increase the width of the reading area when enlarged content is used or may use different orientations to increase the size of content.

Blind (and other users of screen readers)

SC 4.1.3 Status Messages (AA)

Summary: When new status content is added to the screen without changing the user’s context, users should be made aware of the important changes in content that are not given focus in a way that doesn’t unnecessarily interrupt their work. The messages to the users should be programmatically determinable through a role or properties.

This is especially beneficial for users who are blind, have low vision, or users with cognitive or learning disabilities that use assistive technology with screen reading capabilities.

Status messages include, but are not limited to:

• brief messages about the completion or status of the search,
• system busy or system available announcements,
• form error or completion messages, or
• information on the progress of a process.

When status messages are not programmatically indicated, users of assistive technology, such as screen readers, may be unaware of the status change.

This may also have benefits to users with cognitive disabilities that use assistive technology that can use information communicated by aria-live regions.

New Conformance Requirement Note

A new conformance requirement note was also added to the Full Page Conformance Requirement of WCAG. It indicates that the term “full page includes each variation of the page that is automatically presented by the page for various screen sizes”. What that means is that each variation created by a responsive breakpoint or other automatic trigger such as user agent detection needs to conform in order for the page to conform. This means that each variation of a page needs to be tested for all of the success criteria. In practical reality this means that portions of the page that changed can be retested while unchanged portions should have the same findings.

Give Feedback on WCAG 2.1

Interested parties can provide feedback on WCAG 2.1 and related documents via the WCAG github issues page.

What’s Next for WCAG?

More work still remains to increase access to a wider range of content for more people with disabilities. There will be future updates that may come first in a WCAG 2.2 that builds on WCAG 2.1 or next as a whole new and renamed version of WCAG that may address broader issues such as user agent and authoring tool accessibility requirements, broaden the technology scope, and consider measures of conformance that include user testing. For more information on future plans for WCAG see the Silver Task force wiki page. The effort is called Silver because the periodic table symbol for Silver is AG — AG being the initialism for Accessibility Guidelines.

Helpful Resources

There are several informative documents that help users understand and test the WCAG success criteria. My favorite is the understanding WCAG 2.1 (editors draft) document. There is also the How to Meet WCAG document, which has been updated for WCAG 2.1. For information specifically on the solutions available for building more accessible apps, please visit the developer tools page.

What’s New in WCAG 2.1 from the W3C’s WAI provides some useful information including personas that help you understand how each success criteria applies to people with disabilities.