WCAG 2.2

Hello and welcome back. This is the WCAG 2.2 update that I promised. Let's get into it and see what has changed, what is new, what has been removed, all of that stuff.

Let's go. And WCAG 2.2 was released in October 2023. So it's a relatively new standard. And it's important to know that WCAG standards, they only come every couple of years.

So WCAG 1 was in 1999, and then in 2008 there was WCAG 2.0, and then WCAG 2.1 took 10 years, and then WCAG 2.2 took 5 years.

Now, you would think that WCAG 2.3 would come around in 2028, but that's not true.

They're working on WCAG 3, which is supposed to be released around 2030-ish.

So WCAG 2.2 is a very long-term, very foundational thing, and you don't need to worry about big changes until several years out, which is good.

So, WCAG 2.2 it is. You heard about most of the things in WCAG 2.0 and WCAG 2.1.

And there will be a lot that you're going to hear about those.

Let's look at specific what happened to WCAG 2.2.

And the first thing is that you should, if you have looked into WCAG 2.2 from before it was released,

you should forget everything.

about it because during the development of WCAG 2.2, it was just not easy and a lot has

changed over the months and years of working through the drafts. And so you will find some

information on the web that is outdated. Always look at the date that it's after October 2023

to ensure that you're looking at the latest, well, at the released standard stuff

and not, you know, on something that was just a proposal.

Because that can be, like, misleading and then you have not, you know, learned something wrong

or you just can't use it as such.

WCAG 2.2 contains everything from WCAG 2.0 and 2.1, almost.

I'll get to that in a second.

And it adds nine new success criteria and removes one outdated success criteria.

And that's the thing that has been removed.

So that's not contained in WCAG 2.2.

We will go through each change step by step.

And I'm going to explain what these new success criteria mean.

and also how you navigate the missing success criterion.

But before we do that, we should look at WCAG in general.

Again, just to remind you of that.

The structure of WCAG is the same as in 2.1.

WCAG 2.1 did add the whole new guideline input modalities.

2.2 does not do that.

It's completely the same structure.

It has the fear-poor principles, perceivable, operable, understandable, and robust.

And they are useful as ever.

And, you know, that elevator pitch that content needs to be perceivable, understandable,

and can be operated through a variety of input modalities and implemented in a robust way,

that elevator pitch is still there.

The same thing goes for the 13 guidelines.

As I said, nothing has changed there.

WCAG 2.2 is a relatively tame update in that regard.

The guideline goes into a little detail of what needs to be done to make content accessible.

And these are the high-level ideas of WCAG, but you know them by now.

All in all, WCAG 2.2 has 83 success criteria.

And success criteria, they are the guardrails.

When you aim to meet a guideline, what is the minimum you must reach to call your effort a success?

How close can you go to the edge of the road without crashing?

That's why we have success criteria.

Now let's look at the nine new success criteria.

This is the whole list.

It's 2 for 11, focus not obscured, minimum.

2 for 12, focus not obscured, enhanced.

2 for 13, focus appearance.

257 dragging movements, 258 target size minimum, 326 consistent help, 337 redundant entry, 338 accessible authentication, and 339 accessible authentication enhanced.

338 was accessible authentication minimum.

That's a lot of words for these things.

Yeah, let's look at the new.

So the first three will concern the visibility and appearance of the focus.

They are adding two 247 focus visible from WCAG 2.0 and WCAG 2.1.

Then two are about affordances for people who cannot use pointer input or can only use them very imprecisely.

That's the dragging movements and target size one.

One is about consistent help, and three are about making it easier to enter repeat information and making authentication more accessible.

Let's go through them one by one.

So in 2.4 Navigable, you have focus and obscured two ways, one on AA and one on AAAA.

And you have the focus appearance success criterion.

Just as a reminder, these are other ANWASCs in 2.4 navigable,

like bypass blocks, page title, focus order, multiple ways, settings, labels, and focus visible.

An important warning to remember when we're looking at these success criteria,

In contrary to 2.4.7, focus visible, and 2.4.13, which we will talk about focus appearance,

2.4.11, focus not obscured, and 2.4.12, focus not obscured enhanced, the first one was minimum,

are not about the focus indicator, but about the focused UI component itself.

Let's get into it.

So, focus not obscured minimum, it says when a user interface component receives keyboard focus, the component itself is not entirely hidden due to author-created content.

So, when I focus something, it cannot be entirely hidden, which makes sense, right?

You don't want a button to focus that you focus and then it's not visible anymore on the screen.

And so this prevents that.

And then there's the enhanced version of that,

which basically says when a user interface component receives keyboard focus,

no part of the component is hidden by author-created content.

And that's quite important that you have this distinction.

The first one, the lower-level AA criterion, says it can't be entirely hidden.

But it can be somewhat hidden.

Sure, right.

So if it's only like a corner or it's like even, you know, 95% of the UI item is hidden under 2, 4, 11, that would all count as a pass.

And here we have no part of the component can be hidden by author-created content.

What is author-created content?

It's basically the whole thing about dialogues or you have sticky navigation or something like that that can easily hide focused elements.

Let's look at a couple of examples.

And this is to make the distinction between focus visible, focus not obscured, and focus not obscured enhanced.

I will not say minimum whenever I say focus not obscured.

It's just the base one.

So this is the first situation.

So we have an add to cart button and we have a clearly visible focus on it.

This passes obviously all of the success criteria.

There's a visible focus.

The focused element is not obscured.

And it's neither like fully nor partially.

So yay! Then we have this second situation. So this puts a square rectangle in black over like half of the button. And basically this now means this passes focus visible because there is a visible focus around it.

And it also passes focus not obscured minimum because it's not entirely hidden.

So this is passed there.

But of course, paths are hidden, so it fails focus not obscured enhanced, which is a AAA success criterion.

And then the third example is everything is hidden of the UI component apart from the focus.

which, yeah, this is a synthetic example, like nobody will hopefully do this.

But technically, you're passing focus visible, but you're neither passing focus not obscured minimum,

because the whole UI element itself is hidden, and you're not passing focus not obscured,

because if the whole thing is hidden, then also parts of it are hidden.

That's just, you know, common sense.

And then this one obscures, like, all of the parts, like the focus and the UI element itself, and that fails all of the three success criteria.

Just, you know, I don't think it's too complicated, but it helps to, like, think through, like, where the borders are between those different success criteria.

And that brings us to 2.4.13, focus appearance, which is super complicated.

I will read it really quickly and then show two examples and then we will move on.

It's a AAA success criterion.

They tried to do something for low vision people and then they got so complicated that it only worked as a AAA success criterion, which is really a shame.

I wish we had something on the A or AA level.

So this reads, when the keyboard focus indicator is visible, an area of the focus indicator meets all of the following.

The focus indicator area is at least as large as the area of a two pixel thick parameter of the unfocused component or subcomponent.

So basically a two pixel outline around the UI element and then has a contrast ratio of three to one between the same pixels in the focus and unfocus state.

So this ensures that there is enough contrast.

So it's thick and it's contrasty and that's awesome.

And this is, if you ask me, this is how you always should make focus indicators, like something like that.

There are two exceptions.

The focus indicator is determined by the user agent and cannot be adjusted by the author.

So if the author has no choice, they cannot do anything.

That's okay.

or the focus indicator and the indicator's background color are not modified by the author.

So this would be like just relying on the standard formatting of focus indicators,

which, yeah, sure, you should never do.

Okay, and then this is the example, like that's what I said,

like just having a two-pixel solid thick outline.

But it doesn't mean that it has to be an outline.

It could also be on a side, for example.

As long as the number of pixels in the two-pixel perimeter is the same,

you can style that as you wish.

You could put a square or a rectangle with the same number of pixels next to the button

as a focus style.

that would also work. Or an arrow that has the same number of pixels changing with enough contrast

would also work. You can be creative with this, which I like, but it has to have this two-pixel

outline area. That's the important part. And this shows it with rounded rectangles,

which is fun because if you do just a two pixel border, it's actually a little bit harder because the perimeter is not regular, right?

You don't have like sharp edges and stuff like that.

So, all four of these examples use solid lines. The outset, which basically sets it away from passes, the outline here passes too, and the border passes, because it has enough contrast to the unfocused style.

But the inset, because it's not the same size, that would fail.

And you could make up for the missing area by making it three pixels thick.

Or you could have four pixels at the bottom or something like that.

So you have multiple ways to do that.

Okay, and that brings us to that.

Yeah, you can read about it. I blogged about it on my blog as well.

Like this is the AAA, so we won't come across this a lot.

Then we have new SCs in guideline 2.5 input modalities.

And that's dragging movements and target size.

And really quick dragging movements basically says anything that uses a dragging movement,

which basically means you're pressing down the mouse button,

then you move your mouse, and then you're releasing your mouse.

that falls under this and that can be all achieved with a single pointer without dragging. So this

is not about keyboard navigation or making it available for keyboard users. This is, oh, I have

a slider here and I have to slide like click, hold, drag, release page by page. This says it needs to

be done with a single pointer without dragging like arrow buttons or something like that.

then we have a target size minimum which is a long one again and i don't want to go into like

specifics i won't even read it completely um but basically it requires your unleveled double a

which is you know something that we all love and use uh it requires the size of the target

like clickable areas basically to be 24 by 24 pixels at the minimum. That's the big thing.

If it's smaller, then you need to have spacing around the clickable area. And then you can use

a circle from the center of the clickable area and see if there's nothing else that can be focused

in that clickable area or in that circle, then it passes.

I have an image because that's much easier to explain.

So at the top we have 24 by 24 buttons which pass.

And here at the bottom we have 20 pixels by 20 pixel buttons

with 4 pixel spacing in between.

And if you look, like if you centered this underneath the top example, you would see that the visual icons are spaced the same size apart.

So you have 20 pixels, 20 pixels, and you have 4 pixels.

And if you put a 24 pixel circle inside of every button, it basically only touches, but it does not overlap with other clickable areas or their circle.

And so that passes.

And on the bottom, there's a fail, so there's no space between the 20 by 20 pixel icons.

And so a circle would intersect between the individual buttons.

And so this would be a fail.

And so, yeah, that's basically what you do, 24 by 24 pixel target sizes.

Now you might say, wait a minute, we already had a target size success criteria on 255.

What's happened to that?

Well, that was a 44 pixel by 44 pixel requirement, and that is level AAA, and it's still there.

It just got renamed a little bit into target size enhanced, because this is now target size minimum.

Not a big deal.

The new SCN guideline 3.2 predictable is consistent help.

And that basically says when there is a help mechanism on the page that is repeated across different pages, then you have to put it in the same space, in the same relative order.

And that's basically what it is.

So if you have a help and it's on every page or on multiple pages, then you want to make sure that users can find it easily.

And the help mechanisms that are covered by this are human contact details, human contact mechanisms.

So this would be like a form, for example, contact form.

Self-help option, like a chatbot or something like that.

Or a fully automated contact mechanism, but I don't really know what that is.

Maybe that's the chatbot.

and the self-help option is just like a database of help-related information.

Yeah, that's all there is in 3.2.

Pretty straightforward.

And I think for most CMS-driven websites, relatively easy to achieve.

New SEs in guideline 3.3 input.

redundant entry, accessible authentication and accessible authentication enhanced. So redundant

entry is pretty straightforward as well. So whenever information previously entered or provided to the

user that is required to be entered again in the same process, you either can auto-populate the

field or it makes it available for the user to select. So this is when you have a checkout

process and it says like "Hey, select your billing address" and then you select that and then "Oh,

select your shipping address". It should offer you, it's not required to offer you the billing

address as a shipping address and stuff like that. So that's pretty nice actually. So that's a good

thing. And there are a couple of exceptions when the information is essential. So when re-entering

the information is essential. So that would be like, oh, it's a safety feature or something like

that. When the information is required to ensure the security of the content. And if the previous

you entered information is no longer valid. So that would be something like you are bidding on

something that you want to like get from like you know an online auction site and you enter a number

and then you have to enter your like payment details and then you have to confirm it.

And if during the time where you put in your first bid and the confirmation at the end, the price has changed, then it doesn't need to give you the previously entered price because that is obviously not going to win you the auction.

So it's no longer valid.

So there might be things like that.

But yeah, that's a good thing.

And it will make it easier for a lot of people to fill out forms and stuff like that.

Then we have accessible authentication and accessible authentication minimum.

And these are very similar.

So the accessible authentication minimum says a cognitive function test, such as remembering a password or solving a puzzle, is not required for any step of the authentication process.

unless that step provides at least one of the following things.

And Accessible Authentication Minimum has four things that you can do instead.

And Accessible Authentication Enhanced has two things that you can do instead.

It's very similar.

And I don't repeat this twice because I helped making it this way.

But I'm really happy about that.

It feels very systematic.

So for the AA and the AAA, you can provide an alternative, another authentication method that does not rely on a function test.

So that would be authenticate through email or through an SMS code or something like that.

Or a mechanism that assists the user in completing the cognitive function test.

I don't know how that would work.

In AA, you also have the option to provide object recognition.

So you recognize objects that are on the page, like fire hydrants or something like that.

Or you provide a way to display personal content to the user and use that as an authentication.

Yeah, the AAA enhanced only has the two alternative and mechanism exceptions or ways to address this, I guess.

And then we're almost at the end.

The only other thing is that one outdated success criterion got removed, 4.1.1 passing.

The reason is basically that a lot of people did that wrong, including me.

interpreted it and like the thing that it tried to fix uh has not been a problem for like over 10

years uh because browsers got better and like the web accessibility and the web standards got better

so this is not needed anymore you shouldn't test for it uh and my recommendation is even if you do

2.0 or 2.1 uh testing just ignore passing like it's not worth it i think the 2.1

Standard even got updated to say that.

And so you just don't care about it.

And if you've never heard about 4.1.1 passing, forget that I even mentioned it.

Like the 4s start with 4.2.1 and that's just how it is.

4.1.2.

They start with 4.1.2 and that's just how it is.

Yeah.

And from this wonderful excursion into WCAG 2.2, let's go back and have a good time.

But that's how it goes.

The end.