WCAG 2.2 Success criterion acceptance requirements


Success Criterion Requirements

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

Success Criteria shall:

  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 criteria, not the method to address the criteria.
  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 should:

  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.

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.

Template for new Success Criteria

Each proposed SC is provided in a document (HTML, Doc or other) with the following structure:

  1. The proposed SC text.
  2. A plain English summary of the SC, similar to the 'intent' from the Understanding documents, including what users benefit from the content successfully addressing it (examples are helpful, but not required).
  3. Suggestion for Priority Level (A/AA/AAA).
  4. What Principle and Guideline it falls within (or suggestion for new guideline).
  5. 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).
  6. Description of how this SC can be tested (like the procedure from a technique).
  7. A technique description for how the SC can be fulfilled.
  8. An example (or link to an example) of content that passes the criteria in order to assess the criteria. (Not to be part of the final document.)
  9. Indication of any suggested glossary definitions.

Success Criteria Best Practice Guidelines

The Working Group is striving for WCAG 2.2 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.

  1. 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.
  2. 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

There is further discussion of this in the WCAG 2.x Priority levels discussion page.