Back to Blog

What’s new in WCAG 2.2?

5 Apr 2023

We get questions on a daily basis about 2.2 so we asked our WCAG expert Alaina Birney, CPWA, to discuss the upcoming changes. We’ve included her detailed notes below.

WCAG 2.2 guidelines are expected to be released by the World Wide Web Consortium’s Website Accessibility Initiative in the near future. They were previously expected for release in 2022, but it looks like the release of new guidelines is finally imminent.

WCAG is a framework designed to improve digital accessibility for people with disabilities. As new technologies come along and existing ones evolve, updates are needed to maintain the success criteria to ensure they help users without being superfluous or outdated.

One such criterion, 4.1.1 Parsing, has been dropped from 2.2 because it’s obsolete. This is because most assistive technology no longer needs to parse HTML directly. Over time, tolerance for HTML parsing errors has improved to the point they are no longer an issue, so the standard is being deprecated.

It makes sense, but it also makes it so 2.2 is no longer fully backward compatible with previous guidelines like 2.1 and 2.0. Typically by adhering to a newer version of WCAG, you could be assured that you were also covering previous versions as well. Not so with 2.2. Since it doesn’t include parsing, there are questions about whether it will also conform to WCAG 2.0, which is the version that is enshrined in many laws and organizational requirements around web accessibility.

Some questions remain about whether these success criteria will either be removed from previous versions of WCAG or if 2.2 will just move forward without being completely backward compatible. There are, however, a bunch of changes to success criteria that are more certain which we can talk about.

Our own WCAG expert, Alaina Birney, provided her notes on what’s changing in 2.2 that you can review below.

Success Criteria New to WCAG 2.2 

  • 3.3.7: Accessible Authentication (AA)
    • From Understanding Success Criterion 3.3.7: Accessible Authentication: “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
      • Alternative: Another authentication method that does not rely on a cognitive function test.
      • Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
      • Object Recognition: The cognitive function test is to recognize objects.
      • Personal Content: The cognitive function test is to identify non-text content the user provided to the website.”

Alaina’s strategies for conformance:

  • Do not block copy/ paste functionality so that users can utilize password wallets.
  • Provide an authentication method where a user can enter their email address and receive a link to sign in instead of providing a password.
  • 3.3.9: Accessible Authentication (Enhanced) (AAA)
    • From Understanding Success Criterion 3.3.9: Accessible Authentication (Enhanced): “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
      • Alternative: Another authentication method that does not rely on a cognitive function test
      • Mechanism: A mechanism is available to assist the user in completing the cognitive function test.”

Alaina’s notes: Very similar to the AA requirement, but does not allow for object recognition or personal content.

  • 3.2.6: Consistent Help (A)
    • From Understanding Success Criterion 3.2.6: Consistent Help: “If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content, unless a change is initiated by the user:
      • Human contact details;
      • Human contact mechanism;
      • Self-help option;
      • A fully automated contact mechanism.”

Alaina’s example: If there is a contact us link that is present as the second link in the footer and is present on multiple pages, it should be the second link in the footer each time it appears.

  • 2.5.7: Dragging Movements (AA)
    • From Understanding Success Criterion 2.5.7: Dragging Movements: “All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging unless dragging is essential or the functionality is determined by the user agent and not modified by the author.”

Alaina’s examples:

  • If there is a slider where a user can drag the thumb to select a value within a given range, there should also be buttons to increase or decrease the value of the slider or a text box to manually input the desired value.
  • Another example of a dragging movement would be the ability to adjust the width of columns within a table by dragging the edge of the column.
  • 2.4.11: Focus Appearance (AA)
    • From Understanding Success Criterion 2.4.11: Focus Appearance: “When the keyboard focus indicator is visible, one or both of the following are true:
      1. The entire focus indicator meets all the following:
        • encloses the user interface component or sub-component that is focused, and
        • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and
        • has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors.
      2. An area of the focus indicator meets all the following:
        • is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component, and
        • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and
        • has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels.
    • Exceptions:
      • The focus indicator is determined by the user agent and cannot be adjusted by the author, or
      • The focus indicator and the indicator’s background color are not modified by the author.”

Alaina’s notes:

  • This success criterion is at risk (as of March 27, 2023), meaning that it is still possible changes will be made. This success criterion is “at risk due to concerns around implementation and testing challenges. There is a need for greater information about this, which is expected to be collected during implementation testing in the Candidate Resolution review period. If testing does not document the sufficient implementation of a given feature, it could be removed from the final specification.” (source: WCAG 2.2 Items at Risk W3C) To summarize: the success criterion might be changed or removed because they don’t know how people will be able to test for it. 

General Summary: If the focus indicator is a solid border that encloses the focused component, is offset from the component, and reaches a contrast ratio of at least 3:1 against the background, then this success criterion has been met. 

  • This is assuming that the border appears against the background. If the color of the focus indicator is not the same as the background color when the component is not in focus, the contrast ratio between the focus indicator’s pixels in the component’s focused and unfocused states must reach a contrast ratio of at least 3:1.
  • If the focus indicator is not offset from the component, then it must reach a contrast ratio of at least 3:1 against both adjacent colors- the component and the background.
  • If the browser’s native visible indication of focus is used instead of providing a custom visible indication of focus, then the indicator is exempt from this success criterion.
  • If the focus indicator is not solid or does not encompass the UI component, then the focus indicator must be at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component.

Alaina’s example: If there is a sticky footer and a user navigates to a component towards the bottom of the page using the tab key, the focused component should not be hidden by the sticky footer.

Alaina’s notes: Similar to the AA requirement, but no part of the component can be hidden. AA would allow for a part of the component to be hidden.

  • 3.3.9: Redundant Entry (A)
    • From Understanding Success Criterion 3.3.9: Redundant Entry: “Information previously entered by or provided to the user that is required to be entered again in the same process is either:
      • auto-populated, or
      • available for the user to select.
      • Except when:
        • re-entering the information is essential,
        • the information is required to ensure the security of the content, or
        • the previously entered information is no longer valid.”

Alaina’s example: If a user has already entered their shipping information and is prompted to enter billing information, a checkbox could be provided for the user to indicate that the billing information is the same as the shipping information. If that checkbox is checked, the billing information would be pre-populated with the previously entered shipping information.

  • 2.5.8: Target Size (Minimum) (AA)
    • From Understanding Success Criterion 2.5.8: Target Size (Minimum):  “The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
      • Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
      • Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
      • Inline: The target is in a sentence, a bulleted or numbered list, or its size is otherwise constrained by the line height of non-target text;
      • User-agent control: The size of the target is determined by the user agent and is not modified by the author;
      • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

Alaina’s notes: Example (Source: Understanding Success Criterion 2.5.8: Target Size (Minimum)):

Four groups of components. The first three pass the success criterion, while the last one fails. A detailed description follows the image in text.

  • The first group of components in the image passes because each component has a target size greater than 24 x 24 px. In this case, each component has a target size of 44 x 44 px.
  • The second group of components in the image passes because each component has a target size of 24 x 24 px.
  • The third group of components in the image passes because each component has a target size of 20 x 20 px and is offset from adjacent components by 4 px, resulting in a combined space of 24px (the minimum requirement).
  • The fourth group of components in the image fails because each component has a target size of less than 24 x 24 px and is not offset from adjacent components by an amount of space that would total to 24px when combined with the component’s target size.
Gianna Barnhart
Sales Representative