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.

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.

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)

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:

Failure of 1.1.1 due to omitting the alt attribute on img, area elements
and input elements of type "image"

Failure of 1.1.1
due to providing long description for non-text content that does not
serve the same purpose or does not present the same information

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.

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.

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.

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.

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.

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

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.

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.

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)

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.

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.

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.

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.

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.

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.

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.

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)

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.

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)

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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.

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

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.

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.

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.

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.

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.

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.1 Error Identification: If an input error is automatically
detected, the item that is in error is identified and described to the user
in text. (Level A)

3.3.3 Error Suggestion: If an input error is detected and suggestions
for correction are known, then the suggestions are provided to the user, unless
it would jeopardize the security or purpose of the content. (Level AA)

3.3.4 Error Prevention (Legal, Financial, Data): For forms that
cause legal commitments or financial transactions to occur, that modify or
delete user-controllable data in data storage systems, or that submit test
responses, at least one of the following is true:

Reversible: Transactions are reversible.

Checked: Submitted data is checked for input errors before going on
to the next step in the process.

Confirmed: A mechanism is available for reviewing, confirming, and correcting
information before finalizing the transaction.

3.3.5 Help: Context-sensitive help is available. (Level AAA)

3.3.6 Error Prevention (All): For forms that
require the user to submit information, at least one of the following is true:
(Level AAA)

Reversible: Transactions are reversible.

Checked: Submitted data is checked for input errors before going on
to the next step in the process.

Confirmed: A mechanism is available for reviewing, confirming, and correcting
information before finalizing the transaction.

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

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

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.

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.

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