WCAG 3.0: Further On Up the Road

Back in December 2022, we published a blog post covering what was in the latest Working Draft of the W3C Accessibility Guidelines Version 3, published on 7 December 2021. We’ll call that WCAG3, for short.

WCAG3 is designed to be the replacement for the Web Content Accessibility Guidelines Version 2. Note the difference in name, although it uses the same acronym. We’ll call that WCAG2.

The reasoning behind the name change is to reflect a focus beyond just web content, while keeping the familiar acronym (even though the acronym is pronounced in different ways).

Now, WCAG2 has been through a couple of “upgrades” from Version 2.0 to Version 2.1 and Version 2.2, the latter now at the “Proposed Recommendation” stage and expected to be published as a “W3C Recommendation” later this month, depending on whether W3C members vote for it to be published as is, or require any changes.

Once it’s published as a “W3C Recommendation”, WCAG 2.2 will be the web standard against which conformance claims should be tested. Officially, “While WCAG 2.0 and WCAG 2.1 remain W3C Recommendations, the W3C advises the use of WCAG 2.2 to maximize future applicability of accessibility efforts.”

There might be further upgrades beyond WCAG 2.2 but the big picture is that WCAG2 will eventually be superseded and replaced by WCAG3. When exactly that will happen is unclear, but it’s reasonable to expect it to be no earlier than 2025 and more likely towards the end of the decade. Even then, there will be a transition period of several years before WCAG2 is deprecated and completely replaced by WCAG3.

On 24 July 2023, the W3C Accessibility Guidelines Working Group (AGWG) published the latest Working Draft of WCAG3, so in this blog post, we’ll look at what’s changed in WCAG3 in the newest draft.

In fact, the AGWG has summarized these changes for us.

“The new draft:

  • clarifies the maturity of each section
  • includes new potential approaches to conformance
  • lists some guidelines to be developed”

Let’s pull those apart.

Maturity

The AGWG found there was some confusion about whether the draft guidance in the previous version was ready to use. To remove that confusion, the AGWG has adopted a system of marking sections of the draft according to their maturity, which in turn affects what kind of feedback is invited.

  • Placeholder content is temporary and gives an idea of what to expect. It will be replaced, so no feedback is required. There are 26 sections of this latest draft marked as Placeholder.
  • Exploratory content is still being explored and is not refined or complete, but feedback is invited on the direction it’s taking. There are 11 sections of this draft marked as Exploratory.
  • Developing content is a bit further along, with general agreement on what’s needed. It’s not yet settled, and feedback is invited on how usable it is. There are just two sections of this draft marked as Developing.
  • Refining content has reached consensus and it’s ready for public review and experimental adoption. Feedback is invited on feasibility and implementation. There are no sections of this draft marked as Refining.
  • Mature content is ready for the final standard. Feedback is invited on edge case scenarios and possible omissions. There are no sections of this draft marked as Mature.

This tells us not only that the AGWG invites feedback now on certain sections of WCAG3 but also the stages through which each section will pass toward a final version.

Conformance

A lot has happened to this section and it is marked as Exploratory, so while details and definitions may be missing as yet, it’s worth getting stuck in and providing some feedback on the direction the section is taking.

The new draft goes into quite a bit of detail about a potential conformance model and how claims of conformance can be made and tested.

Significantly, three goals are set for the Conformance Model.

  1. Develop a model that encourages web sites to continue to improve accessibility (vs. stopping at the previous AA level);
  2. Better reflect the lived experience of people with disabilities, who successfully use sites that have some content that does not meet WCAG 2.0 AA, or who encounter barriers with sites that meet WCAG 2.0 AA; and
  3. Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.

Let’s lock that in: the desired conformance model should encourage continuous accessibility improvement, reflect lived experience, and make allowances.

The section then goes into a number of approaches to achieving this model: how to reach desired outcomes, testing and scoring methods, and associated ideas on conformance levels (still the Bronze, Silver, and Gold previously mooted), including issue severity, adjectival ratings (e.g., “fail, pass, exemplary” or a numeric rating), and pre-assessment checks.

We found the two proposed approaches to assessing accessibility to be interesting. One is the previously suggested approach of testing Outcomes to verify that user needs have been met (not unlike WCAG2’s Success Criteria), while the other involves making Assertions that procedures to improve accessibility have been followed.

The tests applied to identified Outcomes can be Quantifiable (e.g., does an image have an accessible name?) and Qualitative (e.g., is an image’s accessible name appropriate?). You can see that those two examples equate to the normative requirements of WCAG2’s existing Success Criterion 1.1.1 Non-Text Content, “has a text alternative that serves the equivalent purpose”.

However, even these tests may not mean that web content is actually usable by people with various disabilities, which is where Assertions come in.

Assertions are where a person or organization makes a claim of fact they have followed a procedure to test whether their content is usable by a person with disability. That can include usability testing, assistive technology testing and “plain language review”, and “heuristic evaluation” by expert testers and auditors.

These Assertions must be formally documented to form part of a claim of conformance to WCAG3.

This might raise a number of questions in your mind, and that’s exactly what the AGWG wants feedback on in order to define associated procedures, develop examples, and test the viability of this approach.

Guidelines

This section has been greatly expanded in number from the half dozen examples in the previous draft to 23 topics. On the other hand, all proposed details of the guidelines have been removed. That’s to remove the distraction of the details of the previous examples and focus on what the topics should be.

The way to think of Guidelines is as ways to address accessibility issues that will lead to positive Outcomes. At this stage, they are designed to cover current WCAG2 guidance.

Note that these Guidelines are all marked as Placeholder, so don’t jump in yet with your views on what “Keyboard support” should mean.

The Guidelines will expand in number and detail in future drafts, and then be available for feedback.

While the previous draft listed the Guidelines according to a numbering system similar to that used in WCAG2, this draft lists them in alphabetical order, “but we do not expect that to persist.”

Conclusion

At this stage, we recommend diving into and providing feedback on the Conformance section, which is marked as Exploratory as a whole, and particularly its “Outcomes and Methods” and “Assertions and Procedures” subsections, which are the two sections marked as Developing.

Creating WCAG3 is a massive task and the AGWG is to be congratulated for taking it on. Certainly, there are those who doubt the value of making such a huge change in direction from WCAG2 to WCAG3 but we don’t think anyone can doubt the AGWG’s good intentions.

What we wrote in our previous post on WCAG3 still very much holds true and our analysis is still valid. We’ve just moved a little further down the road to WCAG3.

For now, look at what’s in the new draft, and do what you can to provide positive, constructive feedback. In particular, look for the Editor’s Notes sections with a green background that expand on the kind of feedback the AGWG is looking for.

Details on how to provide feedback can be found in WCAG 3 Introduction.

Resources

Categories: Technical

About Ricky Onsman

Veteran Australian web designer, front end developer, writer and editor. As a writer and/or editor, I've worked with the likes of UX Australia, SitePoint, Web Directions and Smashing Magazine. As a freelance designer and front end dev, I focused on building accessible websites, then worked with a number of design, UX and accessibility-focused companies in Australia, North America and Europe before joining the Knowledge Center team at TPGi.