Explainer for W3C Accessibility Guidelines (WCAG) 3.0

Draft Community Group Report

Latest editor's draft:
(Google, Inc.)
GitHub w3c/silver
File a bug
Commit history
Pull requests


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

Status of This Document

This specification was published by the Silver Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

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

If you wish to make comments regarding this document, please send them to public-silver@w3.org (subscribe, archives).

1. Introduction

W3C Accessibility Guidelines (WCAG) 3.0 is the next major version that will replace the Web Content Accessibility Guidelines (WCAG) 2.2. 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 finished, 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. WCAG 3.0 had a project name of "Silver", so the original groups working on it and much of the early design work carries that project name.

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

2.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:

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

2.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)

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

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

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 How Conformance Fits into the Information Architecture

We aren’t losing content, we are restructuring

5.2 Selecting a Representative Sample