The Evolution of WCAG: A Postcard from the Front Lines

WCAG 2.0 was a complete overhaul of the requirements (known as “success criteria” in WCAG parlance), both in language and structure. WCAG 2.0 introduced the then new concepts of POUR (perceivable, operable, understandable, and robust) and three levels of severity (A, AA, AAA) with the “A” level success criteria being the most critical, followed by AA and AAA. Focusing on the needs of users with differing types of disability, WCAG 2.0 focused primarily on outcomes, rather than specific techniques, which left open the door for creative solutions to address those needs.

And it was a hit! Subject matter experts were extremely excited about the changes in WCAG 2.0, and through persistent promotion and advocacy, slowly but surely, larger commercial entities, recognizing both the moral need and also the business advantages, began to adopt the WCAG standard. Legislative bodies in territories outside the United States started to legally mandate WCAG 2.0 as being the minimum expectation required to address the human rights need of equality for all. WCAG 2.0 was gaining traction!

Meanwhile, in the United States, the US federal government was also taking steps to make the web a more equitable space, using the spending power of the US federal government to drive change. Section 508, part of the Rehabilitation Act of 1973, was released shortly before WCAG 1 (1998). Essentially, the Section 508 regulations mandate that when the federal government develops, procures, maintains, or uses electronic and communications technology, it must ensure that persons with disabilities are provided comparable access to and use of that which is provided to persons without disabilities.

The impact of Section 508 on digital accessibility can never be underestimated, but for technology companies, it also created something of a problem: an increasingly large number of countries were adopting the WCAG standard, but for US-based entities, there was a different, competing standard with Section 508. Through multiple lobbying efforts, and spanning a period of almost a decade*, the Section 508 requirements went through a “refresh,” and the net result was a harmonization of the two standards, with Section 508 effectively adopting WCAG 2.0 as the new standard to be met. For technology companies this was a huge development: now they had one accessibility standard to adhere to for the entire world.

WCAG 2.1

Meanwhile however, back at the W3C, the accessibility specialists (the Accessibility Guidelines Working Group) were starting to recognize that while WCAG 2.0 was both a robust specification, and was also seeing significant adoption at a global scale, it was also starting to show its age. Specifically, technology was still advancing, and the experts were seeing some specific gaps in the specification—either because we knew more about the needs of a greater number of disabled users or because of actual new technology emerging in the marketplace (e.g., mobile).

By late 2015, the Accessibility Guidelines Working Group started to revisit the specifications requirements. Research task forces were established related to low vision, cognitive disabilities, and mobile (touch interfaces). These three groups researched existing gaps and came back to the larger group with suggestions and a collection of proposed new success criteria. A few different ideas were contemplated on how to add those new requirements into the existing specification, and after some internal debate, the working group settled on “dot-extension” releases to WCAG, culminating in the publication of WCAG 2.1 on June 5, 2018. The next-generation release retained all the existing structure and conformance requirements found in WCAG 2.0, but added a total of 17 new success criteria. Critical to that effort, however, was the need to remain backward compatible with WCAG 2.0, meaning that web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors who are required by policy to conform with WCAG 2.0 will be able to update content to WCAG 2.1 without losing conformance with WCAG 2.0.

(One of the interesting lessons learned during this activity was how difficult it was to create a testable and measurable requirement to meet the needs of users with cognitive issues—the lessons spawned a whole new effort at the W3C and the publication of Making Content Usable for People with Cognitive and Learning Disabilities,¹ a W3C note that gives advice on how to make content usable for people with cognitive and learning disabilities. This includes, but is not limited to, cognitive disabilities, learning disabilities (LD), neurodiversity, intellectual disabilities, and specific learning disabilities.)

WCAG 2.2

One wrinkle the Accessibility Guidelines Working Group had to address in the development of WCAG 2.1 was the need to get the extension published in a timely manner. This was due to the fact that legislators in the European Union were in the process of establishing EU mandates for digital inclusion, and they wanted to be using the most up-to-date guidance and requirements available and were waiting in anticipation for the release of WCAG 2.1. But that legislation was also committed to a fixed timeline, and so the working group was under some pressure to publish what was ready as soon as possible so that the EU could reference the most recent specification.

Fortunately, adopting the “dot-extension” model left open the door to further future extensions, and so a number of proposed success criteria that, for whatever reason, did not make it into the 2.1 release, continue to be worked on within the working group, with the intention of publishing a WCAG 2.2 document in the future.

While slightly smaller in scope than the changes introduced in WCAG 2.1, the WCAG 2.2 Working Draft² provides nine additional success criteria, as well as advances an existing success criteria (focus visible) from a AA requirement to an A requirement (this later change has minimal impact on implementers, who for the most part are mandated to meet both A and AA success criteria—the change here was procedural so that the working group could add additional requirements related to the larger topic as new success criteria [focus appearance (minimum), AA; and focus appearance (enhanced), AAA]).

While still a work in progress today (Nov 2021), the work on WCAG 2.2 is nearing completion. The initial target release date for WCAG 2.2 was mid-December 2021; however, due to a number of comments received by the working group—which W3C process requires formal responses to—the actual release date may be deferred to spring 2022 as the working group responds to those comments.

WCAG 3.0

As the working group continued to work on both WCAG 2.1 and WCAG 2.2, there was a growing realization that while the WCAG 2.x series of success criteria were indeed making the web more accessible, the structure and mechanics of WCAG 2.x had some built-in limitations with regard to conformance that were proving difficult to overcome.

The most specific of those was that in the WCAG 2.x track, final conformance was binary: either you successfully met ALL the success criteria (at level A, or for most legislated requirements, A and AA), or you failed. When applied to small personal websites, this was not seen as totally unreasonable, but for larger enterprise websites with thousands of web pages (or more!), perfection was seen as an unachievable goal.

Additionally, the scale and scope of digital communications has expanded exponentially, and the accessibility requirements (success criteria) that were in WCAG 2.x are today being applied to different types of digital content above and beyond “web content” (e.g., PDF documents, and native mobile applications)—sometimes with less than perfect outcomes. The working group was also looking ahead to emergent platforms such as virtual and augmented reality, real-time communications (chat applications such as Messenger or Slack), and “The Internet of Things” (a.k.a. IoT). The question was this: How do we make WCAG applicable to these types of content as well? And what to do about “less than perfect”?

Beginning somewhere around spring 2017 (while WCAG 2.1 was still being worked on), a new research group was established within the larger working group to start thinking about the next generation of the WCAG standard. Dubbed the “Silver Task Force” (AG—as in Accessibility Guidelines—is also the periodic table entry for silver, thus the geeky double entendre).

Early on, some basic assumptions and decisions were made: the next-gen standard would be research based, the requirements needed to be written so that they were easier to understand (using plain language principles), the conformance model would have a graduated conformance mechanism (bronze, silver, gold), and the structure and applicability would be as agnostic as possible (applicable to both the variety of emergent technologies we are seeing today and also to what we can only imagine for tomorrow)—that a flexible framework was needed to meet that challenge. (Related to that, another early decision was to retain the WCAG “brand name,” but for the 3.x version, the acronym will actually stand for the “W(3)C Accessibility Guidelines.” The internal consensus was that WCAG as a brand had gained significant traction, and we did not want to lose that marketing advantage—standards need to be promoted as well!).

Finally, WCAG 3.0 would incorporate content from, and partially extend, the W3C’s User Agent Accessibility Guidelines 2.0³ and Authoring Tool Accessibility Guidelines 2.0.⁴ While there will be a lot of overlap between WCAG 2.x and WCAG 3.0, WCAG 3.0 includes additional tests and different scoring mechanisms. As a result, WCAG 3.0 will not be backward compatible with WCAG 2.x; WCAG 3.0 will not supersede WCAG 2.2 and previous versions; rather, it will be an alternative set of guidelines.

A significant amount of progress has been made on the Draft WCAG 3,⁵ but a lot of work remains to be done. A basic framework has been developed (but has not yet been “stress-tested” to verify it will work in practice), and a number of sub-teams have been doing the required research and fact-gathering needed to migrate the existing requirements of WCAG 2.x into the WCAG 3 framework, but some early work has also started on newer requirements that the WCAG 2.x framework could not support.

Earlier in 2021 (March), the initial (and incomplete) Draft Recommendation was published as a First Public Working Draft; the intention at that time was to solicit early feedback from stakeholders on both direction and structure. (The working group is currently using GitHub⁶ to track and manage that feedback, and the invitation for stakeholder feedback remains open to the general public.)

A major challenge the working group is dealing with today is that working on two standards (WCAG 2.2 and 3.0) at the same time is complex—there are a lot of moving pieces and multiple milestones that must be met within the process-driven W3C framework. However, anticipating the publication of WCAG 2.2 within the next three or four months, the working group envisions turning all their collective effort to the WCAG 3 activity in short order.

When Will WCAG 3.0 Be Ready?

Probably one of the most frequently asked questions about WCAG 3 is this: When will it be ready? The honest answer today is that we don’t really know for sure (but we’re working on it).

The working group has recently approved a revised, multipronged work plan (starting now, but mostly for once WCAG 2.2 is published) that envisions the specification being ready for final review sometime in 2025, with an anticipated publishing date of 2026. But as anyone who works in technology recognizes, these are very long timelines, and a lot can change between now and then.

However, based on how long it took to get WCAG 2.0 to its final published state more than a decade ago, there is a reasonable presumption that the current timeline is workable and achievable. The working group has committed to regular updates, and because the W3C process mandates that all the work happens publicly, stakeholders will be able to track that progress and provide feedback every step of the way.

(As an active member of the working group, I encourage you to at least follow along. Watch for emergent requirements, and give them a spin—we need and actively solicit real-world feedback, and the ability for anyone to comment on the work is a cornerstone of our activity. We want to hear from as many stakeholders as we can, so don’t be shy; let us know how we’re doing over at GitHub.)

References

* Standards development is ALWAYS a slow process!

1. See: https://www.w3.org/TR/coga-usable/.
2. See: https://www.w3.org/TR/WCAG22/.
3. See: https://www.w3.org/TR/UAAG20/.
4. See: https://www.w3.org/TR/ATAG20/.
5. See: https://www.w3.org/TR/wcag-3.0/.
6. See: https://github.com/w3c/silver/issues.

Disclaimer:

This is to inform readers that the views, thoughts, and opinions expressed in the article belong solely to the author, and do not reflect the views of Amnet.

Copyright © 2023 Amnet. All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other non-commercial uses permitted by copyright law. For permission requests, write to [email protected].