New in WCAG 2.2 AA: A Summary of Success Criteria Expected in May 2023 Release

With the expected release of the Web Content Accessibility Guidelines version 2.2 in May 2023, I am currently using the working draft to summarize the different success criteria found in WCAG 2.2 Conformance Level AA. Using my checklist, which is sharing the split screen with me, I’m going to read through and quickly summarize each success criterion.

For example, the first success criterion has to do with focus appearance. I have changed the titles in my checklist and guide to what I think are more common sensical titles for each success criterion. So, for 2.4.1.1, I have Focus Indicator Visibility (the actual title is Focus Appearance).

When you go through the official documentation, there can be some confusion since there are two different ways to meet this success criterion. You can do one or both, but both have different bullets to them where you need to work through and understand how to meet one option or the other.

However, the key is to not get caught up in the different minimum requirements and instead focus on how to make sure the focus indicator stands out from the page while meeting the requirements set forth by WCAG. A good way to do this is to have a solid enclosed border of two CSS pixels and ensure that there is a three-to-one color contrast ratio between the focused and unfocused states as well as between any adjacent colors.

Moving on to the next success criterion, I have labeled it as “Focused elements are visible” (2.4.12). This success criterion is all about making sure that when an element receives focus, it is not hidden behind anything. For example, sticky footers and sticky headers that are fixed in place can sometimes cause focus to be hidden behind them. Therefore, it is important to ensure that there are no pop-ups, overlays, or situations where an element receives focus but the focus is lost because it is hidden or blocked by other content.

With 2.5.7 gets that dragging movements and this might get slightly confusing, but the key to remember here is that if there is a function that requires a dragging movement that you have an alternative where someone doesn’t need to drag, but rather just needs to have a single point where they can select an item and then a single point where they can place it elsewhere using a mouse or with touch with a finger or stylus.

So this is not, at first, I thought this had to deal, had concerned keyboard navigability, but that’s not it, what the dragging movement success criterion is focused on is not requiring the dragging movement, but rather the ability to start at one place and then click another and accomplish the same, the same dragging function without the need to drag an item the entire way.

So it’s just, think of it in terms of using a mouse on a desktop. We can select an item at one point and then we can go to another point and then click our mouse and then place whatever we are dragging to that second point. So what this success criterion gets at is removing the dragging movement in between clicking and holding and then dropping. Rather, we just have to have one point and then a second point where we can accomplish the same thing. And this could be by a mouse and it could be by touch with a finger or stylus.

The next success criterion is 2.5.8. This gets at target size. And so the key here is just making sure that our interactive elements, anything that we might click or select or add input to or whatever the case is, we just make sure that has a minimum size. And so the minimum size required by 2.5.8 is 24 by 24 pixels.

However, there are exceptions. And one of those exceptions is if the size of the target is not 24 by 24, let’s say it’s 20 by 20, then there is adequate space around that target to where another target could not be clicked. If you have a 20 by 20 target and you add 4 by 4 space around it so that the total between the target and the space is 24 by 24, then you would meet this success criterion.

And there are other ways, there are other exceptions to this 24 by 24. So for example, a text link in a sentence would be an exception or if the target spacing is essential. So think about how pins in a map can be close together, really there is no room to space those out. So that would be an exception.

So there are exceptions to this success criterion, but the important takeaway is that we are only concerned with making our pixels, our pixel targets a certain size. And so really you don’t want you to get caught up in the minimum here, you’d rather go above and beyond. So I would have my targets at least 24 by 24, ideally larger. And that way we can avoid the exceptions and we can avoid any possibility where we don’t meet this threshold because not only is it helpful for accessibility, it’s just overall a better user experience when targets are easy to click.

So think about when you’re using a phone and you’re on a website, if you have larger targets, it’s easier to touch those targets and activate them. And what we want to especially make sure that we don’t do is that we don’t have targets that are close together and one is mistakenly clicked or selected when another was intended. So that’s all what 2.5.8 is getting at.

And then with 3.2.6, I think most websites are likely conformant with this success criterion. I have the title as help options consistent.

So whenever you have help available, you want to make sure that it is available in a consistent and a predictable manner across the web pages that are part of a common series of web pages. So you don’t have to have every page have the same help at exactly the same place. Although that could possibly be ideal, but on the pages that are alike and have a common purpose, then you need to make sure that your help options are available in a similar predictable and consistent manner throughout.

So let’s take an e-commerce website. With product pages, we know product pages are going to have a common purpose. So we want to make sure that if we do have a support link on those product pages, that support link is going to be in the same place. Similarly, if we have a chatbot, we want to make sure that that chatbot is in the same place, or it’s not missing on some pages, but there on others. Or if we have contact information, that contact information is located in the same place, or at least similar place relative to the order of the pages.

It’s not with the web content accessibility guidelines, whenever you hear consistent, it doesn’t mean exactly the same, but it does mean consistent. So there may be times where the ordering changes or there may be some slight variance, but generally there should be a consistency and it should be predictable. And so this success criterion doesn’t require that you offer help, but rather if you do have help options, that they remain consistent throughout the pages where they are repeated. So if you do, like, as I said, it’s pages of a common purpose. It’s not necessarily across the entire website because you might have, for example, those product pages on an e-commerce website, and then you might have the checkout pages. So the checkout pages might have different options for support. So for example, there could be a frequently asked questions link or a knowledge base link. And so if that’s the case, then that wouldn’t necessarily apply to the product pages. But ultimately here, we’re just concerned with if there’s help, it’s available in a consistent location.

With the next success criterion, it’s 3.3.7, it’s redundant entry. And so what this gets at is if information has already been entered by the user, and this is in the same session, so it doesn’t apply for every time a user visits a website, but if information has already been entered, it’s available either to be auto-populated or selectable. And the exceptions would be when reentering the information is essential or the previously entered information is no longer valid. So when reentering information is essential, that could be where you need to confirm a password to make sure that you have indeed entered the password that you intend to. And with previously information, so some information has time of the essence, right? It’s important, the timing, and it may no longer be good once a certain amount of time has passed. So that could be an illustration of when previously entered information is no longer valid. But the key with the success criterion is making sure that if a user enters information, so think of a billing address and a shipping address. If the user has already entered the billing address or the shipping address, let’s say it’s the shipping address that comes first, then we want to make sure that that information can be selected or auto-populated so that the user does not have to reenter that information once again.

And that’s usually already the case with many websites because this gets to user experience as well as accessibility.
So the accessibility leads right into user experience, and here we want to make sure that we are saving time and reducing the need to reenter information over and over again.

With 3.8, it’s the last success criterion under AA conformance, and it’s titled accessible
authentication. And so the key to meeting this success criterion is that users do not have to log in by remembering
a password or solving a cognitive test.

However, there are exceptions to this. And so one exception is if the cognitive test is only recognizing objects, then that would be, that would still meet this success criterion. However, that’s about optimal that we have a CAPTCHA for recognizing objects, but it is recognized as an exception.

And the way to, there are many ways that someone can enter into a, enter a password without having to remember it.

And so the official documentation page lists out several different ways where you don’t have to remember a password, but a password can be entered.

So if the form fields are labeled correctly, if you allow for copy and paste, these are ways where a password does not have to remember. There are also third-party password managers, if the ability to integrate a password manager is available. But what this is getting at is just reducing the need to remember a password or solve a cognitive test simply to log in, that is what the success criterion is getting at.

So there are a number of exceptions, and I won’t go through them all here, but the point is that you do have a way to log in without remembering a password or having to go through a cognitive test unless that test involves recognizing objects.

This is a quick rundown of the Web Content Accessibility Guidelines version 2.2 conformance level AA. Obviously, this is only a quick overview, but now you have a really good idea of what each success criterion is getting at.

In my WCAG course, I will have video explanations of each, and so I’ll cover a lot of the same material, but I’ll also go into some of the examples, and then also I will link to that course below. But you can also download this checklist that I have been going through and sharing the split screen with.

You can download this checklist at accessible.org as well as my guide. So with my guide, I expand upon these initial summaries, and I provide examples, and I also have a section where I go and have a plain English explanation written out.

And then with the course, what I’ll do is I just have that feature available by video as well, but the course is going to include all of the success criteria. So it’s going to include 38 success criteria in 2.0 conformance level AA, and then it will also include WCAG 2.1 AA success criteria that were added.

All of the links will be in the description below, but this is what you can expect as long as the working draft remains in place for 2.2 AA and carries over to the official documentation. If there are any revisions, I will note those below and the YouTube description as well.