Overview of the issues with different conformance schemes

The purpose of this page is to capture recent discussion about whether there should be 2 or 3 levels of conformance in WCAG 2.0.

Summary of Issue

WCAG 1.0 had 3 conformance levels and WCAG 2.0 also started out with 3. In WCAG 2.0 however the definition of what the 3 levels meant has changed. (See "WCAG 1.0 and 2.0 levels" below) The content of the guidelines has also changed with additional "things to do if you really want to make an accessible site" added to Level 3. Also Level 3 has items that could not be applied to all sites with all technologies. This change led some to suggest that level 3 be removed.

Others suggested that the guidelines just be simplified by taking the items in the three levels and redistributing them into 2 levels etc.

At a recent face-to-face meeting seven variations were proposed. All essentially proposing either 2 or 3 levels and distributing the current guidelines in different ways or labeling the groups differently.

Thus, the question is actually a combination of three questions:

• should there be two levels or three levels?
• if two levels – how should items be redistributed between the two remaining levels? (and perhaps the guide doc)
• should all of the items in level 3 be removed from the guidelines?

Note: Independent of the 2 levels or 3 levels discussion, the group is continually evaluating all of the success criteria at all of the levels The question here is not about individual Success Criteria, but the restructuring of the guidelines and the treatment of the L3 success criteria as a whole. We expect to move and/or remove additional Success Criteria at more than one level before we are finished.

WCAG 1.0 and Current WCAG 2.0 Level Definitions

WCAG 1.0 Levels of conformance

Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.

[Priority 1]

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.

[Priority 2]

A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.

[Priority 3]

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

Some checkpoints specify a priority level that may change under certain (indicated) conditions.

WCAG 2.0 Levels of conformance (current draft)

The success criteria for each guideline are organized into three (3) levels of conformance.

• Level 1 success criteria:
  1. Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.
  2. Can reasonably be applied to all Web resources.
• Level 2 success criteria:
  1. Achieve an enhanced level of accessibility through one or both of the following:
     1. markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies
     2. the design of the content and presentation
  2. Can reasonably be applied to all Web resources.
• Level 3 success criteria:
  1. Achieve additional accessibility enhancements for people with disabilities.
  2. Are not applicable to all Web resources.

Note: Comments will be included in guidance doc that level 3 conformance should not be required by public policy since it is intended to list criteria for those who want to expend extra effort to make their sites more accessible where possible.

Summary of Issues

• Some participants felt that we should stay with three levels because it provided 3 graded levels of conformance
  • A minimum level (first steps toward accessibility) that is not too large a step.
    • Allows companies, customers or government to specify a small "basic" set (L1).
  • A next level with important (L2) provisions - without including really tough (L3) provisions that would prevent most people from ever trying for conformance at this level.
  • A third level with provisions that are too hard for widespread application but important for "those who want to do extra effort for accessibility" so that authors are aware and encouraged to do them when they can.
• Some participants felt that we should change to 2 levels.
  • Simpler conformance
  • Different number than WCAG 1.0 so less confusing than same number but different levels.
  • to require Having only 2 levels decreases the probability that level 2 items would ever be required. (Note: this increases pressure to move L2 Success Criteria to L1)
  • See also "L3 should be dropped" comments two bullets below)
• There was disagreement among two level supporters as to whether that meant redistributing the L3 items to L2 (and some L2 to L1) or whether it meant just dropping all of the L3 items as Success Criteria
• Some 2 level proponents felt that L3 should be dropped as Success Criteria
  • Because some don't apply to all sites
  • Because some are hard to do or unreasonable to require
  • Because some were felt to be less testable
  • Because there is a risk that conformance to level 3 might be required by public policy.
• Some supported dropping (or moving to guide doc) any items that were found to not be testable in the end (no matter what level) but did not favor dropping all of level three.
• Some could support 2 levels if the items were redistributed to the other levels (L3 to 2 and some L2 to L1) (and removal of items that are found to be not testable) but other two level proponents could not live with that.
• Proponents of redistribution (rather than removal) felt that
  • removal of L3 SC to another document and/or add them to advisory items would cause them to never be seen by most implementers, summarizers, etc
  • Some level 3 items were important to keep in the guidelines. Some were only moved out of level 2 because there was a level 3. If it was eliminated then they should move up to level 2.
  • Other items were placed in level 2 because it was a middle level of accessibility. If L2 was made the bottom level of accessibility – then they feel those items need to be moved up to Level 1.
• Some felt that it was important that Level 1 be as minimal as possible to provide as small a ‘first step’ as possible. They were against any movement of L2 items to L1 for this reason..

RE Having only one level of conformance with all else in second advisory level

• Some felt that this would be simplest and most straight forward conformance.
• Some felt this would cause Level 1 to become to big, to include to many L2 SC (and we would lose the ‘small first step’)
• Some felt that there needed to be something beyond minimum conformance.

Current Result and Questions

These results are basically consistent with the results each time this is revisited. In our latest round we were unable to reach consensus for any of the 3 or 2 level approaches proposed. (Consensus is defined as everyone says they can live with it, even if they might prefer something else.)

The greatest support currently was for the 3 level approach so this draft continues to have three levels. Because we do not have unanimous consensus on this however, this question is still open and we are seeking input from the field in the form of comments or any solutions that would address all of the concerns above.

The open questions are:

1. should there be two levels or three levels?
2. if two levels – how should items be redistributed between the two remaining levels? (and perhaps the guide doc)
3. should all of the items in level 3 be removed from the guidelines?
4. Is there a proposal that addresses all of the show-stoppers (issues listed above) to unanimous consensus - since unanimous consent is the groups goal wherever possible?

$Date: 2005/07/01 22:52:33 $ Prepared by Gregg Vanderheiden for the WCAG WG as a companion to the 30 June 2005 WCAG 2.0 Working Draft.