The Web Content Accessibility Guidelines, a Commented Overview
By Gerd Waloszek, Product Design Center, SAP AG – 02/18/2002 • updated 01/20/2004
Overview
- Web Content Accessibility Guidelines 1.0
- Section 508 and the Web Content Accessibility Guidelines 1.0
- Web Content Accessibility Guidelines 2.0 (Draft)
- Conclusions
Many people talk about Section 508 and the challenges associated with it for software developers and companies. But few people really know the detailed federal regulations (Section 508) and the W3C's Web Content Accessibility Guidelines. With this article, I intend to provide a quick overview of the current regulations and the regulations to come. I will take a closer look at the Web Content Accessibility Guidelines 1.0, their relation to Section 508, as well as at the relation between the current version 1.0 of the WAI guidelines and the forthcoming version 2.0. The latter has been published as a draft document and is currently under discussion.
Please note that this article is a comparison from a technical and academic perspective. It does not constitute a legal analysis of Section 508 and the W3C guidelines.
Web Content Accessibility Guidelines 1.0
The W3C's Web Content Accessibility Guidelines 1.0 comprise a fairly long document that states 14 guidelines for achieving accessibility.
Below you will find an overview of the guidelines. In the W3C document each guideline is complemented by the rationale behind the guideline and a list of checkpoint definitions that explain how the guideline applies in typical content development scenarios.
|
No. |
Short Form |
Long Form
|
|---|---|---|
|
1 |
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. |
|
2 |
Don't rely on color alone. |
Ensure that text and graphics are understandable when viewed without color. |
|
3 |
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. |
|
4 |
Clarify natural language usage. |
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text. |
|
5 |
Create tables that transform gracefully. |
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents. |
|
6 |
Ensure that pages featuring new technologies transform gracefully. | Ensure that pages are accessible even when newer technologies are not supported or are turned off. |
|
7 |
Ensure user control of time-sensitive content changes. |
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped. |
|
8 |
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. |
|
9 |
Design for device-independence. |
Use features that enable activation of page elements via a variety of input devices. |
|
10 |
Use interim solutions. |
Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. |
|
11 |
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. |
|
12 |
Provide context and orientation information. |
Provide context and orientation information to help users understand complex pages or elements. |
|
13 |
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. |
|
14 |
Ensure that documents are clear and simple. |
Ensure that documents are clear and simple so they may be more easily understood. |
Let me direct you to some of the issues that I think are important. One of these issues is captured in guideline 1. It demands that equivalent alternatives to information that is given visually or auditorily are provided. I have written a whole article covering this very topic because I feel that the term "equivalent information" needs to be explained.
Guideline 3 demands the correct use of HTML markup and style sheets. This requirement often clashes with reality and the limitations of HTML, which lead Web designers to "use" or "misuse" markup according to their design needs.
Guideline 12 requires that context and orientation information are provided; guideline 13 adds to that and calls for clear navigation mechanisms. In all these respects, there are currently no universally supported solutions, such as mechanism that explain the purpose of a page, its high-level structure, its location within a Website, or its relation to other pages. Technical solutions may be feasible but often overwhelm users with unnecessary information.
Checkpoints
As the W3C's guidelines are fairly general, they are explained by checkpoints. The checkpoints show how the guidelines apply in typical content development scenarios and are ordered according to three priority levels. As there are too many checkpoints to list in this article, I am providing an extra page with an excerpt from the respective W3C document.
You will find the checkpoints in the form of a checklist as Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 of the W3C at www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist.html. See also the guidelines themselves for more information on the checkpoints. Moreover, you will find additional information in the document Techniques for Web Content Accessibility Guidelines 1.0 at http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/ which is complemented by the parts Core Techniques, HTML Techniques and CSS Techniques. This technical document is ordered according to the guideline numbers. Each guideline is followed by one or more checkpoints which themselves are complemented by links to sections in the technical guidelines.
This sounds more complicated than it is, although admittedly the navigation between the different sections of the guidelines is a bit complex in my opinion. Therefore, let me explain the relation between a guideline, its checkpoints and links with an example:
| Guideline 5. Create tables that transform gracefully |
|---|
|
Checkpoints: ... 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]
... |
This is an "ideal" example because it has links to all three technical subsections. If you follow the links you get detailed information on how to design and implement certain accessibility features.
Conformance Levels
The W3C's Web Content Accessibility Guidelines 1.0 define three levels of conformance to their document. These levels depend on whether checkpoints of different priority levels are satisfied:
- Conformance Level "A": all priority 1 checkpoints are satisfied
- Conformance Level "Double-A": all priority 1 and 2 checkpoints are satisfied
- Conformance Level "Triple-A": all priority 1, 2, and 3 checkpoints are satisfied
Priority 1 relates to checkpoints that must be satisfied, priority 2 to checkpoints that should be satisfied, and priority 3 to checkpoints that may be satisfied.
Conformance Claims
Claims of conformance can be integrated into the respective software and must be in one of two prescribed forms; see the Web Content Accessibility Guidelines 1.0 for details.
Conformance claims not only contain the conformance level but also the scope of the conformance, e.g. a page, site, or defined portion of a site or portal.
Currently, it seems that Web designers or software companies can issue conformance statements on their own - there is no "official" institution for doing that (it would be overwhelmed by work, anyway). The next question is, how you can do that. Should you walk through every page of your site or portal with the checklist provided by the W3C? This may require a lot of resources with respect to time and people. Also many issues may be subject to personal interpretation.
As a rescue, there are automatic checking tools, such as Bobby (Bobby Worldwide written in Java by CAST). Bobby not only checks Web pages, it also offers its own conformance approval ("Bobby Approved"). Bobby received very mixed reactions with respect to its usefulness from its users. It still leaves many issues open to the reviewer and also lists issues that are not real issues. Thus, it may create more work than it intends to save.
Section 508 and the Web Content Accessibility Guidelines 1.0
As we focus here on Web applications, Websites, and portals, the relevant paragraph of Section 508 is §1194.22, which deals with Web-based Intranet and Internet information and applications. If you first look at the summary document of Section 508 you may be mislead by the following statement:
- The criteria for web-based technology and information are based on access guidelines developed by the Web Accessibility Initiative of the World Wide Web Consortium.
However, take a closer look at the full-text version of Section 508 and you will find that there is only a partial one-to-one correspondence between Section 508 guidelines and WAI guidelines. Here are the respective statements taken from Section 508 (highlighted by the author):
Note to §1194.22:1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:
Note (from the author): This comparison table does not include all priority 1 checkpoints of the Web Content Accessibility Guidelines 1.0. This table has been rearranged by the author to include two tables in one. 2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section. WCAG 1.0 is available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. Supplement - Guidelines l - p (Added by the Author)
|
The Section 508 guidelines that have no equivalent WAI guideline refer to scripts, applets and plug-ins, and form support as well as to repetitive navigation links and timed responses.
Important requirements in these regulations are:
- Equivalent alternatives to the primary mode of presentation; for example, a text page can be offered if equivalence cannot be obtained in other ways; images and audio clips have to be complemented by text equivalents
- Redundant access mechanisms so that users need not rely on one single access mechanism; for example, using the mouse as the only access device is discouraged - keyboard access has also to be provided
- Readability independent of certain layout techniques, such as style sheets (CSS) or layout tables
- Correct use of markup, table cell types, and frame titles to convey the logical structure of documents and parts thereof.
Web Content Accessibility Guidelines 2.0 (Draft)
Finally, let's take a short look at the draft of the upcoming Web Content Accessibility Guidelines 2.0 and see what has changed. The new guidelines are divided into a top and a bottom layer. The top layer is independent of technology and covers the more general concepts, whereas the bottom layer covers the more specific concepts.
The top layer of the guidelines is divided into an overview of design principles and four guidelines presentation, interaction, comprehension, and technology considerations. Each guideline has several checkpoints associated with it, all in all there are 21 checkpoints. Each checkpoint is divided into normative and non-normative (informative) information. The normative text describes what software must conform to the guidelines, while the informative text only helps to make the normative text easier to understand. A checkpoint consists of:
- Normative: the checkpoint text, success criteria
- Informative: definitions, benefits, examples
The bottom layer, where the specific concepts are described, is contained in a separate Techniques Document, which offers code examples, screen shots and other technology-specific information. Currently, the links into this document are not active, which actually means that this document cannot be accessed. The technologies covered comprise
- HTML/XHTML techniques, CSS techniques, PDF techniques, server-side and client-side scripting techniques, SVG, SMIL and XML techniques
Overview of the Guidelines and Checkpoints
The following table lists the four guidelines and their corresponding checkpoints.
Guideline 1 - Presentation. Design content that allows presentation according to the user's needs and preferences
| 1.1 | Provide a text equivalent for all non-text content. |
| 1.2 | Provide synchronized media equivalents for time-dependent presentations. |
| 1.3 | Use markup or a data model to provide the logical structure of content. |
| 1.4 | Identify the primary natural language of text and text equivalents and all changes in natural language. |
| 1.5 | Separate content and structure from presentation. |
Guideline 2 - Interaction. Design content that allows interaction according to the user's needs and preferences
| 2.1 | Provide multiple site navigation mechanisms. |
| 2.2 | Provide consistent and predictable responses to user actions. |
| 2.3 | Either give users control of mechanisms that cause extreme changes in context or warn them of pending changes. |
| 2.4 | Either give users control over how long they can interact with content that requires a timed response or give them as much time as possible. |
| 2.5 | Use device-independent event handlers. |
| 2.6 | Avoid causing the screen to flicker. |
| 2.7 | Handle input errors, such as misspellings. |
Guideline 3 - Comprehension. Make it as easy as possible to use and understand
| 3.1 | Use consistent presentation. |
| 3.2 | Emphasize structure through presentation, positioning, and labels. |
| 3.3 | Write as clearly and simply as is appropriate for the content. |
| 3.4 | Supplement text with non-text content. |
| 3.5 | Annotate complex, abbreviated, or unfamiliar information with summaries and definitions. |
Guideline 4 - Technology considerations. Design for compatibility and interoperability
| 4.1 | Choose technologies that support the use of these guidelines. |
| 4.2 | Use technologies according to specification. |
| 4.3 | Design user interfaces compatible with assistive technology. |
| 4.4 | Ensure that content remains usable when technologies that modify default user agent processing or behavior are turned off or not supported. |
Checkpoint Mapping
The W3C provides a mapping between the checkpoints of version 1.0 and 2.0; it is too long to be listed in this article. You will find the mapping document under the following link: www.w3.org/WAI/GL/2001/08/24-mapping.html. In addition, I provide a separate page with a shortened version of the mapping that is taken from the W3C mapping document for your convenience.
Improvements in WCAG 2.0
The W3C states:
|
We hope that WCAG 2.0 will have several improvements over WCAG 1.0.
|
In my opinion, the new guidelines are much better structured than the old ones. Organizing accessibility issues under four main topics helps to focus on certain aspects, such as interaction or presentation. On the other hand, the checkpoints are very general in scope and allow a wide range of interpretations. Thus, they are rather "good rules of thumb" for the development than actual "checkpoints" of a technical checklist, where reviewers can put their marks. For example, the checkpoint "Handle input errors, such as misspellings" can be satisfied by error messages using ugly technical jargon, as well as by automatic correction or error prevention techniques. So, the quality of the error handling is not an issue for this checkpoint. Maybe, the Technical Document will have to say more about this.
Conclusions
As the Technical Document for the WCAG version 2.0 is still not available publicly, it is too early to come to any realistic conclusions about the usefulness of the new guidelines as such on the one hand, and in comparison to the existing ones on the other hand. But one thing is for sure: there will be a lot of "stuff" that developers have to digest - and this will be a tedious job. Therefore, it is a good idea to include accessibility support into the technologies themselves so that accessibility is "automatically" included in Web or portal pages - and life is made much easier for developers and designers.
See the commented link list in this edition for further links on Section 508 and to W3C documents on accessibility.
