What’s New in WCAG 2.2

Last modified November 16, 2023

If you’ve been keeping up with the accessibility space, then you might already know that there’s a new and updated version of the Web Content Accessibility Guidelines (WCAG) that’s been under review for the last several months. The new version will remove Success Criteria 4.1.1 – Parsing and add nine new Guidelines. What does that mean for us, practically? Let’s break it down:

Removing Success Criteria 4.1.1

The now-retired SC 4.1.1 had to do with parsing: writing correct and semantically valid HTML so that browsers and assistive technologies could accurately parse the information and present it to the user. Practically, that included things like ensuring that all elements have starting and ending tags, avoiding duplicate attributes, making sure any child elements were nested / ordered correctly, etc.

In general, this is (of course) still a best practice for writing code in general. However, HTML, browsers, and assistive technologies have all gotten a lot smarter in the last few years and are now capable of handling errors in less disruptive ways.

For example, if you were to omit a closing tag for an element, it would likely still render in the browser. The error is (of course) not ideal, but browsers have learned how to handle and accommodate many common mistakes; they can take a “best guess” at what was intended and still load the page. Furthermore, most assistive technologies used to do their own parsing of the HTML, which meant that mistakes like that could be incredibly disruptive. Now, it’s more common for assistive technologies to rely on the browser for that, via the accessibility tree. Since the browser has gotten smarter about parsing, that means any assistive technologies that use the browser have gotten smarter, too!

Since parsing errors will (in the vast majority of cases) no longer cause browsers or assistive technologies to crash, the WCAG has decided to retire SC 4.1.1.

The New Guidelines

Here’s a look at the nine new guidelines that have been added as part of 2.2:

2.4.11 and 2.4.12 – Focus not Obscured (AA and AAA)

Both of these guidelines have to do with ensuring that the element with focus is visible to the user. 2.4.11 is the minimum (AA) required to pass, while 2.4.12 is the enhanced, or ideal (AAA).

2.4.13 – Focus Appearance (AAA)

This guideline instructs us to create focus indicators that are easily noticeable due to their high visibility in order to achieve AAA compliance. To meet this criteria, a focus indicator must have:

The only exceptions to this are when the focus indicator is either:

2.5.7 – Dragging Movements (AA)

This guideline is an especially important one – especially in the era of touch screens. We often make assumptions about how our users will interact with our interfaces, and this guideline reminds us that not everyone is capable of gesture and/or touch-based interactions.

2.5.7 states that any action that involves dragging must also offer a simple, pointer-based alternative.

2.5.8 Target Size (Minimum)

Similarly to 2.5.7, 2.5.8 offers us guidance around creating target sizes for interactive elements that are easy for everyone to use and help minimize mis-clicks and mistakes.

To meet this criteria, targets for pointer inputs (such as buttons) must be at least 24x24 pixels, with the following exceptions. Targets can be less than 24x24 pixels if:

3.2.6 Consistent Help (A)

Guideline 3.2 concerns making websites predictable and intuitive for users – and 3.2.6 specifically concerns the location of help mechanisms. To comply, help tools (when available) need to be placed in the same location on every page. That could apply to chat tools, guided tutorials, contact information, or other ways for users to get un-stuck when they’re confused. The actual help doesn’t need to be provided on the page (for example, it could be a link to an FAQ), but the link to the help needs to be offered in a consistent location throughout the website.

3.3.7 Redundant Entry (A)

Like so many accessibility guidelines, this one is also just a polite and user-friendly thing to do: don’t ask for the same information more than once in the same session. If the information has to be re-submitted, auto-fill and selection options are preferred. There are a few exceptions to this, though:

3.3.8 and 3.3.9 Accessible Authentication (AA and AAA)

Finally, the last two new guidelines have to do with making it as easy as possible for users to get logged in. When we require users to do various tasks before allowing them to access the content – such as memorize information, click on photos of specific things, etc. – we’re effectively gating the content behind a cognitive function test. This puts our users with cognitive disabilities at a severe disadvantage.

What do you think of the changes?

Do you think they’re beneficial? Will you be implementing any right away?

◀ Back to all blogs