WCAG 2.1 Success Criteria

Success Criteria Requirements

These requirements are provided as guidance to the WCAG Working Group as it works to define new Success Criteria in WCAG 2.1. The guidance here may be changed by the working group if necessary.

Success Criteria shall:

Address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criteria is not met.
Be testable through automated or manual processes.
Describe the specific condition required to meet the criteria, not the method to address the criteria.
Utilize the WCAG 2.0 A/AA/AAA level structure.
Ensure for revised Success Criteria that pages that meet the revised guidance continue to meet the corresponding WCAG 2.0 Success Criteria.
Apply to all content unless preconditions for the application of the success criteria are explicitly identified (e.g. "except interruptions involving an emergency").
Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)
Avoid creating a requirement for something that is already required by an existing Success Criterion.
Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.

Success Criteria should:

Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
Use glossary definitions to simplify and shorten all Success Criteria for shared or ambiguous terms.

Checklist for proposals for new Success Criteria or to change existing Success Criteria

Each proposed SC is provided on its own page, and that page (location of the page TBD, likely on GitHub) contains:

The SC text.
- If suggesting a wording change to an existing success criteria, write the complete SC text and then follow that with a version which indicates the changes by surrounding new text with "@@". For example (just an example), "1.4.3 Contrast (Minimum): The visual presentation of @@text, images of text, and icons@@ has a contrast ratio of at least 4.5:1, except for the following: (Level AA)".
Suggestion for Priority Level (A/AA/AAA).
Indication of any suggested glossary definitions or changes.
What Principle and Guideline it falls within (or suggestion for new guideline)
A description of what the intent of the SC is, including what users benefit from the content successfully addressing it (examples are helpful, but not required).
Clear information about how the proposal will benefit users, along with justification and evidence of the benefits (this may be a link to a separate resource).
Description of how this SC can be tested.
Possible technique titles which could be used to satisfy the SC (just the title).

Success Criteria Best Practice Guidelines

The Working Group is striving for WCAG 2.1 to be as clear as possible, and has established the following as Best Practice Guidance. For groups submitting Success Criteria proposals, these are guidelines and are not intended to be absolute. For example, a SC proposal may be written using notes or lists if the proposal is deemed clearer as a result, however, the Working Group may restructure the content upon further review for clarity.

Ensure that the criteria is written as simply as possible without loss of clarity or testability. SC are better when they:
1. Are concise and clear
2. Minimize the use of lists to where they make the success criteria easier to follow. When lists are necessary numbered lists are preferred to more easily allow referencing specific items
3. Avoid the use of "notes" to make the criteria clear (Notes are regarded as Normative in WCAG 2.0 and 2.1)
4. Avoid jargon and unnecessarily complex language.
The SC can be summarized into a simple language sentence that describes its theme

Initial Suggestion for Priority Level

From Understanding Levels of Conformance:

The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included:

whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can’t make content accessible)
whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)
whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week’s training or less)
whether the Success Criterion would impose limits on the “look & feel” and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors)
whether there are no workarounds if the Success Criterion is not met

Further Discussion

Archetypical examples of ‘essential’ in WCAG 2.0 are: 1.1.1 Non-text Content, 1.2.2 Captions (Prerecorded), and 2.1.1 Keyboard. There is considerable overlap between ‘essential’ (first bullet) and ‘no workarounds’ (fifth and last bullet). The workarounds (e.g., file name, automatic captions, mouse keys) are very inadequate.

Four SC are ‘blocking’, which is to say they are reference by Conformance Requirement 5 for Non-Interference: 1.4.2 - Audio Control, 2.1.2 - No Keyboard Trap, 2.3.1 - Three Flashes or Below Threshold, and 2.2.2 - Pause, Stop, Hide. These SC are all at Level A.

The ‘all content’ consideration is the major discriminating factor for AAA. All A and AA SC are applicable to all Web sites and types of content. It is only AAA SC that might not satisfy the ‘all content’ consideration.

The consideration for difficulty described in the third bullet (from Understanding, above) can be paraphrased as the SC being ‘easy’ to do. There are not any SC that require 40 hours of training, so there is a bit of hyperbole in that line of Understanding. Some SC are not technically challenging, but are labor intensive. An example is 1.2.8 Media Alternative (Prerecorded) which is Level AAA.

The ‘look and feel’ factor described in the fourth bullet (from Understanding, above) can be paraphrased as the SC being ‘invisible’ — since the SC may be satisfied with no visual effect or with only trivial impact to the default presentation.

The factors of being ‘easy’ and ‘invisible’ are often used together and then characterized as the SC only requiring a ‘light touch’.

As levels were assigned, there was agreement that Level A SC should only require a ‘light touch’. The ‘blocking’ SC are exceptions to this ideal. There are also SC that are important enough that they are Level A, even though they are neither ‘easy’ nor ‘invisible’. An example of ‘essential’ outweighing the expectation that Level A SC only require only a ‘light touch’ is 1.2.2 Captions (Prerecorded).

Observations

Please see the table in the Discussion tab associated with this page for the rational behind these observations.

In general, WCAG 2.0 Level A SC are: either [essential and (easy or invisible)] or [both easy and invisible]. 21 of 25 Level A SC are characterized this way.

There are four Level A SC that are exceptions to the above general rule for Level A. They are: 1.2.1 Audio-only and Video-only (Prerecorded), 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative (Prerecorded), and 2.4.1 Bypass Blocks.

2.4.1 Bypass Block is an outlier because it is the only WCAG 2.0 Level A SC that is not essential and not [both easy and invisible].

In general, WCAG 2.0 Level AA SC are not essential. Only 2 of 13 are essential, namely 1.2.4 Captions (Live), and 1.2.5 Audio Description (Prerecorded).

In general, WCAG 2.0 Level AAA SC are not possible for all content. 21 of 24 Level AAA SC are characterized this way.

There are three Level AAA SC that are exceptions to the above general rule for Level AAA. They are: 1.2.8 Media Alternative, 1.4.6 Contrast (Enhanced), and 3.3.6 Error Prevention (All).