“Normative” parts of the guidelines define what must be done to conform to WCAG 2.0.

Most of the materials available are “Advisory”, which explain the Working Group's intent and provide recommended ways to meet the requirements. However, it is not mandatory to follow the advice in advisory materials, if you have another way to meet the specific requirement of the Success Criteria.

Normative sections: Conformance, Principles, Success Criteria, Definitions.

• Technologies not under control of W3C can be used if they provide accessibility features that meet WCAG requirements
• New technologies can incorporate accessibility features, and WCAG will still be relevant
• If only some features are supported, use the technology for those features and provide fallback to meet other Success Criteria

Examples

• AJAX
  • Techniques exist to support WCAG SC
  • Like Flash, requires more author responsibility at this time
  • W3C is developing new technology features to increase ability to create WCAG-conformant applications in AJAX
    • WAI-ARIA Roadmap
    • WAI-ARIA Roles
    • WAI-ARIA States and Properties
    • XHTML Role Attribute

• Sufficient techniques: following these techniques will meet the Success Criterion. Only one sufficient technique per success criterion must be followed.
• Advisory techniques: not required for WCAG conformance, but recommended by the WCAG Working Group.
• Failure techniques: describe known content authoring practices that fail the WCAG Success Criteria.

• General techniques: describe practices that can be implemented in any technology
• Technology-specific techniques: code approaches for specific technologies

WCAG 2.0 currently provides technology-specific techniques for:

• HTML
• CSS
• Script

In this example of an image link, the image is changed when the user positions the pointer over the image. To provide keyboard users with a similar experience, the image is also changed when the user tabs to it.

Assistive technology (AT): special tools used by people with disabilities to interact with Web content. AT can adapt the page to the user's requirements so the author doesn't have to anticipate every user need. Most AT are not tested by authors, and require the encoding of content to support standard practices and accessibility APIs so it can reliably access it.

Text alternatives: because not all forms of non-text content can be transformed into accessible formats, WCAG 2.0 commonly requires text alternatives. Although some richness is lost, text can be transformed in a variety of ways and therefore provides the widest interoperability with AT.

Programatically determined: AT can reliably determine a state or property of content. Normally this requires that explicit, standard coding practices be followed, but it is also possible to use design practices that support widely-implemented heuristics.

Change of context: a change in the current browser window, or a change in input focus that the user did not initiate.

Keyboard interface: pointing devices (like a mouse) provide continuous, graphical-based input that is difficult for many people with disabilities to use. Keyboards and devices that use keyboard interfaces provide discrete input that most people can use. WCAG 2.0 requires compatability with keyboard interfaces, which allow standard keyboards as well as a wide variety of keyboard emulation hardware and software.

Visual contrast is specified in terms of a Luminosity Contrast Ratio, which is defined as a mathematical formula.

• At Level 1, content supports keyboard interface unless it intrinsically requires analog input (e.g., a graphics drawing program).
• At Level 3, content must work with keyboard interfaces. Some types of content may not be able to meet this Level 3 requirement.

Description of examples:

1. The link to the WCAG home page does not have a description of where it goes. The description is in this paragraph but the association is not programatically determined.
2. The link has its destination directly associated.
3. The link has its destination explained in the same paragraph. AT could retrieve this information easily, although it does not now. This is not programatically determined, but may be if AT support evolves.

Ruby is used to give the reading of Han characters (Kanji). The pronunciation information is rendered in parentheses immediately following the base text. (User agents that support Ruby do not show the parentheses.)

• Parsing replaces full validation requirements. There has been a lot of discussion about this, but parsing into a predictable representation is the aspect of validation that is crucial for accessibility, as any user agent must be able to understand the content.