W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

Summary of Issues, Revisions, and Rationales for Changes to WCAG 2.0 2006 Last Call Draft

Note: as of 30 April 2008, WCAG 2.0 has advanced to Candidate Recommendation. See the current set of changes in the diff-marked version of WCAG 2.0.

Overview

The Web Content Accessibility Guidelines (WCAG) Working Group received many substantive comments on the 2006 Last Call Working Draft and has revised the guidelines and supporting documents substantially to address and incorporate resolutions to the comments. An updated public WCAG 2.0 Working Draft is at http://www.w3.org/TR/2007/WD-WCAG20-20070517/. A Call for Review is available. Additional information on updates is available in the WCAG 2 FAQ.

This document provides an overview of the changes made to WCAG 2.0 since the Last Call Working Draft, and the rationale for making or not making suggested changes.

The WCAG Working Group made extensive efforts to simplify the language, shorten WCAG 2.0, and make it easier to use. It still is a technical document and includes some new terms needed to deal with access to new and evolving technologies. However, many of the special terms in the last draft have been removed and replaced with simpler explanations and terms. The "Baseline" concept has been replaced with the concept of Web technologies that are "Accessibility Supported" (see below). Some new success criteria were also added and the conformance level for others was changed, particularly in the cognitive, language, and learning areas.

Table of Contents

General Issues

Issues by Guideline (Including issue, resolution and rationale)

Key Issue Summaries

Length - Organization of documents

The length of the WCAG 2.0 Guidelines has been substantially reduced. Information from the introduction has been moved to a separate Introduction to WCAG 2.0 document and the Understanding WCAG 2.0 document. Some of the longer appendices have been removed. The WCAG 1.0 to 2.0 mapping is now a separate document that is being revised and made more useful to developers (which is not yet available with this draft). Based on comments received, the conformance section was moved from the front to a location after the guidelines to make it easier to get to the guidelines. The working group is also considering moving more information out of the Introduction in later drafts.

Quick Reference

In addition, a new WCAG 2.0 Quick Reference document has been created that provides a concise summary of just the guidelines and their success criteria, along with a listing of the techniques that have been identified as being sufficient for meeting the guidelines. This Quick Reference can also be customized by the user to show the techniques for just the technologies they are interested in, or just the levels of interest. It can also show the advisory techniques as well. Because this Quick Reference provides links to all of the other WCAG documents throughout, the working group expects that most developers and many others will use this as their primary document for working with WCAG 2.0.

Understanding WCAG 2.0

The Understanding WCAG 2.0 document continues to be book-length because it is in many ways a reference book on WCAG 2.0. Unlike WCAG 1.0, where questions arose later as to what some guidelines meant and what was needed to meet them, the working group set out to create a report that would accompany WCAG 2.0 and provide information on the intent of each guideline and success criterion as well as what was sufficient to meet it, advisory techniques, examples etc. These are all compiled in the Understanding WCAG 2.0 document. To make it easier to use in the future, the working group is considering breaking the Understanding WCAG 2.0 document into a collection of small (1 to 4 page) documents, one for each guideline and success criterion. (Right now, when you click on a link to Understanding WCAG 2.0 the first time it can take a long time for the whole document to download before it will jump to the referenced section in the document).

Techniques for Understanding WCAG 2.0

The Techniques for WCAG 2.0 document is also very large; in fact it is larger than last time because additional techniques have been added. The individual techniques themselves are quite short, ranging from a page to a few pages each each. The greater length of Techniques document (the full collection of techniques) is the result of the working group being much more thorough in providing documentation on different techniques for meeting WCAG 2.0 than was true for WCAG 1.0. Documentation for each of the techniques includes intent, user agent notes, and examples. In addition, a way to test to see if the technique was implemented properly is provided for all sufficient techniques and the testable advisory techniques.

The working group is planning on breaking this techniques document up into smaller collections and is also considering making each technique a 1-3 page separate document in a collection to facilitate their access and use.

There are many additional techniques to document and the working group is very interested in soliciting contributions of new techniques as well as help in documenting any of the techniques that are currently listed in Understanding WCAG 2.0 that have not yet been written up.

Complexity - Simplification

In the previous draft the working group focused on technical aspects and did not focus sufficiently on making the guidelines easy to read and understand for those who would be using the guidelines. Extensive effort has been made in the draft to address this. The guidelines have been reworked from top to bottom to remove unnecessary technical terms, to replace new terms with words explaining the issue instead and to use plainer language wherever possible.

WCAG 2.0 remains a technical reference standard and there is some level of complexity that that entails. Also, because it is technology neutral, it can seem (and is) more abstract in some respects. To offset this, the working group has included a few examples to make things clearer and introduced the Quick Reference document (early in the review process) that provides concrete examples of sufficient techniques right after each success criterion.

The working group still found a need for a few new terms to deal with the accessibility issue being presented by new Web technologies. These were kept to a minimum however and most of the new terms that appeared in the last draft have been replaced with simpler terminology. Wherever possible, plain language was used to replace new terms. The terms authored units, web units, authored component, baseline, and parsed unambiguously have all been replaced by more easily understood terms and explanations.

The Quick Reference document has also simplified the use of WCAG 2.0. One can start from this document (which is a compilation of text from the other documents) and get an overview of all the requirements and techniques to meet them. The Quick Reference in turn has links that will take the user directly to the parts of WCAG 2.0 or Understanding WCAG 2.0 or the Techniques and Failures documents that they are interested in.

The WCAG working group seeks comments on which aspects of the new design are most helpful as well as additional input on ways to make WCAG 2.0 easier to understand and use.

Baseline - "Accessibility Supported"

In the previous drafts the working group had introduced and developed the concept of Baseline to address the fact that technologies were constantly changing and to eliminate the "until user agent" clauses that had caused problems in WCAG 1.0. From the comments it was clear that this term was widely misunderstood and/or incomprehensible. The working group has therefore reworked the issue and moved to a more plain language way of addressing the problem of ensuring that technologies are supported by assistive technologies. The concept of "accessibility-supported" is now used to describe technologies "that work with assistive technologies and the accessibility features of user agents".

Basically the guidelines allow the use of new technologies as long as they work with assistive technologies and the accessibility features of browsers and other user agents. The guidelines then go on to set rules for when a technology, or features or extensions of technologies, can qualify as "accessibility supported".

The objective is to allow the introduction and use of new Web technologies, but to prevent such technologies from being used to satisfy the WCAG 2.0 success criteria if they do not work with assistive technologies and the accessibility features of browsers and other user agents. Only technologies that are supported can be used to meet the WCAG 2.0 success criteria and thus conform to WCAG 2.0. And all information and functionality of the page must be presented using technologies that are accessibility supported.

Authors who don't know which technologies or which aspects and features of a technology have support from assistive technologies should consult documented lists of technologies that are known to have accessibility support. Such lists can make it easier than it is today for an author to identify technologies or features of different technologies that are supported by assistive technologies and can be used to meet the success criteria that require assistive technology support (i.e. require that content can be programmatically determined.)

The W3C WAI will be compiling existing information on its technologies. It is expected that other organizations will compile such information for their technologies. There will undoubtedly be others who create documented lists as well.

Cognitive, Language, and Learning Disabilities

A concern of a number of commenters on the last draft was the coverage of people with cognitive disabilities in WCAG 2.0. Some felt that not enough was included that covered cognitive, language, and learning disabilities. Others felt that testability of success criteria was not critical and was a barrier to the inclusion of many good techniques for those with cognitive, language, and learning disabilities. Others were concerned that the guidelines gave the impression that if you met the success criteria of WCAG 2.0 that everyone could use Web content.

To address these issues, representatives of the working group met with people with different interests and expertise in cognitive, language, and learning disabilities and reviewed the full document to find ways to better address these groups (people with different cognitive, language, and learning disabilities). In some cases success criteria were moved up in conformance level(s). 3 new success criteria were added as well as adding a number of best practices for cognitive, learning, and language disabilities as advisory techniques. And a note making it clear that WCAG 2.0 did not address all of the needs of people with disabilities, particularly cognitive, language, and learning disabilities, was added to the introduction of the documents.

Validity

A number of comments advocated that conformance to WCAG 2.0 require that content validate or be used strictly according to specification. The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.

The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter.

Although the working group cannot require validity, it recommends it and it is our #1 sufficient technique listed for conforming to SC 4.1.1. (Success Criterion 4.1.1)

Level AAA conformance

A number of commenters noted that the third level of conformance differed from the other levels in that it was the only one that did not require authors to meet all of the success criterion to conform. Some felt this was not correct while others felt it would be too easily abused. The working group changed the conformance model and now all level AAA success criteria are required for AAA conformance. Because some Level AAA success criteria cannot be satisfied by certain classes of content, it is not always possible for a web page to claim Triple-A conformance.

Levels of Conformance

Some comments said that the description of the three levels was confusing. They have been rewritten to address this. We have clarified that having different levels of conformance does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability.

The meanings of the different levels have been written so it will be clearer why different success criteria occur at different levels.

Some success criteria at different levels are quite similar to one another, but one is a more restrictive version of the other. For example, SC 2.2.4 (at Level AAA) is a more restrictive version of SC 2.2.1 (Level A), since SC 2.2.1 permits exceptions for certain types of time limits, but SC 2.2.4 does not.

Conformance

The entire conformance section was reworked to address a wide range of comments including those around baseline, user contributed content, aggregation etc. Some highlights are mentioned here.

We have clarified that WCAG is descriptive rather than prescriptive. That is, it doesn't say what should be accessible. Rather, it is a measure of accessibility. The conformance section has been rewritten to reflect this. A way to specify partial conformance was also added.

In the process the working group decided to not outline specifically which types of content did or did not need to meet WCAG 2.0. This would have moved beyond defining an accessibility standard and into the realm of regulators by describing when content should or should not conform, which is beyond the scope of WCAG 2.0 and its working group.

Partial Conformance

Sometimes web pages are created that will later have additional content added to them. For example, an email program, a blog, or an article that allows users to add comments to the bottom. Another example would be a company or individual who compiles a page from multiple sources. Sometimes the content from the other sources is automatically inserted into the page over time.

In both of these cases it is not possible to know at the time of original posting what the content of the pages will be. A section on Partial Conformance was added to address these situations. Note that a page that partially conforms is considered non-conforming.

Scoping

There was a concern that an example in the conformance section would encourage the exclusion of more difficult material from a conformance claim. This language has been removed. While no voluntary standard can force people to apply the standard to everything they do, WCAG 2.0 does make it clear that any content that is within the scope of a conformance claim (that is, anything they are claiming conforms) fully meets WCAG 2.0 or has an alternative version that does.

Alternative Versions

WCAG 2.0 currently allows pages that do not conform to be included in a set of pages that conform, as long as all of the information on the page that does not conform is also on a page that does conform. The working group has been wrestling with a couple of questions around this issue and is seeking input and techniques that could make this work better. A presentation of the issue and the techniques documented so far can be found at http://www.w3.org/WAI/GL/2007/05/alternate-versions.html.

Issues by Guideline (Including issue, resolution and rationale)

Comments on Guideline 1.1 (Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language)

SC 1.1.1 Non-text Content

One commenter was concerned that the wording was not clear in that content could meet multiple situations in the list. Another commented that the CAPTCHA provision was hard to understand and was ambiguous in one respect. The wording of this success criterion was modified to make it easier to understand and to clarify what is required when content satisfies more than one situation.

Several new failures were also added:

New SC 1.1.x

There was a request that sign language equivalents for any prerecorded spoken language be added as a success criterion for 1.1.1. This was not accepted as a success criterion for 1.1.1, since this guideline is about providing text alternative and sign language is not text. Sign language is required for audio-visual material in 1.2.5 however. And an advisory technique was added to SC 3.1.5 to provide sign language versions of information, ideas, and processes that must be understood in order to use the content.

Comments on Guideline 1.2 (Provide synchronized alternatives for multimedia)

A request for audio descriptions of live multimedia to be required was not accepted since it is almost impossible to do unless the live multimedia is scripted.

Many concerns were expressed about the difficulty of providing captions and/or audio descriptions for multimedia, and this might cause pages containing multimedia to be excluded from conformance claims. The working group recognizes that this is a serious concern. However, multimedia will not be accessible to people with hearing or vision disabilities without these accommodations and therefore captions and descriptions are required. The ability to provide a full text alternative for audio description is however sufficient.

1.2.1 Captions (Prerecorded)

There was a concern that multimedia alternatives to text that are provided for people with cognitive disabilities would need to be captioned. A clause was added to make it clear that if they are alternatives to text on the page, they did not need to be captioned. However, captions are still recommended for them.

1.2.2 Audio Description or Full Text Alternative

Concerns were expressed that a full multimedia text alternative is not an adequate alternative to audio description, and should not be permitted as an alternative to audio descriptions in SC 1.2.2. A full transcript provides all the information from the multimedia (visual and auditory), and that has been our measure for an accessible alternative. It does not provide the same experience, but text alternatives to graphics do not provide the same experience either. In addition, audio-description does not always provide all of the information that is presented visually. For example Audio description may not provide all of the information in a training video which is almost all speaking over top of the visuals.

1.2.3 [was 1.2.4] Audio Description

The working group clarified that if the audio track provides full information about a video then no Audio Description would be necessary.

1.2.5 Sign Language

The working group clarified that the reason sign language is needed in addition to captions is that it enables people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. The user will not have control over the speed of the captions in multimedia, and may not be able to read the text quickly enough.

1.2.7 Full Text Alternative

The question was raised as to why Full text alternatives for multimedia are not required at Level A. This was not done because audio descriptions are usually more effective than text alternatives. This is due to the fact that they contain much additional rich audio information from the sound track and because they allow individuals who are blind the option of viewing the material with other people. Full text alternatives are however sufficient to meet Level A as discussed above.

Comments on Guideline 1.3 (Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure)

This guideline has been reworded to avoid confusion between "relationships" and "structure".

1.3.1 Info & Relationships

A commenter suggested that 1.3.1 and 1.3.4 overlapped. The working group agrees. SC 1.3.1 and the former SC 1.3.4 have been combined: "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." This wording ensures that it is the meaning conveyed by the presentation that must be programmatically determined, and allows the author to indicate the meaning in text if it is not feasible to do so programmatically.

This success criterion covers a large number of techniques related to the way that information is marked up. The user agent notes were updated for many of these techniques to record the known limitations of browser and user agents in supporting mark-up that represents these relationships. Additional common failures were also added.

There is now an explicit recommendation that CSS, rather than layout tables, be used in all techniques related to web page layout.

It is explained that there are no technology-specific success criteria in the normative guidelines because this would make them impossible to satisfy with other technologies, e.g., if the guidelines contain HTML-specific success criteria, then it will be impossible to meet them using a technology like PDF or perhaps even other markup languages. SC 1.3.1 is a particularly difficult success criterion to discuss in technology neutral language.

Although the association of labels and form elements was already covered by this success criterion and by SC 4.1.2, commenters noted that it was difficult for users to understand. A failure and an advisory technique were added to SC 1.3.1 to make this more obvious.

This success criterion also requires that content that visually conveys that it is a heading or subheading can be programmatically determined to be a heading. However, it does not require that the content contain headings, only that they be identifiable by user agents, including assistive technology, if they are used.

1.3.2 [was 1.3.3] Meaningful Sequence

This success criterion has been rewritten for additional clarification: "When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."

The success criterion recognizes that for some content, there are many possible correct reading sequences. For example, the reading sequence for a page that contains two independent articles can present either first. Either would be an acceptable programmatically-determined reading order.

It is not necessary that source order match presentation order to satisfy this success criterion. If the source order is the programmatically determined reading order, then the content must make sense in that order. However, as long as this condition is satisfied, the visual content order may be modified by CSS, for instance.

1.3.3 [was 1.3.5] Size, Shape, Location

This success criterion has been moved to Level A because assistive technology may not be able to preserve shape, size, visual location, or orientation of components when it transforms content to an alternate presentation. Its wording has also been clarified: "Instructions provided for understanding and operating content do not rely on shape, size, visual location, or orientation of components."

Comments on Guideline 1.4 (Make it easier for people with disabilities to see and hear content including separating foreground from background)

1.4.1 [was 1.3.2] Use of Color

There was some confusion about this success criterion because it only addresses the visual use of color. There was a request that color also be programmatically determined (e.g AT can access the information). No change was needed for this because SC 1.3.1 already requires that information conveyed through color must be programmatically determined and thus addresses the needs of those accessing content via assistive technology like screen readers. This success criterion (1.4.1) addresses the needs of users with visual disabilities such as low vision or color blindness who are viewing the content visually.

1.4.2 Audio Turnoff

This success criterion has been changed to apply to any audio that plays automatically, not just to background audio.

Because automatic audio can interfere with assistive technology, this success criterion has been moved to Level A.

1.4.3 [was 1.4.1] Contrast (Minimum)

Some commenters felt that this success criterion should be raised to Level A. Because Level A attempts to put the fewest possible limitations on presentation, and because assistive technology will be able to present the text or text equivalents of this content to the user, the working group felt that this success criterion should stay at Level AA. Additional research on contrast has been incorporated into this success criterion.

1.4.4 [NEW ] Resize text

This is a new success criterion that was added based on additional input from commenters regarding the importance of supporting resized text. It reads: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality.

1.4.5 [was 1.4.3] Contrast (Enhanced)

Some commenters felt that this success criterion should be raised to Level AA. Because of the additional limitations it puts on presentation, the working group felt that this success criterion should stay at Level AAA.

The contrast equations were clarified and the level of contrast required changed based on input and further work.

There was a request for the research behind the recommendations. Additional information regarding contrast research has been incorporated into the Understanding 1.4.5. document for this success criterion.

1.4.6 [was 1.4.4] Low or No Background Audio

There was a request to move this provision up a level. Because of the additional limitations it puts on presentation, the working group felt that this success criterion should stay at Level AAA. 1.4.2 was however moved up to level A.

1.4.7 [NEW ] Resize and Wrap

This is a new success criterion that was added based on additional input from commenters regarding the importance of supporting resized text. It reads: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally.

Comments on Guideline 2.1 (Make all functionality available from a keyboard)

2.1.1 Keyboard

There has been some confusion about what it means to support a keyboard user interface. The definition of keyboard interface was reworded to clarify that it applies even if the underlying device does not have a keyboard, e.g., if a touchscreen PDA has a keyboard interface and a connection for external keyboards, that would be covered. There was also confusion over the phrases "a non-time-dependent manner" and "analog, time-dependent input". The success criterion was reworded to make it clearer, getting rid of these terms and the technical language they used.

Comments on Guideline 2.2 (Provide users with disabilities enough time to read and use content)

2.2.1 Timing

There was confusion about WCAG's use of the terms "time-out" and "time limit". We now use "time limit" consistently throughout.

There was a concern that the success criterion sounded like it applied to user agents as well as content. The success criterion has been changed to clarify that it was intended that only time limits set by the content are in scope.

The working group acknowledges that 20 seconds, or any other limit, may not be enough for all users to react in all circumstances but felt that 20 seconds was a reasonable amount of time to require based on clinical input. The Understanding 2.2.1 document for SC 2.2.1 provides more information about why the particular limits (10 times the default, 20 seconds) in this success criterion were chosen.

The Working Group views automatic updates, which happen after a set amount of time or on a periodic basis, to be time limits and intended that case to be covered by this success criterion. This may not have been clear so we have added the following content to the Understanding 2.2.1 document: "Any process that happens without user initiation after a set time or on a periodic basis is a time limits. This includes partial or full updates of or changes to content, or expiry of a window of opportunity for a user to react to a request for input."

2.2.3 Pausing

This success criterion has been modified to allow moving content that is pure decoration to simply be stopped without requiring a means to restart it: "Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user."

Automatically scrolling text is an example of functionality that must satisfy this success criterion. There must be a way to pause the text to give the person time to read and understand it.

2.2.6 Re-authenticating

The suggestion was made to move this up to a higher level. This success criterion was kept at Level AAA because there are reasons, such as financial security or personal information where this cannot be done because it is against regulations to preserve any of this information once a session expires or is terminated. So it cannot be implemented on all Web pages.

Comments on Guideline 2.3 (Do not create content that is known to cause seizures)

There was a request for clarification of the difference between blinking and flashing. We have made the following changes to clarify the differences:

The following note was added to the definition of "blink":

Note: The slower blink is in contrast with flashing, which refers to rapid changes in brightness which can cause seizures. See general flash threshold and red flash threshold.

Flashing can be caused by the display, the computer rendering the image or by the content being rendered. The author has no control of the first two. They can be addressed by the design and speed of the display and computer. The intent of this criterion is to ensure that flicker that violates the flash thresholds is not caused by the content itself. For example, the content could contain a video clip or animated image of a series of strobe flashes or close-ups of rapid fire explosions.

2.3.1 Three Flashes or Below Threshold

This provision was reworded to make its derivation clearer and to allow application across broader conditions. The constraints of this success criterion are based on the existing seizure disorder research and the broadcast industry guidelines in place in several countries. It is primarily based on the work of Jeavons and Harding and on the guidelines developed in UK and used elsewhere. References to the research are available from the resource links provided in the Understanding and the techniques documents.

Comments on Guideline 2.4 (Provide ways to help users with disabilities navigate, find content and determine where they are)

The working group added a new success criterion at Level AAA: "Where content is organized into sections, the sections are indicated with headings."

SC 1.3.1 requires that headings be programmatically determined. However, because of the importance of headings to navigation, we have added discussion to Understanding 2.4, drawing attention to SC 1.3.1 and the role of headings in navigation.

2.4.1 Bypass Blocks

Providing visible skip navigation links was considered a difficult requirement for Level A because of the potential for visual clutter making content harder to understand. However, the Working Group recognizes the importance of visible skip navigation for switch users, people using techniques that generate keyboard strokes slowly and others. A note has been added which says:

NOTE: When possible, a visible link is preferred over a hidden link. Visible links are necessary for those navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.

2.4.2 [was 2.4.3] Page Titled

We added "descriptive" to this success criterion and moved it to Level A.

The success criterion does not require that titles be unique because the working group is concerned that requiring uniqueness will lead to titles that are not as descriptive and usable. It may be very difficult to create titles that are descriptive, unique, and reasonably short. For example, a Web unit that generates titles dynamically based on its content might need to include part of the dynamic content in the title to ensure that it was unique. We are also concerned that authors may make titles unique mechanically, such as by including a unique number in the title that is unrelated to the content. For these reasons, although we encourage unique titles in the techniques for this success criterion, we are not including uniqueness in the success criterion itself.

2.4.3 [was 2.4.6] Focus Order

This success criterion has been moved to Level A and reworded for clarity "If a Web page may be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation."

2.4.4 Link Purpose (Context)

There has been confusion about the difference between this success criterion, "The purpose of each link can be determined from the link text and its programmatically determined link context." and the Level AAA success criterion, "The purpose of each link can be identified from the link text." We have changed SC 2.4.4 to make it clearer that it may be necessary for the user to request context information to understand the purpose of the link, e.g., title attributes, the associated table headings when the link is contained within a table cell, or the enclosing sentence. At Level AAA, the purpose of the link can be understood from the link text independent of its context. We have also changed the language to clarify that the text describing the purpose, and not the purpose itself, is what can be programmatically determined.

This success criterion has been moved to Level A because without it, it requires significantly greater effort (and keystrokes) for assistive technology users to determine link context. This item may be moved back to Level AA if it is determined that it causes pages to fail at Level A that are, in fact, accessible.

There was concern that the title attribute is not well supported by assistive technology and its use should not be a sufficient technique for this success criterion. We have added more user agent and assistive technology limitations in their support for the title attribute. The working group would like to see better user agent support for the title attribute, but feels that this should remain a sufficient technique while efforts to improve user agent and assistive technology support are made.

This success criterion allows for link text such as "Click here" and "more" as long as the purpose of the link can still be determined from programmatically determined context such as the enclosing sentence, paragraph, or list item. However, the Intent section of Understanding SC 2.4.4 has been changed to encourage authors to make the link text as meaningful as possible.

2.4.5 [was 2.4.2] Multiple Ways to navigate (was moved but not changed)

2.4.6 [was 2.4.5] Labels Descriptive

This success criterion was moved to Level AA. It addresses descriptive headings and labels, which may need to be understood in context. While headings may not have sufficient descriptive power in isolation, when viewed in the context of a structured document, they do have sufficient descriptive power.

2.4.7 Location

There were concerns about how to tell which set of Web pages this success criterion applied to. The definition of "set of Web pages" clarifies that the Web pages must have a specific relationship to one another and have been created as a body of work by an author, group, or organization.

2.4.8 Link Purpose (Link Text)

This success criterion is at Level AAA because of the potential usability problems introduced by requiring that the link text alone be sufficient. For instance, in a table of links, repeating the table header information in each cell makes the table much more difficult to use.

2.4.9 [NEW] Section Headings

This is a new success criterion that was added based on additional input from commenters regarding the importance of providing headings for different sections in a documents to faciliatate understanding. "2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings."

Comments on Guideline 3.1 (Make text content readable and understandable )

The working group has had difficulty developing success criteria for Principle 3 that are testable, human-language independent and that apply to all web pages, and that address the needs of people with different cognitive, language, and learning disabilities. We have added some best practices for cognitive, learning, and language disabilities as advisory techniques, since advisory techniques do not need to be testable or universal.

A number of suggestions were made that WCAG2 should add WCAG 1's Checkpoint 14.1 (Use the Clearest and simplest language appropriate for a site's content). The working group was unable to come up with a testable equivalent of WCAG1 14.1. We added an advisory technique to Guideline 3.1 and SC 3.1.5 that reads, "Using the clearest and simplest language appropriate for the content."

There were requests to combine SC 3.1.1 and SC 3.1.2, to move them up and to move them down. After much discussion, the consensus of the working group was to leave them at their current levels.

There were requests for success criteria on the location of labels for form fields. SC 1.3.1 requires that the relationship between a form field and its label be programmatically determined. However, since visual positioning can be important, especially for pages translated into other languages, we added an advisory technique to Success Criterion 1.3.1 and Guideline 3.2 titled "Positioning labels to maximize predictability of relationships."

3.1.1 Language of Page

We have clarified our use of "primary language" to be the default human language of the Web page. We included a reference to Internationalization Best Practices: Specifying Language in XHTML & HTML Content, and added a discussion of multilingual documents to the Intent section. Authors of multilingual documents are encouraged to meet SC 3.1.2, even if they are only claiming Level A conformance.

3.1.2 Language of Parts

Based on comments from the Internationalization Working Group, we have determined that text direction is not an accessibility issue unless it affects the meaningful sequence of text. This success criterion no longer requires that the direction of text be identified.

A number of comments were made asking when a word taken from one language has become part of another language. We added the following clarification: "Frequently, when the natural language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words are not included in this success criterion."

3.1.3 Unusual Words

SC 3.1.5 (now 3.1.3) is a Level AAA success criterion because it cannot be applied to all web pages. Content in some fields would become extremely difficult to read if all specialized vocabulary had to be defined either inline or via linking, even when the terms are well known in their respective fields. Jargon is typically a barrier for people who are not in the field where the jargon is used - e.g., the jargon of literary history may be problematic for chemical engineers but not for literary historians. Practitioners in a field are likely to provide definitions when introducing new terms or re-defining existing ones - even when they are writing for their professional peers. We have added information to the Intent section, encouraging authors to satisfy this success criterion even for lower levels of conformance for specialized information intended for non-specialist readers.

3.1.5 Reading Level

Even specific target audiences may contain people who can understand the subject matter but have disabilities that make it difficult to deal with complex text. While reducing the complexity of the text will help all such people, the success criterion only requires additional supplementary material that will assist some of those users.

The success criterion relies on the UN definition because it takes into account cultural differences in education systems. The Working Group did not want to base the success criterion on a particular country's educational system. The UN definition provides a framework for translating the purpose of the success criterion into the specifics for different countries.

Comments on Guideline 3.2 (Make Web pages appear and operate in predictable ways)

3.2.1 On Focus

A change in content that occurs because the user has requested a different view of the current content is not considered a change of context. However, it is necessary for assistive technology to be informed of the change. SC 4.1.2 now includes state and properties among the information that must be programmatically determined and for which notifications of changes must be available to assistive technology.

3.2.2 On Input

The exception for moving to the next user interface control in the tab order was removed. This success criterion now reads, "Changing the setting of any user interface component does not automatically cause a change of context unless the authored unit contains instructions before the component that describe the behavior." Note that auto-advance-focus can be an important accessibility aid for the mobility impaired, so it is still permitted, but only if the user has been warned about it as they would be if configured their user agent for this behavior.

User interfaces that allow the user to select different views of the same data cause changes in content, but not changes in context.

3.2.3 Consistent Navigation

This success criterion applies to the logical order and default presentation of the content. This success criterion does not prohibit choices in adaptive interfaces; enabling adaptive interfaces and alternate presentations is a goal of WCAG2. However, the user still needs to initiate the change in order, even if the change is initiated by global actions such as selecting preferences in a user agent or using a user agent with adaptive behavior.

3.2.4 Consistent ID

Comments on Guideline 3.3 (Help users avoid and correct mistakes)

This guideline was moved from Principle 2 to Principle 3 since it addressed issues of whether or not the user could understand the content, rather than whether they could activate it.

To help users avoid errors, we added a new success criterion at Level AA, "Information or cues are provided when content requires user input".

These success criteria do not prevent the use of programmatic information which can be used by AT or the user agent to identify and provide error information. There must be some mechanism to provide the error information to the user. Even when provided by the AT or user agent rather than the content author, the information can still be conveyed in some form of text to meet this requirement.

We added a new Level AAA success criterion, similar to SC 3.3.3 but without exclusions for certain classes of forms.

The old 2.5.1 success criteria now look like

3.3.3 Error Prevention

The first bullet has been updated to require that transactions, rather than actions, are reversible.

The third bullet has been rewritten to make it clear that the user has the opportunity to review the results being submitted before confirming the transaction: "A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction."

3.3.4 [NEW] Labels or Instructions

This is a new success criterion that was added based on additional input from commenters regarding the importance of providing clear labels or instructions when content requires user input. "3.3.4 [NEW] Labels or Instructions: Labels or instructions are provided when content requires user input. (Level AA)".

3.3.5 Help

The success criterion does not prevent use of Accessible Rich Internet Application Specifications or other technologies to add information that will allow user agents or assistive technologies to provide context-sensitive help. If additional information is programmatically provided in the markup and testing demonstrates that context-sensitive help is provided to the user via the user agent or assistive technology, this success criterion has been satisfied.

Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality. In most cases, context-sensitive help should not be placed in the form itself, but should instead be available to users when they request it (e.g. by linking to a separate help file).

While context-sensitive help is useful and sometimes necessary for people with disabilities, the type and level of detail for context-sensitive help varies greatly depending upon the type and functions of the site. For this reason, the working group felt this should remain at Level AAA.

3.3.6 [NEW] Error Prevention (All)

This is a new version of a success criterion that exists at level AA but has limitations on it. It was added in level AAA without those limitations to emphasize its importance overall. The "unlimited" version was not possible at level AA because it would be too broad to apply to all content. For example, these techniques would not be appropriate for the action of logging out of a secure banking site or selecting a link that closes a window.

Comments on Guideline 4.1 (Maximize compatibility with current and future user agents, including assistive technologies)

The working group looked at the issue of validity carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.

The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our number one technique listed for conforming to SC 4.1.1.

4.1.1 Parsing

To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:

Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quote are not complete.

4.1.2 Name, Role, Value

The wording of this success criterion has been changed to indicate that it is only user interface components with which users interact that are covered by the requirement, and states and properties must also be programmatically determined: "For all interactive user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically determined and programmatically set; and notification of changes to these items is available to user agents, including assistive technologies."