WCAG 2.2: What changes for websites and how does it impact users?
WCAG 2.2: What changes for websites and how does it impact users?
Estimated read time: 10 minutes
The Web Content Accessibility Guidelines (WCAG) are an international standard for making web content accessible to people with disabilities. An updated version of WCAG – version 2.2 with 9 new success criteria and one promoted from AA to A – is expected to become the official standard in the summer of 2021. These updates focus on added guidance to help users with cognitive challenges, added criteria for eBooks and other types of digitized media, and new helpful guidelines especially for touchscreens and mobile platforms.
WCAG 2.2 follows the same theme of WCAG 2.1 – improving accessibility for three groups:
users with cognitive or learning disabilities
users with low vision
users with disabilities on mobile devices
I’m Kate – an IAAP (International Association of Accessibility Professionals) certified Web Accessibility Specialist and I work with Sam – an expert screen reader user. We both work for Fable, a leading accessibility testing platform powered by people with disabilities. While the W3C is an extremely thorough technical document, we thought it might be helpful to create a plain language summary of these changes, focused on required actions and resulting impact.
At Fable, we believe organizations should go beyond accessibility guidelines to create exceptional and accessible user experiences. However, WCAG compliance is often embedded into accessibility legislation, so it’s useful to understand what’s needed to comply and what the outcome should be.
We’re going to review WCAG 2.2 from two perspectives:
Organizations that want to meet the new level A and AA guidelines
How assistive technology users will benefit from the new guidelines
Note: we’re only going to cover changes that impact A and AA compliance, not AAA. Level AA compliance is widely considered the globally accepted minimum standard, based on various accessibility laws. We’ve done our best to ensure we’re accurately interpreting 2.2, but please make sure you’re also using the official W3C WCAG 2.2 reference document.
This success criterion is not new, but it is being promoted from AA to A.
You could use the default browser focus state (but make sure you haven’t removed them using “outline: none” in your CSS).
Alternatively, you can create your own highly visible focus states (which are even better than the browser defaults which aren’t always highly visible). Reversing the link colour and background on focus is a great way to maintain your branding in focus states. Adding a thick border can also work well. Or even combining the two approaches can work.
The Effect on People with Disabilities: Where am I?
This reflects just how important it is for people who can see and use a keyboard to know where the focus is at all times. It’s nearly impossible to navigate without seeing what you are currently focused on.
To meet this new success criterion, update your design system focus states to include:
1 pixel or greater border around the entire focused element OR
8 pixel or greater border on the shortest side
Colour change with 3 to 1 contrast difference from unfocused state
3 to 1 contrast with all background colours OR 2 pixel or greater border around the entire focused element
Make sure that when focusable elements are taken out of the design system and used on your website or app that the focus indicator (i.e., border) is not hidden or overlapping with other elements on the screen.
Supply alternatives to dragging in a user interface, unless dragging is essential. For example, ensure users can adjust the price range of a search filter using + and – buttons or entering a number in an input field instead of dragging a slider.
The Effect on People with Disabilities: Everyone wants to reorder things
From apps on a homepage, to items in a queue or list, dragging to reorder is a fundamental interaction. It can be used to design, show priority, or order of action. It’s critical that people with disabilities who can’t drag with a mouse are not left out of this method of interaction. Thanks to this guideline, People with Disabilities will no longer be left out of interactions that, today, commonly require dragging with a mouse.
Leave room around focusable elements that aren’t inline. This includes navigation links, buttons, form fields, but not links within paragraphs.
Small targets that are less than 44 pixels in width or height must have at least a 44-pixel high and wide selection area. For example, a 24-pixel square icon needs 10 pixels of padding on all sides (10 + 24 + 10 = 44).
Alternately, you can provide users with a way to enlarge elements so that they are at least 44 pixels in width and height.
Effect on People with Disabilities: Make sure everyone can click
Loss of dexterity is one of the most common symptoms of aging. This guideline helps make sure the interface you create today will work for you in 25 years and will work for everyone else right now. As well, this is critical for users on mobile devices, who may just have larger fingers, or slightly less hand-eye coordination, to ensure that everyone can touch what they intended to.
If you provide contact information (forms, emails, phone, chatbots, etc.), put it in the same place on every page of your website or app both visually and in the code.
Effect on People with Disabilities: Something will go wrong
Murphy’s law: if it can go wrong, it will go wrong. And when it does go wrong, that can be a stressful, difficult experience. The easier it is for someone to find help, the better the experience they will have, and the less they will even remember the problem in future. As well, someone who is less stressed is easier for your customer service to help. Lastly, even when we don’t wind up needing any help at all, the confidence boost of knowing where help is if we want it goes a long way!
Don’t hide controls that are critical to a process behind a hover or focus state. For example, you can’t have a checkout button that displays only if you hover over “view order total.” Usability testing is a great way to catch anything that will slow a user down in completing a process.
Make sure your user testing participants include people with various levels of technical capability, i.e., novices, intermediate, and expert
Don’t force users to remember and manually type in their password for authentication. Allow users to copy and paste a password into form fields or use a password manager tool.
Alternately, allow users to authenticate using their device face scan, fingerprint, or PIN number. You can also allow users to authenticate using a third-party provider using OAuth. Two-factor authentication with USB that allows users to press a button instead of typing in a unique code is another option.
The more ways users can authenticate, the more likely it becomes that all users will find a way that works best for them.
Effect on People with Disabilities: Don’t Make Me Think
People with disabilities can struggle with cognitive issues. We can also just have a lot going on that, like everyone else, makes things harder. Making sure we can copy and paste our passwords, or use our password manager of choice, and that we don’t have to enter the same information multiple times, can make online interactions twice as fast as otherwise, and half as stressful, letting everyone get on with our day. As well, the easier it is to log-in, the easier it becomes to keep our accounts secure from third parties.
In a process with multiple steps, don’t force users to re-enter the same information more than once. For example, allow users to specify that billing address is the same as shipping address instead of re-entering it. Auto-populate fields with data that the user has stored in their browser whenever possible.
Exceptions include essential re-entry such as validating a password for security purposes.
Effect on People with Disabilities: Speed and Accuracy
Users of assistive technology can already struggle with on-screen keyboards that are slower than we would like, voice dictation that is imperfect, websites that threaten to log us out if we’re too slow, and so-on. By making sure information only needs to be entered once, you ensure not only that the interaction is faster and less stressful, but that we have the time and capacity to ensure that the information we do need to enter is complete and accurate.
Conclusion and takeaways
As the Web Content Accessibility Guidelines continue to grow in length and complexity, it’s more important than ever to test with users of assistive technology to ensure you’re not missing anything critical.
Fable’s accessibility testing platform powered by people with disabilities can help you to understand:
where the barriers to accessibility are in your digital products,
how to prioritize fixing them, and
how to avoid creating them in the first place.
Conclusion from A Person with A Disability: New Changes, Same Theme
While these changes may seem a bit overwhelming at first, hopefully this article has gone some way to help you clarify what you need to do, and what the impact will be. However, when thinking about accessibility beyond compliance, it becomes clear that the latest W3C guidelines are just variations on a theme. The theme is removing barriers and making access possible for everyone.
The W3C guidelines are enormously helpful in this work, but they’re not the end. If you notice a barrier in your product or design, don’t wait for a W3C guideline before removing it! Testing with real users can help you discover those barriers and working with users can also guide you towards the best way to remove them.
Kate Kalcevich is Head of Services at Fable. Kalcevich is an experienced accessibility leader and disability advocate with an extensive career. She most recently led digital accessibility efforts at Canada Post. Previously, Kalcevich held a series of progressively senior roles in the Ontario public service, including in product, user experience, and design roles. In recent years, she has focused on change management to increase the accessibility capabilities of organizations.