The Evolution of WCAG:  A Roadmap to Achieving Digital Accessibility

It’s fairly obvious to anyone who works in the technology sector that the only thing constant is change, and when it comes to the world of digital accessibility, change is as constant there as anywhere else. Whether it’s advances in software or hardware tools, or new developments in the code used for developing web content, digital accessibility is evolving like all other aspects of the web. In this article, we’ll review some history of WCAG (the Web Content Accessibility Guidelines) and look ahead to anticipated changes – in both the short term and the longer term.

The History of WCAG

With roots tracing all the way back to the earliest days of the internet, WCAG (the Web Content Accessibility Guidelines) is one of the more important standards to emerge from the W3C – the World Wide Consortium – the global web standards organization. The first version of WCAG, was published on May 5th 1999, and was initially based on research and work done at the Trace R & D Center at the University of Wisconsin – Madison, and subsequently adopted to the W3C’s standards process. Using a checklist format, it was the beginning of Web Accessibility as we know it today.

However, the checklist format quickly began to expose some significant and problematic issues: specifically, content authors could “tick the boxes” but still end up with web content that was not accessible to people with differing disabilities. Very shortly after its initial release, the experts who had created WCAG 1 reconvened with a goal of rewriting WCAG, resulting in the publishing of WCAG 2.0 nine years later, in December of 2008.

WCAG 2.0 was a complete overhaul of the requirements (known as Success Criteria in WCAG parlance), both in language but also in structure. WCAG 2.0 introduced the then new concepts of P.O.U.R. (Perceivable, Operable, Understandable, and Robust), as well as 3 levels of severity (A, AA, AAA) with “A” level Success Criteria the most critical, followed by AA and AAA.

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 but also the business advantages, began to adopt the WCAG standard. Legislative bodies in territories outside of the United States started to legally mandate WCAG 2.0 as being the minimum expectations 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 were 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 under-estimated, 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 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 a “dot-extension” releases to WCAG, culminating in the publication of WCAG 2.1 on June 5th, 2018. The next-generation release retained all of 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 backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors that 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 that activity was how difficult it was to create a testable and measurable requirement to meet the needs of users with cognitive issues – those 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 time-line, and so the Working Group were 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 Candidate Recommendation provides 9 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 implementors, 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).

The following Success Criteria are all new in WCAG 2.2:

• 2.4.11 Focus Appearance (AA)
• 2.4.12 Focus Not Obscured (AA)
• 2.4.13 Focus Not Obscured (Enhanced) (AAA)
• 2.5.7 Dragging Movements (AA)
• 2.5.8 Target Size (Minimum) (AA)
• 3.2.6 Consistent Help (A)
• 3.3.7 Accessible Authentication (AA)
• 3.3.8 Accessible Authentication (Enhanced) (AAA)
• 3.3.9 Redundant Entry (A)

In January of 2023, WCAG 2.2 advanced (for the second time) to Candidate Recommendation at the W3C. According to the W3C’s Process documentation a Candidate Recommendation is a final draft specification that satisfies the technical requirements of the Working Group that produced it and their dependencies, and has already received wide review.

W3C publishes a Candidate Recommendation to signal to the wider community that it is time to do a final review, as well as provide an opportunity to gather implementation experience. Companies and organizations are now encouraged to start implementing the new Success Criteria in their emergent work; the W3C acknowledges however that those new SC are not required for legal conformance at this time. None-the-less, implementing the new SC, and providing implementation feedback (both positive and negative) is a critical step in ‘hardening’ the spec. The latest version integrates changes in response to comments received from the 6 September 2022 Candidate Recommendation.

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 is binary: either you successfully meet ALL of the Success Criteria (at level A, or for most legislated requirements, A & AA), or you fail. When applied to small personal websites, this was not seen as totally unreasonable, but for larger enterprise websites that consist of thousands of webpages (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” (for example, PDF documents, and native mobile applications) – sometimes with less than perfect outcomes. The Working Group were 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: how do we make WCAG applicable to these types of content as well? And what to do about “less than perfect”?

Beginning somewhere around the spring of 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 technology we are seeing today, but 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 will include additional tests and testing methods, as well as different scoring mechanisms. As a result, WCAG 3.0 will not be backwards 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.

The WCAG Working Group published its First Public Working Draft (FPWD) of WCAG 3 in December of 2021. A significant amount of public feedback was received, and a number of significant changes are now emerging based on that feedback. Given the enormity of the project, and the number of different “moving pieces” involved, the working group also decided to introduce a number of ‘status indicators’, allowing the group to provide greater clarity around the different work items being addressed. Those status indicators are:

• Placeholder: This content is temporary, it showcases the type of content or section to expect here. All of this is expected to be replaced. No feedback is needed on placeholder content.
• Exploratory: The working group is exploring what direction to take with this section. This content is not refined, details and definitions may be missing. Feedback should be about the proposed direction.
• Developing: There is rough agreement on what is needed for this section, although not all high-level concerns have been settled. Details have been filled, but are yet to be worked out. Feedback should be focused on ensuring the sections are usable and reasonable in a broad sense.
• Refining: The working group has reach consensus on this section. It is ready for broad public review and experimental adoption. Feedback should be focused on the feasibility and implementability.
• Mature: Content is believed by the working group to be ready for recommendation. Feedback should be focused on edge case scenarios the working group may not have anticipated.

A major challenge the Working Group is dealing with today is that working on two standards (WCAG 2.2 & 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 3 or 4 months, the Working Group envisions turning all of 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 when will it be ready? The honest answer today is, we don’t really know for sure (but we’re working on it).

Based on feedback from the FPWD, the Accessibility Guidelines Working Group has decided to follow an agile approach for developing WCAG 3.0. The goal is to work in a way that allows the Working Group to rapidly develop new concepts, to test those concepts, gather feedback about them, and iterate on them further. This is done using a structured approach, such as through temporary single-topic subgroups, and by using the aforementioned status levels.

Priorities are decided in real-time as new concepts are developed and as feedback comes in. The Working Group processes themselves are regularly evaluated and iterated on to optimize the group’s ability to develop WCAG 3 into a high quality, future-proof, and equitable standard. In deciding priorities, the Working Group will ensure regular and open collaboration with stakeholders, including people with disabilities, industry, and the W3C Advisory Committee.