Web Content Accessibility Guidelines 1.0
In May 1999, the World Wide Web Consortium in conjunction with the Trace Center prepared the Web Content Accessibility Guidelines version 1.0. The purpose of the recommendation is to explain how to make Web content accessible to people with disabilities, and since its publication it has been the guiding force behind much of the accessibility discussion. The target audience includes page authors, website developers, and the designers of authoring tools. They claim that following their guidelines "will also make make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.)."
The document was meant to stand alone, so it does not chart the current developments in web browsers or other technologies -- that is left up to the Web Accessibility Initiative. Instead, the WCAG and the associated Checkpoints and Techniques form a complete body of well-researched guidelines for designing accessible Web media independent of rapid changes.
It would be pointless to try to recast the WCAG, as it is a thorough and extensive document. It follows a very logical structure: statement of guideline, rationale behind guideline and the group that benefits from it, and a list of checkpoints that explain how the guideline can be applied in typical scenarios. The checklist breaks the WCAG into elements of highest priority (websites must satisfy these) down to lowest priority (websites may satisfy these). Finally, parallel to the checkpoints there is an in-depth set of Techniques that act as an accessibility tutorial. It is recommended that interested readers read or scan the Web Content Accessibility Guidelines document itself, learn some of the techniques, and begin putting them in practice. There is no need to duplicate them here. However, I will summarize the main points on the checklist and then offer some commentary on how the WCAG differs from the recommendations of the Access Board about Section 508.
Table of contents:
Summary of Guidelines
Source: WCAG 1.0
- Provide equivalent alternatives to auditory and visual content.
- Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
- The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text can be readily output to speech synthesizers and braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper.
- Don't rely on color alone.
- Ensure that text and graphics are understandable when viewed without color.
- If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits.
- Use markup and style sheets and do so properly.
- Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.
- Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it.
- Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. They must be aware that these practices cause accessibility problems and must consider whether the formatting effect is so critical as to warrant making the document inaccessible to some users.
- Clarify natural language usage.
- Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.
- Create tables that transform gracefully.
- Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.
- Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables").
- Ensure that pages featuring new technologies transform gracefully.
- Ensure that pages are accessible even when newer technologies are not supported or are turned off.
- Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.
- Ensure user control of time-sensitive content changes.
- Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.
- Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all.
- Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities.
- Ensure direct accessibility of embedded user interfaces.
- Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.
- When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible.
- Design for device-independence.
- Use features that enable activation of page elements via a variety of input devices.
- Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other.
- Use interim solutions.
- Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.
- Use W3C technologies and guidelines.
- Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.
- Provide context and orientation information.
- Provide context and orientation information to help users understand complex pages or elements.
- Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.
- Provide clear navigation mechanisms.
- Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site.
[ Back to Top ]
Comparison to Section 508 Guidelines
A quick glance back at the Section 508 standards for Web-based applications will raise some questions as to the difference between the Section 508 Guidelines and the Web Content Accessibility Guidelines. The Section 508 standards were issued by a government committee charged with advising federal entities about how to make their sites comply with Section 508 law. In contrast, the WCAG -- while similar in many of its recommendations -- is intended to educate all Web developers and provide an extensive set of guidlines, checkpoints, and how-tos on accessibility. Thus, the WCAG is much broader in scope. In addition, the WCAG is generally more strict than Section 508.
Fortunately, a more systematic analysis of the two documents already exists. Head over to Jim Thatcher's Side-by-Side Comparison site, learn more about the differences between the two, and come back here for more.
[ Back to Top ]
Additional Resources
Web Content Accessibility Guidelines, 1.0: Official 1999 W3C recommendation explaining (1) how to make Web content accessible to people with disabilities and (2) how to make Web information more available to all users.. The guidelines are intended for Web developers and developers of authoring tools. (large download)
Checklist for WCAG 1.0: An appendix to the Accessibility Guidelines, this document provides a checklist of all official checkpoints from the WCAG, organized by concept. The list is intended to be used as a guide for reviewing and modifying a site to comply with the published Web standards.
Techniques for WCAG 1.0: Gateway for a series of related W3C documents providing HTML and CSS techniques for satisfying the requirements of the WCAG.
Section 508 and WCAG - A Side-by-Side Comparison: Jim Thatcher's thorough analysis of the differences and similarities between these two documents.
[ Back to Top ]