Latest Public Draft of WCAG 2.2 Features Nine New Success Criteria, Other Updates

September 9, 2020

The Web Content Accessibility Guidelines will soon be enhanced with the updates pending in WCAG 2.2. On August 11, W3C published its latest draft of WCAG 2.2, revealing a number of new success criteria since the first public draft published in February.

WCAG 2.2 is backwards-compatible with WCAG 2.1, published in June 2018, so complying with WCAG 2.2 would mean you also comply with WCAG 2.1 (as well as WCAG 2.0, since these iterations have added to the previous versions, not taken away from them).

The draft states that WCAG 2.2 serves to continue the work of WCAG 2.1: "Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices."

Here is an overview of what to expect in WCAG 2.2, starting with the nine new success criteria, with the language and in-line links copied directly from the draft, and in the order presented in the new features section of the draft:

3.3.7 Accessible Authentication (Level A)

If an authentication process relies on a cognitive function test, at least one other method must also be available that does not rely on a cognitive function test.

2.5.7 Dragging (Level AA)

All functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging is essential.

3.2.6 Findable Help (Level A)

For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

2.4.13 Fixed Reference Points (Level A)

When a web page or set of web pages is an electronic publication with pagebreak locators, a mechanism is available to navigate to each locator and each locator maintains its place in the flow of content, even when the formatting or platform change.

2.4.11 Focus Appearance (Minimum) (Level AA)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.
  • Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state.
  • Adjacent contrast: The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.
  • Unobscured: The item with focus is not entirely hidden by author-created content.

2.4.12 Focus Appearance (Enhanced) (Level AAA)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 2 CSS pixel solid border around the control.
  • Change of contrast: Color changes used to indicate focus have a contrast ratio of at least 4.5:1 with the colors changed from the unfocused control.
  • Unobscured: No part of the focus indicator is hidden by author-created content.

3.2.7 Hidden Controls (Level AA)

Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them persistently visible.

2.5.8 Pointer Target Spacing (Level AA)

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:

  • Enlarge: A mechanism is available to change the CSS pixel size of each target, or its spacing, so there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets;
  • Inline: The target is in a sentence or block of text;
  • User agent: The size of the target is controlled by the user agent and is not modified by the author;
  • Essential: A particular presentation of the target is essential to the information being conveyed.

3.3.8 Redundant Entry (Level A)

For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:

  • auto-populated, or
  • available for the user to select.

Exception: When re-entering the information is essential.

Other expected changes in WCAG 2.2

Visible focus indicator required for any level of conformance

In addition to the nine new success criteria, one existing criteria, 2.4.7 Focus Visible, has been changed from Level AA to Level A. This means there is no level of WCAG conformance that would allow for there to be no visible indicator upon keyboard focus.

New success criteria added to back end of existing criteria, changing conformance grouping

Previous versions of WCAG placed success criteria of the same conformance level together under each guideline. According to the numbering section of the draft:

In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2 versions is important, new success criteria in WCAG 2.2 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level.

This means that it will be especially important to note whether a success criterion is noted as Level A, AA, or AAA, as they will no longer be grouped from lowest to highest conformance levels.

The group coordinating the WCAG 2.2 updates is welcoming feedback by September 18.

Comments

Recent posts

What Does Restaurant Curbside Pickup Have to Do with Digital Accessibility?

September 21, 2020

Why Autoplay Is an Accessibility No-No

September 21, 2020

Google Chrome’s PDF Tagger Highlights the Need for PDF Accessibility

August 18, 2020

Not sure where to start?

Start with a free analysis of your website's accessibility.

GET STARTED