WCAG 2.1: Understanding the Success Criteria

The Web Content Accessibility Guidelines (WCAG) 2.1 were officially published by the World Wide Web Consortium (W3C) on June 5, 2018. These guidelines build upon the earlier WCAG 2.0 standards introduced in December 2008.

Relative to WCAG 2.0, WCAG 2.1 guidelines aim to make web content accessible to a broader range of people with disabilities, including those with cognitive, motor, auditory, and visual disabilities.

The goal of WCAG 2.1 is to establish a unified standard for web content accessibility that meets the needs of individuals, organizations, and governments on an international scale.

Navigating WCAG 2.1: Updates and insights

While WCAG 2.2 is the latest version of WCAG, WCAG 2.1 continues to be the standard frequently referenced by many U.S. and international laws. Here are some quick facts about WCAG 2.1:

• WCAG 2.1 builds upon and extends WCAG 2.0 without superseding or replacing it:

WCAG 2.1 incorporates all WCAG 2.0 success criteria, retaining their original numbering. It ensures backward compatibility: Content conformant to WCAG 2.1 at a specific level (e.g., WCAG 2.1 AA) is also conformant to WCAG 2.0 at the same level.

• Relative to WCAG 2.0, WCAG 2.1 includes 17 additional success criteria:

These consist of five Level A, seven Level AA, and five Level AAA criteria. They primarily address:

• • Mobile accessibility: Enhancements for small screens and touch interfaces.
  • Motor and dexterity disabilities: Accommodations for users with motor challenges.
  • Low vision and cognitive disabilities: Improvements for users with visual and cognitive disabilities.
  • Additional benefits: Enhancements for individuals utilizing voice input, those with vestibular disabilities, and users of screen readers.

• WCAG 2.1 introduces an additional guideline and conformance requirement:

Version 2.1 of WCAG includes a guideline focusing on input modalities that is not present in WCAG 2.0. It also adds a note to the Full-Page Conformance Requirement, clarifying that “full page” encompasses every variation of a page automatically presented for different screen sizes.

• WCAG 2.1 supports responsive design conformance:

Every variation of a page created through responsive breakpoints or other automatic triggers (e.g., user agent detection) must conform with WCAG 2.1. Each page variation must be tested against all success criteria. In practice, only the changed portions require retesting, while unchanged sections should retain their original conformance status.

What are the WCAG 2.1 success criteria?

To ensure your web content conforms to WCAG 2.1, it’s essential to understand the success criteria. In the following section, we’ve provided a summary of each of the 17 criteria that WCAG 2.1 introduced. Because WCAG 2.1 incorporates WCAG 2.0, full conformance with WCAG 2.1 also involves meeting the original WCAG 2.0 success criteria.

We’ve organized the new WCAG 2.1 success criteria by the user groups they primarily benefit. Keep in mind that individual success criteria may support multiple user groups. For example, many of the new WCAG 2.1 criteria designed to improve accessibility for people with motor and dexterity disabilities also enhance the usability of content on mobile devices, such as smartphones and tablets.

SC 1.3.5 Identify Input Purpose (AA)

Summary: For content developed using markup languages, the purpose of specific input fields defined in WCAG 2.1 must be conveyed programmatically. This can be achieved by using the `autocomplete` attribute in HTML.

User impact: When this criteria is met, the input purpose can be transformed by personalization tools and communicated 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 criterion builds on SC 1.3.5 by ensuring icons, regions, links, buttons, and other user interface elements communicate their purpose.

User impact: This allows for personalization that benefits individuals 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.

User impact: Users with cognitive disabilities or other disabilities related to focus and / or memory may require more time to read content or to complete interactions, such as filling out an order form. Using timed events can create obstacles for users who need to take breaks. By displaying the length of inactivity before a timeout occurs, you enable users to plan their breaks effectively.

Criteria supporting users with low vision

SC 1.4.10 Reflow (AA)

Summary: Content must be displayed without losing any information or functionality and should avoid the need for both vertical and horizontal scrolling, except when a two-dimensional layout is essential for the content’s use or meaning. Specifically, vertically scrolling content should fit within a width of 320 CSS pixels, and horizontally scrolling content should fit within a height of 256 CSS pixels.

User impact: Many users with low vision use the browser zoom function to increase the size of content. When zooming a page necessitates scrolling in both horizontal and vertical directions, it significantly increases the effort required to read the content. This guideline is primarily intended to support desktop users who use zoom functionality and is less applicable to mobile devices.

SC 1.4.11 Non-Text Contrast (AA)

Summary: Visual details that help users spot graphics and active user interface controls (and their different states) need a contrast ratio of at least 3:1 against neighboring colors. This criterion covers everything from buttons and form fields to focus indicators and selected state indicators.

Any identifying parts of the control need to have sufficient contrast with the adjacent background. In practice, this means that not all parts 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.)

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

User impact: Sufficient contrast is necessary to ensure that identifying features of controls and states (non-text) are distinguishable by people with low vision. Low-contrast controls can be harder to see and may be completely overlooked by individuals with visual disabilities.

SC 1.4.12 Text Spacing (AA)

Summary: 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. 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.

User impact: Individuals with low vision or dyslexia might adjust text spacing to enhance readability or improve their reading speed. 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. This standard may also have benefits for users with cognitive and learning disabilities.

SC 1.4.13 Content on Hover or Focus (AA)

Summary: When content appears on focus or hover—and then disappears as soon as focus or hover ends—three requirements must be met:

1. Additional content must be dismissible using the keyboard without shifting focus or hover states. 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.

User impact: This criterion is essential for making content in a hover or focus state accessible to users with low vision.

Criteria supporting users of speech input

SC 2.1.4 Character Key Shortcuts (A)

Summary: When a webpage includes shortcuts that can be activated with a single key—such as letters, numbers, punctuation marks, or symbols without the need for a modifier key—users should be given the option to either reconfigure these shortcuts (for example, by remapping them to require a modifier) or disable them entirely. This requirement does not apply when the control associated with the shortcut is focused, nor does it apply to access keys, as those inherently require a modifier key.

User impact: Using key shortcuts without modifiers can create significant barriers: speech input users might unintentionally activate shortcuts while navigating the page or dictating text, and users with mobility impairments may accidentally press keys, leading to the unintentional triggering of 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.

User impact: 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.

Criteria supporting users with vestibular disabilities

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. Motion animation that is essential or not presented based on user interaction is not covered by this criterion.

User impact: 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. This requirement may also benefit for users with cognitive and learning disabilities who may be distracted by motion.

Criteria supporting users with motor and dexterity disabilities

SC 2.5.1 Pointer Gestures (A)

Summary: All functionalities on a page should be accessible using a single pointer action, such as a single click or tap, a click or tap-and-hold, or a double click or tap. Features that typically require complex multi-point or path-based gestures—like swiping, dragging, pinching, or drawing—must also be provided unless the gesture is essential—such as signing a name—or is a fundamental part of the user interface, like scrolling the screen.

User impact: This requirement supports users who may lack the precision, dexterity, or necessary tools to perform complex gestures accurately.

SC 2.5.2 Pointer Cancellation (A)

Summary: Users must have the ability to cancel, or “undo,” actions triggered by pointer events. Pointer events consist of both down-events (such as placing a finger on a touchscreen or pressing the button on a mouse) and up events (such as lifting a finger off a touchscreen, or releasing the button on a mouse). There are several ways this requirement can be met, including only responding on the up-event, providing alternative means, allowing the up-event to cancel a response from the down-event, or allowing undo or cancel actions that are completed on the up-event, such as drag and drop. Essential use exceptions apply.

User impact: People with motor disabilities can unintentionally trigger touch or mouse events, resulting in unexpected actions. 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.

SC 2.5.4 Motion Actuation (A)

Summary: When interactions or functionalities depend on device or user motion—such as shaking, tilting, or gestures detected by the device’s camera—an alternative input method must be provided to perform the same action, unless the motion-based action is essential.

User impact: If alternatives are not available, users with motor disabilities or those unable to perform gestures or activate device sensors will be unable to access the page’s functionality.

SC 2.5.5 Target Size (AAA)

Summary: Pointer input targets should be a minimum of 44×44 CSS pixels. 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 must be a certain size.

User impact: Smaller targets can be difficult for many users, including those with hand tremors or limited dexterity, to activate effectively, especially when interacting with smartphones or mobile devices that have small touchscreens.

SC 2.5.6 Concurrent Input Mechanisms (AAA)

Summary: A page must allow users to switch between input mechanisms.

User impact: Users may rely on various input methods when interacting with a website—such as a keyboard, mouse, stylus, touchscreen, or speech input—and they might even use more than one at the same time. 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)

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.

User 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.

Criteria supporting screen reader users

SC 4.1.3 Status Messages (AA)

Summary: When new status information is added to the screen without altering the user’s current context, users should be notified of important changes that are not in focus in a manner that does not unnecessarily disrupt their workflow.

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.
• Information on the progress of a process.

User impact: Status messages can be recognized by assistive technology through the right roles or properties. When status messages are not programmatically indicated, users of assistive technology, such as screen readers, may be unaware of the status change.

This criterion is especially beneficial for users who are blind, have low vision, or have cognitive or learning disabilities and who use assistive technology with screen reading capabilities.It may also support individuals with cognitive disabilities who use assistive technology that can process information communicated by aria-live regions.

WCAG 2.1 essentials: Resources for accessibility

A variety of resources are available to help organizations understand and test their digital experiences against WCAG 2.1 success criteria. For example, the World Wide Web Consortium’s (W3C) How to Meet WCAG document provides up-to-date information about WCAG standards.

You can also download our Must-Have WCAG Checklist, an interactive guide that explains each WCAG 2.1 and 2.2 success criterion and outlines various methods for testing accessibility. To explore solutions for building more accessible applications, visit our Developer Tools page.

Count on Level Access for WCAG 2.1 success

Websites are in a state of continual change, with content frequently being added, updated, or removed. This ongoing evolution of digital content can make it challenging for any organization to maintain conformance with WCAG standards.

Partnering with a trusted digital accessibility solution provider, like Level Access, can equip your teams with the necessary technology and expertise to meet WCAG 2.1 standards and consistently deliver inclusive online experiences.

Contact a member of the Level Access team to learn how our digital accessibility platform can empower you with the tools, training, and guidance needed to begin your journey toward WCAG conformance today.