What’s new in WCAG 2.2?
On October 5th, the 2.2 update of the Web Content Accessibility Guidelines (WCAG) was released. We know you don't feel like rereading all the WCAGs, so we've summarized everything that has changed compared to previous versions for you!
Most of the updates are just formalizations of practices that were already considered best practices. The biggest novelty concerns registration and authentication flows.
The first news is the deprecation of Success Criterion 4.1.1 Parsing. The reason is that the evolution of browsers and assistive technologies has made it obsolete.
More Emphasis on Focus Visibility
Focus visibility was already addressed in Success Criterion 2.4.7 Focus Visible, Level AA. WCAG 2.2 extends the requirement, specifying that not only must the interactive element have a focus state, but it must also be at least partially visible and not covered by other components (Success Criterion 2.4.11 Focus not Obscured, Minimum, Level AA).
At the AAA level, it is further enhanced, indicating that the element must be completely visible (Success Criterion 2.4.12 Focus not Obscured, Enhanced) and, more interestingly, that the focus style must meet certain criteria (Success Criterion 2.4.13 Focus Appearance).
It specifies the minimum area and minimum contrast that the focus style must have (2 pixels compared to the perimeter of the component and 3:1 contrast ratio).
Dragging and Target Size
The first concerns dragging (and therefore sliders!) and requires the same action to be performed with a single click or through an input field that allows the specification of the same value.
The second requires that clickable areas have at least a size of 24x24 pixels or at least be enclosed in an empty area of 24x24 pixels. This was already a well-established best practice that had not yet been formalized within the WCAG.
Although the WCAG only talks about empty areas inside the component, it is still preferable for this area to be clickable.
Success Criterion 3.2.6 Consistent Help is added following the concept behind the 3.2.3 Consistent Navigation. This criterion requires the navigation to be consistent within a group of similar pages. Criterion 3.2.6 extends the requirement for help mechanisms like contacts, FAQ links, or chatbots.
Success Criterion 3.3.7 Redundant Entry, Level A, encourages limiting situations where users must enter the same data more than once. The solution is using pre-populated fields. This, in addition to being an accessibility criterion, is also a best practice in user experience.
Registration and Authentication
Two new criteria impact registration and authentication flows: Success Criterion 3.3.8 Accessible Authentication (Minimum), Level AA, Success Criterion 3.3.9 Accessible Authentication (Enhanced), Level AAA.
The first defines that authentication methods based on cognitive tests, including the need to remember a password or a number sequence (including OTPs), should no longer be used. However, it is considered passed if the password field allows browser autofill and if copying and pasting the OTP (even on two different devices) is possible.
The criterion also impacts CAPTCHAs, excluding using all those requiring recognition of letters or mathematical operations. However, those based on image recognition are considered accessible.
The second criterion makes the first more stringent, excluding image recognition from the exceptions.
To conclude, it's evident that prioritizing these two criteria significantly impacts the evolution of authentication methods. The growing adoption of magic links and biometric authentication is a testament to this trend. This shift also aligns seamlessly with the movement towards passwordless authentication, a change that enhances security and greatly improves user accessibility. As we wrap up, the future of authentication is on a promising and user-centric path.