Requirements for WCAG 3.0

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/silver/requirements/
Latest published version:
https://www.w3.org/TR/wcag-3.0-requirements/
Latest editor's draft:
https://w3c.github.io/silver/requirements/
History:
https://www.w3.org/standards/history/wcag-3.0-requirements/
Commit history
Editors:
(TetraLogical)
(Google, Inc.)
(W3C)
Feedback:
GitHub w3c/silver (pull requests, new issue, open issues)

Abstract

The Requirements for WCAG 3.0 document is the next phase in the development of the next major upgrade to accessibility guidelines that will be the successor to Web Content Accessibility Guidelines (WCAG) 2 series. The Silver Task Force of the Accessibility Guidelines Working Group and the W3C Silver Community group have partnered to incubate 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 these high-level requirements for the next phase of the project, the prototyping and public input.

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

The Requirements for WCAG 3.0 is published as a joint effort of the Silver Task Force of the Accessibility Guidelines Working Group and of the W3C Silver Community Group. It is a work in progress, and comments are welcome as Github Issues or by email.

This is the second phase of the Requirements developed during Q1 2019 after months of prototyping work. We anticipate one additional phase in Q3-Q4 2019 after months of evaluating how well actual content can be developed for WCAG 3.0.

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 12 June 2023 W3C Process Document.

1. Introduction

People with disabilities can face problems using online content and applications. Disabilities can be permanent, temporary, or recurring limitations.

We need guidance that:

The Web Content Accessibility Guidelines (WCAG) 2.0 were designed to be technology neutral, and has stayed relevant for over 10 years. The Authoring Tool Accessibility Guidelines (ATAG) 2.0 has been implemented in the open source authoring tool communities (chiefly Wordpress and Drupal) with little known uptake in commercial authoring tools. UAAG 2.0 offers useful guidance to user agent developers and has been implemented on an individual success criterion basis. There is no known user agent that has implemented all of UAAG 2.0.

1.1 Comparison to WCAG 2.x Requirements

WCAG 3.0 builds on the WCAG 2.0 Requirements of 2006. The WCAG 2.0 requirements are:

  1. Ensure that requirements may be applied across technologies
  2. Ensure that the conformance requirements are clear
  3. Design deliverables with ease of use in mind
  4. Write to a more diverse audience
  5. Clearly identify who benefits from accessible content
  6. Ensure that the revision is "backwards and forward compatible"

WCAG 3.0 wishes to advance the WCAG 2.0 Requirements of:

  1. applied across technologies
  2. clear conformance
  3. ease of use
  4. diverse audience
  5. identify who benefits

WCAG 3.0 does not want to advance the WCAG 2.0 requirement: "Ensure that the revision is 'backwards and forward compatible'" . The intention is to include WCAG 2.x content, but migrate it to a different structure and conformance model.

The WCAG 2.1 Requirements are very specific to WCAG 2.1 and will not be advanced by WCAG 3.0. WCAG 3.0 plans to migrate the content of WCAG 2.1 to WCAG 3.0, but the WCAG 2.1 Requirements document referred to structural requirements which are specific to WCAG 2.x.

The WCAG 2.1 Requirements are:

  1. Define a clear conformance model for WCAG 2.1/dot.x releases
  2. Ensure the conformance structure utilizes the WCAG 2.0 A / AA / AAA model

1.2 WCAG 3.0 Scope

WCAG 3.0 will have a broader scope than WCAG 2.0 and 2.1. The Web Content Accessibility Guidelines (WCAG) are scoped to Web and to Content. WCAG 3.0 is being designed to be able to include:

The current project design does not intend to write separate specifications or normative requirements for the technology stack beyond digital content. The goal is to provide information that technology venders can choose to use to improve the accessibility of their products to support the guidelines.

1.3 Silver Task Force Research

Editor's note

Introductory text about the research efforts undertaken, with pointers to methodology and results

The research done in 2017-2018 by the Silver Task Force, the Silver Community Group, and the research partners was used to identify the key problem statements related to the current accessibility guidelines (WCAG 2.x, ATAG 2.0 and UAAG 2.0). See the Silver Research Summary slides for more detailed information. These problem statements were used to identify the opportunities for WCAG 3.0 to address that will improve accessibility guidance.

During the year of WCAG 3.0 research, a recurring theme was the popularity and quality of the guidance in WCAG 2.0. Most of the opportunities identified in the research were improvements in the structure and presentation accessibility guidance to improve usability, to support more disability needs, and to improve maintenance.

1.4 Large and Dynamic Sites

In addition to the above research, an issue was raised about how to apply accessibility evaluation and conformance to large and dynamic web sites which are updated frequently. This led to development of Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them. Suggestions in that document are an additional source of input to these requirements.

1.5 Design Principles and Requirements

This document has two sections: a Design Principles section and a Requirements section. Requirements need to be measured or clearly demonstrated. They are used at the W3C phase of Candidate Recommendation, where the Candidate Recommendation Transition Request reports that the requirements were met. Design Principles are important statements that are less measurable, but are used to guide, shape and steer decision-making during the development process of WCAG 3.0. Both are essential in guiding the development of the WCAG 3.0 project.

2. Opportunities for WCAG 3.0

The Problem Statements describe areas identified during the WCAG 3.0 research in 2017-2018 that can be addressed in the new guidelines. Each problem statement also has an opportunity section that is the basis for the WCAG 3.0 Requirements.

2.1 Usability

2.2 Conformance Model

There are several areas for exploration in how conformance can work. These opportunities may or may not be incorporated. Then need to work together, and that interplay will be governed by the design principles

2.3 Maintenance

2.4 Issue Severity

Editor's note

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

  1. What to do with non-critical issues?
  2. How to deal with people having have different ideas on what is critical?
  3. How do we incorporate context/process/task? Is that part of scoping, or issue severity? Both are important to the end result.
  4. Can the matrix inform designation of functional categories? For example, the Text Alternative Available outcome.

The Issue Severity Subgroup:

  1. Demonstrated that it is possible to categorize tests by severity. See the critical severity worksheet for this information.
  2. Added examples of critical failures to the tests for Text Alternative Available and Translates Speech And Non-Speech Audio.
  3. Severity rating is best done at the test level. The higher the level the impact is assessed at, the less it aligns with the experience.
  4. It would be best to incorporate task/context for the best alignment. This does depend on scoping and how to define the task/process.
  5. It will be a lot of work to categorize each test with an impact level and the functional needs affected. It maybe best to focus on the critical issues. It would also be best to do the categorization as we go along, when creating tests.
  6. Severity rating could contribute towards scoring, but there are many other questions to do with scoring.
  7. Severity rating could also contribute towards prioritization, which could replace A/AA/AAA (at the test level)
Note

Proposed updates

  • For the process of creating this: focus on critical issues. Don't try to rate high / medium / low.
  • Use the critical severity matrix to categorize tests. (At least set up that process to define each test by functional need and impact).
  • We could use Critical / High for a level of conformance. For example:
    • "Bronze" could be an absence of any critical or high issues;
    • "Silver" could be an absence of any critical, high, or medium issues.
  • We could use the severity scales as input to a post-testing process where you prioritize issues based on your context and tasks.

3. Design Principles

The WCAG 3.0 Design Principles are based on the requirements of WCAG 2.0 and build on those requirements to meet needs identified in the WCAG 3.0 research.

Accessibility guidelines should:

  1. Support the needs of a wide range of people with disabilities and recognize that people have individual and multiple needs.
  2. Support a measurement and conformance structure that includes guidance for a broad range of disabilities. This includes particular attention to the needs of low vision and cognitive accessibility, whose needs don't tend to fit the true/false statement success criteria of WCAG 2.x.
  3. Be flexible enough to support the needs of people with disabilities and keep up with emerging technologies. The information structure allows guidance to be added or removed.
  4. Be accessible and conform to the Guidelines. Note: This design principle will move to the Requirements section once the Conformance section is completed and we determine a specific measurement of compliance.
  5. Be written in plain language, as easy as possible to understand. We need a definition of plain language that includes the ease of translation. Ideally, it will be a broadly accepted definition internationally.
  6. Improve the ability to support automated testing where appropriate and provide a procedure for repeatable tests when manual testing is appropriate.
  7. Provide requirements to address functional needs, while avoiding or minimizing negative impacts on other functional needs.

The creation process for the guidelines should:

  1. Actively recruit a diverse range of people with disabilities in recognition of the importance of their contributions to accessibility standards and solutions. Review and monitor whether people are included. Continually evaluate inclusive features of available tooling and procedures.
  2. Facilitate global participation and feedback.
  3. Be data-informed and evidence-based where possible. We recognize that research and evidence are influenced by the number of people with a particular disability, by the size of the body of research, and by the difficulty in capturing data regarding some disabilities or combination of disabilities. The intent is to make informed decisions wherever possible to ensure that the needs of all people with disabilities are prioritized, including needs that differ from the majority. In situations where there is no evidence or research, valid data-gathering methods should be used to obtain and evaluate information from advocacy groups, people with lived experience and other subject matter experts.
  4. Be written so the Guideline content is usable in adaptable and customizable ways. For example, WCAG 3.0 content is available to be extracted by users to adapt to their needs.

4. Requirements

Previous W3C Accessibility Guidelines described how to make web pages accessible to people with disabilities. These guidelines provided a flexible framework that has kept the guidelines relevant for 10 years. Changing technology and changing needs of people with disabilities has shown areas where they could be improved. The requirements are drawn from the research performed by WCAG 3.0 to improve the guidelines, and the suggestions from the Silver Design Sprint.

The WCAG 3.0 Requirements are high level and will be expanded and refined as Silver members move through the prototyping process.

4.1 Broad disability support

Silver guidance includes tests and other evaluation methods. Some guidance may use true/false verification but other guidance will use other ways of measuring and/or evaluating where appropriate so that more needs of people with disabilities may be included (for example: rubrics, sliding scale, task-completion, user research with people with disabilities, and more). This approach includes particular attention to people whose needs may better be met with a broad testing strategy, such as people with low vision, limited vision, or cognitive and learning disabilities.

4.2 Flexible maintenance and extensibility

Create a maintenance and extensibility model for guidelines that can better meet the needs of people with disabilities using emerging technologies and interactions. The process of developing the guidance includes experts in the technology.

4.3 Multiple ways to display

Make the guidelines available in different accessible and usable ways or formats so the guidance can be customized by and for different audiences.

4.4 Technology Neutral

Guidance should be expressed in generic terms so that they may apply to more than one platform or technology. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist.

4.5 Readability

The core guidelines are understandable by a non-technical audience. Text and presentation are usable and understandable through the use of plain language, structure, and design. They link to instruction videos, illustrations, and how-to where available. Creation of new videos and illustrations are outside the scope of this project at this time.

4.6 Regulatory Environment

The Guidelines provide broad support, including

4.7 Motivation

The Guidelines motivate organizations to go beyond minimal accessibility requirements by providing a scoring system that rewards organizations which demonstrate a greater effort to improve accessibility.

4.8 Scope

The guidelines provide guidance for people and organizations that produce digital assets and technology of varying size and complexity. This includes large, dynamic, and complex websites. Our intent is to provide guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more.

A. Change Log

A.1 Changes Prior to First Public Working Draft

A.1.1 Changes Prior to Second Version of Requirements

  • New requirements for Readability, Regulatory Environment, Motivation, and Scope.
  • Added paragraph explaining the differences between Design Principles and Requirements as a result of requests from the AGWG face-to-face meeting of 11 and 12 March 2019.
  • Added new Design Principles and Requirements and changed wording of existing Design Principles and Requirements based on feedback from AGWG in Q1 and Q2 2019
  • Added a new Scope section to the Introduction that clarifies that WCAG 3.0 plans to address Authoring Tools, User agents and Apps. (26 April 2019)
  • Reworded Technology Neutral to bring it more in line with the original WCAG 2.0 Requirements wording. (26 April 2019)
  • changed Design Principle 9 to more clearly show that there will not be a hierarchy of disabilities and that when there is no research, how we will address that.

B. Acknowledgements

B.1 Participants of the Silver Task Force and Silver Community Group who contributed to the 2021 and 2020 versions of this document

B.2 Participants of the Accessibility Guidelines Working Group who reviewed the 2021 and 2020 versions of this document

B.3 Research Partners

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

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