Explainer for W3C Accessibility Guidelines (WCAG) 3.0

W3C Editor's Draft

This version:
https://w3c.github.io/silver/explainer/
Latest published version:
https://www.w3.org/TR/wcag-3.0-explainer/
Latest editor's draft:
https://w3c.github.io/silver/explainer/
Editors:
(TetraLogical)
(Invited Expert)
(Google, Inc.)
(W3C)
Participate:
GitHub w3c/silver
File an issue
Commit history
Pull requests

Abstract

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

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. 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/.

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.

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

GitHub Issues are preferred for discussion of this specification.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership.

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 15 September 2020 W3C Process Document.

1. Introduction

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.

One of the goals of W3C Accessibility Guidelines (WCAG) 3.0 is that it will be written using plain language as much as possible so that people who are not technical can still understand it, and so WCAG 3.0 can be more easily translated into other languages. When it is published, WCAG 3.0 will have many ways for making the web and other digital content (like video or mobile apps) more accessible to people with disabilities.

This Explainer includes background information on the development of WCAG 3.0, its goals and research. It also provides additional explanation of structure and differences from the current WCAG 2 guidelines to make it easier for people to understand.

2. 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. Researched accessibility guidance needs
  2. Developed problem statements and opportunities to improve accessibility guidance
  3. Received input from industry leaders for directions to proceed
  4. Drafted requirements for the project (they will be reviewed after public feedback from the First Public Working Draft)
  5. Created and tested prototypes for aspects of the project
  6. Created a First Public Working Draft

2.1 Background on WCAG 3.0

The Silver Community Group and their research partners conducted a year of research which included a literature review as well as interviews, surveys, and self-reporting with people with disabilities, content developers, quality assurance professionals, tool developers, designers and policy makers.

The results are available in The Research Summary Slide Deck. One recurring theme was positive perceptions about the popularity and quality of the guidance in WCAG 2.0. Most of the opportunities identified in the research were changes in the structure and presentation of accessibility guidance to:

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.

For further introduction to WCAG 3, see the WCAG 3 Introduction.

Editor's note

W3C strives to be as inclusive as possible, and has actively sought participation and input from a broad range of stakeholder groups. We recognize, however, that there is always room for improvement in practices to support inclusion and representation. As you evaluate this document, please consider whether there are ways the Working Group can better support your review, feedback, or inclusion within the process of creating this standard. We welcome feedback on this question as part of your comments.

3. Goals

3.1 Goals for Inclusion

These goals come from the Silver Requirements Design Principles. The creation process for the guidelines should:

3.2 Goals for Content

3.3 Goals for Conformance

Editor's note

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

4. Non-Goals or Out-of-Scope

5. Explanation Behind Decisions

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

5.1 Structure of these guidelines

This section is non-normative.

Plain language summary of Structure of these guidelines
  • Guidelines: solutions to accessibility problems.
  • Outcomes: the desired result (or “outcome”) of reducing accessibility problems. This is what you test for.
  • Methods: detailed ways and tests for rating how well your project meets an outcome.

Some of these sections are in this document. You can find others in links within the sections.

End of summary for Structure of these guidelines

Figure 1 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.

5.1.1 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.

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

5.1.2 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.

Example: Convey hierarchy with semantic structure

5.1.2.1 Critical errors

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).
5.1.2.2 Outcome rating

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.

5.1.3 Methods structure

Figure 2 Screenshot of a Method for Structured Content

Each outcome has one or more methods. There are three types of methods:

  • All - Methods that apply across all technologies.
  • Technology specific - Methods that apply to one of a predetermined list of technologies such as HTML, PDF, or VR.
  • Fallback - Methods that apply to emerging or proprietary technology and for technology that does not yet have a method written

When technology specific methods are provided, the outcomes will also include one or more fallback methods.

The methods include detailed information on how to meet the outcome, code samples, working examples, resources, as well as information about testing and scoring the method.

Example: Semantic headings (HTML)

Note

While WCAG 3 Methods have some similarity with WCAG 2 Techniques, they are not the same and are not interchangeable.

5.1.3.1 Description

Each method includes a detailed technical description of the method with instructions on how the method works that do not depend on examples. If there are dependencies between methods, these are also listed here. Dependencies between methods will be a rare situation.

5.1.3.2 Examples

Each method also includes working code samples and detailed examples.

5.1.3.3 Tests

Tests provide ways to check that methods and techniques have been followed. Tests include step-by-step instructions on evaluating the method based on the technology being used. Tests may vary by technology as needed.

Tests specify the unit being tested and the approach to scoring for that test.

5.1.3.4 Test Scoring

Each method includes information on how to score individual instances of the test. The testing results for methods inform the rating of the related outcome.

5.2 Additional Documentation and Scoring Information

This section is non-normative.

Plain language summary of Additional Documentation and Scoring Information
  • How-to information: advice written in plain language, including information on how to get started with accessibility.
  • Functional needs: how to solve the access problems that people face.
  • Functional categories: groups of disability types.
  • Conformance levels: scoring your project’s accessibility. There are three levels for your project’s final score: bronze, silver, or gold. Scoring is not required.

Some of these sections are in this document. You can find others in links within the sections.

End of summary for Additional Documentation and Scoring Information

The core structure has inter-relationships with supporting documents and the scoring process. Functional needs inform both 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.

Figure 3 Documentation and Scoring Structure

5.2.1 How tos

The How-To content provides explanatory material for each guideline that applies across technologies. This guidance explains how to apply the concepts presented in the guidelines for non-technical readers. This plain language resource includes information on getting started, who the guideline helps and how, as well information for project managers, designers and developers.  

Figure 4 Example screenshot of a How-To for Structured Content

The example of a How-To for Structured Content provides basic information organized by tabs to help people get started with accessibility for structured content, plan for implementing accessible structured content across a project, design accessible structured content, and basics for developers new to accessibility of structured content. It also includes information on examples, the outcomes for meeting the guideline, and resources.

5.2.2 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.

Example: Use without vision.

Editor's note

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.

5.2.3 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:

  • Vision and Visual
  • Hearing and Auditory
  • Sensory Intersections
  • Mobility
  • Motor
  • Physical and Sensory Intersections
  • Speech
  • Attention
  • Language and Literacy
  • Learning
  • Memory
  • Executive
  • Mental Health
  • Cognitive and Sensory Intersections
Editor's note

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.

5.2.4 Conformance Levels

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.

Editor's note

This first draft focuses on bronze level. Future drafts will have more information on silver and gold levels. Bronze level will be similar to WCAG 2 AA, while silver and gold will include more usability-type testing. This is still under development. WCAG 2.X AAA success criteria are generally included in WCAG 3. The design of the scoring model awards more points for implementing the outcomes that come from WCAG 2.X AAA.

5.3 How Conformance Fits into the Information Architecture

5.4 Selecting a Representative Sample

6. Research and Input from Industry Leaders

The Silver Community Group partnered with academic and corporate researchers to address a list of specific questions related to improving accessibility standards. Details of the research questions, projects, and the results are on the Silver Research Archive wiki page.

6.1 Problem Statements

The Silver Research themes were organized into Problem Statements in three areas: Usability, Conformance, and Maintenance.

(quoted from Silver Research Problem Statements)

People generally liked the advice of WCAG, but commented about the content:

6.2 Silver Design Sprint Suggestions

The Problem Statements were presented to 27 industry leaders representing different stakeholder groups, including:

These industry leaders held a two-day, guided design sprint to recommend solutions which are summarized in the Design Sprint Report Suggestions section.

6.2.1 Usability

  1. Take existing WCAG 2.1 guidance and rewrite it in plain language, using editors with simple language or plain language experience. The existing success criteria may need to be updated, but most of WCAG 2.1 guidance is still valid. It needs more clarity, ease of reading, and ease of translation.
  2. Organize the data in small snippets that can be coded and categorized so they can be assembled dynamically to meet the needs of the person looking for information.
  3. Create a comprehensive view for W3C Technical Report purposes, and for those who need to view the total document.
  4. Create a solution that addresses the needs of people to find information by role, problem, by disability, and by platform. How can people discover what they need to know?
  5. Design a homepage that is oriented toward helping beginners and is separate from the W3C Technical Report. Include shortcuts for expert users who know what they want (for example, a code sample for an accessible tab panel)

6.2.2 Conformance

  1. Design a conformance structure and style guides that shift emphasis from “testability” to “measureability” so that guidance can be included that is not conducive to a true/false test. True/false tests can be included, but they are not the only way to measure conformance.
  2. Develop scorecard or rubric measures for testing task accomplishment, instead of technical page conformance.
  3. Develop a point and ranking system that will allow more nuanced measurement of the content or product: for example: bronze, silver, gold, and platinum ratings where the bronze rating represents the minimal conformance (roughly equivalent to meeting WCAG 2.1 AA), and increasing ranks include inclusive design principles, task-based assessment, and usability testing.
  4. Include a definition and concept for “substantially meets” so people are not excessively penalized for bugs that may not have a large impact on the experience of people with disabilities.
  5. Remove “accessibility supported” as an author responsibility and provide guidance to authoring tools, browsers, and assistive technology developers of the expected behaviors of their products.
  6. Develop a more flexible method of claiming conformance that is better suited to accommodate dynamic or more regularly updated content.

6.2.3 Maintenance

  1. Develop a core of rarely-changing requirements (normative) with modules of platform oriented advice, examples, tests, and support materials that can be updated as technology changes.
  2. Develop a method for accessibility experts to contribute new content, such as design patterns, codes and tests, where the experts vote material up and down without waiting for working group approval.
  3. Change the working group process to include Community Group participation.
  4. Improve access to specification development tools (for example, Github) so that people with disabilities can participate more easily in spec development, whether through new or modified tooling. There are existing efforts that can be incorporated and improved on.
  5. Develop specification content a small amount of guidance at a time, and fully develop the content before including it in the spec. Keep a public schedule when issues will be worked on, so the public can contribute in a timely manner.
  6. Keep a changelog of all changes to the spec so reviewers can easily find the changes.

A. References

A.1 Informative references

[508-criteria]
Section 508 Functional Performance Criteria. United States Access Board. 8 December 2011. URL: https://www.access-board.gov/ict/#chapter-3-functional-performance-criteria
[appmanifest]
Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Anssi Kostiainen; Matt Giuca; Aaron Gustafson. W3C. 25 August 2021. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
[ATAG20]
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/
[en-301-549]
Accessibility requirements suitable for public procurement of ICT products and services in Europe. European Telecommunications Standards Institute. February 2014. URL: https://www.etsi.org/deliver/etsi_tr/101500_101599/101550/01.01.01_60/tr_101550v010101p.pdf
[svg]
Scalable Vector Graphics (SVG) 1.0 Specification. Jon Ferraiolo. W3C. 4 September 2001. W3C Recommendation. URL: https://www.w3.org/TR/SVG/
[UAAG20]
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Note. URL: https://www.w3.org/TR/UAAG20/
[wai-aria]
Accessible Rich Internet Applications (WAI-ARIA) 1.0. James Craig; Michael Cooper et al. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria/
[WCAG22]
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/