Success Criteria of WCAG 2.1 Summarized

Posted by Joppe Kroon on July 15, 2019

The WCAG 2.1 update published in 2018 was a backwards compatible, additions only version. It adds 12 new A and AA (and 2 AAA) level success criteria focused on mobile accessibility, people with low vision, and people with cognitive and learning disabilities.

Reading through all the documentation can be intimidating, whereas a checklist can be too brief. Inspired by the session on WCAG 2.1 at NCDT of 2019, this post summarizes each success criterion; hopefully creating a middle ground between the full specifications and a checklist.

At the end of each section you’ll find a link to the “Understanding” document of the success criterion. Here you’ll find all exemptions, recommended techniques, and more.

If you are in fact looking for a checklist, WebAIM has created a checklist of all 2.x success criteria. Alternatively, the How to Meet WCAG (Quick Reference) is always a good place to start.



Orientation (AA)

Some people can’t, or prefer not to change their device orientation. Therefore the content should not force an orientation, but adjust to the orientation the device reports.

This criterion does not cover changes in content or functionality due to the size of the display.

Understanding Success Criterion 1.3.4: Orientation

Identify Input Purpose (AA)

It should be possible to programmatically determine the purpose of an element. This would allow user agents and assistive technologies to help the user more effectively.

For example, to help people with reading difficulties, tooling can add familiar icons to an input field. A birthday cake could then appear before an input field marked as autocomplete="bday".

The autocomplete attribute for inputs is currently the only technique available for this criterion. However, there is a working draft to add the ability to annotate other types of content as well.

Understanding Success Criterion 1.3.5: Identify Input Purpose

Reflow (AA)

Users with low vision may use the zoom function to be able to see content. If the page does not reflow correctly, this can introduce a second scrollbar. But scrolling in two dimensions is often problematic for users.

This criterion determines that up to a browser zoom level of 400%, only one scrollbar should be visible. This means that the site or application should be able to handle:

  • A viewport width of 320 css pixels without needing a horizontal scrollbar for horizontal languages (or otherwise horizontally consumed content).
  • A viewport height of 256 css pixels without needing a vertical scrollbar for vertical languages (or otherwise vertically consumed content).

This criterion interacts with existing criterion 1.4.4 Resize Text. Of course combining these success criteria could create a situation that is unworkable. Therefore, the reflow criterion mentions it is only necessary to be able to achieve a 200% increase of the text size. In other words, you can use breakpoints at certain zoom levels to reduce the base text size.

Content which requires two dimensional layout for usage or meaning, like tables, images, and video are exempt from this criterion.

Understanding Success Criterion 1.4.10: Reflow

Non-Text Contrast (AA)

Complementing existing criterion 1.4.3 Contrast (Minimum) for text, this criterion concerns (active) user interface components and (meaningful) graphical objects. It defines a minimum of 3:1 contrast ratio for adjacent colors.

User interface components should be clearly identifiable from their surroundings in each state (apart from the inactive state). The borders of an input field, for example, should have enough contrast from the external background to identify the field. However, if the inner background already has enough contrast the border can be safely ignored for this purpose.

A white text field with a black border on a white background
Using a border for contrast
A white text field with a grey border on a darkblue background
The adjacent background provides the contrast, the border can be ignored.

Any state indicator should also have a 3:1 contrast with neighboring colors, which could be colors of the component itself, e.g. the check mark of a checkbox, or a thumb of a slider.

This rule also applies to meaningful graphical objects that are not accompanied by visible text which explains their meaning, such as stand-alone icons, charts, and graphs. Brand logos are a notable exception here.

Graphical objects are usually more complex regarding color. Only the parts required for understanding need to contrast with their surroundings.

A pound sign inside an orange downward pointing arrow

In the graphic to the left, the pound sign and the overall arrow shape are the elements that convey meaning. The shape then should be discernible against the background, and the pound sign against the orange color of the icon.

Understanding Success Criterion 1.4.11: Non-text Contrast

Text Spacing (AA)

A user may change the way text is displayed to improve readability (often with plugins). This criterion determines that the site or application should handle this gracefully. All content and functionality should not get cut off, overlap, or become hidden in some other way.

This criterion suggests being able to handle increases to the following parameters:

  • Line height (line spacing) to at least 1.5 times the font size.
  • Spacing following paragraphs to at least 2 times the font size.
  • Letter spacing (tracking) to at least 0.12 times the font size.
  • Word spacing to at least 0.16 times the font size.

Understanding Success Criterion 1.4.12: Text Spacing

Content on Hover or Focus (AA)

Additional content that appears due to keyboard focus or hover (on another element) should:

  • Be dismissable without moving the pointer or the focus.
  • Not disappear when moving the pointer over the additional content.
  • Remain visible until the user dismisses the content, removes the focus or hover, or the content becomes outdated.

For example, a tooltip should remain visible while the mouse is moved over the tooltip itself, and should be dismissable through the ESC key.

Understanding Success Criterion 1.4.13: Content on Hover or Focus

Character Key Shortcuts (A)

Single character key shortcuts can be useful for many users, but can be a nightmare for others. This affects speech input users in particular. Single character shortcuts often trigger due to ambient noise or even during their normal input.

Therefore, users should be able to remap these shortcuts to one that uses a modifier key. If that is not possible, a user must be able to turn off the shortcut entirely.

Understanding Success Criterion 2.1.4: Character Key Shortcuts

Pointer Gestures (A)

Gestures like swiping, pinching, and multi-finger scrolling, can be a powerful method to provide functionalities. However, some people find it difficult or even impossible to accomplish these gestures.

That’s why this criterion requires that all operations that use multipoint or path-based gestures can also be achieved through alternative methods, for example:

  • Besides dragging the slider thumb, a user can also operate a slider by clicking the slider track.
  • Besides swiping, a user can also dismiss a notification by tapping it and then pressing an on screen button.

Understanding Success Criterion 2.5.1: Pointer Gestures

Pointer Cancellation (A)

Users should be able to always back out of accidental or erroneous pointer input, allowing them to feel safe using an application or site.

For a simple tap or click action, this can be achieved by triggering only on the ‘up’ event. This allows a user to move away from the target area before releasing, never firing the action.

When the interaction is more complex, like a drag and drop, an easy undo option can be a lifesaver. Alternatively, you could ask for confirmation before executing the action, or allow the user to drop on an illegal location.

Understanding Success Criterion 2.5.2: Pointer Cancellation

Label in Name (A)

Speech input users expect to be able to navigate to a component by speaking its label. Also, sighted users expect their screenreader to speak the text located next to the focused input. This success criterion ensures this is the case by defining that the visible label should also be the programmatic label.

Assistive technology will use the value of aria-label, aria-labelledby or the full content of the element (including parts that have been visibly hidden) as the ‘accessible name’. These techniques allow authors to provide additional context for users of assistive technologies. But, when the accessible name is too different from what is visible, it prevents these users from navigating effectively.

This criterion determines that the accessible name should at least contain the visible label. It is best if the accessible name starts with the visible label.

Text used as a symbol is not considered a label in this case. For example, a “B” button in a rich text editor can simply be named “toggle bold text”.

Include operators in mathematical expressions and formulae as is. This way, speech input users can rely upon their knowledge of how their tools will translate a formula for them. This does require using the proper symbols, e.g. × instead of *.

Understanding Success Criterion 2.5.3: Label in Name

Motion Actuation (A)

Modern sites and applications may add motion driven functionality, such as shaking to start a dice roll, or holding up a hand towards the camera to stop playback.

The motion actuation criterion ensures that all users can fully enjoy these functionalities. It determines that:

  • The response to the motion can be turned off to prevent accidental activation.
  • Non-motion based controls that achieve the same result, usually buttons, are available when motion sensing is disabled.

This criterion does not apply to functionalities that are completely dependent upon motion, such as a step counter. Motion through space, e.g. movement registered by geolocation sensors, is similarly exempt.

Understanding Success Criterion 2.5.4: Motion Actuation

Status Messages (AA)

To keep users from losing their place, authors should never move the focus unless expected. The focus position should remain untouched, unless the movement of focus would be expected, for instance in the event of a dialog opening. A page reload is another notable exception.

When a change of content occurs, status messages are a good way to inform the user. They do not steal focus, and assistive technology can announce them when the user is ready for them. For web content, this usually involves an aria-live region.

Understanding Success Criterion 4.1.3: Status Messages

About the author: Joppe Kroon

Senior developer at TOPdesk, member of the Accessibility Guild. Interests include web development, code style and quality, and making sure we do the best we can for our users.

More Posts