WCAG 2.0 Features
- Normative and Advisory Content
- Support for non-W3C and emerging technologies
- Techniques
- Tests
Normative and Advisory Content
- Normative:
- What must be done to conform to WCAG 2.0
- Conformance, principles, success criteria, definitions
- Advisory:
- Recommended ways to meet the requirements
- Not mandatory for meeting the guidelines
“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.
Support for non-W3C and emerging technologies
The baseline allows WCAG to support more technologies.
- WCAG works for W3C technologies and other technologies
- Success criteria remain applicable to new technologies
- Fallbacks when technology doesn't support accessibility fully
- 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
Techniques
Techniques provide advice on how to meet the Success Criteria. There are three types of techniques:
- Sufficient techniques
- Advisory techniques
- Failure techniques
- 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.
Techniques
Types of techniques:
- General Techniques
- Technology-specific techniques
You can submit techniques to the Working Group, or provide separate sets of techniques for non-W3C technologies.
- 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:
WCAG 2.0 Tests
Verify that sufficient techniques have been followed
- Test files
- Test procedures
Not mature yet but will be part of the final set of documents.
WCAG 2.0 Tests: Test Procedure
Script technique “Using both keyboard and other device-specific functions”
Procedure
- Find all interactive functionality
- Check that all interactive functionality can be accessed using the keyboard alone
Expected Results
WCAG 2.0 Tests: Test File
Script technique “Using both keyboard and other device-specific functions”
<a href="menu.php" onmouseover="swapImageOn('menu')" onfocus="swapImageOn('menu')"
onmouseout="swapImageOff('menu')" onblur="swapImageOff('menu')">
<img id="menu" src="menu_off.gif" alt="Menu" />
</a>
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.
Overview of WCAG 2.0 Requirements
- Important concepts
- Overview by Principle
- Principle 1: Perceivable
- Principle 2: Operable
- Principle 3: Understandable
- Principle 4: Robust
Important concepts
- Assistive technology
- Text alternatives
- Programatically determined
- Change of context
- Keyboard interface / input device independence
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.
Principle 1: Perceivable
Accommodate sensory disabilities
- Text alternatives for images, multimedia, and other forms of non-text content
- Semantic information about content structure that allows it to be transformed into forms the user can perceive
- Visual and audio contrast
Example: Luminosity Contrast
-
5
5
At Level 2, luminosity contrast should be 5 : 1
-
10
10
At Level 3, luminosity contrast shoudl be 10 : 1
Visual contrast is specified in terms of a Luminosity Contrast Ratio, which is defined as a mathematical formula.
Principle 2: Operable
People should be able to interact with content, regardless of manual disability or sensory disability that impacts their ability to use input devices.
- Content supports keyboard interface
- Time limits are not imposed on user, or user can adjust them
- Blinking or moving content, which can be very distracting to some users, can be stopped
- Flashing that could cause photosensitive seizures is not present
- Navigation and orientation features can be programatically determined
- Supports provided to help users recover from input errors effectively
- 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.
Example: Programatically determined link context
Description of examples:
- 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.
- The link has its destination directly associated.
- 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.
Principle 3: Understandable
Users must be able to understand content.
- Information provided to allow AT to adapt to the natural language (e.g., English, Japanese)
- Additional information provided for words and terms that might not make sense on their own
Example: Ruby to clarify pronunciation of text
慶應義塾大学
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.)
Principle 4: Robust
- Ensure content can be parsed into a predictable representation
- Expose names, roles, states, and properties to assistive technology
- 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.
Example: Parsing
<p>This contains <b>bold, <i>italic</b> text</i>.</p>
This HTML code may be parsed into various representations by user agents.
- This contains bold
italic
text.
- This contains bold
italic text
.
- This contains bold
italic text.
- <Not parsed, rejected by user agent>
