This Explainer accompanies the drafts of the W3C Accessibility Guidelines (WCAG) 3.0.

This is a first draft of the Explainer. It is not normative (informative) and is not expected to become a W3C Recommendation. It provides background on W3C Accessibility Guidelines (WCAG) 3.0.


The current proposal for WCAG 3 is made up of different parts and sections, including:

These parts and sections are inter-related and are continually being refined and updated as more sections are developed. Each publication of WCAG 3 will include updates to some, but not necessarily every part and section. This process will facilitate quarterly updates which provides opportunities for public review and comment throughout the evolution of the guidelines. As a result, the document is a work-in-progress. Content will evolve and there may be changes to layout and style that are not yet reflected in all parts of the present release and will be reflected in future releases. The parts and sections updated in this release are:

W3C Accessibility Guidelines (WCAG) 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [[WCAG22]] and previous versions, but does not deprecate WCAG 2.X. It will also incorporate content from and partially extend User Agent Accessibility Guidelines 2.0 [[UAAG20]] and Authoring Tool Accessibility Guidelines 2.0 [[ATAG20]]. These earlier versions provided a flexible model that kept them relevant for over 10 years. However, changing technology and changing needs of people with disabilities have led to the need for a new model to address content accessibility more comprehensively and flexibly. WCAG 3.0 originally had a project name of "Silver", so the original groups working on it and much of the early design work carries that project name.

This Explainer includes:

Background and development history

The Silver Task Force of the Accessibility Guidelines Working Group and the W3C Silver Community group have partnered to produce the needs, requirements, and structure for the new accessibility guidance. To date, the group has:

  1. Developed a list of Web Content Accessibility Guidelines stakeholders and their job stories
  2. Researched needs for a new major version of the Web Content Accessibility Guidelines; (Silver Research Project)
  3. Developed problem statements and opportunities to improve accessibility guidance;
  4. Received input from industry leaders for directions to proceed to address the problem statements; The full Final Report of the Silver Design Sprint is incorrectly labeled as a draft. It contains all the information on the Design Sprint.
  5. Drafted Requirements for WCAG3;
  6. Created and tested prototypes for aspects of the project; and
  7. Created a First Public Working Draft of WCAG3 and quarterly updated Working Drafts.


The goal of WCAG 3.0 is to provide information that can be used to improve the accessibility of products on a variety of platforms. WCAG 3.0 uses a model that allows it to address more disability needs than WCAG 2.X, as well as address publishing requirements and emerging technologies such as web XR (augmented, virtual and mixed reality) and voice input. It will also provide non-normative (informative) information about the ways web technologies need to work with authoring tools, user agents, and assistive technologies. The WCAG 3.0 model is designed to support better coverage across disabilities and be easier to maintain, so that the new model will be more enduring over time as technologies evolve.

Goals for Inclusion

The creation process for the guidelines should:

Goals for Content

Goals for Conformance

The goals are based on the Silver research, the results from the Silver Design Sprint, and input from the Accessibility Guidelines Working Group, the Silver Task Force and the Silver Community Group.

Non-Goals or Out-of-Scope

Explanation Behind Decisions

The following sections describe the decision process behind some of the more difficult or controversial topics.

Structure of these guidelines

Core Structure

Figure 1 shows the core structure of WCAG 3.0. WCAG 3.0 has three levels of content with associated documentation. Guidelines form the top level. Each guideline contains multiple outcomes, with associated critical errors and outcomes scoring. Each outcome contains multiple methods, with an associated description and examples, tests, and test scoring.

Guidelines structure

Guidelines provide a high-level, plain-language version of the content for managers, policy makers, individuals who are new to accessibility, and other individuals who need to understand the concepts but not dive into the technical details. They provide an easy-to-understand way of organizing and presenting the outcomes so that non-experts can learn about and understand the concepts. Each guideline includes a unique, descriptive name along with a high-level plain-language summary. Guidelines address functional needs on specific topics, such as contrast, forms, readability, and more. Guidelines group related outcomes and are technology-independent.

Guidelines are the essential part of W3C Accessibility Guidelines. Structuring the guidelines to provide information for accessibility beginners and other non-technical stakeholders addresses some of the usability issues identified in the Silver research and suggestions from the Silver Design Sprint.

Outcomes structure

Each guideline contains multiple outcomes. Outcomes result from practices that reduce or eliminate barriers that people with disabilities experience. Outcomes form the basis of a flexible and expansive architecture for accessibility guidelines that closely relates to the needs of people with disabilities. Outcomes are designed for use by developers, testers, and other technical experts.

Outcomes are written as testable criteria and include information on how to score the outcome in an optional Conformance Claim. Within a guideline, outcomes have an AND relationship. All relevant outcomes must be addressed but not all outcomes will apply to all technologies and situations. When an outcome does not apply, it is marked NA in the scoring.

Outcomes were not a result of the Design Sprint, but came from a joint meeting of AGWG to address scoring. Adding a level devoted to normative scoring addressed a number of issues:

  • The need for testable statements that were stable. This allows testing companies and regulators to state that the testable statement is not subject to change with methods. There was discussion of making the Methods normative to address this concern, but the consensus was that it was better to add a layer that was technology neutral so it could include emerging technologies.
  • A new layer gave us the ability to add precise definitions as well as plain language.
  • Outcomes allow guidelines to multiple barriers to address more complex functional needs of people with disabilities. All the Outcomes could then be required. For example: For a headings guideline could have multiple outcomes that require all outcomes to pass: it needs to have semantic text AND visual formating AND describe the text content following the heading.

Meeting minutes of the joint meeting of 14 May 2020.

Critical errors

Critical errors section is being revised. The following describes the proposal in the First Public Working Draft. This will probably change in future Working Drafts.

Outcomes include the related critical errors that can occur and how to identify them. Not all outcomes have critical errors. Any critical errors will result in the lowest score for the outcome.

Evaluating processes requires counting critical errors that occur within the process and associated views. Critical errors are:

  • Errors located anywhere within the view that stop a user from being able to use that view (examples: flashing, keyboard trap, audio with no pause);
  • Errors that when located within a process stop a user from completing a process (example: submit button not in tab order); and
  • Errors that when aggregated within a view or across a process stop a user from using the view or completing the process (example: a large amount of confusing, ambiguous language).

Outcome rating

Outcome rating section is being revised. The following describes the proposal in the First Public Working Draft. This will probably change in future Working Drafts.

Each outcome is rated on a scale of 0 to 4. The rating model is designed to be flexible in order to allow more functional needs of people with disabilities to be included in the guidelines. 

Each outcome defines the rating criteria used for that outcome. The rating criteria are designed to be technology agnostic but tie to the available methods so that method level scoring can be rolled up when possible or the tester can make an informed judgment call about the outcome rating.

Methods structure

The Method structure is being revised to merge more closely with ACT Rules and reduce ambiguity in testing. There is an example for Text Alternatives in the latest Working Draft.

Functional needs

The development of WCAG 3 guidelines starts with functional needs. A functional need is a statement that describes a specific gap in one’s ability, or a specific mismatch between ability and the designed environment or context. Functional needs are applied to specific topics (for example: contrast, forms, readability, and more) to identify the barriers experienced by people with disabilities. The barriers in these topics inform the outcomes, which state the conditions to test whether the functional needs have been met. Functional needs are documented in the how-tos, supplementary material accompanying the guidelines.

The work of cataloging functional needs is still in process and will continue after the First Public Working Draft.  Those interested can see more information in the draft Functional Needs.

Functional categories

Functional categories of disabilities group the functional needs of users with disabilities. Functional categories are used when reporting test results in the optional conformance claim.

Functional categories are similar to functional performance criteria in Section 508 [[508-criteria]] and functional performance statements in en 301 549 [[en-301-549]]. The current list of functional categories is:

The list of functional categories is a draft. Creating meaningful groupings is still a work in progress and currently evolving along with the work on cataloging functional needs. This work will continue after the First Public Working Draft.  Those interested can see more information in the document DRAFT Functional Needs.

How the parts work together

The core structure has inter-relationships with supporting documents and the scoring process. Functional needs inform user needs (captured in the How-To), outcomes, and functional categories. The tests within methods are used to inform the scores for each outcome. Then outcome scores are aggregated to create scores by functional category and an overall score. These then result in a bronze rating. Silver and gold ratings build on the bronze rating to demonstrate improved accessibility. General information about guidelines is available in How-To documents.

Documentation and Scoring Structure from First Public Working Draft

The Scoring process is in the process of extensive revision.

Conformance Levels

The Conformance Levels are being revised with the Scoring. The following paragraph describes the proposal in the First Public Working Draft.

WCAG 3 has an optional scoring system that can better inform organizations on the quality of their accessibility effort. The optional conformance levels provide a way for organizations to report their conformance in simple manner. The bronze level is based on the score in each functional category and the overall score. Silver and gold levels require conforming at the bronze level plus additional improved usability for people with disabilities.

Selecting a Representative Sample

This is the basics of the proposal from Q2 2020 that was approved to go into the FPWD. There are still many details that need to be worked out and many objections to be resolved.

Minutes of Joint AGWG Silver "Deep Dive" meeting on Representive Sampling where the group agreed to return to this discussion in a later draft.