Updated October 9, 2023
Is a new WCAG version a big deal?
WCAG version 2.2 officially became a W3C recommendation in October 2023. For those of us that follow digital accessibility closely, changes to the Web Content Accessibility Guidelines (WCAG) are a pretty big deal. Stability in standards is important so WCAG does not change very often. It has been five years since WCAG version 2.1 was fully released. And WCAG 2.2 is only the fourth version of the guidelines released in the past 25 years.
If you are responsible for a website or digital product, what does it mean for you? Access Armada has already made some small changes to its website in anticipation of the new standards. If you are already following digital accessibility best practices, the impact may be small. WCAG 2.2 is meant to be fully backwards compatible with earlier versions and introduces specific incremental changes in a few key areas.
But WCAG occupies a central role in determining what is considered accessible, so it is definitely worth paying attention to how your site measures up against these new standards. And if you are still relatively new to accessibility, it is worth targeting the latest guidelines from the start.
Subscribe to our Newsletter
What is WCAG?
The Web Content Accessibility Guidelines are widely accepted as the final word in setting standards for what counts as web or digital accessibility. WCAG guidelines are an initiative of the World Wide Web Consortium (W3C), which is responsible for setting standards on the web more broadly.
The US federal government still hasn’t created regulations determining what accessibility standards need to be met by private businesses (or even local and state governments). But in practice, the government uses WCAG as the de facto rules. In lawsuits filed against private businesses for inaccessible websites or apps under the ADA, federal court rulings have used WCAG 2.0 or 2.1 Level AA as their standard.
What’s new in version 2.2?
Let’s start with what hasn’t changed.
W3C is working on a more ambitious overhaul of WCAG (version 3.0) which is planned for release later this decade. But WCAG 2.2 is a minor version change. This means that the existing guidelines and criteria from versions 2.0 and 2.1 are all still in effect. In fact, they are exactly the same word-for-word. So if you are currently in compliance with WCAG 2.1, everything in the new version 2.2 is fully backwards compatible.
But there are some new guidelines. For the most part, these are not brand-new requirements. Instead, the new guidelines extend accessibility principles that are implicit in earlier versions and refine them with explicit guidelines and criteria.
A new focus on focus
For users that rely on keyboard navigation, the browser displays an outline around the interactive element that is currently in focus. Without this outline, it would be impossible for the user to perceive where they are on the page. In WCAG 2.2, the Focus Visible guideline is upgraded to Level A. If you are currently WCAG 2.1 Level AA compliant (which you should be), this doesn’t change anything for you practically. But this change in level represents the increased importance of focus in version 2.2 and there are new guidelines with more detailed instructions for how focus outlines should be implemented.
Focus Appearance
By default, browsers should automatically include a focus outline for all interactive elements. In practice, these defaults often conflict with a site or mobile app design. That means that the focus outline is often hard to make out against low contrast color backgrounds. And custom focus styles can introduce the same problem. The new Focus Appearance guideline (AAA) builds on existing rules to add more clarity around how to make focus states visible. There are multiple ways to meet the new guidelines, but the simplest way is to ensure that focus states are designed as high contrast, solid outlines that fully enclose the element that is in focus. (We covered the new Focus Appearance guideline in more detail here.)
Focus Not Obscured
Even if the focus state is designed in the most visible way, that doesn’t help if it’s covered by something else. The new Focus Not Obscured guideline ensures that layered elements on the site like a sticky alert banner or cookie consent widget in the footer do not fully cover up the focus states. For example, if the cookie consent widget covers up the footer navigation links, users might be able to tab into links that are behind the widget. To pass this new guideline, users must ensure that these elements do not cover up focusable content or force users to first close the obscuring element before being able to tab to other page elements.
No need for mouse precision
We’ve addressed the guidelines that support keyboard navigation users. It is also important not to exclude mouse users with limitations in their fine motor control (such as hand tremors). WCAG 2.2 introduces new guidelines that are intended to make it easier to make selections or inputs using a mouse or alternative single pointer input systems.
Less reliance on drag and drop
For example, you may not have considered that drag and drop functionality can be pretty cumbersome for users that have hand tremors or lack the strength to hold a mouse button down while repositioning the pointer accurately. For users that rely on assistive technology such as an eye tracker, using this functionality can be challenging as well. The Dragging Movements guideline requires creating alternatives to dragging. This can include building in functionality to move objects by clicking to select an item and then clicking again to deposit it.
But it’s also perfectly accessible to build in alternative methods directly into the interface. For example, instead of dragging to recenter a map, you can also provide left, right, up, and down buttons to move the view. This requirement is often not relevant to the average site builder, but is very important to consider when installing third party products or widgets on your site.
Minimum link or button target sizes
For users with hand tremors or other difficulties with fine motor controls, it is important to make sure that buttons and other click areas are big enough (and far enough away from other buttons). The goal should be to make it easy to select the relevant button without missing or accidentally clicking something else. But this is also a great example of how accessibility can improve the user experience for everyone.
As mobile touchscreen devices became more common, having large touch targets has long been a best practice. When buttons are too small or close together, it’s easy to accidentally touch the wrong target. And it becomes harder in bumpy environments like on a bus or train. UX and design teams should already be planning their designs around having large enough buttons and other interactive elements on their sites. Google has included large tap targets as a mobile experience scoring parameter for years.
The new Target Size Minimum guideline requires that buttons and other targets be at least 24x24 pixels (or is at least 24 pixels away from nearby targets). But in practice, it’s better to make targets even larger if you can. The AAA version of this guideline sets a minimum size of at least 44x44 pixels.
Reducing cognitive load
Passwords are hard to remember
For those of us that try to use strong, unique, and secure passwords, it’s hard to keep track of them all. And this can be significantly more challenging for those with memory limitations, dyslexia or other limitations. Of course, there are security implications to any changes to login authentication but the new Accessible Authentication guideline offers a number of alternatives or mechanisms to allow users to login without having to remember a password (or solve a puzzle). You may already support some of these options including allowing users to paste in passwords, use autocomplete or a password manager or offer a 2 factor authentication method that can be activated via click or biometrics. This is another area where it is important to evaluate Single Sign On (SSO) vendors to ensure that their solutions are accessible (including ensuring that they do not force users to solve CAPTCHAs to login).
Don’t force users to enter information twice
When an app or purchase process requires you to enter the same information multiple times, it can be very annoying for everyone. For users with cognitive or memory difficulties, it can be a significant barrier to completing the process. Many apps already support solutions to this problem such as a “Billing address is same as shipping address” checkbox. The Redundant Entry guideline requires prefilling information that has already been provided or making it easily available for the user to select or copy.
Providing consistent UX
The new Consistent Help aims to reduce opportunities for confusion by making sure that help mechanisms on a site can always be found in the same location. This guideline builds on existing rules around keeping the user experience and navigation the same across your site. Help mechanisms might include a phone number, contact button or form, chatbot, FAQ, or hours of operation. For example, if the phone number is on the upper right corner on the homepage, it should not be moved to a different location on another page. While providing help mechanisms is always a good idea, this guideline doesn’t require that you do so. (But if you do, it’s important to make sure it’s easy to find.)
What should you do?
While WCAG 2.2 is now official, you probably have a little bit of time before regulatory bodies and courts adopt it. If you are otherwise compliant with WCAG 2.1, you should be in pretty good shape. You may even already be in compliance with many of these new 2.2 guidelines based on your past accessibility or usability work.
Our recommendation is to review the guidelines, identify your accessibility gaps and build out a medium term roadmap for how you can address the necessary improvements. It may also take third-party widgets, tools and products some time to come into compliance with the new standards. Some of the fixes are likely to be simple. But if you do need to replace or upgrade third-party products, you may need a little while to find and implement a WCAG 2.2 compliant alternative.
If you are just starting your accessibility journey, there is no time like the present. This is a great opportunity to leapfrog straight to the latest and greatest in accessibility. We recommend including WCAG 2.2 guidelines in your upcoming audits and as part of the accessibility improvements on your roadmap.
