W3C Accessibility Guidelines (WCAG) 3.0

W3C Editor's Draft

More details about this document
This version:
Latest published version:
Latest editor's draft:
Commit history
(Library of Congress)
(Google, Inc.)
Project Manager:
(Deque Systems, Inc)
GitHub w3c/silver (pull requests, new issue, open issues)


The W3C Accessibility Guidelines (WCAG) 3.0 provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices. They address various types of web content including static content, interactive content, visual and auditory media, and virtual and augmented reality. The guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

Each guideline in this standard provides information on accessibility practices that address documented user needs of people with disabilities. Guidelines are supported by multiple outcomes to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each outcome.

This specification is expected to be updated regularly to keep pace with changing technology by updating and adding methods, outcomes, and guidelines to address new needs as technologies evolve. For entities that make formal claims of conformance to these guidelines, several levels of conformance are available to address the diverse nature of digital content and the type of testing that is performed.

W3C Accessibility Guidelines 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [WCAG22] and previous versions, but does not deprecate these versions. WCAG 3.0 will incorporate content from and partially extend User Agent Accessibility Guidelines 2.0 [UAAG20] and Authoring Tool Accessibility Guidelines 2.0 [ATAG20]. While there is 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 is not backwards compatible with WCAG 2.X. WCAG 3.0 does not supersede WCAG 2.2 and previous versions; rather, it is an alternative set of guidelines. Once these guidelines become a W3C Recommendation, the W3C will advise developers, content creators and policy makers to use WCAG 3.0 in order to maximize future applicability of accessibility efforts. However, content that conforms to earlier versions of WCAG continue to conform to those versions.

See WCAG 3 Introduction for an introduction and links to WCAG technical and educational material.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

To comment, file an issue in the W3C silver GitHub repository. The Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive). In-progress updates to the guidelines can be viewed in the public editors' draft.

This document was published by the Accessibility Guidelines Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 2 November 2021 W3C Process Document.

1. Introduction

This section (with its subsections) provides advice only and does not specify guidelines, meaning it is informative or non-normative.

Editor's note

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

  • WCAG3
  • WCAG3 Explainer
  • Guideline How-tos
  • Outcomes
  • Methods
  • Functional categories

These parts and sections are inter-related and are continually being refined and updated as more sections are developed. Content is in various states of maturity. The status is marked at the top of each section (see 1.2 Section status levels). Each publication of WCAG 3 will include updates to some, but not necessarily every part and section. This process will facilitate quarterly updates, which provide 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:

  • First draft of the WCAG3 Explainer, which takes explanatory material out of WCAG3 to improve usability.
  • New conformance section on user-generated content and the glossary definition of user-generated content.
  • A new proposal revising the Methods template to address comments from the First Public Working Draft (FPWD). This proposal was done in partnership with the ACT task force.

End of note

Plain language summary of Introduction

The W3C Accessibility Guidelines (WCAG) 3.0 show ways to make web content accessible to people with disabilities. WCAG 3.0 is a newer standard than the Web Content Accessibility Guidelines (WCAG) 2.2. You may use WCAG 2.2 or the new standard.

What’s new in WCAG 3.0?

End of summary for Introduction

1.1 About WCAG 3.0

This introduction provides a brief background to WCAG 3.0. Detailed information about the structure of the guidelines and inputs into their development is available in the Explainer for W3C Accessibility Guidelines (WCAG) 3.0. That document is recommended reading for anyone new to WCAG 3.

This specification presents a new model and guidelines to make web content and applications accessible to people with disabilities. The W3C Accessibility Guidelines (WCAG) 3.0 support a wide set of user needs, use new approaches to testing, and allow frequent maintenance of guidelines and related content to keep pace with accelerating technology change. WCAG 3.0 supports this evolution by focusing on users’ functional needs. These needs are then supported by outcomes and technology-specific methods to meet those needs. 

Following these guidelines will make content more accessible to people with a wide range of disabilities, including accommodations for blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. Following these guidelines will also often make content more usable to users in general as well as accessible to people with disabilities.

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.

There are many differences between WCAG 2.X and WCAG 3.0. Content that conforms to WCAG 2.2 A & AA is expected to meet most of the minimum conformance level of this new standard but, since WCAG 3.0 includes additional tests and different scoring mechanics, additional work will be needed to reach full conformance. Since the new standard will use a different conformance model, the Accessibility Guidelines Working Group expects that some organizations may wish to continue using WCAG 2.X, while others may wish to migrate to the new standard. For those that wish to migrate to the new standard, the Working Group will provide transition support materials, which may use mapping and other approaches to facilitate migration.

1.2 Section status levels

As part of the WCAG 3.0 drafting process each normative section of this document is given a status. This status is used to indicate how far along in the development this section is, how ready it is for experimental adoption, and what kind of feedback the Accessibility Guidelines Working Group is looking for.

For more details, see the AG Process page.

1.2.1 Filtering less mature content

Placeholder and exploratory sections may be distracting to reviewers who want to focus on more vetted cotent. These sections can be hidden with the following button:

1.3 Relationship to other W3C guidelines

The Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] were designed to be technology neutral, and have stayed relevant for over 10 years. The Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20] provide guidance for various types of software that assist people in writing accessible content. User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG20] offers useful guidance to user agent developers and has been implemented on an individual success criterion basis.

These guidelines have normative guidance for content and helpful implementation advice for authoring tools, user agents, and assistive technologies.

For more details about differences from previous guidelines, see Appendix: Differences From WCAG 2.

Editor's note

This version of the guidelines includes an example method for ATAG (Author control of text alternatives) and UAAG ( Reflow of captions and other text in context). Future drafts of the guidelines will include additional examples of ATAG- and UAAG-related content.

End of note

1.4 Goals and Requirements

The goal of WCAG 3.0 and supporting documents is to make digital products including web, ePub, PDF, applications, mobile apps, and other emerging technologies more accessible and usable to people with disabilities. It is the intention for WCAG 3.0 to meet this goal by supporting a wider set of user needs, using new approaches to testing, and allowing more frequent maintenance of guidelines to keep pace with accelerating technology change. The hope is that WCAG 3.0 will make it significantly easier for both beginners and experts to create accessible digital products that support the needs of people with disabilities.

Research and design work performed by the Silver Task Force identified key requirements needed to improve upon the existing WCAG 2.X structure. These requirements, presented in the Requirements for Silver document, shaped the guidelines that follow and should be taken into account when evaluating and updating the guidelines.

Editor's note

While the majority of guidelines are still to be written and we continue to explore additional ways of validating conformance, we seek wider public review on the approach presented here.

End of note

2. Normative requirements

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Plain language summary of Normative requirements

There are two types of content in this document:

End of summary for Normative requirements

In addition to this section, the Guidelines, Testing, and Conformance sections in WCAG 3.0 provide normative content and define requirements that impact conformance claims. Introductory material, appendices, sections marked as non-normative, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].

Editor's note

Outcomes are normative. The working group is looking for feedback on whether the following should be normative or informative: guidelines, methods, critical errors, and outcome ratings.

End of note


This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Plain language summary of Guidelines

The following six guideline examples show different features of WCAG 3.0:

End of summary for Guidelines

The individuals and organizations that use WCAG vary widely and include web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including functional categories of disabilities, general guidelines, outcomes that can be tested, a rich collection of methods, resource links, and code samples.

The guidelines included in this draft have been selected to show different types of content:

Editor's note

These are early drafts of guidelines included to serve as initial examples. They are used to illustrate what WCAG 3.0 could look like and to test the process of writing content. These guideline drafts should not be considered as final content of WCAG 3.0. They are included to show how the structure would work. As this draft matures, numbering of individual guidelines will be removed to improve overall usability of the guidelines in response to public requests. WCAG 2.x success criteria will be migrated to this new structure before WCAG 3.0 moves to candidate recommendation.

As more content is developed, this section will be a list of guidelines with a unique short name, and the text of the requirement written in plain language. To see the overall plan for migrating content from WCAG 2.1 to WCAG 3.0, see the WCAG to Silver Outline Map.

End of note

Text alternatives

Guideline status: Placeholder. We will be addressing this topic.

Guideline: Provide text alternative for non-text content.

Learn how to meet guideline "Text alternatives"

Text alternative available

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Provides text alternatives for non-text content for user agents and assistive technologies. This allows users who are unable to perceive and / or understand the non-text content to determine its meaning.

Editor's note

We selected the Text Alternatives guideline to illustrate how WCAG 2.2 success criteria can be moved to WCAG 3.0 with minimal changes. Most of the material was directly copied from W3C sources such as WCAG 2.1, Web Accessibility Tutorials, and HTML 5.3 examples.

For this First Public Working Draft, we included HTML methods. This will be expanded in future drafts. We have also included a method, Author Control of Text Alternatives (ATAG), that demonstrates how requirements from the Authoring Tool Accessibility Guidelines (ATAG) 2.0 can be included as methods.

End of note

Outcome details and methods for "Text alternative available"

Clear words

Guideline: Use common clear words.

Learn how to meet guideline "Clear words"


Common clear words

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Uses common words to reduce confusion and improve understanding.

Editor's note

We selected Use Clear Words to show that the new WCAG3 structure can include accessibility guidance that does not fit into the WCAG 2.x structure. In the research phase of this project, we identified user needs from the Cognitive Accessibility Task Force and the Low Vision Accessibility Task Force that could not be addressed by a true/false success criterion in WCAG 2.1. We wanted to select one of those user needs and include it in the first draft of WCAG3 to show that more complex user needs can be included and still be testable and scored.

Use Clear Words is a new guideline proposed by the Cognitive Accessibility Task Force (COGA) and includes research, documents and comments from COGA. The selection of user needs and the outcomes necessary to address them is aligned with the new COGA publication, Making content usable for people with cognitive and learning disabilities [coga-usable].

The clear words guideline was included to illustrate that the proposed WCAG 3.0 scoring and structure can be used in non-binary testing. Clear words guideline uses a rating scale with flexible units of measure. For example, testing could be done by a webpage, a paragraph, a section of instructions on an application, or other. A manual tester evaluates the paragraph, webpage, or section on a rating scale. While we do not know of any mainstream accessibility tool that measures common words, there are some working prototypes of tools developed outside the W3C. We are interested in feedback on testing this guideline and its scoring.

There are a number of exceptions to this guideline. We are interested in feedback where to put that information for ease of use.

This category of new guideline needs further development. It is included to show that it could work, not necessarily that this is the shape of the final guideline.

End of note

Outcome details and methods for "Common clear words"


Guideline: Provide captions and associated metadata for audio content.

Learn how to meet guideline "Captions"

Translates speech and non-speech audio

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Translates speech and non-speech audio into alternative formats (e.g. captions) so media can be understood when sound is unavailable or limited. User agents and APIs support the display and control of captions.

Outcome details and methods for "Translates speech and non-speech audio"

Conveys information about the sound

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Conveys information about the sound in addition to the text of the sound (for example, sound source, duration, and direction) so users know the necessary information about the context of the sound in relation to the environment it is situated in.

Editor's note

This guideline demonstrates how the WCAG3 structure can be used with emerging technologies such as virtual reality, augmented reality and other immersive web technologies (XR). Research in this area is ongoing and we expect to complete more details in future drafts.

The Silver XR group has been working closely with other groups within the W3C as well as researchers in the area of captioning in immersive technologies. This is a rapidly developing field, and the recommendations listed are more exploratory. They are included as an example that WCAG3 can be used with emerging technologies. We hope that including this guideline will help inspire more research in this area.

Because this guideline was included to demonstrate emerging technology, there is little guidance included on traditional captions. Future drafts will also include more traditional caption guidance.

We want public feedback about whether open captions (burned in captions) should be considered as equivalent to closed captions. Closed captions are formed from text, which can be customized to meet user needs. For example, the text has the potential be repositioned, resized and presented in different color schemes. Open captions are burned in representations of text. As such, the text of open captions cannot be customized or adapted to other languages. Existing open captions can also conflict visually with any closed captions.

End of note

Outcome details and methods for "Conveys information about the sound"

Structured content

Guideline: Use sections, headings, and sub-headings to organize content.

Learn how to meet guideline "Structured content"

Headings organize content

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Organizes content into logical blocks with headings relevant to the subsequent content. This makes locating and navigating information easier and faster.

Outcome details and methods for "Headings organize content"

Uses visually distinct headings

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Uses visually distinct headings so sighted readers can determine the structure.

Outcome details and methods for "Uses visually distinct headings"

Conveys hierarchy with semantic structure

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Provides semantic structure that conveys the hierarchy to help explore and navigate the content.

Outcome details and methods for "Conveys hierarchy with semantic structure"

Editor's note

We included the structured content guideline as an example of an “easy” guideline that was well understood and addressed diverse disability needs. While WCAG2 addresses headings from the semantic needs of screenreader users, little has been done to directly address the needs of people with cognitive disabilities around headings. This guideline shows how a well-known area of accessibility can address more user needs of different groups of people with disabilities. The structured content guideline has multiple outcomes working together to cover the different aspects of accessibility needed for different categories of people with disabilities.

The structured content guideline began as a guideline on use of headings. Going through the content development process, we realized that it was a broader topic than simply headings, but there is little content developed beyond headings. Note that this guideline is used for prototyping, and is the most uneven in style of content. Additional outcomes and content will be added in future drafts to make this guideline more complete.

Structured content guideline also shows how several WCAG 2.1 success criteria can be re-combined and include AAA level success criteria such as 2.4.10 Section Headings.

Do you like the inclusion of broader needs for structured content than providing semantics for screenreader users? Do you think this should be a separate guideline, or do you like having multiple, testable outcomes supporting the guideline? Do you like the approach of merging WCAG2 success criteria with related user needs?

End of note

Visual contrast of text

Guideline: Provide sufficient contrast between foreground text and its background.

Learn how to meet guideline "Visual contrast of text"

Luminance contrast between background and text

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Provides adequate luminance contrast between background and text colors to make the text easy to read.

Editor's note

Visual Contrast is a migration from WCAG 2.1 with significant updates:

  • New calculations of contrast based on more modern research on color perception.
  • Merging the 1.4.3 AA and 1.4.6 AAA levels into one guideline.
  • New test of text contrast.
  • At this time, it only includes textual visual contrast.

We propose changing the names of Contrast (Minimum) and Contrast (Enhanced) to Visual Contrast of Text as a signal of a paradigm change from one about color to one about perception of light intensity. The reason for this change is that the understanding of contrast has matured and the available research and body of knowledge has made breakthroughs in advancing the understanding of visual contrast.

The proposed new guidance more accurately models current research in human visual perception of contrast and light intensity. The goal is to improve understanding of the functional needs of all users, and more effectively match the needs of those who face barriers accessing content. This new perception-based model is more context dependent than a strict light ratio measurement; results can, for example, vary with size of text and the darkness of the colors or background.

This model is more responsive to user needs and allows designers more choice in visual presentation. It does this by including multi-factor assessment tests which integrate contrast with inter-related elements of visual readability, such as font features. It includes tests to determine an upper limit of contrast, where elevated contrast may impact usability.

This outcome will eventually include a second rating approach based on the mean average APCA value for all text in a process and view based on a character count.

End of note

Outcome details and methods for "Luminance contrast between background and text"

Error prevention

Guideline: Provide features that help users avoid errors.

Learn how to meet guideline "Error prevention"

Input instructions provided

Outcome status: Exploratory. We are exploring one or more possible directions for this content.

Outcome: Provides instructions for inputs that have data entry requirements (for example, required, date, password) so users know how to provide valid information.

Outcome details and methods for "Input instructions provided"

Editor's note

An additional outcome, Moderated form completion: Guides data entry, provides validation, and moderates form completion so users can avoid data entry errors, is under development. Details will be posted when available.

End of note

Editor's note

The Error Prevention guideline is a combination of WCAG 2.2 success criteria and additional requirements to address a broader range of functional needs.

For WCAG 2.2 success criteria, we focused on Success Criterion 3.3.2: Labels or Instructions (Level A), which states, "Labels or instructions are provided when content requires user input." We are still working on outcomes and methods to address Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) and Success Criterion 3.3.6 Error Prevention (All) (Level AAA). We drew on WCAG 2.2 Techniques, Easy Checks, Web Accessibility Tutorials, and ACT Rules to create the outcomes, methods, examples, and tests, including (but not limited to):

To identify requirements beyond those specified in WCAG 2.2, we used user journeys to explore user needs related to different error-related scenarios, such as error on data entry and error on form submission (see Error Flows Inventory (Google Doc)). We then elaborated those scenarios to explore and define features that help prevent errors and help users recover from errors. We defined common user needs related to errors, such as "User needs instructions for inputs that have data entry requirements so they can enter data in the correct format." We used the DRAFT Functional Needs as a guide to define specific functional needs, such as "User needs instructions that display at the source of input so they can access the instructions while focused on the input" for functional needs related to limited vision, attention, and memory. We summarized functional needs in the Error User Needs Worksheet (Google Sheet) and used those as the basis for defining guidelines, outcomes, and methods.

The guidelines, outcomes, and methods related to errors are not complete. However, we would like your feedback on the structure and approach to defining accessibility guidelines with this user-first approach. Does the user journey approach make sense as a way of defining accessibility features? Are the methods clear in how they help achieve the outcome? Are the tests understandable and straightforward?

For this 3rd Public Working Draft, we include three methods to support the outcome of Input instructions provided for the Error Prevention guideline, which focuses on preventing errors from occurring. We are still working on additional outcomes and methods. We are also working on a guideline for Error Notification that will address outcomes and methods related to helping users recover from errors. We hope to include the remaining Error Prevention content and the complete Error Notification guideline in the 4th Public Working Draft, due out in December 2021.

End of note

4. Testing

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Section status: Exploratory. We are exploring one or more possible directions for this content.
Plain language summary of Testing - What types of tests and scopes are used?

WCAG 3.0 includes four types of tests which are evaluated pass/fail:

Tests can be applied to four different scopes:

End of summary for Testing

Editor's note

This section is exploratory. Outstanding questions that need to be addressed include:

  • Developing detailed examples of each test type,
  • Finalizing names and descriptions of scope and test types,
  • If there are further test types that should be added,
  • Determining what to document for procedural tests,
  • How protocols will be incorporated,
  • How well this approach to testing supports additional requirements not addressed in 2.1,
  • Testing the accuracy, reliability, repeatability, etc. of this approach,
  • How well this approach will support regulatory needs,
  • How a process will be defined and documented,
  • How these tests will be integrated into a conformance model (including levels or scores), and
  • Get feedback from designers, developers and other communities on wording choice.
  • Rework plain language section
  • Determine how organisations can declare which convention they are following in a way that is transparent, both to their users and for the purpose of verification in audits
  • Address all github issues under test types and terminology milestone.

End of note

Editor's note

The model presented provides a structure for testing that can be built upon to better accommodate dynamic or very frequently updated content than WCAG 2.X. We are exploring additional approaches to testing using sampling and/or other alternatives for reaching conformance in situations where testing all content is not possible. We also plan to include a definition and concept for substantially conforming in order to address the potential difficulties presented when testing all content in large digital products and 3rd party content.

End of note

WCAG 3.0 tests outcomes. Outcomes are written as testable criteria that allow testers to determine if the content they are evaluating satisfies the criteria.

Testing outcomes use items, views, user processes, and the aggregate to define what is being tested.

Items are the smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, an icon, or an image.

Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not restricted to content meeting that definition. For example, a view could be considered a "screen" in a mobile app.

User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required in order to complete an activity. A user process may include a subset of items in a view or a group of views.

Examples of a process include:

A process is comprised of one or more views or subsets of views. Only the part of the views that support the user process are included. in a test of user process.

The aggregate is the combination of items, views, and user processes that collectively comprise the site, set of web pages, web app, etc.

4.1 Types of tests

WCAG 3.0 includes four types of tests:

  1. Unconditional tests,
  2. Conditional tests,
  3. Conventional tests, and
  4. Procedural tests.

All tests results will pass or fail. The criteria used to evaluate whether the test pass differ for each type of test. The inter-rater reliability for an unconditional test is higher than the inter-rater reliability of a conditional test which higher than that of a procedural test. A conditional test includes an additional checkpoint that determines which unconditional and conditional tests will be used. As a result of these differences, the information tested change based on the test type to ensure each can be evaluated as pass or fail. For example, unconditional and conditional tests evaluate the results as they do in WCAG 2. Procedural tests may only evaluate a statement that the procedural occurred, instead of the results. Meeting an outcome may include one or more of these types of test.

Testing the outcomes using these tests might involve a combination of automated evaluation, semi-automated evaluation, and human evaluation.

Although content may satisfy all outcomes using unconditional and conditional tests, the content may not always be usable by people with a wide variety of disabilities. The conditional and procedural tests address this gap by evaluating more of the user experience.

Editor's note

We are looking for more appropriate terms to distinguish between types of tests and scope and welcome suggestions. Other terms suggested for 'unconditional' are 'quantitative', 'non-conditional', 'less-subjective', constant', 'definitive', 'pass/fail' or "fixed objective". Other terms suggested for 'conditional' are 'qualitative', 'qualified' and 'fixed subjective.' Other terms suggested for 'conventional' are 'convention based objective', 'use case', or 'contextual' Other terms suggested for 'procedural' are "process evaluation" and "process based subjective.'

End of note

Editor's note

We continue to test this approach and others for validity, reliability, sensitivity, adequacy, and complexity.  Alternatives that we are exploring are noted as separate editor’s notes where applicable. We welcome suggestions on ways to improve the scoring to better meet these criteria.

End of note

4.1.1 Unconditional tests

Unconditional tests are tests where the results will not vary based on the tester or approach. Examples include testing whether something exists or against an unconditional value. Unconditional tests evaluate content, often against a unit or view, for accessibility.

Unconditional tests evaluate against a universal criterion that is true in all situations and requires no subjective evaluation.

Methods using unconditional tests include the baseline to test against. Most often this baseline is whether or not something is present. In the case of color contrast, this baseline is a number.

Unconditional tests may be automated or manual. Automated evaluation can be completed without human assistance. These tests allow for a larger scope to be tested but automated evaluation alone cannot determine accessibility. Over time, the number of accessibility tests that can be automated is increasing, but manual testing is still required to evaluate most methods at this time.

4.1.2 Conditional tests

Conditional tests rely on informed qualitative evaluations based on a set of criteria. The test results may vary slightly between experienced testers. Examples include testing quality and applicability.

Methods using conditional tests include the criteria being tested and guidance on evaluating how well the content meets the criteria of the conditional test.

4.1.3 Conventional tests

Conventional tests evaluate the results within a particular context. The tests are still unconditional or conditional tests but the context dictates:

  • which unconditional or conditional tests are used, or
  • what the baseline is used to test against.
WCAG will rely on conventional tests when a solution will improve accessibility but where that implementation of the solution will vary based on situation, such as language, type of content, or other design decisions. Examples include testing for consistency of design decisions and content choices.

Methods using conventional tests include the test criteria the organization would need to evaluate, parameters for success and failure, and, if it is a conditional test, guidance on evaluating how well the content meets the criteria of the conditional test.

4.1.4 Procedural tests

Procedural tests evaluate whether a process was used to improve accessibility. Examples include usability and plain language testing. Procedural tests could include assistive technology testing, user-centered design methods, plain language testing, and both user and expert usability testing. Procedural testing often applies to the aggregate or user process. Methods would provide guidance for different procedures that are proven to improve accessibility and would test declarations about the procedural used rather than the results.

Editor's note

The requirements for what would be evaluated for procedural tests are to be determined.

End of note

4.1.5 Technology specific testing

Each outcome includes methods associated with different technologies. Each method contains tests and techniques for satisfying the outcome. The outcome is written so that testers can test the accessibility of new and emerging technologies that do not have related methods based solely on the outcome.

5. Conformance

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

5.1 Conformance

Plain language summary of Conformance

You might want to make a claim that your content or product meets the WCAG 3.0 outcomes. If it does meet the outcomes, we call this “conformance.” To conform to WCAG 3.0, your test results must show that your project is accessible.

If you want to make a conformance claim, you must use the process described in this document. Your content can conform to WCAG 3.0, even if you don’t want to make a claim. You can still use this process to test your project’s accessibility.

End of summary for Conformance

5.1.1 Conformance levels

Section status: Exploratory. We are exploring one or more possible directions for this content.
Editor's note

WCAG 3.0 will include a new conformance model in order to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

  1. Develop a model that encourages websites to continue to do better and better (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;
  3. Allow for bugs and oversight by content authors, provided the impact of them is limited to users with disabilities.

To do this, the conformance model prioritizes content needed to complete tasks while still testing the entire view for accessibility errors. This priority is reflected in the scoring system, which does not allow for errors along the paths needed to complete processes but allow for some accessibility errors outside process completion. This means that sites may conform at the lowest level (Bronze), while still containing a small amount of content that does not meet one or more guidelines, so long as that content doesn’t prevent people with disabilities from successfully using the site.

We seek feedback on whether this flexibility will be beneficial in encouraging content providers to meet conformance because it is more achievable or whether content providers are less likely to improve accessibility if they aren't required to. We also seek feedback on the conformance approach as a whole.

End of note

WCAG 3.0 defines three levels of conformance: bronze, silver, and gold. Bronze

Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0. While there is a lot of overlap between WCAG 2.X and WCAG 3.0, WCAG 3 includes additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X. Silver

Silver is a higher conformance level. Gold

Gold is the highest conformance level.

5.1.2 User Generated Content

Section status: Exploratory. We are exploring one or more possible directions for this content.

Web content publishers may include content provided by the users of their digital products. We refer to such content as "User Generated Content".

Examples of User Generated Content include:

  • social media postings and comments,
  • uploaded photographs, or
  • uploaded videos or other multimedia.

User Generated Content is provided for publication by visitors where the content platform specifically welcomes and encourages it. User-generated content is content that is submitted through a user interface designed specifically for members of the public and customers. Use of the same user interface as an authoring tool for publication of content by agents of the publisher (such as employees, contractors, or authorized volunteers) acting on behalf of the publisher does not make that content User Generated Content. The purpose of the User Generated Content Conformance is to allow WCAG 3 outcomes and methods to require additional or different steps to improve the accessibility of User Generated Content.

An important part of WCAG Conformance is the specific guidance that is associated with individual WCAG 3 guidelines and outcomes. Not all WCAG 3 guidelines will have unique outcomes and testing for User Generated Content. Unless User Generated Content requirements are specified in a particular guideline, that guideline applies as written whether or not the content is User Generated.

Editor's note

We plan for a future Working Draft to include specific examples of guidelines with additional requirements for user generated content. One example would be 'alternative text'. The Authoring Tool Accessibility Guidelines (ATAG) has specific guidance for providing a mechanism for alternative text. The ATAG 2.0 Guideline B.2.3 - "Assist authors with managing alternative content for non-text content" could be adapted to provide specific, guideline-related guidance for user generated alternative text.

End of note

The web content publisher should identify all locations of User Generated Content (such as commentary on hosted content, product descriptions for consumer to consumer for sale listings, and restaurant reviews) and perform standard accessibility evaluation analysis for each. If there are no accessibility issues, the User Generated Content is fully conforming. Steps to Conform

If accessibility issues are identified, or if the website author wants to proactively address potential accessibility issues that might arise from User Generated Content, then all of the following must be indicated alongside the User Generated Content or in an Accessibility Statement published on the site or product that is linked from the view or page in a consistent location:

  1. Clearly identify where User Generated Content can be found on the publisher's digital product (perhaps by id href);
  2. Clearly identify the steps taken to encourage accessibility in User Generated Content such as prompting the user for ALT text for their uploaded images before they are accepted and the disallowal of text attributes except as they are part of semantic markup such as strong, headings, etc., as enumerated in Guideline Outcomes;
Editor's note

Editor's Note: Once the conformance approach is included, content that passes all tests will be considered fully conformant. It remains to be determined how to address User Generated Content that has accessibility issues; and to define what minimum thresholds might be acceptable. We expect WCAG 3 to provide this guidance within individual guidelines and outcomes and to support testing for conformance. The working group is looking at alternative requirements to apply to User Generated Content guideline by guideline, and is seeking feedback on what would serve as reasonable requirements on how to best support accessibility in User Generated Content with known (or anticipated) accessibility issues. The working group intends to more thoroughly address the contents and the location of an accessibility statement in a future draft.

End of note

5.1.3 Conforming alternative version

Section status: Placeholder. We will be addressing this topic.
Editor's note

For this first draft, the Accessibility Guidelines Working Group has focused on the basic conformance model. For a next draft, we will explore how conforming alternative versions fit into the new conformance model.

End of note

5.1.4 Only accessibility-supported ways of using technologies

Section status: Placeholder. We will be addressing this topic.
Editor's note

For this first draft, the Accessibility Guidelines Working Group has focused on the basic conformance model. For a next draft, we will explore how accessibility-supported fits into the new conformance model.

End of note

5.1.5 Defining conformance scope

Section status: Exploratory. We are exploring one or more possible directions for this content.

When evaluating the accessibility of content, WCAG 3.0 requires the outcomes apply to a specific scope. While the scope can be an all content within a digital product, it is usually one or more sub-sets of the whole. Reasons for this include:

  • Large amounts of content are impractical to evaluate comprehensively using anything beyond automated evaluation of atomic tests;
  • In many cases, content changes frequently, causing evaluation to be accurate only for a specific moment in time;
  • Some content is more important to the majority of users than other content; and
  • Content that mostly meets the requirements but has problems can interfere with the user's ability to complete a process begun elsewhere.

WCAG 3.0 therefore defines two inter-related ways to scope content: views and processes. Evaluation is done on one or more complete views or processes, and conformance is determined on the basis of one or more complete views or processes.

Conformance is defined only for processes and views. However, a conformance claim may be made to cover one process and view, a series of processes and views, or multiple related processes and views.  All unique steps in a process MUST be represented in the set of views. Views outside of the process MAY also be included in the scope.

Editor's note

The AG WG and Silver Task Force recognize that representative sampling is an important strategy that large and complex sites use to assess accessibility. While it is not addressed within this document at this time, our intent is to later address it within this document or in a separate document before the guidelines reach the Candidate Recommendation stage. We welcome your suggestions and feedback about the best way to incorporate representative sampling in WCAG 3.0.

End of note

5.1.6 Conformance requirements

Section status: Exploratory. We are exploring one or more possible directions for this content.

In order for technology to conform to WCAG 3.0, the following conformance requirements apply:

  1. Conformance level - Content MUST meet the requirements of the selected conformance level.

5.1.7 Conformance claims

Section status: Exploratory. We are exploring one or more possible directions for this content.

Conformance claims are not required. Authors can conform to WCAG 3.0 without making a claim. The material below describes how to make a conformance claim if that option is chosen. Required components of a conformance claim

A conformance claim MUST include the following information:

  1. Date of the claim;
  2. Guidelines title, version and URI W3C Accessibility Guidelines 3.0 at ???
  3. Conformance level satisfied: (bronze, silver, or gold);
  4. A concise description of the views and processes, such as a list of URIs for which the claim is made, including any state changes which lead to a new view; and
  5. The technology including the hardware, software, and assistive technology used to test the claim. Example conformance claim

On 12 August 2020, the following 10 views and 2 processes conform to WCAG 3.0 at a bronze level. Processes were selected because they are the most common activities on the site and include 4 unique views. The other 6 views are the most commonly used.

These were tested using Firefox and Chrome on a Windows platform. The assistive technology used included JAWS and Dragon.

6. Glossary

This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative.

Section status: Exploratory. We are exploring one or more possible directions for this content.

Many of the terms defined here have common meanings. When terms appear with a link to the definition, the meaning is as formally defined here. When terms appear without a link to the definition, their meaning is not explicitly related to the formal definition here. These definitions are in progress and may evolve as the document evolves.

End of note

Automated evaluation

Evaluation conducted using software tools, typically evaluating code-level features and applying heuristics for other tests.

Automated testing is contrasted with other types of testing that involve human judgement or experience. Semi-automated evaluation allows machines to guide humans to areas that need inspection. The emerging field of testing conducted via machine learning is not included in this definition.


Satisfying all the requirements of the guidelines. Conformance is an important part of following the guidelines even when not making a formal Conformance Claim.

See Conformance.


To declare something outdated and in the process of being phased out, usually in favor of a specified replacement.

Deprecated documents are no longer recommended for use and may cease to exist in the future.

The process of examining content for conformance to these guidelines.
Different approaches to evaluation include automated evaluation, semi-automated evaluation, human evaluation, and user testing.
Functional need

A statement that describes a specific gap in one’s ability, or a specific mismatch between ability and the designed environment or context.


High-level, plain-language content used to organize outcomes.

See Guidelines in the Explainer.

Human evaluation

Evaluation conducted by a human, typically to apply human judgement to tests that cannot be fully automatically evaluated.

Human evaluation is contrasted with automated evaluation which is done entirely by machine, though it includes semi-automated evaluation which allows machines to guide humans to areas that need inspection. Human evaluation involves inspection of content features, by contrast with user testing which directly tests the experience of users with content.


Content provided for information purposes and not required for conformance.


Content required for conformance is referred to as normative.

End of note


Detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.

See Methods in the Explainer.


Content whose instructions are required for conformance.


Content identified as informative or non-normative is never required for conformance.

End of note


Result of practices that reduce or eliminate barriers that people with disabilities experience.

See Outcomes.


A sequence of steps that need to be completed in order to accomplish an activity / task from end-to-end.

Semi-Automated Evaluation

Evaluation conducted using machines to guide humans to areas that need inspection.

Semi-automated evaluation involves components of automated evaluation and human evaluation.


Mechanism to evaluate implementation of a method.

Tests can include true / false evaluation or various types of rating scales as appropriate for the guideline, outcome, or technology.


Technology-specific approach to follow a method.

Editor's note

Future work on the glossary will better define terms such as publisher, content author, etc.

End of note

User need

The end goal a user has when starting a process through digital means.

User testing

Evaluation of content by observation of how users with specific functional needs are able to complete a process and how the content meets the relevant outcomes.

A. Guidelines development methodology

B. Differences from WCAG 2

B.1 Outcomes

Outcomes are different from WCAG 2.X success criteria. Compared to success criteria, outcomes are written to be:

The design of outcomes allows more varied needs of people with disabilities than could have been included in WCAG 2.X. 

Methods map approximately to WCAG 2.X Techniques documents.

B.2 Approximate mapping of WCAG 2 and WCAG 3 documentation

Success Criteria Outcomes
Techniques Methods
Understanding How-to

C. Change log

D. Acknowledgements

D.1 Participants who made notable contributions to the creation of this document

Editor's note

This section is intended to document participants who made notable contributions. The method of identifying these individuals is in process and a list should be included in the next draft and updated for each subsequent draft.

End of note

D.2 Participants of the Silver Task Force and Silver Community Group who contributed to this document

D.3 Participants of the Accessibility Guidelines Working Group who reviewed this document

D.4 Research Partners

These researchers selected a Silver research question, did the research, and graciously allowed us to use the results.

D.5 Enabling funders

This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and now under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

E. References

E.1 Normative references

Making Content Usable for People with Cognitive and Learning Disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 29 April 2021. W3C Working Group Note. URL: https://www.w3.org/TR/coga-usable/
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

E.2 Informative references

Authoring Tool Accessibility Guidelines (ATAG) 2.0. Jan Richards; Jeanne F Spellman; Jutta Treviranus. W3C. 24 September 2015. W3C Recommendation. URL: https://www.w3.org/TR/ATAG20/
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/UAAG20/
Web Content Accessibility Guidelines (WCAG) 2.0. Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/
Web Content Accessibility Guidelines (WCAG) 2.2. Charles Adams; Alastair Campbell; Rachael Bradley Montgomery; Michael Cooper; Andrew Kirkpatrick. W3C. 21 May 2021. W3C Working Draft. URL: https://www.w3.org/TR/WCAG22/