The Web Content Accessibility Guidelines 2.0 (WCAG 2.0) Working Draft is a new set of guidelines for making the content on websites accessible to people with disabilities. This Working Draft evolved from the current WCAG 1.0, which was published in 1999. WCAG 2.0 is an attempt to make the guidelines more robust, measurable, and technology-independent. In addition, more supporting information is incorporated into WCAG 2.0 than was present in WCAG 1.0.
These guidelines are being developed by a group representing industry, government, educational, and nonprofit interests. The official name of the group is the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). Since WCAG 2.0 is a Last Call Working Draft, it is still under development and can be commented on and contributed to at the time of the publication of this book. Modifications can be expected up until it is officially accepted by the W3C, so some of the details contained within this chapter are likely to have changed by the time it is published.
The purpose of this chapter is to give you a good understanding of how WCAG 2.0 is organized and how you might use the guidelines effectively. It will explain the differences between WCAG 1.0 and WCAG 2.0, the purpose of the various elements of WCAG 2.0, and its attendant documentation and resources. The chapter is not an exhaustive analysis of WCAG 2.0, a full reference, or a complete tutorial on every detail. It is a roadmap to assist you in getting acquainted with the guidelines. We thought it best to present the information like this, and generalize somewhat, because it is still subject to change.
These guidelines are for producing accessible content delivered using web-based technology. Although many consider them standards, they are not. It is appropriate to have a short discussion of the difference between standards and guidelines, so we'll begin by making that distinction.
Standards are repeatable, measurable, and testable specifications that can be used as normative technical requirements. An example of a standard is IEEE 802.11b, the Institute of Electrical and Electronics Engineers standard for 10Mbps Wireless Local Area Networking. Any device claiming to conform to this standard can be tested by any lab and be found to either meet or not meet the standard.
Guidelines, such as WCAG, are literally guidance. An example of a guideline might be "To stay healthy, a person should exercise at least 20 minutes a day.
" But what constitutes "healthy"? Does this mean optimum health, a state of homeostasis, or just "better than poor health"? The point is that guidelines are open to interpretation. (WCAG 2.0 tries to break this mold somewhat; all the "success criteria" are written as testable statements, with the aim of making the guidelines more testable.)
So, why do people keep pointing at the various WAI guidelines as standards?
The answer is that industry and governments use standards all the time, as mechanisms to ensure normative activity. What this means in real life is that governments and industry need to have a measurable, testable way to ensure that accessibility exists in a given web document, and to what extent.
When accessibility advocates note that accessibility is a quality, not a quantity, and therefore not measurable except to an individual's unique needs, one of two things happen:
Of course, I understand now," and then they go and use the automated tool and accept whatever comes out as a test and measure.
So, the issue here for both regulators and implementers is that the WAI has consistently failed to write measurable, testable standards for the web technologies within the W3C purview. The guidelines are, by definition, a "best practice" for any document on the Web in any form. What is needed is an accessibility standard for HTML, XHTML, and so on that is specific, testable, and measurable. Such a standard would be ideally submitted to the International Organization for Standardization (ISO) or the American National Standards Institute/International Committee for Information Technology Standards (ANSI/INCITS) for fast-track incorporation. Regulators and industry could then reference the standard, making it easy to keep pace with changes in technology.
WCAG 2.0 from 50,000 Feet
WCAG 2.0 is voluminous—more than 600 printed pages. As one commenter noted:
Part of my concern is that it is really huge. As a developer, I could go through WCAG 1.0 and find the relevant information that I needed to make sure I had what I needed in my website. It is all there in WCAG 2.0 in amazingly rich detail. That amazingly rich detail is just so much information to parse.
This is why it is good to start off by reading the "Understanding WCAG 2.0" document, which provides a more manageable overview. As you'll see in this chapter, there are also annotated checklists for developers to follow to quickly determine which items apply, and how they are applicable to the technology they are using. So, digesting WCAG 2.0 isn't actually as nightmarish as you might first think. The other place you should visit straight away to get better acquainted with WCAG 2.0 is the "Overview of WCAG 2.0 Documents" page.
WCAG 2.0 is organized in a completely different manner from WCAG 1.0. WCAG 1.0 consists of guidelines, which each includes a set of checkpoints that explain how the guideline applies to web development . The checkpoints are prioritized as Priority 1, 2, and 3. In contrast, WCAG 2.0 is organized by principles, guidelines, and success criteria. Additionally, the success criteria are not prioritized, but instead are ranked by levels. These components of WCAG 2.0 are described in the next section.
The new guidelines are more technology-independent and address web-based accessibility issues in a more general manner than WCAG 1.0. This is at least in part because of the changing nature of the Web and the technologies that are being used to produce and present web content. The WAI is trying to make sure that the guidelines can address these changing and evolving technologies, and that they will be useful in determining the accessibility of web pages produced with methods and technologies not yet developed.
While the guidelines and principles are more general, a great deal of material is being supplied on how to achieve conformance. This material is specific and helpful. It is also still under development, so those who are involved in the accessibility arena are encouraged to make contributions.
Here, we'll look at the contents of the WCAG 2.0 Working Draft, including the principles, guidelines, and the three levels of success criteria that form the guidelines. A good understanding of these elements and how they are used is critical in understanding WCAG 2.0 as a whole.
The WCAG 2.0 is organized around four design principles of web accessibility:
The following are the guidelines for each principle. These are not for the most part technology-specific. They tell you what to do, not how to do it. For a more detailed list of the guidelines and their subparts, refer to WCAG 2.0 Appendix B.
The first principle is that content that cannot be perceived in some way or another by web visitors is not serving its purpose.
Principle 1: Content must be perceivable
Four guidelines help those designing and building websites to make content perceivable to the largest number of people possible.
Guideline 1.1 Provide text alternatives for all non-text content
Providing text alternatives for nontextual content makes it possible for people with different abilities using different devices to perceive the content of web-based resources.
Guideline 1.2 Provide synchronized alternatives for multimedia
Where multimedia is presented on the Web or using web-based technology, alternatives such as synchronized captioning with audio and video presentations should be presented.
Guideline 1.3 Ensure that information and structure can be separated from presentation
It is necessary to ensure that information, structure, and functionality can be separated from presentation (the way the content looks or sounds). Using structural markup correctly ensures that standards-compliant user agents can determine how the content should be presented, even when the user agent must adapt the presentation to meet the needs of people with disabilities. Conversely, incorrect use of structural markup—for example, to create visual effects that are not related to the organization and meaning of the content—may create unintended obstacles for users with disabilities.
Guideline 1.4 Make it easy to distinguish foreground information from its background
The second principle is that any elements on the web page must be usable by all persons, regardless of disability.
Principle 2: Interface elements in the content must be operable
Five guidelines are associated with this principle.
Guideline 2.1 Make all functionality operable via a keyboard interface
Guideline 2.2 Allow users to control time limits on their reading or interaction
Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity
Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it
Guideline 2.5 Help users to avoid mistakes and make it easy to correct mistakes that do occur
The third principle is that all content (be it text, images, and so on) and controls (for example, navigation elements) must be readable by all users, whether or not they are sighted.
Principle 3: Content and controls must be understandable
This principle has two guidelines.
Guideline 3.1 Make text content readable and understandable
Guideline 3.2 Make the placement and functionality of content predictable
The fourth principle is that all content should be designed so that it will not break in the future; for example, when viewed in future user agents.
Principle 4: Content should be robust enough to work with current and future user agents (including assistive technologies)
Two guidelines support the fourth principle.
Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies)
Guideline 4.2 Ensure that content is accessible or provide an accessible alternative
Success criteria are defined as "testable statements that are not technology-specific
" (www.w3.org/TR/WCAG20/). These criteria indicate what must be done to achieve success at various levels of conformance. They are used to determine if a "web unit" conforms to WCAG 2.0.
Web unit is a collective term for a collection of information on the Internet, not necessarily a single web page, but accessed through single uniform resource identifier (a URL, for example.). A set of web pages, plus some images and a style sheet, accessed through a single URL would count as one web unit.
The success criteria have been organized into three separate levels of conformance. Each level has its own criteria, as follows (www.w3.org/TR/2005/WD-WCAG20-20051123/intro.html#overview-design-principles):
Note: Some guidelines do not contain level 1 success criteria, and others do not contain level 2 success criteria.
This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. In WCAG 1.0, each checkpoint is assigned a "priority" according to its impact on accessibility for users. Thus Priority 3 checkpoints appear to be less important than Priority 1 checkpoints. The Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria grouped under Levels 1, 2, and 3 as described above.
The Working Group believes that all success criteria should be testable. Tests can be done by computer programs or by people who understand this document. When multiple people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained.
In analyzing the successcriteria levels, it is clear that they do not point to a specific technology but are more general in nature, so they can be applied with a variety of technological solutions. This is a strong point for the guidelines.
As we just mentioned, the guidelines and success criteria in WCAG 2.0 are presented in a way that is not technology-specific. However, as you go deeper into the documentation linked to the success criteria, the techniques for specific technologies begin to emerge. This information is found in the "techniques" documents for the different W3C technologies. These guides are indispensable for WCAG 1.0, and will probably be more so in WCAG 2.0, due to its size and complexity. For example, the following documents are available for WCAG 1.0:
The following are also available for WCAG 2.0:
One problem with WCAG 2.0 is that the guidelines are so general that it is sometimes difficult to determine which guideline or guidelines apply to a specific technique or situation. Using tables to format a page is a good example of this. The following is the guideline dealing with tables:
Guideline 1.3 Ensure that information and structure can be separated from presentation.
This is all well and good; however, the guideline does not mention tables (or other website constructs) specifically. But that's the point—it is deliberately structured so that it deals in general with all of the issues that make the collision of structure and presentation lead to inaccessible web pages. This way, the guideline will be relevant to future technologies as well as current ones.
Let's have a look at the success criteria that appear under this guideline (there are no Level 3 criteria for this guideline):
Level 1 Success Criteria for Guideline 1.3
1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.
1.3.2 Any information that is conveyed by color is also visually evident without color.
1.3.3 When the sequence of the content affects its meaning, that sequence can be programmatically determined.
Level 2 Success Criteria for Guideline 1.3
1.3.4 Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined.
1.3.5 Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components.
Looking at these success criteria, it is not hard to figure out that all of these could be applied to tabular data. When you get used to how WCAG 2.0 works, it can be quite effective. When you've identified which guidelines apply to a particular problem, find those guidelines on the W3C site, and then follow the How to meet. . . links to find out how meet the success criteria.
Let's compare this to the WCAG 1.0 guidelines, checkpoints, and priorities for making tables accessible. Guideline 5 is the main one related to tables:
Guideline 5. Create tables that transform gracefully.
5.1 For data tables, identify row and column headers. [Priority 1]
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1]
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]
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]
5.5 Provide summaries for tables. [Priority 3]
5.6 Provide abbreviations for header labels. [Priority 3]
Checkpoint 10.3 also applies to tables:
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped [Priority 3].
These checkpoints look much more obvious to try to follow, at least, at this level (WCAG 2.0 does have technology-specific support documents, but the guidelines themselves are technology-independent).
Even someone who is familiar with WCAG 1.0 may find it difficult to figure out which WCAG 2.0 guidelines and success criteria apply to a particular situation, such as tables. The document "Mapping of WCAG 1.0 checkpoints to WCAG 2.0 success criteria" can be very useful in this situation.
Sometimes a particular situation can exist that is covered by multiple guidelines. This will be more complicated than having to deal with only one guideline, but the same techniques outlined here apply.
Also, many users find the WCAG 2.0 Checklist to be a good quick reference for the guidelines.
In this section, we outline the apparent advantages and concerns that have been raised about the WCAG 2.0 guidelines.
The following are the advantages of WCAG 2.0:
The accessibility community is not unified in support of either the approach or the claimed effectiveness of WCAG 2.0. Some of the expressed concerns are discussed in the following sections.
At this time, the guidelines do not appear to be completely measurable. This was one of the original aims. One of the most common aspects of any technical standard is its ability to have compliance be measurable. That is, such a standard must have metrics—ways to measure a particular product's compliance that can be compared objectively with other products. Much of WCAG 2.0 contains subjective, rather than objective, measurements.
For example, how does one measure an "appropriate alternative text for a non-text element"? Obviously, an art historian would feel that a book would need to be written to express the Mona Lisa, whereas someone who had no opinion or appreciation might have "painting of a smiling lady" as their alternative text. Which is right? Which is better? WCAG 2.0 leaves this to the testers' own interpretation. In no other endeavor do the authors of works have such ability to be their own "critics." This should be improved by the time the final version comes out.
WCAG 2.0 is a revolutionary rather than evolutionary standard. Development has been proceeding worldwide that utilizes the practices and examples of WCAG 1.0. Much of the significant expenditure in this regard may need to be supplemented by organizations choosing to implement WCAG 2.0. As a revolutionary standard, many of the techniques and mechanisms (such as validation tools) that have been developed will need to be reexamined one by one, potentially with significant costs. Due to long product cycles, this could take years.
The impact of not having an evolutionary standard is well understood by standards organizations. The International Committee on Information Technology Standards has a policy discussion of the factors involved in balancing standards evolution. This document (available at www.ncits.org/sd9_feb2002.htm#_Toc514030136) was developed by INCITS (then X3), who took more than ten years to examine this one issue. The committee's findings—that standards need to ensure some effective, retrospective, progression—underscore the challenges in this area that WCAG 2.0 presents to specific consumers of the guidelines.
Some examples follow, illustrating different points of view from the various parties involved.
Several considerations apply to website developers:
Interruptions, such as WCAG 2.0 updated content, can be postponed or suppressed by the user, except interruptions involving an emergency"), even if justified!
WCAG 2.0 concepts such as baselines and scoping are complex and have not yet been fully developed. A baseline is defined as follows:
A "baseline", as used in WCAG 2.0, is the set of technologies that an author assumes are supported and turned on in accessible user agents. Authors must ensure that all information and functionality of the Web content conform to WCAG 2.0 even when a user agent supports and uses only the technologies in the baseline.
Using this definition, baselines are most useful in a controlled environment where the technology used by the end user is limited. In a public environment, which is much harder to control, it will be more difficult for baselines to be useful and helpful to the user or the developer. Since they have such a wide reach, it will be difficult. Scoping of conformance may help, but it is too early to tell.
Conformance means meeting the WCAG 2.0 success criteria. The success criteria levels explain what is expected to achieve conformance. In order to define and explain how scoping is used in conformance, a definition is required. Here is the definition of conformance from the W3C:
Conformance claims can be limited, or "scoped," to pertain to only some parts of a Web site. Scoping by URI to exclude sections of a site is allowed so that authors can make claims for just some parts of a site. . . .Scoping cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria.
The positive aspect of this is that parts of sites can be clearly marked as accessible or inaccessible. The negative aspect is that the exclusion of parts of websites can cause major problems when it is decided that certain parts of a site do not "need" to be prioritized for accessibility to people who have disabilities—scoping shouldn't be considered an excuse to leave some sections of the website inaccessible. At best, it would be considered an admission of failure.
The following are some other concerns related to WCAG 2.0:
Section 508 covers all Electronic and Information Technology (EIT). Our discussion will be limited to Subpart B – Technical Standards, Section 1194.22 of the Section 508 Standards (see Appendix B of this book for an excerpt of this part).
There are close matches between WCAG 1.0 and Section 508 1194.22 paragraphs (a) through (l). Beyond that, the mappings diverge.
Section 508 covers more than just web-based technology. Plus it was meant to be more precise and measurable than the WCAG guidelines that existed at the time. The desired effect was to cover a wide range of technologies, including Flash, PDF, and Java. This suggests that Section 508 is a bit closer to WCAG 2.0 than the original WCAG 1.0.
Several mappings are useful in understanding the relationship between Section 508 and WCAG 1.0 and WCAG 2.0, formulated and written by Jim Thatcher:
Leaning more towards how Section 508 works, WCAG 2.0 concentrates on the result, aiming to be more outcome-based. The guidelines themselves emphasize the final result that is achieved. As noted earlier in this chapter, at their highest level, the guidelines are technology-independent. Only as you go deeper into the success criteria and documentation on how to achieve those criteria do the technology-specific techniques begin to appear. The technological restrictions on achieving the goal are not as onerous as they were under WCAG 1.0, and there are more ways to achieve compliance.
If WCAG 2.0 could be made "regulatory friendly" with adoption as a worldwide accessibility regulatory standard, it would make it easier to maintain and enforce accessibility. However, implementation of this goal can be perceived as culturally unfriendly. Not all situations in all cultures are going to be covered, and this can produce unwanted situations. This is obviously a delicate situation, and a middle ground must be found to benefit the largest number of people.
The focus of regulatory compliance is often at odds with technical compliance. This is seen often in the U.S. with the Section 508 Standards. The legal requirement of compliance with the regulatory standards creates confusion in developers, who simply want to know the answer to "How do I code this?
" or "How do I use a tool to check the code?
" Since the "standards" are regulatory rather than technical, there are no easy mechanisms to ensure technical compliance, and U.S. companies have fought furiously to prevent standardized metrics that would allow easy comparison between products. Such comparisons could result in millions of dollars in windfalls and losses, based on how the final metrics are determined.
WCAG 2.0 tries to walk this line better than 1.0. However, the fundamental issue—that regulatory standards require a functional compliance and technical standards require a measurable, testable compliance—is not solvable without involving standards organizations such as ISO in the process, something that W3C is understandably loath to consider at this time.
Looking at all the concerns, it is fair to say that the jury is still out on WCAG 2.0. Ultimately, whether WCAG 2.0 will be the accessibility standard of the future will be decided by developers, their clients, and the governments of the world. And their awareness will be the responsibility of the W3C's WAI.
The WCAG 2.0 guidelines are organized in a way that is radically different from WCAG 1.0's organization. While the concepts are to some degree evolutionary, the organization of the guidelines is definitely revolutionary. This will require a good deal of work on the part of those who are used to the WCAG 1.0 guidelines.
Since the guidelines are outcome-based, many of the old restrictions no longer exist. The goals are designed so that new technology that has not yet been developed can achieve them without imposing the many restrictions that exist in the WCAG 1.0 guidelines.
Due to the fragmentary nature of the W3C process, there are varying degrees of consistency in the quality of the implementation practices that have been developed. Many of the sample markup fragments in the "how to meet" documents advocate practice that is not consistent with WCAG 1.0 best practice, such as not clearly identifying headers in a table. These sections are informative rather than normative; however, many developers generally do not have the time to review the arcane language in the guidelines document itself, and will simply refer to the "how to meet" sections when attempting to write or determine compliant code.