The working group received
many substantive comments on the Last Call draft have revised the guidelines
and accompanying documents substantially to address and incorporate
them. A new public working draft can be found at http://www.w3.org/TR/2007/WD
This document provides an overview of the changes made and the rationale for changes or for not making suggested changes.
You will find that extensive effort was made to simplify the language, shorten WCAG 2.0, and make it easier to use. It still is a technical document and introduces a couple new concepts needed to deal with access to new and evolving technologies. But many of the special terms have been removed and replaced with simpler explanations and terms. Some new success criteria were also added and the conformance level for others was changed – particularly in the cognitive, language and learning areas. Finally the term “Baseline” was removed and focus is now on Web technologies that are “Accessibility Supported”.
Reviewers of the new draft are encouraged you to check the relevant sections of this document if you have questions about the new draft. You may find the answers here.
The following links are provided to make it easier to jump to the sections of this document you may be interested in.
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
1.2 Provide synchronized alternatives for multimedia
1.3 Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure
1.4 Make it easier for people with disabilities to see and hear content including separating foreground from background
2.1 Make all functionality available from a keyboard
2.2 Provide users with disabilities enough time to read and use content
2.3 Do not create content that is known to cause seizures
2.4 Provide ways to help users with disabilities navigate, find content and determine where they are
3.1 Make text content readable and understandable
3.2 Make Web pages appear and operate in predictable ways
3.3 Help users avoid and correct mistakes that do occur
4.1 Maximize compatibility with current and future user agents, including assistive technologies
The length of WCAG 2.0 has been substantially reduced. Information from the introduction has been moved to a separate Introduction to WCAG 2.0 document and the Understanding WCAG 2.0 document. Some of the longer appendices have been removed. The WCAG 1.0 to 2.0 mapping is now a separate document that is being revised and made more useful to developers. Based on comments received, conformance section was moved from the front to a location after provisions to make it easier to get to the provisions. The working group is also considering moving more information out of the Introduction in later drafts.
In addition, a new Quick Reference to WCAG 2.0 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 all of 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.
The Understanding WCAG 2.0 document continues to be as long as a book. This is because it is in many ways a reference book for Understanding WCAG 2.0. Unlike WCAG 1.0 where questions arose later as to what some guidelines meant and what was needed to meet them, the working group set out to create a report that would accompany WCAG 2.0 and provide information on the intent of each guideline and success criterion as well as what was sufficient to meet it, advisory techniques, examples etc. These are all compiled in the Understanding WCAG 2.0 document. To make it easier to use in the future, the working group is considering breaking the Understanding WCAG 2.0 document into a collection of small documents, one for each guideline and success criterion. (Right now, when you click on a link to Understanding WCAG 2.0 the first time it can take a long time for the whole document to download before it will jump to the referenced section in the document).
This document is again very large. In fact it is larger than last time since techniques have been added.
Again, this document is large because of the number of techniques the working group has documented. The individual techniques themselves are quite short, ranging from a page to a few pages each. Again, the working group tried to do a better job than was done for WCAG 1.0 in documenting each of the techniques with intent, user agent notes, examples and a way to test to see if you completed the technique (if the technique is listed as a sufficient technique for meeting a success criterion.)
The working group is planning on breaking this document up into smaller collections and is also considering making each technique a 1-3 page separate document in a collection to facilitate their access and use.
There are many additional techniques to document and the working group is very interested in soliciting contributions of new techniques or help in documenting any of the techniques that are currently listed in Understanding WCAG 2.0 that have not yet been written up.
In the previous draft the working group focused too much on technical aspects and did not focus sufficiently on making the guidelines easy to read and understand for those who would be using the guidelines. Extensive effort has been made to rework the guidelines 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 couple of new terms to deal with the accessibility issue being presented by new Web technologies. These were kept to a minimum however and most of the new terms that appeared in the last draft have been replaced with simpler terminology. Wherever possible, plain language was used to replace new terms. The terms authored units, web units, authored component, baseline, and parsed unambiguously have all disappeared.
The Quick Reference document has also simplified the use of WCAG 2.0. Users 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.
Comments are sought on which aspects of the new design are most helpful as well as additional input on ways to make WCAG 2.0 easier to understand and use.
In the previous drafts the working group had introduced and developed the concept of Baseline to address the fact that technologies were constantly changing and to eliminate the “until user agent” clauses that had caused problems in WCAG 1.0. From the comments it was clear that this term was widely misunderstood and/or incomprehensible. The working group has therefore reworked the issue and gone to a more plain language way of addressing the problem. The concept of ‘accessibility-supported’ is now used to describe technologies that work with assistive technologies and that have user agents that work with them and assistive technologies.
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 not to prevent the introduction of new Web technologies, but to not allow such technologies to be used to meet WCAG 2.0 success criteria if they do not work with assistive technologies and the accessibility features of browsers and other user agents.
Authors who don't know which technologies or which aspects and features of a technology have support from assistive technologies should consult documented lists of technologies that are known to have accessibility support. Such lists can make it easier than it is today for an author to identify technologies or features of different technologies that are supported by assistive technologies and can be used to meet the success criteria that require assistive technology support (i.e. require that content can be programmatically determined.)
The W3C WAI will be compiling existing information on its technologies. It is expected that other organizations will compile such information for their technologies. There will undoubtedly be others who create documented lists as well.
A concern of a number of commenters on the last draft was the coverage of people with cognitive disabilities in WCAG 2.0. Some felt that not enough was included that covered language, learning, and cognitive 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 language, learning, and cognitive 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 the working group met with representative and reviewed the full document to find ways to better address these groups (people with different language, learning, and cognitive disabilities). In some cases success criteria were moved up in conformance level(s). 3 new success criteria were added as well as adding a number 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 language, learning, and cognitive disabilities, was added to the introduction of the documents.
In the new draft (of there are XX SC (of ) that specifically address language, learning, and cognitive disability issues and XX that support assistive technologies for people with language, learning, and cognitive disabilities (such as reading text aloud or high lighting it as read). These latter success criteria will also support new assistive technologies in the future for translating language into simpler forms of language.
A number of comments advocated
that conformance to WCAG 2.0 require that content validate or be used
strictly according 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.
That being said the working group recommends it and it is our #1 technique listed for conforming to SC 4.1.1.
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.
Some comments said that the description of the three levels was confusing. They have been rewritten to address this. The entire conformance section was also reworked to address a wide range of comments including those around baseline, user contributed content, aggregation etc.
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 seemed to move beyond defining and accessibility standard and into the realm of regulators by describing what should or should not conform.
See also the notes on the Conformance Section at the end of this document
There was a concern by some commenter that the language used in the draft encouraged scoping tough material out of the conformance claim. This language has been removed. While there is nothing that any standard can do to prevent people from not applying the standard to everything they do (this is an issue only regulators could address) WCAG 2.0 does make it clear that any content that is within conformance claim (that is, anything they are claiming conforms) fully meets WCAG 2.0 or has an alternative version that does.
WCAG 2.0 does currently allow
pages that do not conform to be included in a set of pages that conform
as long as all of the information on the page that does not conform
is also on a page that does conform. The working group has been wrestling
with a couple of questions around this issue and is seeking input and
techniques that could make this work better. For a fuller
presentation of the issue and the techniques documented today can be
found at http://www.w3.org/WAI/GL/2007
No. CSS layouts
are not prohibited. Source order must match presentation order only
when it would change the meaning of the content to present it in a different
order.
Issues by Guideline (Including issue, resolution and rationale)
One commenter was concerned that the wording was not clear in that content could meet multiple situations in the list. Another commented that the CAPTCHA provision was hard to understand and was ambiguous in one respect. . The wording of this success criterion was modified to make it easier to understand and to clarify what is required when content satisfies more than one situation.
Several new failures were also added:
There was a request for sign language equivalent 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 for audio descriptions of live multimedia to be required was not accepted since it is almost impossible to do unless the live multimedia is scripted.
Many concerns were expressed about the difficulty of providing captions and/or audio descriptions for multimedia, and this might cause pages containing multimedia to be excluded from conformance claims. The working group recognizes that this is a serious concern. However, multimedia will not be accessible to people with hearing or vision disabilities without these accommodations. The ability to provide a full text alternative for audio description is however sufficient.
There was a concern regarding multimedia alternatives to text that are provided for people with cognitive disabilities would need to be captioned. A clause was added to make it clear that if they are alternatives to text on the page, they did not need to be captioned. However, captions are still recommended for them.
Concerns were expressed that a full multimedia text alternative is not an adequate alternative to audio description, and should not be permitted as an alternative to audio descriptions in SC 1.2.2. A full transcript provides all the information from the multimedia (visual and auditory), and that has been our measure for an accessible alternative. It does not provide the same experience, but text alternatives to graphics do not provide the same experience either. In addition, audio-description does not always provide all of the information that is presented visually. For example Audio description may not provide all of the information in a training video which is almost all speaking over top of the visuals.
The working group clarified that if the audio track provides full information about a video then no Audio Description would be necessary.
The working group clarified that the reason sign language is needed in addition to captions is that it enables people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. The user will not have control over the speed of the captions in multimedia, and may not be able to read the text quickly enough.
The question was raised as to why Full text alternatives for multimedia are not required at Level A. This was not done because audio descriptions are usually more effective than text alternatives. This is due to the fact that they contain much additional rich audio information from the sounds 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.
This guideline has been reworded to avoid confusion between "relationships" and "structure".
A commenter suggested that 1.3.1 and 1.3.4 overlapped. The working group agrees. SC 1.3.1 and the former SC 1.3.4 have been combined: "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." This wording ensures that it is the meaning conveyed by the presentation that must be programmatically determined, and allows the author to indicate the meaning in text if it is not feasible to do so programmatically.
This success criterion covers a large number of techniques related to the way that information is marked up. The user agent notes were updated for many of these techniques to record the known limitations of browser and user agents in supporting mark-up that represents these relationships. Additional common failures were also added.
There is now and explicit recommendation that CSS, rather than layout tables, be used in all techniques related to tables.
It is explained that there are no technology-specific success criteria in the normative guidelines because this would make them impossible to satisfy with other technologies, e.g., if the guidelines contain HTML-specific success criteria, then it will be impossible to meet them using a technology like PDF or perhaps even other markup languages. SC 1.3.1 is a particularly difficult success criterion to discuss in technology neutral language.
Although the association of labels and form elements was already covered by this success criterion and by SC 4.1.2, commenters noted that it was difficult for users to understand. A failure and an advisory technique were added to SC 1.3.1 to make this more obvious.
This success criterion also requires that content that visually conveys that it is a heading or subheading can be programmatically determined to be a heading. However, it does not require that the content contain headings, only that they be identifiable by user agents, including assistive technology, if they are used.
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, or orientation of components."
There was some confusion about this success criterion because it only addresses the visual use of color. SC 1.3.1 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.3.2) addresses the needs of users with visual disabilities such as low vision or color blindness who are viewing the content visually.
This success criterion has been change to apply to any audio that plays automatically, not just to background audio.
Because automatic audio can interfere with assistive technology, this success criterion has been move 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 new success criterion that was added to address suggestions from commenters regarding the importance of supporting resized content. 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.
Some commenters felt that this success criterion should be raised to Level AA. Because of the additional limitations it puts on presentation, the working group felt that this success criterion should stay at Level AAA.
The contrast equations were clarified and the level of contrast required changed based on input and further work.
There was a request for the research behind the recommendations. Additional information regarding contrast research has been incorporated into the Understanding 1.4.5. document for this success criterion.
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 new success criterion that was added to address suggestions 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..
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.
There was confusion about WCAG's use of the terms "time-out" and "time limit". We now use "time limit" consistently throughout.
There was a concern that the success criterion sounded like it applied to user agents as well as content. The success criterion has been changed to clarify that it was intended that only time limits set by the content are in scope.
The working group acknowledges that 20 seconds, or any other limit, may not be enough for all users to react in all circumstances but felt that 20 seconds was a reasonable amount of time to require based on clinical input. The Understanding 2.2.1 document for SC 2.2.1 provides more information about why the particular limits (10 times the default, 20 seconds) in this success criterion were chosen.
The Working Group views automatic updates, which happen after a set amount of time or on a periodic basis, to be time-outs 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-out. 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."
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.
There was a request for clarification of the difference between blinking and flashing. We have made the following changes to clarify the differences:
The following note was added to the definition of "blink": Note: The slower blink is in contrast with flashing, which refers to rapid changes in brightness which can cause seizures. See general flash threshold and red flash threshold.
"Flashing can be caused by the display, the computer rendering the image or by the content being rendered. The author has no control of the first two. They can be addressed by the design and speed of the display and computer. The intent of this criterion is to ensure that flicker that violates the flash thresholds is not caused by the content itself. For example, the content could contain a video clip or animated image of a series of strobe flashes or close-ups of rapid fire explosions."
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.
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."
There has been confusion about the difference between this success criterion, "The purpose of each link can be determined from the link text and its programmatically determined link context." and the Level AAA success criterion, "The purpose of each link can be identified from the link text." We have changed SC 2.4.4 to make it clearer that it may be necessary for the user to request context information to understand the purpose of the link, e.g., title attributes, the associated table headings when the link is contained within a table cell, or the enclosing sentence. At Level AAA, the purpose of the link can be understood from the link text independent of its context. We have also changed the language to clarify that the text describing the purpose, and not the purpose itself, is what can be programmatically determined.
This success criterion has been moved to Level A because without it, it requires significantly greater effort (and keystrokes) for assistive technology users to determine link context. This item may be moved back to Level AA if it is determined that it causes pages to fail at Level A that are, in fact, accessible.
There was concern that the title attribute is not well supported by assistive technology and its use should not be a sufficient technique for this success criterion. We have added more user agent and assistive technology limitations in their support for the title attribute. The working group would like to see better user agent support for the title attribute, but feels that this should remain a sufficient technique while efforts to improve user agent and assistive technology support are made.
This success criterion allows for link text such as "Click here" and "more" as long as the purpose of the link can still be determined from programmatically determined context such as the enclosing sentence, paragraph, or list item. However, the Intent section of Understanding SC 2.4.4 has been changed to encourage authors to make the link text as meaningful as possible.
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 may be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation."
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.
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 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 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.
A number of comments were made asking when a word taken from one language has become part of another language. We added the following clarification: "Frequently, when the natural language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words are not included in this success criterion."
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.
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 first bullet has been updated to require that transactions, rather than actions, are reversible.
The third bullet has been rewritten to make it clear that the user has the opportunity to review the results being submitted before confirming the transaction: "A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction."
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.
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.
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.
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. "
We have completely rewritten the conformance section. Some of the 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.
We have clarified that having different levels of conformance does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability.
The meanings of the different levels has been written to it will be clearer why different success criteria occur at different levels.
Triple-A (AAA) conformance has been changed to require that all Level AAA success criteria be satisfied. 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.
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.
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.
(see discussions at front of this document on these two topics)