Why WCAG 2.2?
Introduction
People sometimes ask, “Why does the Digital Accessibility team keep talking about WCAG 2.2? Isn’t WCAG 2.1 good enough?”
Meeting
WCAG 2.1 is absolutely a good thing. By following WCAG 2.1, organizations can meet the legal requirements of the ADA Title II rule. Doing so also makes digital content much more usable and accessible for people with disabilities.
That said,
WCAG 2.2 has been the recommended version of WCAG since 2023. WCAG 2.2 improves on WCAG 2.1 in important ways, without adding much extra work for testers, designers, or developers.
WCAG 2.2 has also been adopted by many states, cities, universities, companies, and other organizations across the United States. It is quickly becoming the de facto standard as well as the recommended standard.
At the same time, work is already underway on WCAG 3.0. While it will likely be several years before WCAG 3.0 becomes the recommended standard, this is a good reminder that accessibility standards continue to evolve. Organizations that stay current and prioritize accessibility can avoid building up “technical debt” and rushing to catch up later.
For these reasons, our agency requires WCAG 2.2 conformance and encourages others to adopt it as well. Below, we explain why there is strong support for adopting WCAG 2.2.
A New Recommended Version
The World Wide Web Consortium (W3C) is the international organization that maintains WCAG. WCAG 2.2 became the W3C’s recommended version on October 5, 2023.
The proposed draft of the ADA Title II rule was released a few months before that. However, the final Title II rule was not published until the following year. As a result, the final Title II rule refers to WCAG 2.1, even though WCAG 2.2 was already the most current version.
In its notes about the rule, the U.S. Department of Justice explained that public entities may choose to meet WCAG 2.2 Level AA instead of WCAG 2.1 Level AA. According to the DOJ, WCAG 2.2 provides equal or greater accessibility and usability.
In simple terms, organizations can comply with the rule by meeting either WCAG 2.1 or WCAG 2.2. Choosing WCAG 2.2 may offer better experiences and outcomes for users.
Low Effort, High Impact
Technology and user expectations change over time, so accessibility standards must change too. These changes need to happen in a clear and predictable way to avoid confusion or wasted effort. That is why WCAG versions are designed to be backward compatible.
Backward compatibility means that if you meet a newer version of WCAG, you also meet the earlier versions, going back to WCAG 2.0.
Each new version of WCAG reflects changes in technology and expands coverage to better support people who may have been underserved in the past.
The size of WCAG updates has varied. WCAG 2.0, released in 2008, included 61 success criteria. WCAG 2.1, released ten years later, was a major update. It added 17 new criteria, many focused on mobile technology and improved support for people with cognitive disabilities.
WCAG 2.2 is a smaller update. It adds nine new success criteria total, but only six at Levels A and AA, which are the levels required for legal compliance. WCAG 2.2 also removed one older criterion.
The new criteria are explained in detail in the W3C article
What’s New in WCAG 2.2. In short, they address newer technologies like multi‑factor authentication and improve support for people with cognitive and motor disabilities.
One standout example is
Success Criterion 2.5.8, Target Size (Minimum). Many people with motor disabilities have difficulty using buttons or links that are too small or too close together. Earlier versions of WCAG offered guidance, but the newest version is very clear.
Success Criterion 2.5.8 sets a clear standard: clickable targets plus their padding should be at least 24 by 24 pixels, with some exceptions. This clarity has made testing easier. Developers quickly created web browser tools to check target size, such as
Adrian Roselli’s 24 x 24-pixel bookmarklet. The bookmarklet can be added to a tester's browser favorites and used to quickly verify target size.
This success criterion reflects the overall spirit of WCAG 2.2. It is easy to test, but it can make a big difference for users. In other words, it requires little extra effort but delivers a strong ROI.
Approximately 0.5% of the bugs our team has logged since the start of our project implementation have been linked to the new version 2.2 criteria. The WCAG 2.2 updates have come into play more frequently during the design phase, and as a part of drafting templates and standards. And in those cases, they have largely provided helpful clarity. This experience shows that adopting WCAG 2.2 adds very little burden, while still providing meaningful improvements in accessibility.
Broad Adoption Across Sectors
At first, it was unclear how quickly organizations would adopt WCAG 2.2. Now, more than two years later, adoption has been strong across many sectors.
Cities and counties around the country have followed suit, such as St. Louis, Missouri; South Bend, Indiana; Centreville, Mississippi; and the County of Maui.
Public universities are often leaders in digital accessibility, and many have already moved to WCAG 2.2. Examples include the University of Illinois, Michigan State University, the University of North Carolina at Chapel Hill, and South Dakota State University.
Many private companies and nonprofit organizations have also adopted WCAG 2.2. These include large organizations such as Bank of America and Kaiser Permanente. Many vendors of accessibility tools, like Siteimprove, also now provide WCAG 2.2 support.
Now Is the Time
Keeping up with WCAG updates also helps organizations avoid technical debt. Laws and regulations often lag behind technical standards, but over time, newer standards tend to become part of legal requirements.
WCAG 3.0 is already in development, and a draft is available. While it may take years before WCAG 3.0 becomes the recommended standard, organizations that stay current with WCAG 2.2 will be better prepared when that transition happens. Staying up to date now means less work later—and better accessibility for users today.
And that’s why we at OHA strive to meet WCAG 2.2 and encourage others to do the same!
[Content note: Generative AI was used to support plain language revisions to this article. All content was written and reviewed by human subject matter experts.]