WCAG 1.0

WCAG 1.0 was the cumulative effort of the web community to arrive at a few basic accessibility guidelines. It is divided into three priority levels: Priority Level 1, Priority Level 2, and Priority Level 3. These are cumulative, so satisfying Priority Level 2 will also satisfy Level 1. In a flash of brilliant vernacular, the W3C decided to also add the term Conformance Level as well—Conformance Level A, Conformance Level Double-A, and Conformance Level Triple-A. Amazingly, these conformance levels map to the priority levels, so if your site meets all the requirements of Priority Level 1, you are actually meeting Conformance Level A. Sound needlessly convoluted? It is.

1. www.w3.org
2. www.w3.org/WAI

ACCESSIBILITY

According to the W3C, content authors “must” cover all items in Priority Level 1; doing otherwise would jeopardize the very ability of certain groups to even access a website. Furthermore, developers “should” satisfy Priority Level 2, and they “may address” Priority Level 3.

There are 14 major accessibility guidelines in WCAG 1.0. Each is divided into a bunch of checkpoints. In an even brighter flash of brilliance, the 14 guidelines do not map elegantly to priority/conformance levels; instead, any given checkpoint inside a guideline could apply to any of the three levels. For instance, guideline 2 states “Don’t rely on color alone.” Within that, checkpoint 2.1 states “Ensure that all information conveyed with color is also available without color, for example from context or markup.” Checkpoint 2.2 then goes on: “Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.” Checkpoint 2.1 is required for Priority Level 1 while Checkpoint 2.2 is required for Priority Level 2 (images) and Priority Level 3 (text). If you haven’t already guessed, things are rarely simple with the W3C.

Here are the 14 guidelines.7 Some guidelines are more obvious than others, and the checkpoints within each range from the painfully obvious to the near impossible:

1. Provide equivalent alternatives to auditory and visual content.
2. Don’t rely on color alone.
3. Use markup and style sheets and do so properly.
4. Clarify natural language usage.
5. Create tables that transform gracefully.
6. Ensure that pages featuring new technologies transform gracefully.
7. Ensure user control of time-sensitive content changes.
8. Ensure direct accessibility of embedded user interfaces.
9. Design for device-independence.
10. Use interim solutions.
11. Use W3C technologies and guidelines.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.

WCAG 2.0

WCAG 2.0 arrived in 2006 and saw both criticism and praise from developers all over the Web. Many considered it a major step forward, while others, like accessibility consultant Joe Clark, blasted it as a major step backward.8 In essence, the WAI shifted away from the

1. W3C, “Web Content Accessibility Guidelines 1.0” ( www.w3.org/TR/WAI-WEBCONTEN T/ #Guidelines ).
2. Joe Clark, “To Hell with WCAG 2,” A List Apart, May 2006 ( www.alistapart.com/article s/ tohellwithwcag2 ).

technique-centric approach and rewrote the guidelines by principle. This means that instead of a bunch of HTML code samples (the dominant technology in the late 1990s), the theories and recommendations apply to all technologies, from SVG to Flash to Portable Document Format (PDF). Instead of 14 general guidelines, WCAG 2.0 has been distilled into four major pillars:

Perceivable: This ensures that content can be perceived by users with at least one sense—usually vision or hearing.

Operable: The content must be delivered in a way that users can operate it using standard technology.

Understandable: This one’s a bit fuzzier, but the content must be presented in a way that’s understandable.

Robust: Interfaces and hardware for disseminating the content must be robust enough to handle disability access.

Within those four, three levels of success criteria replace WCAG 1.0’s priority levels. In terms of writing accessible websites, the same fundamental concepts apply to both versions of the WCAG, such as images and multimedia requiring text alternatives, form elements needing labels, and content and background having at least a five-to-one contrast differential. On a technological and tactical level, there is little difference.

In fact, if a company has developed their website with web standards—in this context defined by using well-formed, semantic HTML and CSS for presentation—it has already made huge progress toward being more accessible. In the next section, we will cover some accessibility basics and how to supplement and refine your markup to meet and exceed current laws.