The waiting is over, WCAG 2.2 (opens in new window) is a W3C Recommendation from 5th of October 2023. This means that we got 9 new success criteria and basically also means that 4.1.1 Parsing is a bit strange. This post is just a brief reflection with a personal touch, please check the official favorite asked questions for more info (opens in new window).
WCAG 2.2 brings 9 new success criteria
I am not a lawyer, this is not legal advice and I can’t tell you when, but I am certain that WCAG 2.2 will be a part of existing legislation and compliance. I think that it will happen quite soon, but don’t wait and start with implementing WCAG 2.2 now (at least on level A and AA).
We got 2 new success criteria on level A, 4 new success criteria on level AA and 3 new success criteria on level AAA. So compliance-wise (usually levels A and AA required), we need to think at least about 6 new criteria. 2 of them are not very common for an average website but needs checking anyways (dragging movements and enhanced accessible authentication).
Two new WCAG 2.2 success criteria on level A
3.2.6 Consistent Help and 3.3.7 Redundant Entry are two new success criteria on level A that should be extremely easy to check and also implement.
Users like consistent experience on websites and in apps, so it should be logical for designers and developers to find information about help in the same place. Please check 3.2.6 Consistent Help (opens in new window).
Forms are essential for data input and I don’t think that I met a person that was happy if form required them to input same data multiple times. 3.3.7 Redundant Entry (opens in new window) was obviously needed because developers and designers didn’t think about that. So now we have it.
Four new WCAG 2.2 success criteria on level AA
2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum) are new success criteria on level AA.
2.4.11 Focus Not Obscured (Minimum, opens in new window) will require developers to account for never hiding focus, which can happen when we use sticky and other elements that cover parts of the user interface.
2.5.7 Dragging Movements (opens in new window) will enable users that have difficulties with custom dragging interactions (or maybe just prefer more efficient methods) to use the interface with an alternative. Accessibility is about alternatives, so that most of us can use interfaces.
2.5.8 Target Size (Minimum, opens in new window) was much wanted for a long time and it finally arrived. I will not go into details about how it could be even better (read bigger minimum requirement), but it is still a step forward in my opinion. Making interactive elements easier to use is always positive.
3.3.8 Accessible Authentication (Minimum, opens in new window) will cover some cases that will improve usability for many of us. As an example: remembering complex one time codes in long number format for people with dyslexia, dyscalculia, issues with short time memories and so on can be a huge barrier. Making it simpler and still secure should be a priority in all products.
Three new WCAG 2.2 success criteria on level AAA
AAA level can be sometimes difficult to achieve. That’s also why it’s normal to skip it in legislation. But still, sometimes we should consider success criteria on level AAA to make our products more usable and accessible. And WCAG 2.2 success criteria on level AAA are an example on how AA is often just a baseline and we should check the benefits of AAA.
2.4.12 Focus Not Obscured (Enhanced, opens in new window) makes focus indication always wholly visible. This one should probably be on your list to realize even if it is an AAA level. Visible focus is essential for a lot of users that can’t or won’t use mouse or touch.
2.4.13 Focus Appearance (opens in new window) is also making sure focus is visible and has good contrast, so I will also suggest striving to make it a part of your design and development.
3.3.9 Accessible Authentication (Enhanced, opens in new window) makes authentication even more user friendly and make logins even more accessible with less mental efforts. Providing third party authentication method to login with pressing a button or maybe with a PIN code or fingerprint on your device as an alternative will for surely add to usability and make your product even more attractive to more users.
Success criterion 4.1.1 Parsing – rest in peace
Success criterion 4.1.1 is not entirely removed from WCAG 2.2 as it still exists there as a note. It is only there to remind us that it is actually obsolete and removed.
This criterion was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria. This criterion no longer has utility and is removed.
WCAG 2.2 Success Criterion 4.1.1 Parsing (Obsolete and removed) – note (opens in new window).
As it takes time for legislation to incorporate WCAG 2.2 instead of WCAG 2.1 or even WCAG 2.0 we also have to look at the change in those two.
Both WCAG 2.1 and WCAG 2.0 now include a note from a conformance perspective which states that 4.1.1 should be considered as always satisfied for any content using HTML or XML. This basically means that we can’t fail 4.1.1 even if we find issues that failed it before. We have to check what other success criteria are failing as a consequence though.
A duplicate value of an id attribute on same page may or may not mean accessibility issue. If id is used as a reference in ARIA (like for example aria-labelledby value) we may report it as failing Success criterion 1.3.1 (if info and relationships are wrong because of it).
Duplicate value of id attributes on same page will now have to be verified if they fail other success criteria (for example 1.3.1 or 4.1.2), but we can’t fail 4.1.1 any more.
Just a quick reflection on consequences of symptoms on a page that failed 4.1.1 previously.
Personally I will still note the findings as duplicate id value (as an example) can actually cause major bugs for all users (when used as JavaScript hooks, for example).
I almost always found problems on complex pages that failed 4.1.1, and it felt right to check HTML validation, but I do agree that browsers just made the page work even if those errors were there. From the point of accessibility it also makes sense to drop 4.1.1 as assistive technology don’t parse HTML anymore and acquires information from accessibility tree anyways.