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.
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:
Researched accessibility guidance needs
Developed problem statements and opportunities to improve accessibility guidance
Received input from industry leaders for directions to proceed
Drafted requirements for the project (they will be reviewed after public feedback from the First Public Working Draft)
Created and tested prototypes for aspects of the project
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.
People generally liked the advice of WCAG, but commented about the content:
Usability
Too difficult to read and translate.
Difficult to get started for beginners.
Ambiguity in interpreting the success criteria. Different accessibility experts will interpret the guidelines differently.
Persuading others to follow WCAG is difficult mostly because of the perception that Accessibility is something added at the end of the development process and is costly.
Conformance Model
Constraints in the Conformance to “What is Strictly Testable” provides an obstacle to including guidance that meets the needs of people with disabilities, but is not conducive to a pass/fail test.
Human Testable (related to Ambiguity) also relates to differences in knowledge and priorities of different testers achieve different results.
Accessibility Supported is a conformance requirement of WCAG 2 that is poorly understood and incompletely implemented
Evolving Technology of the rapidly changing web must be evaluated constantly against the capabilities of assistive technology, and evolving assistive technology must be evaluated against the backward compatibility of existing web sites.
Maintenance
Flexibility to provide more easily discovered, more helpful information that can be updated as technology advances.
Scaling the accessibility guidance so it can be updated to include new and changing technology
Governance of the accessibility standards has not kept pace with changing processes of standard development.
2.2 Silver Design Sprint Suggestions
The Problem Statements were presented to 27 industry leaders representing different stakeholder groups, including:
Accessibility influencers
Information architects
UX professionals
Developers (for example: Web Content, Document, Authoring Tool, User Agent, Assistive Technology)
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.
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.
Create a comprehensive view for W3C Technical Report purposes, and for those who need to view the total document.
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?
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
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.
Develop scorecard or rubric measures for testing task accomplishment, instead of technical page conformance.
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.
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.
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.
Develop a more flexible method of claiming conformance that is better suited to accommodate dynamic or more regularly updated content.
2.2.3 Maintenance
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.
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.
Change the working group process to include Community Group participation.
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.
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.
Keep a changelog of all changes to the spec so reviewers can easily find the changes.
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.
Facilitate global participation and feedback.
3.2 Goals for Content
Support the needs of a wide range of people with disabilities and recognize that people have individual and multiple needs.
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.
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.
Improve the ability to support automated testing where appropriate and provide a procedure for repeatable tests when manual testing is appropriate.
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.
Be written so the Guideline content is usable in adaptable and customizable ways. For example, Silver content is available to be extracted by users to adapt to their needs.
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.
Better align conformance with the experiences of people with disabilities, and keep in mind that people with different disabilities have different experiences.
Treat the needs of all disabilities equitably.
Support a measurement and conformance structure that includes guidance for a broad range of disabilities. This includes more attention to the needs of low vision and cognitive accessibility, whose needs may not fit the true/false statement success criteria of WCAG 2.x.
Consider the needs of more organizations
Be user-oriented instead of page-oriented. Think about what is the person trying to do.
Wherever possible, preserve the organization’s investment in training, tooling, and knowledge.
Support the ability for organizations to choose parts of their site or product for conformance (a logical subset of a site or product).
Create a more flexible conformance model that addresses the challenges in applying the 2.x conformance model to large, complex, or dynamic websites and web applications.
Help organizations prioritize things that have a greater impact on improving the experience of people with disability.
Develop a more flexible method of measuring conformance that is better suited to accommodate dynamic or more regularly updated content.
Remove “accessibility supported” as an author responsibility, and help developers of authoring tools, browsers, and assistive technologies learn the behaviors that users expect of their products.
Improve tests so that repeated tests get more consistent results.
Increase the ability to create more automated tests.
4. Non-Goals or Out-of-Scope
Non-web emerging technologies (this may change as the charter is clarified)
Normative requirements for platforms, operating systems, software in the web technology stack (etc.)
We want to point to external accessibility guidance by the vendor
We want to document the needs of people with disabilities where vendor accessibility guidance is lacking
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
Guidelines are general information and intent written in plain language.
Methods are specific examples, instructions, and tests with more technical information.
We will add a tagging engine to make it easier for people to find information by tags.
We want organizations to be able to use an API to copy the guideline data to use for their own purposes.
Guidelines will include:
updated WCAG 2.1 guidance (technology-specific success criteria will become Methods)
new guidance written for WCAG 3.0
new guidance for task completion testing
Methods are associated with Guidelines. In general, Methods are technology specific.
Methods include tests for each Method.
Each Guideline will have multiple Methods with existing WCAG Technique guidance or new Methods written for WCAG 3.0.
Methods can include tests for determining the percentage points to apply to the conformance score. See the Points and Levels section following for details.
Methods can provide guidance for:
User agents
Authoring tools
Assistive technology
Emerging technologies
5.2 Selecting a Representative Sample
Essential functions vary by industry -- gaming will be different than e-commerce. We can't say what has to be tested, the organization needs to determine what is essential.
The organization (or author) defines the workflows and components, then prioritizes the primary workflows and components to test. See WCAG-EM Steps 2 and 3 to help determine what workflows and components are representative samples.
The ability to get to the workflow, (like login) also must be accessible.
There are going to be technical violations of success criteria that don’t impact accessibility (for example, missing alt text that are explained in the text or the same HTML id attribute that aren’t ever referenced) that shouldn’t negatively impact the score. NOTE: There will be further development and amplification of what shouldn’t negatively impact the score. The concept of pass or fail should no longer be binary, but accounts for a concept of sufficient
People still need to have access to material that still isn’t in the primary flow. Accessibility can be tested even if it doesn’t have a flow. NOTE: There needs to be a way that important sections, like navigation and footer, don’t get overlooked because they aren’t part of the flow.