Four years have passed since we last had an update to the W3C’s Web Content Accessibility Guidelines. Now, within the next few weeks, we are on the threshold of WCAG 2.2 receiving approval from the Web Gods.
The previous update, in June 2018, asked us to calm down and look again at how we were using all the exciting new capabilities of our smart devices: accelerometers, multi-touch screens, voice input. Version 2.2, on the other hand, asks us to go back to the basics with a short list of criteria lots of us have been getting wrong for a while – and, as usual, a few pitfalls to avoid.
So let’s light up that burning bush and see what’s in store for us this time.
Thou shalt not obscure focus
A full third of the changes relate to the visibility of the focus indicator, commonly relied on by people who use the keyboard to navigate around pages and applications.
Firstly, the existing requirement to simply have a visible focus indicator has been promoted from Level AA to Level A. This old timer is now flanked by a pair of surly henchmen known as Focus Appearance and Focus Not Obscured, both Level AA. Focus Appearance asks that focus is not just there, but that it meets certain visual criteria – including explicit colour contrast requirements. Focus Not Obscured wants to see indicator unimpeded by elements like sticky headers or lightboxes; and it has a Level AAA cousin that’s even stricter.
To avoid falling foul of the Focus Twins and their boss, you’ll want to audit all your focus states to ensure they meet the new visual criteria (this is already one of the most common failures we see when auditing third-party sites at Appius). If your site is heavily branded, consider involving your designers early in this process. New size and colour requirements make it likely the visual appearance of some states may need to change quite substantially. If you’re not already, make sure your developers are using the smart :focus-visible selector to reduce the impact of any of these changes for non-keyboard users.
Thou shalt not require fiddly inputs
Time for a couple for all you mouse and touch fans out there.
Almost unbelievably, up to this point there was no official guideline on the minimum size of a clickable element. That changes with the new Target Size criterion, a victory for sausage-fingers everywhere.
The 24px by 24px recommendation follows long-standing UX best practice, so it’s unlikely to trip up many. If you do target Level AA then it’s worth double-checking the dimensions of any key navigation elements and icon-based buttons, taking note of a number of exceptions granted for equivalent, inline and essential elements.
Related to this is the new criterion for Dragging Movements. Essentially this asks for an alternative way to operate any drag-and-drop style interface using single clicks (or taps). This is in addition to existing criteria for keyboard support.
As a relatively uncommon method of interaction on the web this criterion is less likely to affect you – but if it does, this could be one area that requires a little more thought and effort to put right.
Thou shalt grant help consistently
Consistent Help says that when you include help mechanisms such as a contact phone number or a live chat interface across multiple pages, they should always appear in the same relative position.
Now this might sound a little scary for a Level A guideline, but the bar is actually quite low. This is again based on some pretty well-established UX principles, so it’s likely you’re already compliant to some extent. The authors are careful to point out that this criterion does not dictate the visual position or, in fact, the presence of any help element on the page. If you have any sort of ‘Help’ link in your header or footer, you're most of the way there already.
Thou shalt avoid repetitive questions
The new Redundant Entry criterion, also Level A, is relevant for anyone with processes involving user input. The idea here is to avoid asking users to enter the same information multiple times (with exceptions for where it is essential or for security reasons, such as a password double-entry field).
Think about journeys like checkouts, which potentially ask for both a shipping address and a billing address. For optimal accessibility, you should ask for the address once, then provide the option to re-use that information again later using a checkbox, dropdown or similar (note that browser autofill isn’t sufficient here, as it’s about what the user has entered rather than what they have stored in their browser). Like most guidelines, this has benefits not just in terms of accessibility, but also data quality and user experience.
During your next review keep a lookout for any time you ask the same question multiple times. If you can avoid doing that, all the better. If you can’t, it’s worth looking into the details of this criterion to see how to provide the most accessible solution for your particular use case.
Thou shalt make it easy to log in
You’re going to read articles about this one, with headlines like “Your login form fails accessibility” and “W3C announces the death of passwords”. As usual, the truth of the new Accessible Authentication criteria – coming in at Level AA and enhanced at Level AAA – is a bit more nuanced.
In short, if you have a username and password based login form then you’ll want to make sure those fields are labelled to provide compatibility with password managers (which, let’s face it, you should be doing already if you’re following other guidelines).
If your login process is more complex then there are some additional areas to watch out for:
- If you use CAPTCHAs they should be no more mentally taxing than a basic object recognition test (so character-based recognition is not compliant, even if paired with an audio alternative).
- If you use mandatory multi-factor authentication then you’ll also need to allow users to verify without having to re-type an authentication code. Scanning QR codes or using on-device biometrics are all good, but asking the user to transcribe anything – no matter how short – will no longer cut it.
Prepare for some potentially difficult conversations about security in this area and remember: the idea that user experience and security are somehow at odds with one another is provably false. W3C provide plenty of practical examples and resources to arm yourself with, should you find yourself fighting this battle with an overzealous IT department.
I hope you’ve found this roundup of the changes in WCAG 2.2 enlightening. If you’d like to learn more about the accessibility of your own site then please get in touch. We regularly carry out accessibility audits and we’d be happy to help, whether for a quick health check against these latest changes or as a complete first-time audit.
SUBMIT YOUR COMMENT