WCAG 2.2 Success criterion acceptance requirements: Difference between revisions

From WCAG WG
(Updates from discussion with Lisa.)
(6 intermediate revisions by 2 users not shown)
Line 7: Line 7:
Success Criteria shall:
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.
# 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 feasibly testable through automated or manual processes, i.e. take a few minutes per page with tools available prior to Candidate Recommendation stage.
# 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.
# Provide consistent results from different testers. This can be assessed through inherent logic or proven through examples.
# Provide consistent results from different testers (e.g. 8/10 testers agree). This can be assessed through inherent logic or proven through examples.
# Describe the specific condition required to meet the criteria, not the method to address the criteria.
# 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.
# Utilize the WCAG 2.0 A/AA/AAA level structure.
Line 17: Line 17:
Success Criteria should:
Success Criteria should:
# Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
# Be as broad as possible, but specific enough not to become a 'catch-all' for any given requirement.
# 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.
# Use glossary definitions to simplify and shorten all Success Criteria for shared or ambiguous terms.
# Use glossary definitions to simplify and shorten all Success Criteria for shared or ambiguous terms.


Line 62: Line 63:
* whether there are no workarounds if the Success Criterion is not met
* whether there are no workarounds if the Success Criterion is not met


=== Further Discussion ===
There is further discussion of this in the [[WCAG 2.x Priority levels discussion]] page.
 
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 [[Talk:WCAG_2.1_Success_Criteria|discussion tab associated with the 2.1 version of 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).

Revision as of 10:27, 7 May 2019


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 criteria 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.0 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.