[contents] [checklist]

W3C

Web Content Accessibility Guidelines 2.0

Editor's Draft 05 April 2006

This version:
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20060405/
Latest version:
http://www.w3.org/WAI/GL/WCAG20/
Previous version:
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20060331/
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:


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 Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Last Call 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 document is for review by the WCAG WG and is subject to change without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.

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

Editorial Note: @@ this section is currently undergoing review.

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.


Table of Contents

Appendices


Introduction

This section is informative.

You are reading the Web Content Accessibility Guidelines (WCAG) version 2.0. This is the central document that defines 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 usable 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 and mobile technologies.

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

The WCAG 2.0 document itself consists of :

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 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 to be used by a diverse audience, including but not limited to:

  • people who create Web content

  • developers who write code

  • QA or accessibility evaluators

  • policy makers

  • managers

  • users

Currently, these informative documents include:

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

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

  • Questions and Answers about Baseline and WCAG 2.0 - Provides additional information on baselines.

  • Understanding WCAG 2.0 - Provides information about each success criterion including:

    • its intent,

    • key terms from the WCAG 2.0 Glossary needed to understand the success criterion,

    • names of and links to techniques that the working group deems sufficient to meet the success criterion, and

    • examples and benefits of the success criterion.

    Note: Each of the "How to meet SC x.x.x" links in WCAG 2.0 links to the relevant section of the Understanding WCAG 2.0 document.

  • Technique and Tests documents - Provide specific details on different techniques including examples, code, and tests.

    Editorial Note: Some techniques documents are unfinished at this time. However, at least one sufficient technique is documented for each success criterion.

  • Application Notes - Provide detailed application information in different areas. For example an Application Note on Forms will provide a collection of techniques, and strategies for creating accessible forms. It will also summarize the different success criteria that relate to forms.

    Editorial Note: No examples of applicaion notes have been 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 of the Web Accessibility Initiative and its Education and Outreach Working Group is highly recommended. The articles called Getting Started: Making a Web Site Accessible and How People with Disabilities Use the Web are especially useful.

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 make their tools aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. The working group encourages users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools. The current version at the time of this document's release can be found at Authoring Tool Accessibility Guidelines.

The Four Principles of Accessibility

The WCAG 2.0 Guidelines are organized around the following 4 principles:

  1. Content must be perceivable

  2. Interface components in the content must be operable

  3. Content and controls must be understandable

  4. Content should be robust enough to work with current and future user agents (including assistive 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.

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.

Conformance

This section is normative.

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.

Note 1: Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria.

Note 2: Guidelines do not necessarily contain success criteria at every level. Some have success criteria at only one level.

This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG 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 under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people.

All WCAG 2.0 success criteria are testable. While some can be tested by computer programs, others must be tested by qualified human testers. Sometimes, a combination of computer programs and qualified human testers may be used. When people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained with high inter-rater reliability.

Note: For each success criterion, there is a list of techniques deemed by the working group to be sufficient to meet the requirement. For each technique, there is a test to determine whether the technique has been successfully implemented. If the test(s) for a "sufficient" technique or combination of techniques is passed, then the working group would consider that success criterion met. However, passing all tests for all techniques is not necessary. Nor is it necessary to meet a success criterion using one of the sufficient techniques. There may be other techniques which are not documented by the working group that would also meet the success criterion.

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 the technologies are supported by accessible user agents including assistive technologies.

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, voice recognition and a wide variety of input and output devices that meet the needs of people with disabilities.

Choosing baseline technologies

In choosing Web technologies (HTML, scripting, etc.) that will be used when building content, developers need to know what technologies they can assume will be supported by, and active in, the user agents (including assistive technologies) that people with disabilities will be using. If authors rely on technologies that are not supported, then their content may not be accessible.

The set of such technologies that an author assumes are supported and turned on in accessible user agents is called a baseline. Developers must ensure that all information and functionality of the Web content conforms to WCAG 2.0 assuming:

  1. that user agents support all the technologies in the baseline, but no other technologies and

  2. that those technologies that are listed in the baseline are all enabled

Who sets baselines?

Baselines may be set by authors, companies, customers and governmental bodies.

WCAG 2.0 does not specify any particular baseline. There are several reasons for this. First, what is appropriate in a baseline may differ for different environments. For example, in the case of content that will be viewed only by employees of a particular company, it may be possible to assume that user agents support more advanced technologies if the company provides the necessary user agents (including assistive technology) to all employees. For public Websites, however, a more conservative level of technology may be all that can be reasonably assumed. Baselines may also vary by jurisdiction. Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time.

Some examples of baselines:

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. The 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 2: A particular government provides high level accessible user agents to all citizens who need them. A government provides all citizens with user agents that support newer technologies. The government is thus able to specify a baseline that includes these newer technologies for all of its Websites for its citizens since the government can assume its citizens' user agents can handle the technologies.

Example 3: A private intranet. An organization (public or private) 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 by the user agent that the organization provides for its employees. Because the company controls the user agents that will view its internal content, the author has a very accurate knowledge of the technologies that those user agents (including assistive technologies) support.

Note: In the examples above, the baseline is not specified in terms of specific user agents but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies).

Use of technologies outside of the baseline

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

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

  2. The non-baseline technologies do 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 (informative) information on baselines can be found at Questions and Answers about Baseline and WCAG 2.0.

Conformance levels 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 (AA) 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 (AAA) means that all Level 1, Level 2 and 50% of the Level 3 success criteria that apply to the content types used are met assuming user agent support for only the technologies in the chosen baseline.

If a success criterion relates to a technology that is not used in the content (for example, there is no multimedia on the site), then that success criterion is met automatically.

Conformance claims

Conformance claims apply to Web units, and sets of Web units. (Web units often take the form of a traditional Web page but can also take the form of a fully interactive and immersive environment.)

Required components of a conformance claim

Conformance claims are not required. However, if you make a conformance claim then 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/2006/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 defining a set of URIs)

Optional components of a conformance claim:

  1. A list of additional success criteria that have been met beyond a standard claim

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

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

    • If a technology is "used but not relied upon," the content would still meet WCAG 2.0 at the stated conformance 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, or other pertinent information about the intended audience. The target audience information CANNOT specify anything related to disability or to physical, sensory or cognitive requirements.

Examples of conformance claims:

Example 1: On 23 March 2005, http://www.wondercall.example.com conforms to W3C's WCAG 2.0, Conformance Level A.The baseline for this claim is XHTML 1.0. The specification that this content "relies upon" is: HTML 4.01. The specifications that this content "uses but does not rely on" are: CSS2, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4.

Example 2: On 5 May 2006, "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to W3C's WCAG 2.0. Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. 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), and Real Video. The specifications that this content "uses but does not rely on" are: JavaScript 1.2, CSS2.

Example 3: On 21 June 2007, http://example.com/nav and http://example.com/docs conform to W3C's WCAG 2.0, Conformance Triple-A. The baseline is ISA-Baseline#2-2007 at http://ISA.example.gov/Baselines/BL2-2007. The specifications that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpeg, png. " The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.

Conformance notes

A Web Unit conforms to WCAG 2.0 at a given conformance level only if all content provided by that Web unit (including any secondary resources that are rendered as part of the Web 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 Web 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) (Refer to success criterion 4.2.1 .)

Aggregated content

Sometimes, a Web unit is assembled ("aggregated") from multiple sources that each may or may not have their own level of conformance. They may in fact not even be Web units of any kind - and thus would not, and sometimes could not, conform to all of the success criteria by themselves. These sources are called authored units ("some set of material created as a single entity by an author"). The conformance level for a Web unit that contains authored units is equal to the lowest conformance level claimed for the Web Unit content and any of the authored units it contains - including any claims pertaining to aggregated authored units. If individual authored units do not carry a conformance claim, then the claim must be based on the Web Unit with the authored units in place.

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. Example 3 above is a scoped conformance claim.

Scoping can include and exclude parts of a site. However processes and authored units must be evaluated in their entirety. If part of a Web unit that is part of a process or task does not conform at some level, then no conformance (at that level) can be made for any Web unit in the process. The same applies to authored units.

Example 1: An online store has a series of pages that are used to select and purchase products. All pages in the series must conform in order to claim conformance for any page that is part of the sequence.

Example 2: A site has a collection of videos for which it is not required to and does not want to claim accessibility. The videos are located in one location (e.g., example.com/movies). The conformance claim for the site or section of the site excludes the location that contains the videos. The conformance claim is valid as long as the Web units to which it applies only link to the videos instead of displaying them as part of the page (that is, as long as the videos are not treated as embedded content within a page for which conformance is being claimed).

Note: Linking to non-conforming content does not make a page inaccessible. Only if the inaccessible content is rendered together with the Web page (or other Web unit), or if the content is itself a Web unit within the set of URIs to which the conformance claim applies, or if the Web unit is part of a process for which a claim is made, would the content have to meet the guidelines in order for the claim to be valid.

This scoping provision does not preclude an organization, customer, or government from requiring that all parts of a site be accessible or meet some standard including WCAG. WCAG does not require that full Web sites conform, although that is certainly seen as desirable. A conformance claim only requires conformance for Web Units that are in the URI set described in the claim.

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 with creation or modification dates before 31 December 2006 conform to WCAG 1.0. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0."

How to refer to WCAG 2.0 from other documents

Information references

When being referenced in an informational fashion, the following format can be used.

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/, Latest version at http://www.w3.org/TR/WCAG20/)

When referring to WCAG 2.0 from another standard with a "should" statement

If WCAG 2.0 is being referred to from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG 2.0 should be referenced. This would mean that all three levels of WCAG 2.0 should be considered but that none are required. The format for referencing WCAG 2.0 from a should statement therefore is:

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)

When referring to WCAG 2.0 from another standard with a "shall" statement

When citing WCAG 2.0 as part of a requirement (e.g., a shall statement in a standard or regulation), the reference must include the specific parts of WCAG 2.0 that are intended to be required . When referencing WCAG 2.0 in this manner, the following rules apply;

  1. Conformance at any level of WCAG 2.0 requires that all of the Level 1 success criteria be met. References to WCAG 2.0 can not be for any subset of Level 1.

  2. Beyond Level 1, a "shall" reference may include any subset of provisions in Levels 2 and 3. That is, it is possible to require "all of Level 1 and [some specific list of SC success criteria in Level 2 and Level 3]" be met.

  3. If Double-A conformance to WCAG 2.0 is specified, then all Level 1 and all Level 2 success criteria must be met.

  4. If Triple-A conformance to WCAG 2.0 is specified, then all Level 1, all Level 2 and one half of the Level 3 items must be met.

Examples

To cite only the Level 1 success criteria (Single-A conformance).

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)

To cite the Levels 1& 2 success criteria (Double-A conformance).

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 & Level 2 success criteria. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)

To cite Level 1 success criteria and selected success criteria from Level 2 and Level 3 :

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)

Note: It is not recommended that Triple-A conformance ever be required site wide.

Example of use of a WCAG reference in a "SHALL" statement.

All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria plus Success Criteria 1.3.3, 1.3.4, 1.4.1, 2.4.2-6, 3.1.6 (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)

Referring to content from WCAG support documents

Techniques, which are listed in Understanding WCAG 2.0 and described in other supporting documents, are not part of the normative WCAG 2.0 Recommendation and should not be cited using the citation for the WCAG 2.0 Recommendation itself. If reference is to be made to techniques in support documents, they should be cited separately as techniques listed in Understanding WCAG 2.0 or as individual technique documents.

Techniques can be cited based on the individual Technique document or on the master WCAG 2.0 Techniques document. For example, the technique “Using alt attributes on img elements” could be cited as

"Using alt attributes on img elements”, W3C World Wide Web Consortium Note. (URL: http://www.w3.org/TR/NOTE-WCAG20-TECHS/UsingAltOnImg.html/)

or

W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URL: http://www.w3.org/TR/NOTE-WCAG20-TECHS/HTMLTechs.html)

Note: Techniques are not designed to be referenced as "required" from any standard or regulation.

WCAG 2.0 Guidelines

This section is normative.

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 all non-text content, one of the following is true: [How to meet 1.1.1]

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.2 For prerecorded multimedia, a combined document containing captions intermixed with audio description transcripts is available. [How to meet 1.1.2]

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]

Level 2 Success Criteria for Guideline 1.2

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

1.2.4 Captions are provided for live multimedia. [How to meet 1.2.4]

Level 3 Success Criteria for Guideline 1.2

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

Guideline 1.2 (media-equiv) Issues

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

Level 1 Success Criteria for Guideline 1.3

1.3.1 Information and relationships conveyed through presentation can be programmatically determined and notification of changes to these is available to user agents, including assistive technologies. [How to meet 1.3.1]

1.3.2 Any information that is conveyed by color is visually evident without color. [How to meet 1.3.2]

1.3.3 When the sequence of the content affects its meaning, that sequence can be programmatically determined. [How to meet 1.3.3]

Level 2 Success Criteria for Guideline 1.3

1.3.4 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.4]

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

Level 3 Success Criteria for Guideline 1.3

(No level 3 success criteria for this guideline.)

Guideline 1.3 (content-structure-separation) Issues

Guideline 1.4 Make it easy to distinguish foreground information from its background

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, have a luminosity contrast ratio of at least 5:1. [How to meet 1.4.1]

1.4.2 A mechanism is available to turn off background audio that plays automatically, without requiring the user to turn off all audio. [How to meet 1.4.2]

Level 3 Success Criteria for Guideline 1.4

1.4.3 Text or diagrams, and their background, 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, background sounds can be turned off, or 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 components 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.

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 operable in a non time-dependent manner 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.

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 interruptions involving an emergency. [How to meet 2.2.5]

2.2.6 When an authenticated session expires, 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 Content does not violate the general flash threshold or the red flash threshold. [How to meet 2.3.1]

Level 2 Success Criteria for Guideline 2.3

(No level 2 success criteria for this guideline.)

Level 3 Success Criteria for Guideline 2.3

2.3.2 Web units do not contain any compontents that flash more than three times in any one second period. [How to meet 2.3.2]

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 mistakes that do occur

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 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 Web 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 passage or phrase in the Web unit can be programmatically determined. [How to meet 3.1.2]

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

Level 3 Success Criteria for Guideline 3.1

3.1.3 A mechanism is available for identifying specific definitions of words or phrases 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, supplemental content is available that does not require reading ability more advanced than the lower secondary education level. [How to meet 3.1.5]

3.1.6 A mechanism is available for identifying specific pronunciation of words where meaning cannot be determined without pronunciation. [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]

3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order) unless the authored unit contains instructions before the control that describe the behavior. [How to meet 3.2.2]

Level 2 Success Criteria for Guideline 3.2

3.2.3 Navigational mechanisms that are repeated on multiple Web units within a set of Web units or other primary resources occur in the same relative order each time they are repeated unless a change is initiated by the user. [How to meet 3.2.3]

3.2.4 Components that have the same functionality within a set of Web 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 should be robust enough to work with current and future user agents (including assistive technologies)

Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies)

Level 1 Success Criteria for Guideline 4.1

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

4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. [How to meet 4.1.2]

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 (ensure-compat) Issues

Guideline 4.2 Ensure that content is accessible or provide an accessible alternative

Level 1 Success Criteria for Guideline 4.2

4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. [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. If content can be entered using the keyboard, then the content can be exited using the keyboard.

  2. Content conforms to success criterion 2.3.1 (general and red flash).

Level 2 Success Criteria for Guideline 4.2

4.2.3 At least one version of the content meets all level 2 success criteria, but alternate version(s) that do not meet all level 2 success criteria may be available from the same URI. [How to meet 4.2.3]

Level 3 Success Criteria for Guideline 4.2

4.2.4 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.4]

Guideline 4.2 (accessible-alternatives) Issues

Appendix A Glossary (Normative)

This section is normative.

abbreviation

shortened form of a word, phrase or name

Note: Includes initialisms and acronyms.

acronym

abbreviation made from the initial letters of a name or phrase that contains several words

Note: Many acronyms can be pronounced as words.

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

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

analog, time-dependent input

input whose result is different depending on the rate of the analog movement (such as when line width varies with pen speed or pressure.)

Note: Most actions carried out by a pointing device can also be done from the keyboard (e.g. clicking, selecting, moving, sizing, etc.). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion. This type of input can be best characterized (or identified) by the fact that the outcome can only be achieved by moving the pointer in a smooth fashion at a certain rate. For example, a watercolor program where stroke width and opacity is a depenent on the rate of movement (and/or pressure) of a "brush".

Application Programming Interface (API)

definitions of how communication may take place between applications

Note 1: Implementing APIs that are independent of a particular operating environment (as are the W3C DOM Level 2 specifications) may reduce implementation costs for multi-platform user agents and promote the development of multi-platform assistive technologies. Implementing conventional APIs for a particular operating environment may reduce implementation costs for assistive technology developers who wish to interoperate with more than one piece of software running on that operating environment.

Note 2: A "device API" defines how communication may take place with an input or output device such as a keyboard, mouse, or video card.

Note 3: In this document, an "input/output API" defines how applications or devices communicate with a user agent. As used in this document, input and output APIs include, but are not limited to, device APIs. Input and output APIs also include more abstract communication interfaces than those specified by device APIs. A "conventional input/output API" is one that is expected to be implemented by software running on a particular operating environment. For example, the conventional input APIs of the user agent are for the mouse and keyboard. For touch screen devices or mobile devices, conventional input APIs may include stylus, buttons, and voice. The graphical display and sound card are considered conventional output devices for a graphical desktop computer environment, and each has an associated API.

Note 4: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

ASCII art

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

Assistive technology (in the context of this document)

a user agent that:

  1. relies on services (such as retrieving Web content and parsing markup) provided by one or more other "host" user agents. Assistive technologies communicate data and messages with host user agents by using and monitoring APIs.

  2. provides services beyond those offered by the host user agents to meet the requirements of users with disabilities. Additional services include alternative renderings (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Example: Examples of assistive technologies that are important in the context of this document include the following:

  • screen magnifiers, which are used by people with visual disabilities to enlarge and change colors on the screen to improve the visual readability of rendered text and images.

  • screen readers, which are used by people who are blind or have reading disabilities to read textual information through synthesized speech or braille displays.

  • voice recognition software, which may be used by people who have some physical disabilities.

  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard.

  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

Note: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone.

Note 1: Audio descriptions of video provide information about actions, characters, scene changes and on-screen text.

Note 2: In standard audio description, narration is added during naturally-occurring pauses in dialog. (See also Extended audio descriptions.)

authored component

an authored unit intended to be used as a part of another authored unit

authored unit

set of material created as a single body by an author

Example 1: a collection consisting of markup, a style sheet, and an image or audio clip.

Example 2: a set of Web pages intended to be viewed only as a unit or in sequence.

Note: This definition based on Glossary of Terms for Device Independence.

baseline

set of technologies assumed to be supported by, and enabled in, user agents

Note: For more information on baselines and their use, refer to Technology Assumptions and the "baseline."

blink

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

captions

text presented and synchronized with multimedia to provide not only the speech, but also sound effects and sometimes speaker identification

Note: In some countries, the term "subtitle" is used to refer to dialog only and "captions" is used as the term for dialog plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.

changes of context

change of :

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web 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.

content

information to be communicated to the user by means of a user agent

Note: 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.

context-sensitive help

help text that provides information related to the function currently being performed

emergency

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

event handler

section of code that responds to an action taken by the user (or user agent)

Note: 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

Note: This technique is only used when the sense of the video would be lost without the additional audio description.

full corrected text screenplay including any interaction

document including correctly sequenced descriptions of all visual settings, actions, and non-speech sounds combined with descriptive transcripts of all dialogue and a means of achieving any outcomes that are achieved using interaction during the multimedia.

Note: A screenplay used to create the multimedia content would meet this definition only if it was corrected to accurately represent the final multimedia after editing etc.

functionality

processes and outcomes acheivable through user action

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 341 x 256 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 1: 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 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R, G, and B are the red, green, and blue RGB values of the color; FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and the "^" character is the exponentiation operatorAn "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.

Note 2: Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)

idioms

phrase whose meaning cannot be deduced from the meaning of the individual words and where you can't change the specific words without losing the meaning

Example 1: In English, "kicking the bucket" means dying. But you can't change it to "kicking the buckets" or "kicking the tub" or "booting the bucket" or "knocking over the bucket" without losing its meaning.

Example 2: In English, "spilling the beans" means revealing a secret. However, "knocking over the beans" or "spilling the vegetables" does not mean the same thing."

Example 3: In Japanese, the phrase "さじを投げる(どうするこ ともできなくなり、あきらめること" literally translates into "he threw a spoon". But it means that there was nothing he could do and finally he gave up.

Example 4: In Ducth, "Hij ging met de kippen op stok" literally translates into "He went to roost with the chickens". But it means that he went to bed early.

information
  1. a message to be sent and received

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

information is conveyed by color

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

informative

for information purposes and not required for conformance

Note: Content required for conformance is referred to as "normative."

initialism

shortened form of a name or phrase made from the initial letters of words or syllables contained in that name or phrase

Note: Not defined in all languages.

Example 1: SNCF is a French initialism that contains the initial letters of the Societe National des Chemins de Fer, the French national railroad.

Example 2: ESP is an initialism for extrasensory perception.

input error

information provided by the user that is not accepted

Note: This includes:

  1. information that is required by the Web 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

Example: The word StickyKeys is jargon from the field of assistive technology/accessibility.

keyboard interface

interface used by software to obtain keystroke input

Note 1: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.

Example: A touch screen PDA has a keyboard interface built into its OS and a connector for connecting external Keyboards. Applications on the PDA can use the interface to obtain keyboard input from either an external keyboard or from other applications that provide simulated keyboard output - such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality.

Note 2: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.

label

text, image or sound that is presented to a user to identify a component within Web content

live audio-only

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

live video-only

A time-based live presentation that 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 based on [UNESCO].

luminosity contrast ratio

(L1 + 0.05) / (L2 + 0.05), where L1 is the luminosity of the lighter of the text or background colors, and L2 is the luminosity of the darker of the text or background colors.

The luminosity of a color is defined as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2).

  • R, G, and B are the red, green, and blue RGB values of the color;

  • FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and

  • the "^" character is the exponentiation operator.

Note: Luminosity values can range from 0 (black) to 1 (white), and luminosity contrast ratios can range from 1 to 21.

mechanism

process or technique for achieving a result

multimedia

audio or video synchronized with another type of media and/or with time-based interactive components

name

text by which software can identify a component within Web content to the user

Note: The name may be hidden and only exposed by assistive technology, whereas a label is presented even without assistive technology. In many (but not all) cases, the label is a display of the name.

natural languages

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

Note: See also sign language interpretation.

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

Note: This includes ASCII Art, which is a pattern of characters.

normative

required for conformance

Note 1: One may conform in a variety of well-defined ways to this document.

Note 2: Content identified as "informative" or "non-normative" is never required for conformance.

parsed unambiguously

only one data structure that can result from parsing

Note: 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.

paused

stopped by user request and not restarted until requested by user

presentation

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

primary education level

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

Note: This definition based on [UNESCO].

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

programmatically set

set by software using methods that are user-agent-supported

pure decoration

serving only an aesthetic function, providing no information, and serving no function.

real-time event

event occurring at the same time as the viewing that is not completely generated by the content and is not pre-recorded

Example 1: A Webcast of a live performance.

Example 2: An on-line auction with people bidding.

Example 3: Live humans interacting in a fantasy world using avatars.

red flash threshold
  • 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 341 x 256 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

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

role

text or a number by which software can identify the function of a components within Web content

Example: A number that indicates whether an image functions as a hyperlink, command button, or check box.

same functionality

the outcome of their use is identical

Example: A submit "search" button on one Web page and a "find" button on another Web page 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

same position relative to other items

Note: 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

translation of spoken words and other audible information into a language that uses a simultaneous combination of handshapes, facial expressions, and orientation and movement of the hands, arms or body to convey meaning

Note: Although some languages have a signed counterpart, most sign languages are an independent language which is unrelated to the spoken language of the same country or culture.

specific sensory experience

a sensory experience that is not purely decorative and does not primarily convey important information or perform a function

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

  2. The way a collection of Web unit is organized

supplemental content

additional content that illustrates or clarifies default text content that users may use instead of, or in addition to, the default text content.

Example: Examples of supplemental content may include text, graphics and audio.

technology

markup language, programming language, style sheet, data format, or API

test or exercise that must use a particular sense

test where the content must be presented in a particular sensory format

Example: Color blindness test, hearing test, vision exercise, spelling test.

text

sequence of characters

Note: 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

unicode

universal character set that defines all the characters needed for writing the majority of living languages in use on computers

Note 1: 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.

Note 2: This definition based on [UNICODE]

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.

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

Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving and rendering Web content.

user-agent-supported

implemented by user agents and assistive technologies

Note: One of the factors that should be considered before adding a technology to a baseline would be the availability of affordable user agents and assistive technologies which support the technology.

variations in presentations in text

changes in the visual appearance or sound of the text, such as changing to a different font or a different voice

video

the technology of moving pictures or images

Note: Video can be made up of animated or photographic images, or both.

Web unit

collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (URLs etc.)

Note: This definition based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to cart to buy them.

Example 2: A Web page including all embedded images and media.

Wisconsin Computer Equivalence Algorithm for FPA

a method developed at the University of Wisconsin - working in conjunction with Dr. Graham Harding and Cambridge Research Associates for applying the United Kingdom's "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" to content displayed on a computer screen, such as Web pages and other computer content.

Note: The Ofcom Guidance Document [OFCOM] 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 Ofcom 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)

This section is informative.

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

 
L3

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

 

 
L2

 

 
L3

 

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

 

 

 
L2

 

 
Guideline 1.4 : Make it easy to distinguish foreground information from its background
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.

 
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 related to flickering or flashing content.

 

 
L3

 

 

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

 
L3

 
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 mistakes that do occur
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 phrases that have become part of the primary language of the content.

 
L3

 

 

 

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

 

 
L2

 

 
L3

 
Guideline 4.1 : Support compatibility with current and future user agents (including assistive technologies)
True Success Criterion Comments
L1

 

 
Guideline 4.2 : Ensure that content is accessible or provide an accessible alternative
True Success Criterion Comments
L1

 

  1. If content can be entered using the keyboard, then the content can be exited using the keyboard.

  2. Content conforms to success criterion 2.3.1 (general and red flash).

 
L2

 
L3

 

Appendix C Acknowledgements (Non-Normative)

This section is informative.

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)

This section is informative.

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)

This section is informative.

Editorial Note: Some links within the document still need to be be turned into references and 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 23 November 2005. This W3C Working Draft is available at http://www.w3.org/TR/2005/WD-WCAG20-20051123/. 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.
UNICODE
The Unicode Consortium. The Unicode Standard, Version 4.0.1, defined by: The Unicode Standard, Version 4.0 (Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), as amended by Unicode 4.0.1 (http://www.unicode.org/versions/Unicode4.0.1/).
OFCOM
Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" available at http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf)