With the upcoming release of the Web Content Accessibility Guidelines (WCAG) version 2.2, you might have some questions about how WCAG changes over time.
We’ve heard some of those questions from our clients:
- How does the World Wide Web Consortium’s Web Accessibility Initiative (W3C-WAI) decide whether to add new success criteria?
- Why is WCAG updated so infrequently?
- Why does each new WCAG version take years to complete and publish?
We’ll try to answer those questions in this article. First, some relevant news regarding WCAG 2.2: It’s not quite ready yet.
The Current Status of WCAG 2.2
Currently, the W3C plans on publishing WCAG 2.2 as an official recommendation in December of 2022. Of course, the W3C had planned a publication date of Fall 2022 — and before that, the new standards were expected by the end of 2021.
While the new guidelines probably won’t change too dramatically before their official publication, webmasters should keep using WCAG 2.1 to audit their content for accessibility for the time being.
For more guidance, read: Why WCAG 2.2 Is Still a Working Draft (And When to Start Preparing)
Understanding The Process for Amending WCAG
WCAG is the most widely cited set of standards for digital accessibility, and the W3C doesn’t update the document very often. That’s by design.
Since the release of WCAG 1.0 in 1999, WCAG has been updated three times, not counting working drafts of WCAG 2.2 or WCAG 3.0 (the latter of which is years away from becoming official guidance).
Of course, if WCAG changed every year — or every few years — it might not be an effective standard. The Guidelines are intended to apply to every website, mobile app, and online resource. To accomplish that goal, every success criterion must undergo rigorous review to make sure that it’s realistically attainable for every type of content.
Additionally, every version of WCAG is backward-compatible. In other words, WCAG 2.1 contains all of the success criteria from WCAG 2.0, and WCAG 2.2 will contain every success criteria from WCAG 2.1 If the authors make a mistake, correcting that mistake might ruin this backwards-compatibility.
To avoid that scenario, WAI follows the W3C process for developing web standards. That’s the same process used to develop and define tools like HTML and CSS (Cascading Style Sheets).
Related: History of the Web Content Accessibility Guidelines (WCAG)
How WCAG Drafts Become Official Recommendations
Each version of WCAG starts as an editor’s draft, which is not an official recommendation of the W3C. Editor’s drafts contain success criteria from the WAI group, which are often based on recommendations from the wider accessibility community.
From there, each draft moves through the following phases (or milestones):
1. Working Draft
The WAI team asks for input from the community in order to create a technical report with proposed improvements for WCAG.
During the Working Draft phase, the editors may ask for feedback regarding a specific area of accessibility. For example, when drafting WCAG 2.1, the WAI group asked for suggestions for improving accessibility on mobile devices, which led to new WCAG 2.1 success criteria that addressed common barriers.
WCAG 2.2 is expected to include success criteria for dragging movements, pointer target spacing, and focus appearance. Read more about the potential new success criteria in WCAG 2.2.
2. Wide Review Working Draft
After receiving comments from the community, the WAI group addresses those comments, which usually means changing the technical requirements of success criteria.
At this point, the draft becomes a Wide Review Working Draft. It is published as a complete document, and the public is invited to leave comments.
3. Candidate Recommendation
During the Candidate Recommendation phase, the WAI encourages developers to begin using the new standards to make sure that they can be implemented. In other words, this is the testing phase.
The technical language in the draft may need to change to ensure that the criteria are practically useful. However, at this stage, the technical report is stable — while the word choice may change, the success criteria included in a Candidate Recommendation will usually become part of WCAG.
4. Proposed Recommendation
After developer testing (and more comments from the public and the WAI working group), the draft becomes a Proposed Recommendation. Members of the W3C can endorse the new version of WCAG at this point.
5. W3C Recommendation
A technical report must receive “significant support" from W3C members and the broader community, including endorsement from the W3C Director. Once that support is established, it becomes an official W3C Recommendation — a new version of WCAG.
Related: The Definitive Website Accessibility Checklist
Preparing for WCAG 2.2 (And Beyond)
As we noted earlier in this article, every version of WCAG 2 is backwards-compatible with earlier versions. While you can (and should) review the new WCAG 2.2 success criteria, the best way to prepare for the new standards is to make sure you’re fully conformant with the current standards.
The Bureau of Internet Accessibility provides a free website analysis report, which currently tests content against WCAG 2.1 success criteria (depending on when you’re reading this — we’ll update our automated audits when WCAG 2.2 becomes the standard).
While automated audits have limitations, they’re an excellent resource when beginning your accessibility journey. For more guidance, send us a message or download our free eBook, Developing the Accessibility Mindset.
