WCAG 2.2 - The death of CAPTCHA?
It's been just over 5 years since WCAG 2.1 was released to the world. I often joke that the Internet ages in dog years (or should that be cat years) making 5 years a very long time so it's great to see WCAG 2.2 finally released. It's been a long road for what's arguably a minor update, but for those it affects, it'll be extremely impactful; users with cognitive and/or physical disabilities being particularly well served this time round.
WCAG 2.2 is backwards compatible with WCAG 2.1, with one criterion (4.1.1 Parsing) removed and 9 new criteria added across levels A, AA and AAA.
While it always takes a little time to see how WCAG criteria will work in practice, the new criteria have included helpful persona quotes that help illustrate the issue, making it much clearer as to what the problem might be for a user. It can be difficult to put yourself in the shoes of another, which is a big reason why a lot of accessibility issues on the web exist, so this is a welcome addition!
We've been following along with the development of WCAG 2.2 for a number of years, through W3C working group discussions and release as a draft specification in 2021, so what does it all mean?
The death of CAPTCHA
For me this feels like the most impactful change, especially relevant to the modern web. Accessible Authentication criteria 3.3.8 and 3.3.9 take aim at CAPTCHA and make it very clear that an alternative must be provided and that the alternative itself must also be accessible.
I can't count the number of times that I've been faced with an unreadable selection of letters, seemingly written in the form of hieroglyphics hidden behind 80s splatter paint and static, only to find the audio alternative to be just as illegible. That's just the tip of the CAPTCHA iceberg, rotating pictures of birds, recognising colours, dragging jigsaw pieces and trying to figure out just how much of a spotlight counts as stop light has often left me wondering "Am I a robot?"
It has become commonplace to find organisations including CAPTCHA as though it were some sort of standard, instead of the user-hostile interaction that it is. The fact that CAPTCHAs trigger more often on mobile is particularly damning due to the number of people using a mobile device for the enhanced assistive technology contained within. As a person with a cognitive disability you may think this is just par for the course, but I know I'm not alone and that's before we even get to the internationalisation issues!
Does this mean that CAPTCHA is dead? Probably not, but more consideration to server-side solutions like rate limiting and backend filtering, or alternative methods like Cloudflare.
A smoother future for forms
Another modern design practice impacted is the use of duplicate form fields. You know the type, where you have to enter your email address twice to make sure you didn't make a mistake. Just like CAPTCHA, this will have to change as Redundant Entry criterion 3.3.7 asks that duplicated fields be auto-populated or available for the user to select.
Speaking with a friend at the weekend, he felt this was a bad idea and it increased the likelihood of user error, but I think it opens up new opportunities for creative design. A great example of this would be asking a user to confirm their email is correct on the page, or as some sites already do, sending a verification email that must be actioned before proceeding.
We'll also see this impacting billing/shipping address fields on e-commerce sites and search fields across the web which will need to pre-populate with the previously searched term on search result pages. A lot of e-commerce platforms already allow you to reuse addresses, but every now and again I come across one who thinks they know better, so it'll be great to see this implemented in more places.
A focus on focusing
It would be unfair to say that branding isn't important, but there are times that it takes precedence over user needs, in ways that really aren't all that essential like the humble focus indicator on links and buttons. When I say focus indicator I'm not just talking about the hover state, which can and perhaps could be treated differently, but the indicator you receive when you navigate via keyboard (or equivalent) using the tab and arrow keys to move around.
On a number of browsers, such as Safari, this is a blue outline around the element and although the default indicator may not be particularly high contrast, system, and browser accessibility controls can increase its size and contrast without being affected by day/night mode or additional styles that a user may use to aid reading. A textbook case of "if it ain't broke, don't fix it."
One problem for users occurs when the default indicator is seen as clashing with brand guidelines (despite technically being part of the browser's UI) leading to it being styled with CSS. More often than not, this is an incomplete styling and doesn't consider all the text/background colour combinations and page styles, meaning some focused elements may lack the necessary contrast or overwrite user style sheets, which are essential for users with light sensitivity and multiple reading disabilities.
As you can see, focus indicators can be difficult and criteria 2.4.11 and 2.4.12 offer support to get it right by addressing areas where there's a focus indicator, but it's hidden behind content or a popup, like a modal window. Particular attention will need to be paid to scroll handlers to ensure moving focus will also move the page and on smaller screens (or with larger font sizes) where there's a greater chance for UI elements to overlap.
What comes next?
I expect many developers and designers will be going through the different stages of grief right now before they (hopefully) ultimately accept these changes, but we'll also have to see them adopted by legislation as the UK and EU regulations are currently locked against WCAG 2.1 to Level AA. It's great to see that GDS is already looking to adopt 2.2 into their patterns and I'd recommend anyone who is already committed to WCAG 2.1 to do likewise. The changes in 2.2 make sense and in many cases are really just calling out and refining issues that would have already existed.
If you haven't started your accessibility journey, or you need help implementing any version of WCAG, why not get in touch? CIVIC provides expert-led accessibility services including auditing, testing and training, and together we can help you reach new customers, and engage better those you already have.
