The Web Content Accessibility Guidelines (WCAG) are a set of recommendations for improving digital accessibility. Digital accessibility is a core part of human‑centered design that helps people with disabilities find, understand, and use digital content. WCAG was first published in 1999, but several newer versions have been released over the years to reflect changes in technology and user needs. WCAG is globally recognized as a leading standard for web accessibility — and while WCAG isn’t law, it is an important basis for complying with regulations like Section 508 and ADA Title II.
Knowing WCAG’s history provides useful context if you’re trying to audit your applications, understand past accessibility decisions, or implement the latest recommendations. Here’s an overview of WCAG’s evolution over the years, along with tips for using version 2.2 and preparing for 3.0.
Who came up with WCAG?
WCAG was created by the World Wide Web Consortium (W3C), the international standards organization responsible for developing core web technologies such as HTML and CSS. Within W3C, the Web Accessibility Initiative (WAI) leads accessibility work, including the development and maintenance of WCAG.
WCAG is developed by working groups made up of accessibility experts, designers, developers, researchers, assistive technology vendors, and representatives from government, industry, and disability organizations. Updates and new versions are released through a public, consensus‑driven process.
How web accessibility standards have evolved
Four versions of WCAG have been published, with a fifth currently in development.
- WCAG 1.0 was released in May 1999
- WCAG 2.0 was released in December 2008
- WCAG 2.1 was released in June 2018
- WCAG 2.2 is the latest version, released in October 2023
- WCAG 3.0 is in development, with a working draft available to the public
WCAG has evolved by refining requirements, adjusting to new technologies, and addressing gaps identified through real‑world use. Over time, these web accessibility standards have shifted from HTML-focused guidance to a more flexible, technology-agnostic framework. Let’s look more closely at WCAG’s evolution across each version.
WCAG 1.0
WCAG 1.0 was published more than 25 years ago, at a time when the web was still relatively young and rapidly evolving. It included 14 Guidelines supported by 65 Checkpoints that websites needed to satisfy. Each Checkpoint provided detailed explanations and examples, many of which were tightly tied to HTML and early web technologies.
The Guidelines focused on two main themes: ensuring graceful transformation, and making content understandable and navigable. Even at this early stage, the working group emphasized that accessibility benefits everyone — including users with and without disabilities. They noted that WCAG would make web content more available on various devices (e.g. desktop, mobile, assistive) and under various constraints (e.g. noisy or poorly-lit surroundings.)
WCAG 2.0
Even as the WCAG 1.0 standards were being published, it was clear that more work was needed. A first public draft for WCAG 2.0 was released in January 2001, just a year and a half after WCAG 1.0 was finalized. The next eight years saw 10 working drafts and two last calls before the final recommendation was released in December 2008.
WCAG 2.0 introduced a hierarchical structure, with ‘layers of guidance’ as a framework for the standards. The 14 original Guidelines of WCAG 1.0 were replaced by a new set of 12 Guidelines, organized under the four ‘POUR’ design principles:
- Perceivable
- Operable
- Understandable
- Robust
Under the Guidelines, Checkpoints were replaced by testable Success Criteria to help users achieve compliance. These were prioritized into three levels of conformance:
- A (lowest) for basic needs
- AA (mid-level) for broader access
- AAA (highest) for maximum inclusivity
WCAG 1.0’s Checkpoints were often specific to HTML, reflecting the web as it existed at the time. But by the mid-2000s, digital content extended beyond web pages to include documents, mobile devices, and emerging native apps. WCAG 2.0 responded by adopting a technology-agnostic structure, ensuring its Guidelines and Success Criteria apply across formats and platforms. Technology-specific guidance was moved into a separate Techniques layer, allowing it to be updated as technologies evolve while Guidelines and Success Criteria remain stable.
WCAG 2.1
In the decade following the release of WCAG 2.0, the internet expanded beyond desktop websites into mobile devices, apps, and connected products. As digital services became embedded in everyday life, accessibility guidance needed to address the new ways people interacted with technology. This shift, along with a deeper understanding of disability, shaped new WCAG Success Criteria focused in three key areas:
- Mobile accessibility
- Support for people with low vision
- Support for people with cognitive and learning disabilities
WCAG 2.1 built on WCAG 2.0 instead of replacing it, so anything that conforms to WCAG 2.1 also conforms to its predecessor. This allowed organizations to extend existing compliance efforts without starting over, while addressing accessibility challenges in mobile and touch‑based interfaces.
WCAG 2.2
In 2020 the COVID-19 pandemic accelerated the evolution of technology as remote work became a new norm. This prompted an update to WCAG to tackle the new digital accessibility challenges that arose. The first WCAG 2.2 draft appeared in August 2020, with the final version released in October 2023.
WCAG 2.2 introduces additional Level A and AA success criteria, with a strong emphasis on improving usability for people with cognitive disabilities, low vision, and motor impairments. Key changes include new requirements related to focus visibility, dragging interactions, and accessible authentication.
Because WCAG 2.2 builds on WCAG 2.1, organizations that already meet WCAG 2.1 AA are well positioned to upgrade. The transition typically involves targeted design and development updates, along with refreshed testing practices.
WCAG 3.0
It’s expected to take several more years for the WCAG 3.0 working draft to be finalized, and several years after that before WCAG 2.2 is deprecated.
WCAG 3 is designed to be easier to understand and more flexible than earlier versions. It aims to cover more user needs — including the needs of people with cognitive disabilities — and work across different types of content, apps, tools, organizational contexts, and future technologies.
In some ways, WCAG 3 builds on earlier versions. Its core purpose remains unchanged, and you can expect to see similar fundamental and specific accessibility requirements. But in other ways, WCAG 3 represents a major shift. It introduces a new structure and conformance model, and expands its scope beyond web content to a broader range of digital products and experiences.
This broader scope is reflected in the full official name: WCAG 3 stands for W3C Accessibility Guidelines, rather than Web Content Accessibility Guidelines. However, the WCAG acronym was kept because of its wide recognition.
Although it’s impractical to try and comply with WCAG 3.0 while it’s still in development, we recommend a few steps to prepare for its eventual release:
- Continue to meet WCAG 2.2 requirements
- Track the development of WCAG 3.0 through W3C updates
- Exceed compliance with an empathy-driven approach to accessibility
- Bake accessibility into your design system to enable quicker updates
- Explore automated accessibility testing to increase coverage
Moving from WCAG 2.1 to 2.2
Conforming to WCAG 2.2 Level AA is best practice for organizations looking to deliver an accessible digital experience and meet legal requirements — especially public sector bodies that must comply with Section 508 and ADA Title II.
The good news is that WCAG 2.2 is backwards compatible. If your digital application already meets WCAG 2.1, you can build on existing work rather than starting from scratch. The transition typically involves targeted design and development updates, alongside updated testing practices.
WCAG 2.2 introduces nine new success criteria, generally focused on improving usability for people with cognitive disabilities, low vision, and motor impairments:
- 2.4.11 Focus Not Obscured (AA) — Ensure when an item gets keyboard focus, it is at least partially visible.
- 2.4.12 Focus Not Obscured (AAA) — Ensure when an item gets keyboard focus, it is fully visible.
- 2.4.13 Focus Appearance (AAA) — Use a focus indicator of sufficient size and contrast.
- 2.5.7 Dragging Movements (AA) — For any action that involves dragging, provide a simple pointer alternative.
- 2.5.8 Target Size (Minimum) (AA) — Ensure targets meet a minimum size or have sufficient spacing around them.
- 3.2.6 Consistent Help (A) — Put help in the same place when it is on multiple pages.
- 3.3.7 Redundant Entry (A) — Don’t ask for the same information twice in the same session.
- 3.3.8 Accessible Authentication (AA) — Don’t make people solve, recall, or transcribe something to log in.
- 3.3.9 Accessible Authentication (AAA) — Don’t make people recognize objects or user-supplied media to log in.
You can find full descriptions and examples of these success criteria on the W3 website: What’s new in WCAG 2.2.
Remember, WCAG compliance is only a starting point for true accessibility. Meeting the complex needs of real people requires a human-centered approach. Our accessibility expert recommends seven steps to shift to empathy-driven accessible design.
This article was created in partnership Last Call Alumni Abby Kingman and our content writer, Peggy McGregor.
