WCAG 2 Extension Principles

This document is an attempt to develop succinct and fundamental WCAG Extension Principles. It incorporates RFC 2119 keywords such as MUST, SHOULD, and MAY in an effort to focus WCAG WG thoughts on basic requirements (e.g., what is to be followed or can be desirably followed.)

Modifications

• Even though extensions MAY or MAY NOT redefine aspects of WCAG 2.0 within the context of the extension, extensions do not affect the validity of any current WCAG 2.0 claim.
• Extensions MAY alter WCAG 2.0 conformance requirements for a given success criterion by increasing normative requirements and success criterion. The applicable extensions MUST define any added conformance terminology. (With the new charter is this bullet point true anymore? Should we drop it?)

Compatibility

• Extensions MUST NOT change the meaning of conformance to WCAG 2.0 on their own.
• Extensions MUST be backward compatible with Core WCAG 2.0 principles, normative requirements, and success criterion. Core WCAG is now and will always be stable and the basis for conformance. (With the new charter is this bullet point true anymore? Should we drop it?)
• Extensions MUST NOT override WCAG 2.0 conformance requirements and success criterion. (With the new charter is this bullet point true anymore? Should we drop it?) If we don't drop this point: @@Question: Should we replace the word: "override"?

Harmonization

• Extensions SHOULD NOT conflict with other WCAG 2.0 extensions conformance requirements.
• Extensions SHOULD harmonize with other WCAG 2.0 extensions conformance requirements.

Integration

@@ Insert diagram to depict integration.

Single diagram of how WCAG extensions could relate to the current WCAG 2 Integration.

David created a diagram of how we might integrate the extensions into a single document. Description: "The task forces, Mobile, Cognitive, and Low Vision would develop guidelines, success criteria and techniques separately, and then integrate them to resolve conflicts and overlaps and then integrate them into the singular WCAG extension. The techniques would be collected in a non normative document as techniques for the extension, and some of them can be referenced from WCAG 2 where the techniques might apply to an existing Success criteria." An updated image is also available on David's site.

Extension Integration (Draft) Simplified version with 2 diagrams. - Laura Carlson

@@Questions:

Is there a better term to replace "override"?

In the "Extensions MUST NOT override WCAG 2.0 conformance requirements and success criterion" principle is there a better word for "override"? "Override" can mean "extend over; overlap." Perhaps the word "cancel" or "countermand" or "rescind" something else? Consult the discussion:

• • Katie's post
  • Laura's post
  • Mike's post
  • Jonathan's post
  • John F's post
  • Wayne's post

References

• RFC 2119 Key Words to Indicate Requirements (MUST, MAY, SHOULD etc.)

Charter

• Web Content Accessibility Guidelines Working Group Charter
  • (DRAFT) Web Content Accessibility Guidelines Working Group Charter
  • Extension requirements ranked high on WCAG WG Priorities under new charter survey - 2015-09-18 to 2015-10-08
  • WCAG Charter Update Survey Results
  • Ideas for Extensions Survey Results

Email

• WCAG extension email thread - July 2015
• Diagram of WCAG Extension integration into WCAG (Proposal) - September 2015

Minutes

• WCAG Minutes of Extension discussion, April 7, 2015
• WCAG Minutes of Extension discussion, July 21, 2015
• WCAG Minutes of Extension discussion, September 22, 2015

Related Wiki Pages

• Extension Integration
• Pros and Cons of candidate requirements
• WCAG Extensions Framework
• WCAG Task Forces