This document outlines the requirements that the Web Content Accessibility Guidelines Working Group (WCAG WG) has set for the development of Web Content Accessibility Guidelines (WCAG) 2.2. These requirements build on the existing requirements for WCAG 2.0, and are designed to work in harmony with the WCAG 2.0 and WCAG 2.1 standards.

Introduction

Web Content Accessibility Guidelines 2.0 (WCAG 2.0) [[WCAG20]] explains how to make Web content accessible to people with disabilities. Since the release of WCAG 2.0 in December 2008 and the release of WCAG 2.1 in June 2018, these standards have been widely adopted and implemented. As a result of feedback from implementers, ongoing changes in technologies, and responding to the need for regular updates in accessibility content standards, the Accessibility Guidelines Working Group (AGWG) is pursuing the development of WCAG 2.2.

The underlying goal of WCAG 2.2 requirements are the same as for WCAG 2.0 and WCAG 2.1 – to promote accessibility of Web content. WCAG 2.2 must satisfy additional requirements addressed in this document including:

The Requirements for WCAG 2.0 [[wcag2-req]] provides details used during the development of WCAG 2.0, including key goals related to technology independence, clearly defined conformance requirements, and more which are still relevant and important. As with WCAG 2.0, work on each specifications in the same line (WCAG 2.x) will provide techniques and supporting documentation to assist in implementation efforts, and any criteria modified or introduced by a WCAG 2.x release will need to be verifiable by implementers.

WCAG 2.x specifications are expected to offer modifications to existing success criteria as well as offer additional guidelines and success criteria but WCAG 2.x requirements may not weaken what is required generally of web content to be considered conformant to either. The result of this is that when a page conforms to WCAG 2.x it will also conform to to the previous versions.

In any WCAG 2.x specification - an existing success criteria may change in priority from a lower level to a higher level, but not the other way around. Criteria can be changed or removed so long as accessibility issues caught by the original success criteria remain issues in the updated guidelines.

For example:

Group members working on different success criteria should maintain good communication about work in progress with the main Working Group and across Task Forces to minimize conflicts/duplication of work wherever possible.

WCAG 2.2 Requirements

WCAG 2.2 success criteria continue support for additional use-cases from WCAG 2.1

WCAG 2.2 will build on WCAG 2.1 and provide additional criteria to address the accessibility of content for use-cases that were a focus of WCAG 2.1. Improvements in support for users of small or touch-screen devices, as well as for low-vision users and users with cognitive, language, and learning impairments.

Utilize the WCAG 2.0 conformance model.

The WCAG 2.0 Requirements document provides details about conformance that needs to be met for WCAG 2.x releases. However WCAG 2.x releases need to provide conformance details that indicate the conformance relationship between them, and existing WCAG 2.0 conformance. WCAG 2.2 must specify that conformance claims indicate that a page conforms to WCAG 2.1 as a base. Future WCAG 2.x specifications must conform to its immediate previous ancestor specification as a base.

Utilize the WCAG 2.0 A/AA/AAA model.

WCAG 2.2 will utilize the WCAG 2.0 A/AA/AAA structure. Additional or changed success criteria will specify at what Level those criteria are provided. When a page conforms to WCAG 2.2 at a specific level, that page must conform to WCAG 2.0 and WCAG 2.1 at the same level or higher.

It is important to note that changes in WCAG 2.2 to the level for any existing WCAG 2.x success criteria need to be made with awareness of the implementability and testability requirements for the new level. For WCAG 2.x releases to ensure backwards compatibility level changes must be clear for the immediate previous ancestor specification as a base.

For example, a success criterion may currently be at Level AAA as a result of very limited testability, and moving that success criteria to Level AA in WCAG 2.2 or a WCAG 2.x would require greater testability. In order to successfully make this transition there must be evidence that testability is more robust.

Example

Some new success criteria and guidelines in WCAG 2.2 are created that effectively make some changes (strengthen) previous WCAG 2.0 conformance requirements, and a page that conformed to WCAG 2.0 is tested against WCAG 2.2:

A web page that previously conforms to WCAG 2.0 AA is reviewed against the new WCAG 2.2 specification. In the review, it is determined that the page still meets 1.4.3, which is now a level A criterion, and the page also meets 5.1 (level A), but it does not meet the new 5.2 (level AA).

As a result, the page could claim to conform to the new WCAG 2.2 success criterion for 1.4.3 Color Contrast [minimum] at level A, and the new 5.1 success criterion (level A), but not the new 5.2 (level AA).

NOTE:The author may choose to change their claim or not, as it will be possible to conform to WCAG 2.2 success criteria without making an explicit conformance claim.

Note that most of these terms are further discussed in the Requirements for WCAG 2.0 [[wcag2-req]]

Success Criterion Acceptance Criteria

These requirements are provided as guidance to the WCAG Working Group as it works to define new Success Criteria in WCAG 2.2. The Working Group will use the WCAG 2.2 working process to prioritize mature proposals review and ensure completeness before acceptance.

Success Criterion Characteristics

Success criteria should:

  1. Address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criterion is not met.
  2. Be testable through an automated process or by a manual process conducted by an individual evaluator, and any tools required to test it are available prior to Candidate Recommendation stage.
  3. Provide consistent results from different testers (e.g. 8/10 testers agree). This can be assessed through inherent logic or proven through examples.
  4. Describe the specific condition required to meet the criterion, not the method to address the criterion.
  5. Utilize the WCAG 2.x A/AA/AAA level structure.
  6. Apply to all content across all websites unless preconditions for the application of the success criteria are explicitly identified (e.g. "except interruptions involving an emergency").
  7. Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)
  8. Avoid creating a requirement for something that is already required by an existing Success Criterion.

Success Criteria Considerations

When crafting success criteria:

  1. Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
  2. Not require testing that is believed to require very large manual efforts. If a tool is very likely to be available soon after publication that makes the testing more efficient, this factor is less important.
  3. Use glossary definitions to simplify and shorten all Success Criteria for shared or ambiguous terms.

Research

The creation process for success criteria should be data-informed and evidence-based where possible. 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 to ensure that all identified needs of people with disabilities are addressed wherever possible. This includes the needs specific to small groups of users. In situations where there is limited or 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.

Acceptance into Editor's Draft

A New Success Criterion can be added to the Editor's Draft when the following are met and approved by the Working Group:

  1. The Success Criterion requirements above are met.
  2. Success Techniques are completed and approved which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.
  3. An Understanding document is completed and approved for the Success Criterion.
  4. Language for the Success Criterion to be included in an update to WCAG2ICT is completed and approved.
  5. Two independent implementations on web pages that actively meet the Success Criterion are available.

Change Log

Substantive changes since the last public working draft

Other substantive changes since the First Public Working Draft