WCAG 2.2 is on the way, what comes with it?

February 25, 2023 | Accessibility

WCAG (Web Content Accessibility Guidelines) 2.2 version has been delayed a couple of times. But now the plan is to release it in April 2023. WCAG 2.2 currently has two versions. WCAG 2.2 W3C Candidate Recommendation Snaphot which was approved for publication in January 2023. And Editor's draft of WCAG 2.2 which may include more recent proposed changes that aren't yet all approved.

According to W3C WAI (Web Accessibility Initiative), the main purpose of the Candidate Recommendation is to ensure that the standard can be implemented. It is stable, but it might change based on implementation experience. They mention one specific criterion which is at risk and might not be included in the final publication. So let's see what the final publication will look like, hopefully in April.

WCAG 2.2 won't be likely immediately added as the accessibility guideline to follow. But I recommend starting to take these into account already. That way you can prepare beforehand and won't have to work on changes later with a tighter deadline. If you have been paying attention to accessibility already, it might very well be that you already have taken care of all these.

Changes from WCAG 2.1 to WCAG 2.2

There will be two changes from WCAG 2.1. The level of criterion 2.4.7 Focus Visible will be changed from level AA to level A in WCAG 2.2. When most sites aim to conform to Level AA, this brings no real difference to those sites. In those cases, both A and AA levels still need to be complied with.

Criterion 4.1.1 Parsing is obsolete and it will be completely removed in WCAG 2.2. The criterion has received quite a lot of feedback of being quite confusing and people have been interpreting it in different ways. So I'm not really surprised to see it go. But this doesn't mean that code validity and quality aren't still important! So continue to make sure all ID attributes are unique and that you use HTML attributes and elements correctly. Quality code will still make a difference, regardless of the user's abilities and skills.

Additions in WCAG 2.2

WCAG draft currently shows 9 new success criteria from WCAG 2.1.

Guideline 2.4 Navigable

2.4.11. Focus Appearance - Level AA

This is the criterion that WAI mentions is at risk and might not make the final publication. I don't have any facts but it might be due to the criterion not being the easiest to understand. I might be completely wrong though, so don't take my word for it. But aim to have your focus styles clear and visible.

When the keyboard focus indicator is visible, one or both of the following are true:
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.
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.

So really not the clearest criterion. A lot of stuff to take care of. If you use the default focus style from the browsers, you should be fine. Or if you use a clearly visible border that is solid and at least 1px thick, you should be fine. The criterion tries to allow different types of borders, for example, those that have a border on only one side of the element. If you want to use those, I can already say that the thicker they are, the more likely they are to already pass the criterion. But in this one you can see some minimum requirements, assuming this criterion doesn't get removed. But good tips even if the criterion would get removed.

2.4.12 Focus Not Obscured (Minimum) - Level AA

This criterion aims to help people visually see the focused items. Sometimes there can be things like pop-up banners blocking the focused item. This criterion does allow part of the focused item to be behind some other element.

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

2.4.13 Focus Not Obscured (Enhanced) - Level AAA

This is the enhanced version of the previous criterion. This one requires that all focused elements are fully visible. No author-created content can be on top of it.

When a user interface component receives keyboard focus, no part of the focus indicator is hidden by author-created content.

Guideline 2.5 Input Modalities

2.5.7 Dragging Movements - Level AA

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.

There is a note that this applies to web content that interprets pointer actions. The requirement doesn't apply to actions that are required to operate the user agent or assistive technology.

2.5.8 Target Size (Minimum) - Level AA

This criterion aims to help people who have difficulties hitting small targets, for example, people with tremors.

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 has an area of at least 24 by 24 CSS pixels;
Inline: The target is in a sentence or block of 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.

Guideline 3.2 Predictable

3.2.6 Consistent Help - Level A

This criterion aims to help people with cognitive disabilities. If the help tools on a web page are always in a different place, it will require a lot of effort from people to find them. Consistency is key.

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.

They have a note that says that access to help mechanisms can be provided directly on the page or it can be provided via a direct link to a different page containing the information.

Guideline 3.3 Input Assistance

3.3.7 Accessible Authentication - Level AA

This criterion aims to help people with cognitive disabilities. Not allowing users to use password managers can be really bad for the users. And not preventing the use of password managers is enough to pass this criterion.

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.

3.3.8 Accessible Authentication (No Exception) - Level AAA

This criterion is stricter than the previous one. This basically removes two of the allowed options. But allowing your users to use their password managers is enough for this one as well.

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.

3.3.9 Redundant Entry - Level A

The aim of this criterion is to help users so they don't have to re-type information they've already entered. This can reduce the cognitive load by quite a bit.

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
previously entered information is no longer valid.

My thoughts on WCAG 2.2

I think the new WCAG version brings good additions. And when looked at from my developer point of view, I already aim to do those in my daily work. I really recommend getting started on having these handled in your websites and applications, just remember that these can still change before the final publication.

More information on WCAG 2.2:

What's new in WCAG 2.2 Draft on the WAI website
Web Content Accessibility Guidelines 2.2 on W3C