It’s January 2023 and there is a new WCAG 2.2 Candidate Recommendation Draft (which apparently is a different type of document from the September Candidate Recommendation Snapshot). Here is a diff between these two versions for your convenience.

Table of Contents

• About the ratings
• 2.4.13 Focus Appearance (Level AAA)
  • Update 7 February 2023
  • Update 2 June 2023
• 2.4.11 Focus Not Obscured (Minimum) (Level AA)
• 2.4.13 Focus Not Obscured (Enhanced) (Level AAA)
• 2.5.7 Dragging Movements (Level AA)
• 2.5.8 Target Size (Minimum) (Level AA)
  • Update 3 February 2023
• 3.2.6 Consistent Help (Level A)
• 3.3.7 Redundant Entry (Level A)
  • Update 4 February 2023
• 3.3.8 Accessible Authentication (Level AA)
• 3.3.9 Accessible Authentication (Enhanced) (Level AAA)
• 4.1.1 Parsing (Obsolete and removed) (Level A)
• Conclusion

About the ratings

I judge the success criteria by different categories:

• Understandability: For me, this is the most important criterion for the success of an SC. If it is hard to understand, it will mean that people will have a hard time learning and internalizing the SC.
• Teachability: While this seems to be closely related to understandability, it is a slightly different aspect that I find critical. Sometimes hard to understand concepts can be easily taught.
• Testability: How much will this change affect testing. Is it a massive burden, or is it something that you can test with other tests.
• Impact: How much will this change improve the lives of disabled people?

All four categories will be graded on a scale of zero to five, where five is the best possible rating. Of course, this is far from scientific, but I try to explain my ratings in (excruciating) detail!

2.4.13 Focus Appearance (Level AAA)

What this SC does: 2.4.11 is supposed to make clear what “visible” means for 2.4.7 Focus Visible. It defines the area that the visible focus needs to cover and how much contrast there needs to be towards adjacent colors.

Rating: This success criterion is a mess. You can see the ambition of the Working Group to finally fix 2.4.7 Focus Visible, but the resulting SC just is not very good. And it hasn’t changed since September. It introduces four new definitions and has various sub-rules. There are different requirements for when the entire focus indicator encloses the UI component in question or when it only partly does so. Sometimes it must meet a 3:1 contrast ratio unless a certain thickness is met. There are no obvious fail cases this way and also no obvious pass cases because one pixel that doesn’t meet the 3:1 contrast ratio means that a different calculation needs to be used. This SC is still at risk and I wished it was either split up or replaced with easier to understand and test guidance. (More in the conclusion below!)

• Understandability: 0 — You can read this Success Criterion many, many times, and you will always find new ways to combine the different clauses which upend your previous assumption of what is a pass or a fail.
• Teachability: 0 — I think I can give most people a good overview on what any success criterion is and how to apply it in practice (be it an implementor or tester) in an hour. For this, I don’t even know where to start. I usually try to summarize a success criterion in one sentence and then spiral out into exceptions and particularities of an SC from there. Here, apart from “defines the appearance of the focus in many ways” I don’t even know where to start.
• Testability: 2 — This is generous. I think that the different descriptions will help to determine relatively exactly if something meets the SC or not. That said, it will be a lot of work to go through every focusable element and see if they meet the SC or if a vital part of the visible focus does not meet the SC. I would expect that this can add hours to some complex pages.
• Impact: 5 — Obviously, having a visible focus is super important. Having this guidance in WCAG 2.2 is long overdue.
• Verdict: 7/20

Update 7 February 2023

Alastair Campbell has published a post explaining the SC. I appreciate the blog post, but it does actually show what the issue here is. his examples are all clear-cut and isolated examples. It is a good introduction for implementers, but it does little for testers. I think this is exemplary by this quote:

For example, a 25 by 100px button requires an indicator area of 25+25+100+100 = 150px.
Technically we need to take off 4px for the corners as they overlap, so it is 146px. However, if you are relying on 4 pixels you have bigger problems. If it is that close, pick a different indicator!

As a tester, it is not on me to chose that. I need to measure it. And if there is a difference of 4px, I need to understand that. I would argue that, if 4px out of an area of 150px doesn’t matter, why insist including it in the definition. Why go through the length of defining a perimeter? The reason is that a CSS outline works that way, the four pixels in the corners are shared between vertical and horizontal borders/outlines.

So those four pixels matter a lot to make it easy to conform in simple instances. Because if we don’t account for those four pixels, the focus definition of outline: 1px solid black would not conform on a white background.

Testers must understand this. That’s why I say that this SC has very intricate new concepts testers must understand making a decision on conformance.

The next example shows a four pixel thick left line next to the text “Example 2”. The text is on a grey background. Considering that this example is about the perimeter rule, the whole height of the link or button is apparently set by the background color. With a star or a circle, the perimeter would follow the exact visual outline of the shape. Here, the faint grey background is counted as part of the shape. Would the perimeter apply only to the text height, if there was no background color? I think so (but I might be wrong). If that was the case, changing the background of a component from white to just off-white would change its focus indicator requirement.

Another example is “Easy to assess passes”, example 3. A white button with black text whose focus style is an inverted color scheme: black button with white text. It’s probably one of the most common examples of a good focus style. But there is nothing in the SC that screams that makes this pass obvious. It passes clause 2 as on focus, 100% of all pixels change color with sufficient contrast, which is more than the pixels needed.

Of course, I can teach those clear examples, but that is not where the rubber meets the road when doing testing and teaching. Even for the clear examples, I need to clearly rationalize why the elements conform. This is especially important when we get to learn new success criteria.

And of course these examples are isolated cases. What happens if a specific style does not meet the SC – even barely – in one case and does meet it in another. That can easily happen when the size of the element changes. What is sufficient in a menu in one language, might not meet the SC in a language with longer words. It adds a lot of complexity to WCAG.

I don’t think this SC will change. “It’s not that bad” is what I have been hearing for a long time now. I and others disagree, but it won’t matter. I think the best case scenario is that everyone will test for the obvious scenarios and then ignore everything that is non-obvious or close enough. And that will probably be OK.

Update 2 June 2023

In the WCAG 2.2 Recommendation Draft update from 17 May 2023 has been demoted to an AAA Success Criterion, which also meant moving it behind the Focus Not Obscured Success Criteria. So this goes from 2.4.11 to 2.4.13.¹ I have changed the headings, left the previous IDs in place (hashtag cool URIs never change) and I won’t reorder the SCs here.

It was also altered again, because why not.

In addition, 1.4.7 is back on AA level again. I guess a visible focus is not that important after all!

2.4.11 Focus Not Obscured (Minimum) (Level AA)

What this SC does: If something receives focus, it can’t be entirely hidden by website content. (Here, you just learned all there is to this success criterion.)

Rating: This is a needed SC. We often see that cookie banners or other messages are on top of focused content.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 4 — This would have gotten a score of 5 if it was an A criterion. I think it’s simple enough to do that it should be a baseline accessibility requirement.
• Verdict: 19/20 — This is a perfect SC. Short, to the point, easy to understand and implement. More of this.

2.4.13 Focus Not Obscured (Enhanced) (Level AAA)

What this SC does: If something receives focus, no part of it can be hidden by website content.

Rating: This is a perfect step up from the AA SC with the same name.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 3 — I think AAA is the right level for this SC, but I could have seen it as an AA criterion as well. As an AAA criterion, its impact is limited.
• Verdict: 18/20

2.5.7 Dragging Movements (Level AA)

What this SC does: Provide an alternative for dragging actions.

Rating: This is also a pretty straightforward SC. The only slight complication is the definition of what “dragging movement” is. Testing is all manual, but dragging is relatively rare and alternatives are usually pretty obvious. Well done!

• Understandability: 4
• Teachability: 5
• Testability: 5
• Impact: 5
• Verdict: 19/20

2.5.8 Target Size (Minimum) (Level AA)

What this SC does: Defines a minimum size for interactive elements (24px by 24px) with some exception when there is enough space around the element or when it is part of a sentence.

Rating: We had 2.5.5 Target Size on level AAA in WCAG 2.1 and having some minimum is certainly good. 24px is a little small for my taste, but it’s always hard to strike the balance here. What I don’t like is that the exceptions are worded differently between the two SCs and I would love to adopt the 2.5.8 wording in the renamed 2.5.5 Target Size (Enhanced) SC.

Teaching could be a little better as there are a lot of exceptions. The definition of target offset is outrageously complicated. (Basically, when two targets are next to each other, the targets can be less than 24px large, as long as the space between the side furthest away of one target is 24px to the nearest side of the second target). Testing can be done in general automatically, with manual reviews for the exceptions. The impact I rated relatively low because such small UI components are relatively uncommon.

Update 3 February 2023

After reading through more issues (particularly w3c/wcag#2972, w3c/wcag#2973, and w3c/wcag#2974) with target offset, I think I need to deduct one point each from Understandability and Teachability, as well as Testability. This is more complicated than it looks and while irregular shapes are rare, their testing will be a significant head-scratcher.

• Understandability: 3 (was: 4)
• Teachability: 2 (was: 3)
• Testability: 4 (was: 5)
• Impact: 3
• Verdict: 12/20

3.2.6 Consistent Help (Level A)

What this SC does: Requires that help mechanisms that repeat on multiple pages are in the same place.

Rating: This is a little nothing burger of a Success Criterion, as usually most mainstream website already meet this and it doesn’t elevate the need for good accessible help mechanisms. I think the name is misleading (similar to Consistent Navigation and Identification) because it is not the help that needs to be consistent, but its placement or order. So Consistent Help Position or something would make this much easier to understand at a glance. This SC has also a note on “same relative order” which explains what is meant with this phrase. Maybe this should better be a normative definition that can also be applied to other “same relative order” SCs?

• Understandability: 4
• Teachability: 5
• Testability: 5
• Impact: 1
• Verdict: 15/20

3.3.7 Redundant Entry (Level A)

What this SC does: Requires that users do not need to enter information again, when they have already provided that data.

Rating: The intent and the wording of this SC is pretty good, and I like that it is on the A level. It makes a lot of sense. It will improve data submission for everyone with a disability. The only ding is the short name, because it should say “No Redundant Entry”. But I won’t deduct points for that!

Update 4 February 2023

Patrick H. Lauke makes the excellent point that the impact of the SC is limited by the fact that it is scoped to the current process. Feels like this should have a companion AA SC that avoids that any users have to enter redundant information in any processes.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 4 (was: 5)
• Verdict: 19/20

3.3.8 Accessible Authentication (Level AA)

What this SC does: Improves accessibility by avoiding cognitive function tests in password authentication flows …

Rating: … unless it is a cognitive function test that is covered by exceptions. And those exceptions explicitly allow the use of CAPTCHAs where you recognize objects. It does not define what the “objects” can be that need to be recognized. I remember that ReCaptcha asked me to identify fire hydrants, and none looked like German hydrants. I’m not sure if this is really a significant improvement for users with cognitive impairments. It’s also not specified that you need an accessible alternative for the CAPTCHA, tho that would be covered by other SCs, I guess.

Testing if some login flow meets this SC will be relatively cumbersome but doable. I expect significant discussions on what a “mechanism to assist the user” is. I don’t know how feasible it is to use content uploaded to the website as a form of authentication.

• Understandability: 4
• Teachability: 4
• Testability: 4
• Impact: 3
• Verdict: 15/20

3.3.9 Accessible Authentication (Enhanced) (Level AAA)

What this SC does: Improves accessibility by avoiding cognitive function tests in password authentication flows …

Rating: … but with fewer exceptions. CAPTCHAs are not allowed, and you cannot make the user identify content they provided to the site.

• Understandability: 4
• Teachability: 4
• Testability: 4
• Impact: 2
• Verdict: 14/20

4.1.1 Parsing (Obsolete and removed) (Level A)

What this SC does: Nothing! It has been removed as it is now obsolete with the modern HTML parsers.

Rating: In the end, removing this SC is the clear-cut decision that we need from the WCAG WG. Without institutional knowledge, many people interpreted “nested according to specification” that it required HTML elements to be “nested according to the HTML specification”, not to the XML parsing rules. Of course, the latter makes much more sense 😉

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 5
• Verdict: 20/20

Conclusion

This gives us the following scores for the success criteria, from best to worst:

• 20 Points
  • 4.1.1 Parsing
• 19 Points
  • 2.4.12 Focus Not Obscured (Minimum)
  • 2.5.7 Dragging Movements
  • 3.3.7 Redundant Entry
• 18 Points
  • 2.4.13 Focus Not Obscured (Enhanced)
• 15 Points
  • 3.2.6 Consistent Help
  • 3.3.8 Accessible Authentication
• 14 Points
  • 3.3.9 Accessible Authentication (Enhanced)
• 12 Points
  • 2.5.8 Target Size (Minimum)
• 7 Points
  • 2.4.11 Focus Appearance

What does that tell us? Not much. I’m personally disappointed that 2.4.11 Focus Appearance has not improved at all since September. I don’t want this Success Criterion to be removed, but it will also be a pain to implement. The Working Group can do better. Split it up in multiple SCs, try not to cover every edge case. There is an exercise going on where the Working Group tries to figure out if 2.4.11’s complexity and reliability. Maybe this SC can be removed from 2.2 and reintroduced in six months in a 2.3 update. Individual SCs should never hold up updates.

Support Eric’s independent work

I'm a web accessibility professional who cares deeply about inclusion and an open web for everyone. I work with Axess Lab as an accessibility specialist. Previously, I worked with Knowbility, the World Wide Web Consortium, and Aktion Mensch. In this blog I publish my own thoughts and research about the web industry.

Sign up for a €5/Month Membership Subscribe to the Infrequent Newsletter Follow me on Mastodon

I’m really not sure what the best way forward is. On one hand, most of the updates feel OK as test criteria but don’t really push accessibility forward. Perhaps that is the strategy here. I think with good leadership, WCAG 2 has good guts to go for another decade. But the Working Group needs to be willing and able to simplify, clarify and modernize the standard.

I’m not a big fan of creating a major revision just for the sake of it. We’re only two versions into WCAG 2, and it held up well. I did propose fixing web accessibility in a more systematic way in 2021. I still think it’s important to re-evaluate how we want web accessibility to succeed.