This Explainer accompanies the drafts of the W3C Accessibility Guidelines (WCAG) 3.0.
This is an updated draft of the WCAG 3.0 Explainer. It is informative, not normative, and is not expected to become a W3C Recommendation. It provides background on [[[WCAG3]]].
W3C Accessibility Guidelines (WCAG) 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [[WCAG22]] and previous versions. It does not deprecate WCAG 2. It may incorporate some content from User Agent Accessibility Guidelines 2.0 [[UAAG20]] and Authoring Tool Accessibility Guidelines 2.0 [[ATAG20]] where it assists authors in meeting guidelines. These versions provided a model that kept them relevant for over 10 years. Changing technology and changing needs of people with disabilities require a new model to address content accessibility more comprehensively.
This Explainer includes:
The goal of WCAG is to provide information that can be used to improve the accessibility of products on a variety of platforms. WCAG 3 will use a model that allows it to:
Additional goals for WCAG 3.0 are written in Requirements for WCAG 3. These are based on the Silver research, the results from the Silver Design Sprint, and input from the Accessibility Guidelines Working Group, the Silver Task Force, and the Silver Community Group.
The creation process for the WCAG 3.0 guidelines should:
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.
Several items are out of scope for WCAG 3.0:
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. The Silver Task Force of the Accessibility Guidelines Working Group (AG) and the W3C Silver Community group partnered to produce the needs, requirements, and structure for the new accessibility guidance. They worked on Silver from 2017-2023. During that time they:
The AG uses an iterative approach to creating WCAG 3.0. Each piece of content will evolve over time, increasing in maturity. As a result, the document is a work-in-progress.
Because different parts of the document have different maturity levels, each normative section includes a status that indicates:
The status indicators, from least to most mature, are:
The working group aims to publish two new drafts each year. Each draft will include targeted questions for the public to consider and respond to in order to advance the working draft. 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.
WCAG 3.0 includes both normative and informative guidance. This guidance is organized into:
Details on each are below.
By default, guidelines are organized by what is tested. WCAG 3.0 will provide a version, similar to the existing QuickRef, that incorporates tags to allow readers to reorganize and filter the content. For example, content will be tagged Perceivable, Operable, Understandable, and Robust so that readers can view WCAG 3.0 criteria in the same structure as WCAG 2.
Guidelines are written as plain language, user-centered outcomes statements.
Guidelines include high-level, plain-language information for managers, policy makers, individuals who are new to accessibility, and other individuals who need to understand the concepts but not the technical details. They provide an easy-to-understand way of organizing and presenting the outcomes so that anyone can learn about and understand the concepts.
Guidelines are normative.
Guidelines are technology-agnostic and address functional needs on specific topics, such as contrast, forms, readability, and more. Foundational requirements, supplemental requirements, and assertions that relate to a Guideline are listed together to encourage adoption of higher levels of accessibility.
Each Guideline contains multiple Requirements:
Requirements reduce or eliminate barriers that people with disabilities experience. Requirements are designed for use by developers, testers, and other technical specialists.
Requirements are normative.
Each Requirement is associated with at least one Method. Methods are informative. Each method contains techniques for meeting the requirements, examples, resources, and sets of tests. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology. For example, the methods supporting the Clear Language guideline.
The AG has discussed also including "Recommendations" at the same level as Supplemental Requirements. Recommendations would be things which could help improve accessibility but may not be objectively testable. They could contribute to levels of conformance above Foundational.
An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3.0, an Assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.
Assertions may supplement Requirements to meet a Guideline. Not all Guidelines include Assertions. Guidelines that include Assertions, list the Assertions with the Requirements. Organizations can make an assertion that they followed a procedure as part of a conformance claim. Assertions can be made in addition to foundational requirements but do not replace foundational requirements.
The working group will consider whether assertions may be used to meet guidelines when requirements are not available.
An alternative to specifying assertions at the requirement or guideline level might be to require that the assertion apply to the scope of the conformance claim.
Procedures used in assertions may be implemented at the organization level, during design and development, or during testing.
Examples of procedures that may be used during implementation might include:
Examples of procedures that may be used to evaluate accessibility might include:
WCAG recommends maintaining additional information that an organization can use to improve or validate procedures and assertions. WCAG will not require organizations to provide supporting documentation to conform.
Assertions must be documented as part of the conformance claim process. The required information may also be made available through the web site.
Assertions might include the following information:
Within the current draft, Foundational Requirements are organized as a decision tree under the relevant Guidelines. Supplemental Requirements and Assertions are then listed below the tree. AG hopes this will assist readers in determining which Requirements and Assertions to use. The AG requests feedback on three early draft examples of this approach: Focus Appearance, Implied Meaning, and Text Alternatives.
AG will continue developing requirements and methods. Each publication will include additional examples, and/or more mature examples for public comment.
AG's next steps include:
AG will also continue to explore the use of assertions and welcomes feedback on the following questions:
WCAG 3.0 includes two types of tests which are evaluated:
Most tests have prescribed ways to meet the test. In some cases, the ways to meet the test will change based on a specific condition being met. For example, different human languages have different readability metrics.
Tests may be objective or subjective. For example, from WCAG 2:
Both these tests are objectively verifiable. They are not subject to variation of results between different testers.
Alternatively, again from WCAG 2:
These tests include a subjective determination of whether they are adequately met.
Testing uses items, views, task flow, and the product to define the scope of what is being tested.
Items are the smallest testable unit. They could be interactive components such as a drop down menu, a link, or a media player. They could also be units of content such as a phrase, a paragraph, a label or error message, an icon, or an image.
Views include all content visually and programmatically available without a significant change. Conceptually, views correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, a view could be considered a “screen” in a mobile app or a layer of web content, such as a modal dialog.
Task flows are a series views that support a specified user activity. A task flow may include a subset of items in a view or a group of views. Only the part of the views that support the user activity are included in a test of the task flow.
Examples of a task flow include:
The product is the combination of all items, views, and task flows that comprise the web site, set of web pages, web app, etc.
Some tests only apply in certain situations. Testing may occasionally require determining and referencing which specifications are being tested. Methods will note whether a test always applies or under what conditions a test applies. Both quantifiable and qualitative tests can be conditional.
Example conditions include:
The quality of an assertion can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.
WCAG 3.0 will use a different conformance model than WCAG 2.2 in order to meet its requirements. Developing and vetting the conformance model is a large portion of the work AG needs to complete over the next few years. Drafts will include maturity models for public review and comment.
AG is exploring a model based on Foundational Requirements, Supplemental Requirements, and Assertions.
The most basic level of conformance will require meeting all of the Foundational Requirements. This set will be somewhat comparable to WCAG 2.2 Level AA.
Higher levels of conformance will be defined and met using Supplemental Requirements and Assertions. AG will be exploring whether meeting the higher levels would work best based on points, percentages, or predefined sets of provisions (modules).
Key concepts AG has and previously considered and continues to explore the following:
The concept of "accessibility-supported" is to account for the variety of user-agents and scenarios. How does an author know that a particular technique for meeting a guideline will work in practice with user-agents that are used by real people?
The intent is for the responsibility of testing with user-agents to vary depending on the level of conformance.
At the foundational level of conformance assumptions can be made by authors that methods and techniques provided by WCAG 3 work. At higher levels of conformance the author may need to test that a technique works, or check that available user-agents meet the requirement, or a combination of both.
This approach means the working group will ensure that methods and techniques included do have reasonably wide and international support from user-agents, and there are sufficient techniques to meet each outcome.
The intent is that WCAG 3 will use a content-management-system to support tagging of methods/techniques with support information. There should also be a process where interested parties can provide information.
An "accessibility support set" is used at higher levels of conformance to define which user-agents and assistive technologies you test with. It would be included in a conformance claim, and enables authors to use techniques that are not provided with WCAG 3.
An exception for long-present bugs in assistive technology is still under discussion.
AG is currently chartered through November 2025. The schedule through that time period is maintained at WCAG 3.0 Timeline.
AG will continue to iterate within a single normative document with informative supporting documentation. After exploring other options such as breaking the content into modules, the group determined that the fastest way forward at this time is to continue creating a single document with varying levels of maturity. We will revisit whether mature content can be published as informative modules as part of the next charter period, when content is more mature.
A final schedule will be delivered as part of this charter period. WCAG 3.0 will not be published until it covers at least as much as WCAG 2.2.
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.
Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of people with disabilities.
Any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).
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.
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.
Equity is the outcome of processes and actions that ensure the spectrum of human reality obtains what is needed to participate, not solely access. As equity relates to WCAG it is about the impact the standards/guidelines have on people with disabilities, along with actually including people with disabilities in the work.
A statement that describes a specific gap in one’s ability, or a specific mismatch between ability and the designed environment or context.
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.
Detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.
Content whose instructions are required for conformance.
A sequence of steps that need to be completed to accomplish an activity / task from end-to-end.
The reproducibility and consistency of scores i.e. the extent to which they are the same when evaluations of the same resources are carried out in different contexts (different tools, different people, different goals, different time). This would be particularly useful to ensure that similar results are achieved by different testers. It would also be useful to see if different testers would select the same path or off-path decisions. Representative sampling tests also fit in this category. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.
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.
Any software that retrieves, renders and facilitates end user interaction with web content (e.g. web browsers, browser plug-ins, media players).
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.
Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page.