W3C logoWeb Accessibility Initiative (WAI) logo

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

Issues and Changes to WCAG 2.0: A Summary of Issues, Revisions and Rationales on WCAG 2.0 Working Drafts

Overview

The Web Content Accessibility Guidelines (WCAG) Working Group received many substantive comments during development of WCAG 2.0 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/WCAG20/. Additional information on updates and a link to the latest Call for Review 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 of April 2006, 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 from earlier drafts 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 from the previous last call document. 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.

We have provided mnemonic handles for guidelines as well as success criteria, to make it easier to understand and remember references to the elements of the guidelines. Success criteria are followed by links to corresponding sections of both the Quick Reference (How To Meet x.x.x) and the Understanding document (Understanding x.x.x).

Quick Reference

The 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, the Understanding WCAG 2.0 document has been broken into a collection of small (1 to 4 page) documents, one for each guideline and success criterion. A single file version of Understanding WCAG 2.0 is also available. (The single file version can also be found in a link at the bottom of each of the individual documents.)

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. The greater length of the Techniques document 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.

Each technique has been separated into a separate document to facilitate its access and use. A single file version that lists all techniques and failures is also available. (The single file version can also be found in a link at the bottom of each of the techniques.)

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

Extensive effort has been made to making the guidelines easier to read and understand than previous drafts. 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 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 earlier drafts 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.

What was Baseline is now "Accessibility Supported"

In 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 comments the working group received, 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.)

Cognitive, Language, and Learning Disabilities

A concern of a number of commenters on earlier drafts 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). Four new success criteria were added as well as 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.

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.

Accessibility Supported Technologies

More discussion has been added to Understanding Conformance about what it means for a technology or technology feature to be accessibility supported. Accessibility support is determined by the capabilities of user agents and assistive technology used for the technology, and the status of a technology will depend on the platforms, human languages, and availability of user agents. An appendix describes the information that should be contained in documentation of accessibility support.

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 allows pages that do not conform to be included in a set of pages that conform, as long as all of the information on a non-conforming page is also on a page that does conform and that the page can be reached via an accessibility-supported mechanism. A section on Understanding Conforming Alternate Versions discusses why WCAG permits alternate versions of web pages to be included in conformance claims, and the types of techniques that can be used to let users locate the conforming version from non-conforming alternate versions.

Non-interference Conformance Requirement

This conformance requirement describes circumstances under which a conforming web page can include content that is not accessibility supported. It also identifies four success criteria that must be satisfied by all content on a web page, whether or not that content is relied upon to satisfy other WCAG success criteria.

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.

An exception was added for media alternatives to text, which do not require an additional text alternative.

Several new failures were also added:

Request for 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 synchronized media)

A request to require audio descriptions for live synchronized media was not accepted since it is almost impossible to do unless the live synchronized media is scripted.

Many concerns were expressed about the difficulty of providing captions and/or audio descriptions for synchronized media, and this might cause pages containing synchronized media to be excluded from conformance claims. The working group recognizes that this is a serious concern. However, synchronized media 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 media 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 text alternative for synchronized media 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 synchronized media (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.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 synchronized media 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 synchronized media, 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 synchronized media 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 simpler layout) 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 (old) 1.3.4 overlapped. The working group agrees. SC 1.3.1 and the former SC 1.3.4 have been combined: "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." 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.

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 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 Sensory Characteristics

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, orientation, or sound."

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 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. This success criterion was reworded to clarify its meaning.

1.4.2 Audio Control

This success criterion has been changed to apply to any audio that plays automatically, not just to background audio. It was also clarified that it must be possible to set audio volume of audio that plays automatically separately from the overall system volume.

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

1.4.3 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 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: Text (but not images of text) can be resized without assistive technology up to 200 percent without loss of content or functionality.

1.4.5 Images of Text (Limited)

This is a new success criterion that requires that text rather than images of text be used whenever possible in the technology in use to enable customization of presentation, unless the image format supports such customizations.

1.4.6 Contrast (Enhanced)

Some commenters felt that this success criterion should be raised to Level AA and that the provision at Level AA should be move to Level A. As discussed above, the working group felt that these success criteria should stay where they were.

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.7 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.8 Visual Presentation

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.

1.4.9 Images of Text (Essential)

This new success criterion requires that text rather than images of text be used for all but decorative or essential purposes.

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.

2.1.2 No Keyboard Trap

This is a new success criterion that requires that content, even if it is not relied upon for WCAG conformance, not trap the keyboard focus such that it cannot be moved away from that component using the keyboard alone. This was formerly a conformance requirement and has been changed into a success criterion in order to be more clear. The conformance requirement has been changed simply to refer to this success criterion.

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.

An exception was added to the requirement to allow the user to adjust the time limit if the time limit is longer than 20 hours to separate time limits on work from session closeouts as a part of maintenance (note that much shorter time limits for session closeout or maintenance are possible with warnings and opportunities for extension, etc.). A note was added to clarify the relationship between automatic timed events covered in this success criterion and events in response to user action covered in SC 3.2.1 (On Focus).

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.2 Pausing

Two success criteria from previous drafts have been combined into a single success criterion, addressing both blinking and 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 in a way 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:

We added a definition for flash and clarified the difference between flash and blink both in the definitions and (in longer form) in the understanding document.

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. A note has been added to clarify that this success criterion and Success Criterion 2.3.2 must be satisfied by the entire web page, not just the content that is relied upon for WCAG conformance.

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 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 Focus Order

This success criterion has been moved to Level A and reworded for clarity "If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."

2.4.4 Link Purpose (Context)

There has been confusion about the difference between this success criterion and the Level AAA success criterion (Link Purpose (Link Only)). 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.

An exception has been added to this success criteria for links whose purpose would not be clear to any user. These do not need to have extra clarification available as an accessibility requirement.

In the Understanding document, we have clarified what constitutes programmatically determined link context.

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.6 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 Focus Visible

This new Level AA success criterion ensures that there is a visible indication of the location of the keyboard focus. Although this is generally user agent functionality, in some technologies it is the responsibility of the author.

2.4.8 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. This success criterion has been moved to Level AAA.

2.4.9 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. The wording of the success criterion has been changed so that a mechanism is available to allow the purpose of the link to be identified from the link text alone. An exception has been added to this success criteria for links whose purpose would not be clear to any user. These do not need to have extra clarification available as an accessibility requirement.

A failure has been added to address the use of links such as “click here” or “more”.

2.4.10 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 facilitate understanding. "2.4.9 Section Headings: Section headings are used to organize the content."

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.

Exceptions for certain kinds of words (proper names, technical terms, and words of indeterminate language) were added to the success criterion.

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 to the Understanding document: "Frequently, when the human 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 should be considered part of the language of the surrounding text unless it is clear that a change of language was intended."

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.5 Change on Request

An option was added to this success criterion to provide a mechanism to turn off automatic changes of context.

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 success criteria now look like

3.3.2 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.2  Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)".

3.3.3 Error Prevention

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

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

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 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."