[contents] [checklist]

W3C

Web Content Accessibility Guidelines 2.0

W3C Working Draft 23 November 2005

This version:
http://www.w3.org/TR/2005/WD-WCAG20-20051123/
Latest version:
http://www.w3.org/TR/WCAG20/
Previous version:
http://www.w3.org/TR/2005/WD-WCAG20-20050630/
Editors:
Ben Caldwell, Trace R&D Center
Wendy Chisholm, W3C
John Slatin, University of Texas at Austin
Gregg Vanderheiden, Trace R&D Center

This document is also available in these non-normative formats:

Copyright © 2005  W3C ® ( MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of issues and recommendations for making Web content more accessible. This document contains principles, guidelines, success criteria, benefits, and examples that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies.

WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents is also available.

Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 (WCAG 1.0), published as a W3C Recommendation May 1999.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

The Web Content Accessibility Guidelines Working Group (WCAG WG) encourages feedback about this Working Draft. Since the 30 June 2005 WCAG 2.0 Working Draft, the WCAG WG has focused on addressing comments received on previous drafts and introducing a new format to make it easier to access support and explanatory information for each success criterion. This draft represents a significant reorganization of the WCAG document set (guidelines and support documents) and includes changes to success criterion as well as rationale and a listing of techniques deemed as sufficient for each success criterion. Does this new organization work for you? Does the new support information provide the information you need most? Are the success criterion at the right level? Is the success criteria wording accurate and understandable? Please refer to "Issue Tracking for WCAG 2.0 Working Draft" for a list of open issues related to this Working Draft. The "History of Changes to WCAG 2.0 Working Drafts" is also available.

Please send your comments by 21 December 2005 to public-comments-wcag20@w3.org. The archives for this list are publicly available. Archives of the WCAG WG mailing list discussions are also publicly available.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The WCAG WG intends to publish WCAG 2.0 as a W3C Recommendation. Until that time Web Content Accessibility Guidelines 1.0 (WCAG 1.0) is the stable, referenceable version. This Working Draft does not supercede WCAG 1.0.

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.

Introduction

You are reading the Web Content Accessibility Guidelines (WCAG) 2.0. This is one of several documents that define and explain the requirements for making Web-based information and applications accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies.

WCAG 2.0 covers a wide range of issues and recommendations for making Web content more accessible. In general, however, the guidelines do not include standard usability recommendations except where they have specific impact on accessibility.

WCAG 2.0 includes:

The Four Principles of Accessibility

The four principles of accessibility are as follows:

  1. Content must be perceivable to each user.

  2. User interface components in the content must be operable by each user.

  3. Content and controls must be understandable to each user.

  4. Content must be robust enough to work with current and future technologies.

These four principles lay the foundation necessary for anyone to access and use Web content. WCAG 2.0 offers information about how to increase the ability of people with disabilities to perceive, operate, and understand Web content. Under each principle there is a list of guidelines that address the principle. Under each guideline there are success criteria used to evaluate conformance to this standard for that guideline. The success criteria are written as statements that will be either true or false when specific Web content is tested against the success criteria. The success criteria are grouped into three levels of conformance each representing a higher level of accessibility for that guideline. (For more information about conformance, see the section titled Conformance , below.)

GB: I would like the wcag20 specification document to provide a definition of "accessibility", in addition to the 4 necessary conditions. For 2 reasons:
1) the necessary conditions are vague in what it is mean by "each user", "understandable", "robust enough to work"
2) a definition might be based on other parameters other than perceivability, operability, understandability and robustness. These parameters are useful to the designer and programmer of the web content, but their problem is that they cannot be easily measured and tested.
The definition of accessibility that I like the most is the one given in the book by Slatin and Rush: an accessibile website is a site where the effectiveness of disabled users is the same as that of non disabled users. "Effectiveness" means in general (wikipedia) the capability of, or success in, achieving a given goal. And more specifically it is given by the accuracy and completeness with which pre-determined users can reach pre-determined goals in pre-determined situations.

The benefits of referring to parameters like "effectiveness" is that they are related to user performance, and this is what really counts.

GB: then the definition of accessibility should be related to the 4 necessary conditions. Most probably the only thig that can be said is that satisfaction of the 4 principles is the best way to achieve an accessible website.
GB: also each success criterion could then be related to the accessibility definition. For example, is we accept the definition given above, the criterion 1.1.1 (For non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information. For multimedia, provide a text-alternative that identifies the multimedia.) could be further clarified by saying things like "text alternatives should provide information to support the same goals".

The principles, guidelines, and success criteria represent concepts that apply to all Web-based content. They address accessibility issues and needs, regardless of the technology used. They are not specific to HTML, XML, or any other technology. This approach makes it possible to apply WCAG 2.0 to a variety of situations and technologies, including those that do not yet exist.

The principles and guidelines give direction and guidance to Web authors. The success criteria are written as true/false statements so that they can be used in determining conformance. Only the success criteria are testable.

Success criteria should be interpreted in the context of the intention expressed in the guideline to which they belong. Likewise, each guideline should be understood in the context of the principle under which it appears.

Related Documents

In addition to WCAG 2.0 (this document) there are a number of related support documents that provide additional information and examples. These other documents are informative only and do not define conformance to WCAG 2.0. Only this document (WCAG 2.0) is normative. That is, only this document can be used for determining conformance to these guidelines. Readers should consult WCAG 2.0 in order to determine the exact wording of the guidelines and success criteria and for information about documenting conformance.

The other informative documents in this set are provided to help readers understand WCAG 2.0 and how to produce conforming content. These informative documents are written for different audiences, including but not limited to:

  • people who create Web content

  • developers who write code

  • policy makers

  • managers

  • GB: people involved in QA or accessibility reviewers

Currently, these informative documents include:

  • Essential Components of Web Accessibility - Explains how the Web Content Accessibility Guidelines work with the other WAI guidelines (User Agent Accessibility Guidelines, and the Authoring Tool Accessibility Guidelines) and with assistive technologies to provide access to the Web by people with disabilities

  • Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents - Provides an overview of WCAG 2.0 and its various informative support documents.

  • Understanding WCAG 2.0 - Provides information about each success criterion including; its intent, key terms needed to understand it, names of and links to techniques that the working group feels are sufficient to meet the success criterion, examples and benefits of the success criterion. The "How to meet SC x.x.x" links in WCAG 2.0 link to the relevant section of the Understanding WCAG 2.0 document for that success criterion.

  • Technique and Tests documents - Provide specific details on different techniques including examples, code and tests where available. Note: For this review we only have a sample of the techniques formatted in the new form.

  • Application Notes - Provide detailed application information in different areas. For example the Application Note on Forms provides a collection of techniques, and strategies for creating accessible forms. It also summarizes the different success criteria that relate to forms. Note: No examples completed as of this release.

The Working Group plans to publish a number of other technology-specific Techniques documents and encourages development of techniques documents that show how to meet WCAG 2.0 using non-W3C technologies. Please visit the Working Group home page for a complete list of these and other informative documents related to WCAG 2.0.

Every attempt has been made to make WCAG 2.0 and the related documents listed above as readable and usable as possible while still retaining the accuracy and clarity needed in a technical specification. Sometimes technical terms are needed for clarity or testability. In these cases, the terms are defined in Appendix A Glossary . The Working Group recognizes that readers who are new to accessibility may need or want additional information. For these readers, the work of the Education and Outreach Working Group of the Web Accessibility Initiative is highly recommended. The articles called Getting Started: Making a Web Site Accessible and How People with Disabilities Use the Web are especially useful.

Conformance

Conformance means that Web content satisfies the success criteria defined in this document. This section outlines the conformance scheme used throughout this document.

The success criteria for each guideline are organized into three (3) levels of conformance.

  • Level 1 success criteria:

    1. Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.

    2. Can reasonably be applied to all Web resources.

  • Level 2 success criteria:

    1. Achieve an enhanced level of accessibility through one or both of the following:

      1. markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies

      2. the design of the content and presentation

    2. Can reasonably be applied to all Web resources.

  • Level 3 success criteria:

    1. Achieve additional accessibility enhancements for people with disabilities.

    2. Are not applicable to all Web resources.

Note: Some guidelines do not contain level 1 success criteria, and others do not contain level 2 success criteria.

This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. In WCAG 1.0, each checkpoint is assigned a "priority" according to its impact on accessibility for users. Thus Priority 3 checkpoints appear to be less important than Priority 1 checkpoints. The Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria grouped under Levels 1, 2, and 3 as described above.

The Working Group believes that all success criteria should be testable. Tests can be done by computer programs or by people who understand this document. When multiple people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained.

Technology assumptions and the "baseline"

WCAG 2.0 defines accessibility guidelines (goals) and success criteria (testable criteria for conformance at different levels of accessibility). The guidelines and success criteria are described in a technology independent way in order to allow conformance using any Web technology that supports accessibility. WCAG 2.0 therefore does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as they are supported by accessible user agents.

WCAG 2.0 uses the term user agent to mean: Any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs - including assistive technologies - that help in retrieving and rendering Web content. .

It is important to note that assistive technologies are included in this definition. (Assistive technologies include screen readers, screen magnifiers, on screen and alternative keyboards, single switches, and a wide variety of input and output devices that meet the needs of people with disabilities.)

IIn choosing technologies to rely upon, developers need to know what technologies they can assume are supported by, and active in, accessible user agents. A set of such technologies is called a baseline. Developers must ensure that all information and functionality comprising the Web content conform to WCAG 2.0 assuming (a) that user agents support only the technologies in the baseline specified for the content and (b) that those technologies are active.

Baselines are defined outside the WCAG 2.0 guidelines as part of a more comprehensive accessibility policy. Baseline considerations will be significantly different if the entity defining the baseline can guarantee the availability of specific user agents.

  • Example 1: A government site that provides information to the public

    A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release.

  • Example 2: A government adopts a guideline for use with accessible user agents in use by its citizens

    A government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies.

  • Example 3: A government provides accessible user agents to all citizens

    A government provides all citizens with user agents that support newer technologies. The government specifies a baseline that includes newer technologies that are supported in the user agents provided by that government.

  • Example 4: A private intranet

    A company or government agency provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only in the user agent which the organization provides for its employees. Because the company controls the user agents that will view its internal content - the author has very accurate knowledge of the technologies that those user agents support.

    (Note that in example 4, the author is not specifying the baseline in terms of a user agent. The organization had specified the user agent to be used by organization employees in advance. The author just has knowledge that only that agent is used so the author has very good knowledge of the technologies the user agent supports and creates a baseline based on those technologies. Care must be taken here however since that agent would have to be cross-disability accessible or else the author's assumptions may be bad because users with disabilities may have to use other user agents to access the content.)

Developers may also use technologies that are not in the specified baseline provided that the following are true:

  1. All content and functionality must be available using only the technologies in the specified baseline.

  2. The non-baseline technologies must not interfere with (break or block access to) the content

    1. when used with user agents that only support the baseline technologies

    2. when used with user agents that support both the baseline and the additional technologies.

Additional information can be found on the baseline at Questions and Answers about Baseline and WCAG 2.0.

Conformance requirements and the baseline

  1. WCAG 2.0 conformance at level A means that all level 1 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.

  2. WCAG 2.0 conformance at level Double-A means that all level 1 and all level 2 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.

  3. WCAG 2.0 conformance at level Triple-A means that all level 1, level 2 and level 3 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.

Editorial Note: The working group is looking at AAA conformance as being an indication that the content goes beyond AA conformance in a major way but do no necessarily require conformance to all level 3 success criteria. Some Level 3 success criteria cannot be applied to all web content and some are not necessary in certain circumstances. We are considering different criteria for claiming AAA conformance. Comments and suggestions are invited.

Conformance claims

Conformance claims apply to delivery units and sets of delivery units. (In many cases, a "delivery unit" is the same as a "page." In other cases, however, such as Web applications, the term "page" may be inappropriate, so the Working Group has adopted the term "delivery unit" from the Device Independence Working Group.)

A conformance claim MUST include the following assertions:

  1. The date of the claim

  2. The guidelines title/version: "Web Content Accessibility Guidelines 2.0"

  3. The URI of the guidelines: http://www.w3.org/TR/2005/REC-WCAG20-YYYYMMDD/

  4. The conformance level satisfied: (Level A, AA or AAA)

  5. The Baseline used to make the conformance claim. (If baseline is a published baseline it can be named along with a URI that points to it. The baseline technologies can also be spelled out individually in the conformance claim. )

  6. Scope of the claim (a URI, list of URI's or a regular expression)

Optional components of a conformance Claim:

  1. A list of the specific technologies "relied upon" to create the content for which the claim is being made. (This includes markup languages, style sheet languages, scripting/programming languages, image formats, and multimedia formats.)

    • relied upon means that the content would not meet WCAG 2.0 at the claimed level if that technology is turned off or not supported)

    • the set of "Relied Upon" technologies must be a proper subset of the Baseline.

  2. A list of the specific technologies that are "used" but not "relied upon"

  3. If a technology is "used" but not "relied upon" the content would still meet WCAG 2.0 at the stated conformanc level even if that technology is turned off or not supported.

  4. A list of user agents that the content has been tested on. This should include assistive technologies.

  5. Information about audience assumptions or target audience. This could include language, geographic information. It CANNOT specify physical, sensory or cognitive requirements.

Examples of conformance claims

Example 1: On 13 March 2005, www.johnpointer.com conforms to W3C's WCAG 2.0, Conformance Level 1.The baseline for this claim is XHTML 1.0. The specification that this content *relies upon* is: XHTML 1.0. The specifications that this content *uses* are: CSS2, Real Video, Real Audio, MP3, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.01 (Windows, Linux), IE 3.0 and 6.0 (Windows, Mac), Jaws 3.7 and Jaws 6.0 (windows), Safari 1.2 (Mac), Opera 7.5 (OSX).

Example 2: On 1 August 2006, "S5: An Introduction" http://meyerweb.com/eric/tools/s5/s5-intro.html conforms to W3C's WCAG 2.0. Conformance Level 1. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/Baseline#1-2006.html. The specification that this content *relies upon* is: XHTML 1.0 (Strict). The specifications that this content *uses* are: JavaScript 1.2, CSS2, png, and jpg.

Example 3: On 1 July 2005, "Photo gallery application" http://foo.makeyourownslideshow.com conforms to W3C's WCAG 2.0, Conformance Level 1. The baseline is ISA-Baseline#2-2005 at http://ISA.gov/Baselines/BL2-2005. The specifications that this content *relies upon* are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpg. The specification that this content *uses* is: gif. The techniques profile that this content uses is, "HTML/ECMAScript for latest browsers."

Conformance Notes

A delivery unit conforms to WCAG 2.0 at a given conformance level only if all content provided by that delivery unit conforms at that level.

Note: If multiple representations can be retrieved from a URI through content negotiation, then the conformance claim would be for the delivery unit that is returned when no negotiation is conducted (unless the server returns an error for that condition, in which case one of the negotiated forms must comply).

Editorial Note: There is some question as to whether URI is specific enough a reference to the material for which the claim is being made.

Editorial Note: A question has been raised as to whether the information required in items 1-3 above should all be transmitted in the HTTP header or in some other way.

Editorial Note: The working group is considering adding the following note to the conformance section to differentiate Web Content from standard stand alone software and other products that are downloaded over the Internet and not used via a user agent.. Note: If data, software or other materials are downloaded over the internet but are not used via a user agent then they are not considered Web content and are not covered by these guidelines.

Level of conformance being claimed

Sometimes a delivery unit is assembled ("aggregated") from multiple sources that each have their own level of conformance. These sources are called authored units. The conformance level for a delivery unit that contains authored units is equal to the lowest conformance level claimed for the delivery unit content and any of the authored units it contains - including claims of aggregated units.

A delivery unit referred to by a URI conforms to WCAG 2.0 at a given conformance level only if all content provided by that delivery unit conforms at that level. For example, if the delivery unit provides information retrieved from a database in response to users' queries, all delivery units containing such information must satisfy the success criteria of WCAG 2.0 to the level at which conformance is claimed. In the case of content negotiation, WCAG 2.0 conformance is not required if the user agent requests a version of the content that does not meet WCAG 2.0 at the specified conformance level.

Editorial Note: We are currently looking at how to handle unknown or community-contributed, authored units that are created using an aggregator supplied tool. We are currently considering whether aggregated content would be judged to conform to WCAG if the aggregator supplied tool can conform to the Authoring Tool Accessibility Guidelines (ATAG) 2.0.

Scoping of conformance claims

Conformance claims can be limited, or "scoped," to pertain to only some parts of a Web site. All conformance claims, however, must be directed to a URI or a range of URIs. Scoping to exclude a particular type of content (for example, images or scripts) from a site is not allowed since it would allow exclusion of individual success criteria. Scoping by URI to exclude sections of a site is allowed so that authors can make claims for just some parts of a site.

Content that conforms to WCAG 1.0

This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999.

The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft.

Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials created or modified before 31 December 2005 conform to WCAG 1.0. Materials created or modified on or after 31 December 2005 conform to WCAG 2.0."

Editorial Note: In some instances, the WCAG 2.0 Working Draft may be easier to conform to than the WCAG 1.0 Recommendation while other criteria might be harder to meet in WCAG 2.0 than in WCAG 1.0. The WCAG WG will consider the differences between WCAG 1.0 and WCAG 2.0 conformance and offer advice to developers who currently conform to WCAG 1.0. This advice might take the form of a WCAG 1.0 conformance profile to WCAG 2.0 and information about migrating from WCAG 1.0 to WCAG 2.0. This advice is not yet available.

Authoring tools

A large part of Web content is created using authoring tools. These tools often determine how Web content is implemented, either by making authoring decisions directly or by limiting the choices available to the author. As a result, authoring tools will play an important role in creating Web content that conforms to the Web Content Accessibility Guidelines. At the same time, we recommend that all authors become familiar with the Guidelines because this will help in creating accessible content and coverage of the Guidelines may vary between tools.

Developers of authoring tools can help to make their tools more aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. We encourage users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools.

Editorial Note: The Authoring Tool Accessibility Guidelines Working Group has published Working Drafts of ATAG 2.0. The above references will need to be updated as ATAG 2.0 moves through recommendation track.

Table of Contents

Appendices

WCAG 2.0 Guidelines

Principle 1: Content must be perceivable.

Guideline 1.1 Provide text alternatives for all non-text content.

Level 1 Success Criteria for Guideline 1.1

1.1.1 For non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information. For multimedia, provide a text-alternative that identifies the multimedia. For live audio-only and live video-only, conform to success criterion 1.1.5.

GB: to me "to identify" means "to refer by name to something else" and I'm not sure that this is the intended meaning. A glossary definition of "identify" should be given

[How to meet 1.1.1]

Note: For requirements for synchronized alternatives for multimedia refer to Guideline 1.2 Provide synchronized alternatives for multimedia.

1.1.2 For non-text content that is functional, text alternatives serve the same purpose as the non-text content. If text alternatives can not serve the same purpose as the functional non-text content, text alternatives identify the purpose of the functional non-text content [How to meet 1.1.2]

1.1.3 For non-text content that is intended to create a specific sensory experience GB: I would say "...non-text content that is intended to create only a specific sensory experience" text alternatives at least identify the non-text content with a descriptive label. GB: in addition I think the definition of the concept "non-text content that is intended to create a specific sensory experience" is too general. While the criterion makes sense to me when applied to (say) a picture of a painting, it is does not make sense when applied to graphics or photos that graphically enhance a web page, for example by inducing certain emotions on the reader. The latter could be marked up so that they are silent wrt assistive technologies. [How to meet 1.1.3]

1.1.4 Non-text content that is not functional, is not used to convey information, and does not create a specific sensory experience is implemented such that it can be ignored by assistive technology. [How to meet 1.1.4]

1.1.5 For live audio-only or video-only content, text alternatives at least identify the purpose of the content with a descriptive label. [How to meet 1.1.5]

Note: Refer to Guideline 1.2 Provide synchronized alternatives for multimedia. for guidance on content that combines live audio and video.

Level 2 Success Criteria for Guideline 1.1

(No level 2 success criteria for this guideline.)

Level 3 Success Criteria for Guideline 1.1

1.1.6 For prerecorded multimedia content, a combined document containing both captions and transcripts of audio descriptions of video is available. [How to meet 1.1.6]

Guideline 1.1 (text-equiv) Issues

Guideline 1.2 Provide synchronized alternatives for multimedia.

Level 1 Success Criteria for Guideline 1.2

1.2.1 Captions are provided for prerecorded multimedia. [How to meet 1.2.1]

Editorial Note: The working group is seeking comment on the following proposal:

  1. Change 1.2.1 to " Provide captions OR provide a text transcript of all audio intermixed with a text description of what is happening visually."

so authors have an option of providing captions OR a text script. Then, at Level 2, require captions.

GB: I prefer this second statement. I would also cleary say that "what happens visually" means information regarding the visual scenes and the spoken dialogues.

1.2.2 Audio descriptions of video are provided for prerecorded multimedia [How to meet 1.2.2]

Editorial Note: The working group is seeking comment on the following proposal:

  1. Change 1.2.2 to " Provide audio descriptions OR provide a text transcript of all audio intermixed with a text description of what is happening visually."

so authors have an option of providing audio descriptions OR a text script. Then, at Level 2, require audio descriptions.

Level 2 Success Criteria for Guideline 1.2

1.2.3 Real-time captions are provided for live multimedia. [How to meet 1.2.3]

Level 3 Success Criteria for Guideline 1.2

1.2.5 Extended audio descriptions of video are provided for prerecorded multimedia. [How to meet 1.2.5]

Guideline 1.2 (media-equiv) Issues

Guideline 1.3 Ensure that information, functionality, and structure can be separated from presentation.

Level 1 Success Criteria for Guideline 1.3

1.3.1 Perceivable structures within the content can be programmatically determined. [How to meet 1.3.1]

1.3.2 When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors. [How to meet 1.3.2]

Level 2 Success Criteria for Guideline 1.3

1.3.3 Information that is conveyed by variations in presentation of text is also conveyed in text or the variations in presentation of text can be programmatically determined. [How to meet 1.3.3]

1.3.4 Any information that is conveyed by color is visually evident when color is not available. [How to meet 1.3.4]

Level 3 Success Criteria for Guideline 1.3

1.3.5 When content is arranged in a sequence that affects its meaning, that sequence can be programmatically determined. [How to meet 1.3.5]

1.3.6 Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components. [How to meet 1.3.6]

Guideline 1.3 (content-structure-separation) Issues

Guideline 1.4 Make it easy to distinguish foreground information from background images or sounds. [level 2 guideline]

Level 1 Success Criteria for Guideline 1.4

(No level 1 success criteria for this guideline.)

Level 2 Success Criteria for Guideline 1.4

1.4.1 Text or diagrams, and their background, must have a luminosity contrast ratio of at least 5:1. GB: I would prefer to see this as a level 1 criterion, given the negative consequences that its violation have: they are frequent on many websites, they may have a significant impact on effectiveness, and they affect many users [How to meet 1.4.1]

1.4.2 A mechanism is available to turn off background audio that plays automatically. [How to meet 1.4.2]

Level 3 Success Criteria for Guideline 1.4

1.4.3 Text or diagrams, and their background, must have a luminosity contrast ratio of at least 10:1. [How to meet 1.4.3]

1.4.4 Audio content does not contain background sounds or the background sounds are at least 20 decibels lower than the foreground audio content, with the exception of occasional sound effects. [How to meet 1.4.4]

Note: A 20 decibel difference in sound level is roughly 4 times quieter (or louder). Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

Guideline 1.4 (visual-audio-contrast) Issues

Principle 2: Interface elements in the content must be operable.

Guideline 2.1 Make all functionality operable via a keyboard interface.

Level 1 Success Criteria for Guideline 2.1

2.1.1 All functionality of the content is operable in a non time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. [How to meet 2.1.1]

Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Note: MouseKeys does not satisfy this success criterion.

Level 2 Success Criteria for Guideline 2.1

(No level 2 success criteria for this guideline.)

Level 3 Success Criteria for Guideline 2.1

2.1.2 All functionality of the content is designed to be operated through a keyboard interface. [How to meet 2.1.2]

Guideline 2.1 (keyboard-operation) Issues

Guideline 2.2 Allow users to control time limits on their reading or interaction.

Level 1 Success Criteria for Guideline 2.2

2.2.1 For each time-out that is a function of the content, at least one of the following is true: [How to meet 2.2.1]

  • the user is allowed to deactivate the time-out or;

  • the user is allowed to adjust the time-out over a wide range which is at least ten times the length of the default setting or;

  • the user is warned before time expires and given at least 20 seconds to extend the time-out with a simple action (for example, "hit any key") and the user is allowed to extend the timeout at least 10 times or;

  • the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible or;

  • the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity.

Editorial Note: The Working Group is considering adding techniques and/or modifying the success criterion to ensure additional accessibility features are employed for events where no alternative to a timeout is possible or where timing is essential.

Level 2 Success Criteria for Guideline 2.2

2.2.3 Content can be paused by the user unless the timing or movement is part of an activity where timing or movement is essential. [How to meet 2.2.3]

Level 3 Success Criteria for Guideline 2.2

2.2.4 Except for real-time events, timing is not an essential part of the event or activity presented by the content. [How to meet 2.2.4]

2.2.5 Interruptions, such as updated content, can be postponed or suppressed by the user, except those involving an emergency. [How to meet 2.2.5]

2.2.6 When an authenticated session has an inactivity timeout, the user can continue the activity without loss of data after re-authenticating. [How to meet 2.2.6]

Guideline 2.2 (time-limits) Issues

Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity.

Level 1 Success Criteria for Guideline 2.3

2.3.1 When content violates either the general flash threshold or thered flash threshold, users are warned in a way that they can avoid it. [How to meet 2.3.1]

Level 2 Success Criteria for Guideline 2.3

2.3.2 Content does not violate general flash threshold or red flash threshold. [How to meet 2.3.2]

Level 3 Success Criteria for Guideline 2.3

(No level 3 success criteria for this guideline.)

Guideline 2.3 (seizure) Issues

Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it.

Level 1 Success Criteria for Guideline 2.4

Level 2 Success Criteria for Guideline 2.4

Level 3 Success Criteria for Guideline 2.4

Guideline 2.4 (navigation-mechanisms) Issues

Guideline 2.5 Help users avoid mistakes and make it easy to correct them.

Level 1 Success Criteria for Guideline 2.5

2.5.1 If an input error is detected, the error is identified and described to the user in text. [How to meet 2.5.1]

Level 2 Success Criteria for Guideline 2.5

2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user. [How to meet 2.5.2]

2.5.3 For forms that cause legal or financial transactions to occur, that modify or delete data in remote data storage systems, or that submit test responses, at least one of the following is true: [How to meet 2.5.3]

  1. Actions are reversible.

  2. Actions are checked for input errors before going on to the next step in the process.

  3. The user is able to review and confirm or correct information before submitting it.

Level 3 Success Criteria for Guideline 2.5

2.5.4 Context-sensitive help is available for text input. [How to meet 2.5.4]

Guideline 2.5 (minimize-error) Issues

Principle 3: Content and controls must be understandable.

Guideline 3.1 Make text content readable and understandable.

Level 1 Success Criteria for Guideline 3.1

3.1.1 The primary natural language or languages of the delivery unit can be programmatically determined. [How to meet 3.1.1]

Level 2 Success Criteria for Guideline 3.1

3.1.2 The natural language of each foreign passage or phrase in the content can be programmatically determined. [How to meet 3.1.2]

Note: This requirement does not apply to individual words or to phrases that have become part of the primary language of the content.

GB: I don't understand the reason for this exception: words like "check-in" are often used in Italian, but unless they are pronounced with the English phonemes, they are highly distorted (namely "check-in" would be pronounced as "kek-in").

Level 3 Success Criteria for Guideline 3.1

3.1.3 A mechanism is available for identifying specific definitions of words used in an unusual or restricted way, including idioms and jargon. [How to meet 3.1.3]

3.1.4 A mechanism for finding the expanded form of abbreviations is available. [How to meet 3.1.4]

3.1.5 When text requires reading ability more advanced than the lower secondary education level, one or more of the following types of supplemental content is available: [How to meet 3.1.5]

  1. A text summary that requires reading ability less advanced than the lower secondary education level.

  2. Graphical illustrations of concepts or processes that must be understood in order to use the content.

  3. A spoken version of the text content.

3.1.6 When a page or other delivery unit is navigated sequentially, elements receive focus in an order that follows relationships and sequences in the content. [How to meet 3.1.6]

Guideline 3.1 (meaning) Issues

Guideline 3.2 Make the placement and functionality of content predictable.

Level 1 Success Criteria for Guideline 3.2

3.2.1 When any component receives focus, it does not cause a change of context. [How to meet 3.2.1]

Note: Refer to Guideline 2.1 Make all functionality operable via a keyboard interface. for requirements for making all functionality operable via a keyboard interface.

Level 2 Success Criteria for Guideline 3.2

3.2.2 Changing the setting of any input field does not automatically cause a change of context . [How to meet 3.2.2]

3.2.3 Components that are repeated on multiple delivery units within a set of delivery units occur in the same relative order each time they are repeated. [How to meet 3.2.3]

3.2.4 Components that have the same functionality in multiple delivery units within a set of delivery units are identified consistently. [How to meet 3.2.4]

Level 3 Success Criteria for Guideline 3.2

3.2.5 Changes of context are initiated only by user request. [How to meet 3.2.5]

Guideline 3.2 (consistent-behavior) Issues

Principle 4: Content must be robust enough to work with current and future technologies.

Guideline 4.1 Use technologies according to specification.

Level 1 Success Criteria for Guideline 4.1

4.1.1 Delivery units can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous. [How to meet 4.1.1]

Level 2 Success Criteria for Guideline 4.1

(No level 2 success criteria for this guideline.)

Level 3 Success Criteria for Guideline 4.1

(No level 3 success criteria for this guideline.)

Guideline 4.1 (use-spec) Issues

Guideline 4.2 Ensure that user interfaces are accessible or provide an accessible alternative(s)

Level 1 Success Criteria for Guideline 4.2

4.2.1 If content does not meet all level 1 success criteria, then an alternate version is available from the same URI that does meet all level 1 success criteria. [How to meet 4.2.1]

4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: [How to meet 4.2.2]

  1. When content violates either the general flash threshold or thered flash threshold, users are warned in a way that they can avoid it.

  2. If the user can enter the content using the keyboard, then the user can exit the content using the keyboard.

4.2.3 The role, state, and value can be programmatically determined for every user interface component of the web content that accepts input from the user or changes dynamically in response to user input or external events. [How to meet 4.2.3]

4.2.4 The label of each user interface control that accepts input from the user can be programmatically determined and is explicitly associated with the control. [How to meet 4.2.4]

4.2.5 The content and properties of user interface elements that can be changed via the user interface can also be directly changed programmatically. [How to meet 4.2.5]

Note: Some examples of standardized properties that typically can be changed by the user interface include its value, whether it is currently selected, and whether it currently has the focus.

Editorial Note: The working group is still considering whether this criterion should be included and, if so, at what level.

4.2.6 Changes to content, structure, selection, focus, attributes, values, state, and relationships can be programmatically determined. [How to meet 4.2.6]

Level 2 Success Criteria for Guideline 4.2

(No level 2 success criteria for this guideline.)

Level 3 Success Criteria for Guideline 4.2

4.2.7 Content implemented using technologies outside of the chosen baseline satisfies all level 1 and 2 WCAG requirements supported by the technologies. [How to meet 4.2.7]

Guideline 4.2 (technology-supports-access) Issues

Appendix A Glossary (Normative)

abbreviation

Shortened form of a word, phrase or name, i.e. a general category that includes abbreviations, initialisms and acronyms.

acronym

An abbreviation made from the initial letters of a name or phrase that contains several words. Many acronyms can be pronounced as words. Defined differently in different languages. For example, NOAA is an acronym made from the initial letters of the National Oceanic and Atmospheric Administration in the United States.

activity where timing is essential

activity where timing is part of the design of the activity and removal of the time dependency would change the functionality of the content

alternate version

a version that provides all of the same information and functionality and is as up to date as any non-conformant content

ASCII art

A picture created by a spatial arrangement of characters (typically from the 95 printable characters defined by ASCII).

audio description

Audio narration that is added to the soundtrack to explain important details that cannot be understood from the main soundtrack alone. During pauses in dialog, audio descriptions of video provide information about actions, characters, scene changes and on-screen text to people who are blind or visually impaired.

authored unit

Some set of material created as a single entity by an author. Examples include a collection of markup, a style sheet, and a media resource, such as an image or audio clip.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

background image

Images that appear behind or to the back of the visual field.

baseline

Set of technologies assumed to be supported by, and enabled in, user agents in order for Web content to conform to these guidelines.

Note: Some examples of entities that may set baselines that an author may have to follow include the author, a company, a customer and government entities.

blink

turn on and off between .5 and 3 times per second

captions

Synchronized transcripts of dialogue and important sound effects. Captions provide access to multimedia for people who are deaf or hard of hearing.

changes of context

A change of user agent, viewport, or focus; or complete change of content that changes the meaning of the delivery unit.

Note: A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

Computer adapted spatial pattern thresholds

The international definitions for spatial pattern threshold are changing and we will adopt the new standards as they are released. If not available we will remove the L3 SC.

content

Information in the delivery unit that is used by the user agent to generate perceivable units. This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user.

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

emergency

a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety or property

event handler

A section of code that responds to an action taken by the user (or user agent). On Web pages, events are usually user actions such as moving the mouse, typing, etc. An event handler determines the response to that action. A technology specific event handler only responds to an action by one kind of input device. An abstract event handler is one which can be activated by a variety of input devices.

extended audio descriptions

audio descriptions that are added to an audio/visual presentation by pausing the video so that there is time to add addional description. This technique is only used when the sense of the video would be lost without the additional audio description.

feature

A feature is a specific component of a technology, for example an element in a markup language or a function call in an Application Programming Interface. Typically, a given feature may only be available in specific versions of the technology, and thus may need to be noted explicitly in the required list.

foreign passages or phrases

Foreign passages or phrases are passages or phrases in a language that is different from the language of the surrounding text.

function

Performs or is able to perform one or more actions in response to user input.

general flash threshold

  • A sequence of flashes or rapidly changing image sequences where both the following occur:

    1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and

    2. there are more than three flashes within any one-second period.

    Note: For the general flash threshold, a flash is defined as a pair of opposing changes in brightness of 10% or more of full scale white brightness, where brightness is calculated as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized-X = (X/FS)^2.2 where FS is full scale (usually 255 today). An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.

idiomatic expressions

words or phrases specific to a region or language that do not mean what the dictionary definitions of the individual words say. For example, the English phrase "he blew his stack" means that someone became very angry.

information

  1. A message to be sent and received,

  2. A collection of facts or data from which inferences may be drawn,

  3. Knowledge acquired through study, experience, or instruction

  4. GB: the difference that makes a difference (Bateson)

information is conveyed by color

perception of the color attributes is essential to understanding a piece of content

information that is conveyed by color

perception of the color attributes is essential to understanding a piece of content

initialism

The shortened form of a name or phrase made from the initial letters of words or syllables contained in that name or phrase. Not defined in all languages. SNCF is a French initialism that contains the initial letters of the Societe National des Chemins de Fer, the French national railroad. ESP is an initialism for extrasensory perception.

input error

Any information provided by the user that is not accepted. This includes:

  1. information that is required by the delivery unit but omitted by the user.

  2. information that is provided by the user but that falls outside the required data format or values.

jargon

words used in a particular way by people in a particular field. For example, the word StickyKeys is jargon from the field of assistive technology/accessibility.

keyboard interface

An alternate method for connecting a keyboard to the device for the purpose of generating text on devices that do not have a built-in or attached keyboard, or an internal method for generating text. Allowing control via the "keyboard interface" means that the content could be controlled through commands issued from the keyboard or by alternate methods that are capable of generating text as if a keyboard had been used.

link

Link refers to a hyperlink between the current document and a single destination. (Here, "link" refers to a single "arc" in the XML Linking Language (XLink) Version 1.0 specification.) Only links that are available to be activated by the user need to meet accessibility requirements. This excludes links that are activated automatically or programmatically.

live audio-only

A time-based live presentation that only contains only audio (no video and no interaction).

live video-only

A time-based live presentation that only contains only video (no audio and no interaction).

Lower secondary education level

the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education.

Note: This definition is adapted from [UNESCO].

luminosity contrast ratio

(L1+.05) / (L2+.05) where L is luminosity and is defined as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized R (for example) = (R/FS)^2.2 where FS is full scale value (255 for 8 bit color channels). L1 is the higher value (of text or background) and L2 is the lower value.

mechanism

a process or technique for achieving a result

multimedia

For the purposes of these guidelines, multimedia refers to combined audio and video presentations. It also includes audio-only and video-only presentations that include interaction.

natural languages

languages are those used by humans to communicate, including spoken, written, and signed languages.

navigational features

mechanisms that allow the user to locate and/or move to a different piece of content.

non-text content

Content that is not represented by a Unicode character or sequence of Unicode characters when rendered in a user agent according to the formal specification of the content type. This includes ASCII Art, which is a pattern of characters.

non-text content that conveys information

non-text content content that communicates ideas, data, facts information and is not text.

non-text content that is functional

non-text content that is capable of performing one or more actions in response to user input and is not text.

Note: This includes, but is not limited to, image-based submit buttons, applets, and embedded programmatic objects.

non-text content that is intended to create a specific sensory experience

non-text content that causes a sensory experience that does not primarily convey important information or perform a function.

normative

Required for conformance.

parsed unambiguously

Parsing transforms markup or other code into a data structure, usually a tree, which is suitable for later processing and which captures the implied hierarchy of the input. Parsing unambiguously means that there is only one data structure that can result

perceivable structures

structures in the document that are reflected in the presentation and can be used for orientation and navigation including determining relationships between parts of the content.

perceivable unit

The result of a user agent rendering the contents of a delivery unit. User agents may or may not render all information in a delivery unit. In some cases, a single delivery unit may be rendered as multiple perceivable units. For example, a single html file that is rendered as a set of presentation slides. Most perceivable units contain presentation and the means for interaction. However, for some devices such as printers, a perceivable unit may only contain presentation.

presentation

Presentation is the rendering of the content and structure in a form that can be perceived by the user.

Primary education level

the six year time period that begins between the ages of five and seven, possibly without any previous education

Note: This definition is adapted from [UNESCO].

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

programmatic user interface component

An interface component created by the author that is in addition to those provided by the user agent. For example, an HTML checkbox would not be a programmatic user interface component because the author is using an interface component supported by the user agent. A checkbox function implemented in script, however, would be a programmatic user interface component because it provides functionality that is not known or supported by user agents and can not be made accessible by user agents even if the user agent complied with UAAG.

real-time events

events that are live and not under the control of the author

red flash threshold

  • A transition to or from a saturated red where both of the following occur:

    1. the combined area of flashes occurring concurrently occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and

    2. there are more than three flashes within any one-second period.

regular expression

A regular expression as defined in XML Schema Part 2: Datatypes, Appendix F.

same functionality

Items are considered to have the same function if the outcome of their use is identical. For instance, a submit "search" button on one delivery unit and a "find" button on another delivery unit may both have a field to enter a term and list topics in the web site related to the term submitted. In this case they would have same functionality but would not be labeled consistently.

same relative order

Each item maintains its position relative to the other items. Items are considered to be in the same relative order even if other items are inserted or removed from the original order. For example, expanding navigation menus may insert an additional level of detail or a secondary navigation section may be inserted into the reading order.

sign language interpretation

providing the translation and meaning of spoken words into specific gestures, hand positions and hand movements.

structure

  1. The way the parts of an authored unit are organized in relation to each other and;

  2. The way a collection of authored units is organized in relation to a delivery unit and;

  3. The way a collection of delivery units is organized

supplemental content

Additional content that illustrates or clarifies default text content, which users may use instead of or in addition to the default text content. For example, there may be supplements in text, graphics, and audio.

technology

Technology means a data format, programming or markup language, protocol or API.

text

A sequence of characters. Characters are those included in the Unicode/ISO/IEC 106464 repertoire.

text alternative

Programmatically determined text that is used in place of non-text content or text that is used in addition to non-text content and referred to from the programmatically determined text.

unfamiliar content

Content might be unfamiliar if you are using terms specific to a particular community. For example, many of the terms used in this document are specific to the disability community.

unicode

Unicode is a universal character set that defines all the characters needed for writing the majority of living languages in use on computers. For more information refer to the Unicode Consortium or to Tutorial: Character sets & encodings in XHTML, HTML and CSS produced by the W3C Internationalization Activity.

URI pattern

A URI pattern is a regular expression identifying a set of resources. A resource belongs to the set if the regular expression matches its URI.

Note: in order to be included in the set, the resource must exist; the regular expression may, and typically will, match URIs that do not refer to any existing resource.

used in an unusual restricted way

words used in such a way that users must know exactly what definition to apply in order to understand the content correctly. For example, the word "representational" means something quite different if it occurs in a discussion of visual art as opposed to a treatise on government, but the appropriate definition can be determined from context. By contrast, the word "text" is used in a very specific way in WCAG 2.0, so a definition is supplied in the glossary.

user agent

Any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving and rendering Web content.

Wisconsin Computer Equivalence Algorithm

The Wisconsin Computer Equivalence Algorithm is a method for applying the United Kingdom's "ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television (Revised and re-issued July 2001)" to content displayed on a computer screen, such as Web pages and other computer content. The ITC Guidance Document is based on the assumption that the television screen occupies the central ten degrees of vision. This is not accurate for a screen which is located in front of a person. The Wisconsin Algorithm basically carries out the same analysis as the ITC Guidelines except that is does it on every possible ten degree window for a prototypical computer display.

Appendix B WCAG 2.0 Checklist (Non-Normative)

The Web Content Accessibility Guidelines 2.0 Checklist serves as an appendix to Web Content Accessibility Guidelines 2.0 [WCAG20]. It lists all of the success criteria from WCAG 2.0 in a checkable list. The level of each success criterion is provided as well as a link to WCAG 2.0 for more information for each success criterion. For many readers, the Checklist provides a quick reference and overview to the information in WCAG 2.0.

Success Criteria

Guideline 1.1 : Provide text alternatives for all non-text content.
True Success Criterion Comments
L1

Note: For requirements for synchronized alternatives for multimedia refer to Guideline 1.2 Provide synchronized alternatives for multimedia.

 

 

 

 

Note: Refer to Guideline 1.2 Provide synchronized alternatives for multimedia. for guidance on content that combines live audio and video.

 
L3

 
Guideline 1.2 : Provide synchronized alternatives for multimedia.
True Success Criterion Comments
L1

 

 
L2

 
L3

 

 
Guideline 1.3 : Ensure that information, functionality, and structure can be separated from presentation.
True Success Criterion Comments
L1

 

 
L2

 

 
L3

 

 
Guideline 1.4 : Make it easy to distinguish foreground information from background images or sounds.
True Success Criterion Comments
L2

 

 
L3

 

Note: A 20 decibel difference in sound level is roughly 4 times quieter (or louder). Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

  
Guideline 2.1 : Make all functionality operable via a keyboard interface.
True Success Criterion Comments
L1

Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Note: MouseKeys does not satisfy this success criterion.

  
L3

 
Guideline 2.2 : Allow users to control time limits on their reading or interaction.
True Success Criterion Comments
L1

  • the user is allowed to deactivate the time-out or;

  • the user is allowed to adjust the time-out over a wide range which is at least ten times the length of the default setting or;

  • the user is warned before time expires and given at least 20 seconds to extend the time-out with a simple action (for example, "hit any key") and the user is allowed to extend the timeout at least 10 times or;

  • the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible or;

  • the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity.

  
L2

Note: Refer to Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity. for requirements for avoiding creating content that could cause seizures due to photosensitivity.

  

 
L3

 

 

 
Guideline 2.3 : Allow users to avoid content that could cause seizures due to photosensitivity.
True Success Criterion Comments
L1

 
L2

 
Guideline 2.4 : Provide mechanisms to help users find content, orient themselves within it, and navigate through it.
True Success Criterion Comments
L1

 
L2

 

 

 

 
L3

 

 

 
Guideline 2.5 : Help users avoid mistakes and make it easy to correct them.
True Success Criterion Comments
L1

 
L2

 

  1. Actions are reversible.

  2. Actions are checked for input errors before going on to the next step in the process.

  3. The user is able to review and confirm or correct information before submitting it.

  
L3

 
Guideline 3.1 : Make text content readable and understandable.
True Success Criterion Comments
L1

 
L2

Note: This requirement does not apply to individual words or to phrases that have become part of the primary language of the content.

  
L3

 

 

  1. A text summary that requires reading ability less advanced than the lower secondary education level.

  2. Graphical illustrations of concepts or processes that must be understood in order to use the content.

  3. A spoken version of the text content.

  

 
Guideline 3.2 : Make the placement and functionality of content predictable.
True Success Criterion Comments
L1

Note: Refer to Guideline 2.1 Make all functionality operable via a keyboard interface. for requirements for making all functionality operable via a keyboard interface.

  
L2

 

 

 
L3

 
Guideline 4.1 : Use technologies according to specification.
True Success Criterion Comments
L1

 
Guideline 4.2 : Ensure that user interfaces are accessible or provide an accessible alternative(s)
True Success Criterion Comments
L1

 

  1. When content violates either the general flash threshold or thered flash threshold, users are warned in a way that they can avoid it.

  2. If the user can enter the content using the keyboard, then the user can exit the content using the keyboard.

  

 

 

Note: Some examples of standardized properties that typically can be changed by the user interface include its value, whether it is currently selected, and whether it currently has the focus.

  

 
L3

 

Appendix C Acknowledgements (Non-Normative)

Participants in the WCAG Working Group. Note: in the Last Call Working Draft this link will be replaced by a list of names.

This publication has been funded in part with Federal funds from the U.S. Department of Education under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

Appendix D The differences between WCAG 1.0 and WCAG 2.0 (Non-Normative)

Since the release of WCAG 1.0 in May 1999, the WCAG Working Group has received feedback on priorities of checkpoints, the usability of the set of documents, and requests for clarifications on the meaning of specific checkpoints and what is needed to satisfy them. Thus, it is intended that WCAG 2.0, when it eventually becomes a W3C Recommendation:

For a detailed comparison, refer to the Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft.

D.1 Improvements in WCAG 2.0

We hope that WCAG 2.0 will have several improvements over WCAG 1.0. While the primary goal of WCAG 2.0 is the same as WCAG 1.0 (to promote accessibility of Web content) additional goals for WCAG 2.0 include improvements that will:

  1. Ensure that requirements may be applied across technologies

  2. Ensure that the conformance requirements are clear

  3. Ensure that the deliverables are easy to use

  4. Write to a more diverse audience

  5. Clearly identify who benefits from accessible content

  6. Ensure that the revision is "backward compatible" with WCAG 1.0

For more information about the intended improvements in WCAG 2.0 Working Draft, please refer to Requirements for WCAG 2.0.

Appendix E References (Non-Normative)

Editorial Note: Links within the document will be turned into references and the links to those documents will be listed here. They are inline for the time being.

WCAG20
"Web Content Accessibility Guidelines 2.0," B. Caldwell, W. Chisholm, J. Slatin, and G. Vanderheiden, eds., W3C Working Draft 30 June 2005. This W3C Working Draft is available at http://www.w3.org/TR/2005/WD-WCAG20-20050630. The latest version of WCAG 2.0 is available at http://www.w3.org/TR/WCAG20/
UAAG10
"User Agent Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen, eds., W3C Recommendation 17 December 2002. The latest version of UAAG 1.0 is available at http://www.w3.org/TR/UAAG10/
UNESCO
International Standard Classification of Education, 1997. A copy of the standard is available at http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm.