What’s New in WCAG 2.2 and Its Impact
The World Wide Web Consortium is updating its Web Content Accessibility Guidelines (WCAG) from version 2.1 to 2.2. The tentative release is targeted for Q3 2023 (July, August, September), though the release date has slipped for quite some time.
Some of the existing success criteria, or testing checkpoints, will change or be removed and others will be added or modified. I cover the main changes briefly in this blog.
WCAG versions at a glance
WCAG have been around for over 20 years, first focusing on blindness and visual impairment, then mobile experiences. The upcoming release aims to enhance digital experiences for persons with disabilities (PWD), with a focus on cognitive and learning disabilities. Here’s a quick timeline of the WCAG versions:
WCAG 1.0 – May 5, 1999
WCAG 2.0 – Dec 11, 2008 – almost 10 years after 1.0
WCAG 2.1 – June 5, 2018 – almost 10 years after 2.0
WCAG 2.2 – working draft expected Q3 2023 – approximately 5 years after 2.1
What are the new guidelines in WCAG 2.2?
There are six new compliance guidelines. Here’s what they are and what they ensure for users:
2.4.11 - Focus Not Obscured (minimum) (AA) – Elements that receive keyboard focus are not entirely hidden by other UI components such as banners, pop-ups, dialogs, etc.
2.5.7 - Dragging Movements (AA) – Whenever the UI requires dragging movements to perform a function, there must be a single-pointer alternative to perform the same function.
2.5.8 - Target Size (minimum) (AA) – The target size for pointer inputs must meet minimum size requirements or have effective spacing or alternative, unless the target is inline or the target size is essential.
3.2.6 - Consistent Help (A) – Each form of a website’s help mechanisms, such as contact info, FAQs, and search bars, must be presented in a consistent manner from page to page for ease of use.
3.3.7 - Redundant Entry (A) – For any mechanism on the page that requires a user to re-enter previously entered information, ensure that there is a server-side mechanism (meaning: site-level) that allows the user to recall that information, such as an auto-populating field, dropdown selection, or checkbox to confirm using the previous information. Third-party mechanisms, such as browser-level autocomplete features or extensions do not satisfy this requirement since they may not be accessible to all users.
3.3.8 - Accessible Authentication (minimum) (AA) – Cognitive function tests, such as needing to remember a username, password, set of characters or pattern, must have a mechanism available, or support a third-party method, to avoid the need to memorize or transcribe information. The easiest way to satisfy this requirement is to support a password manager and avoid the need to transcribe one-time passwords or tokens from a separate device, so that copy/paste is available. Object recognition tests, such as CAPTCHA or recognizing a picture the user previously uploaded, are exempt from this requirement.
There are also three best practices changes in 2.2 (not required for compliance):
2.4.12 - Focus Not Obscured (Enhanced) (AAA)
2.4.13 - Focus Appearance (AAA)
3.3.9 - Accessible Authentication (Enhanced) (AAA)
Find more information on these best practices, visit the W3C’s What's New in WCAG 2.2 Draft page.
What will be removed in WCAG 2.2?
Just one success criteria will be dropped in 2.2:
4.1.1 - Parsing (A) – In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Parsing pertains to writing clean code so that assistive technologies and browsers can understand it.
Applause’s perspective on the impact of WCAG 2.2
It’s difficult to predict how the changes in 2.2 will impact both organizations seeking compliance and testing firms overall. In WCAG 2.1, we saw the need to test for accessibility compliance increase approximately 15%. WCAG 2.1 had a major impact on bugs, which in turn, had a major impact on development teams. Since 2.2 is a smaller release, we anticipate that customers will adopt it much more quickly.
How will the removal of 4.1.1 Parsing impact organizations?
This success criteria is essentially coding standards checks that have no known user impact. For example, in semantic html, missing an end tag. In WCAG 2.1, we enter those as “low severity” issues. If we found user impact, the issue would be identified while testing on another checkpoint. In addition, for the most part, screen readers and browsers have compensated for these errors, but the guideline was included in 2.1 because there were instances where a new version of a screen reader would be released without consideration for parsing.
In one incident, one of our clients was sued when the plaintiff ran a WAVE web accessibility tool and it logged a few errors. The issue turned out to be a missing tag. The issue was very hard to find because it only impacted a few words. Regardless, it had no impact on users. With parsing gone, these types of legal suits should end.
How will legal organizations pursue compliance after WCAG 2.2?
After WCAG 2.1, many firms were very slow to address compliance. In fact, some are still not fully compliant, or if they were, have fallen out of compliance because they have not prioritized it as an ongoing effort. Now, five years later, users/plaintiffs and law firms are much more active in pursuit of equitable digital experiences for all. As we highlight in our blog, How To Avoid ADA Lawsuits and Remediate if You Can’t, the pace of legal action in the U.S. remains high. For example, in 2022, there was a 143% increase in organizations that received multiple lawsuits year over year.
Still, it’s challenging to say what the legal landscape will look like in the wake of WCAG 2.2. One perspective is that since changes are small, organizations should be able to attain compliance rather quickly. But, there is also significantly more awareness of digital compliance and the legal ramifications these days, so law groups may pursue 2.2 compliance at a faster pace. We feel that organizations should have a reasonable time, whatever that may be in the eyes of the law, to do some gap analysis and assess the extent of work needed to be 2.2 compliant.
Beyond WCAG compliance: reasons why compliance makes sense beyond the law
Applause is ready to test as soon as WCAG 2.2 releases. We believe that staying ahead of compliance and making it an ongoing and integral process in your organization is critical. But, beyond the legal risk from non-compliance to the ADA or other applicable laws around the world, organizations who do not make their digital properties accessibility compliant miss out on major market share. The World Health Organization’s latest estimate is that one in six people, or 16% of the global population, lives with some form of disability. In addition, many people experience temporary disabilities due to injury, illness and aging at some point in their lives. Further estimates suggest that friends and family of PWD account for an approximate 3.3 billion additional potential consumers who act based on their connection to PWD.
Leading global enterprises across all industries realize that digital experiences that PWD can navigate easily create a better UX for all of their customers. In addition, some accessibility fixes, like addressing missing or unclear labels, enable automation engineers to build more automation and move faster.
Find out more about accessibility testing, and please contact us with any questions.
