The latest version of the Web Content Accessibility Guidelines (WCAG) is on its way — but it’s not quite ready yet.
On September 6, 2022, the World Wide Web Consortium (W3C) published an official Candidate Recommendation Snapshot for WCAG 2.2. The snapshot integrates changes to the standards in response to public comments received following the May 2021 wide review draft.
However, the snapshot does not officially publish WCAG 2.2 as a recommendation. Currently, WCAG 2.2 is scheduled for publication in early 2023, but that could change.
So, why the long delay? The simple answer: It’s part of the process. Below, we’ll explain why WCAG updates take time — and provide a few tips for preparing your website for the next version of the standards.
WCAG 2.2 will add new requirements for digital accessibility
Every version of WCAG 2.X is designed to be backward-compatible with previous versions. That means that WCAG 2.2 will include all of the requirements from WCAG 2.1 and 2.0, but with new success criteria and minor changes to the document’s language.
Since new versions of WCAG do not deprecate earlier versions, the wording of every success criterion needs to be precise. The authors don’t have the option of issuing a revised version — that’s accomplished through the W3C draft process.
Like earlier versions of the guidelines, WCAG 2.2 has changed numerous times since its introduction. The Candidate Recommendation implements several important changes from the May 2021 Working Draft:
- Added “Focus Not Obscured (Minimum) (AA)” and “Focus Not Obscured (Enhanced) (AAA).” These criteria require that focused elements aren’t obscured by other content, which benefits people who use a keyboard alone to navigate (with no mouse) and some people who use assistive technologies.
- Updated the wording of “Focus Appearance (AA)” and removed “Focus Appearance (Enhanced) (AAA).” WCAG 2.2 will require the appearance of keyboard focus indicators to meet several new standards.
- After “Accessible Authentication (AA)”, added “Accessible Authentication (No Exception) (AAA).” Read more about accessible authentication processes.
- Removed “Visible Controls,” which will be added to supplemental guidance.
- Removed “Page Break Navigation,” which will be added to Supplemental Guidance.
The two removed success criteria (“Visible Controls" and “Page Break Navigation") won’t be included in WCAG 2.2, but that’s not because they’re unimportant — the W3C authors were unable to agree on specific requirements for these criteria.
Related: History of the Web Content Accessibility Guidelines (WCAG)
Changes to WCAG 2.2 demonstrate why webmasters should wait for official recommendations
The W3C draft process can take several years to complete, and that’s intentional: Developers need time to use the new criteria to test their content. If a certain requirement is too broad or too granular to apply to various types of digital content, it will need to be removed or recategorized.
That doesn’t mean that you should ignore new versions of WCAG — but it’s important to remember that the guidelines can (and will) change substantially before their public release.
Related: Understanding the Differences Between WCAG 2.1 and WCAG 2.2
Should I start following WCAG 2.2 ahead of the official release?
The W3C recommends testing content against the latest official version of WCAG. Currently, that’s WCAG 2.1.
If your website fails to conform with WCAG 2.1’s Level A and Level AA success criteria, you shouldn’t focus on the new criteria in WCAG 2.2 until you’ve fixed those issues.
However, if you’re fully conformant with WCAG 2.1, you can certainly “read ahead" and take steps to prepare for WCAG 2.2.
Take a user-focused approach when improving accessibility
We recommend reading about the nine new success criteria in WCAG 2.2 and looking for opportunities. You may be able to take reasonable steps to prepare for conformance with the new requirements — but make sure you focus on how the improvements will benefit users with disabilities.
For example, WCAG 2.2 Success Criterion 3.2.6, “Findable Help,” requires webpages to provide ways for users to find help. That’s important because some people with disabilities may need assistance when browsing your site, and if you provide human contact details or a self-help option, you can create a better experience for those users.
However, if you try to fulfill this requirement by directing users to an unmanned toll-free number, you’re not actually providing a helpful resource. You’re creating a brand-new accessibility barrier.
If you take a user-focused approach, you’ll enjoy more of the benefits of digital accessibility. You’ll also be well-prepared for the official publication of WCAG 2.2 — which should arrive sometime soon.
To start preparing for WCAG 2.2, send us a message to connect with a subject matter expert.
