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, and success criteria 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, photosensitivity and combinations of these. 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.

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 W3C strongly encourages broad community review of this Last Call Working Draft, and submission of comments on any issues which you feel could present a significant barrier to future adoption and implementation of WCAG 2.0. In particular, we encourage you to comment on the success criteria and the conformance model. Reviewers are encouraged to provide suggestions for how to address issues as well as supportive feedback and endorsements of the document.

This 27 April 2006 release of the Web Content Accessibility Guidelines 2.0 is a Last Call Working Draft by the Web Content Accessibility Guidelines Working Group (part of the Web Accessibility Initiative). Publication as a Last Call Working Draft indicates that the WCAG WG believes it has addressed all substantive issues and that the document is stable. The first public Working Draft of WCAG 2.0 was published 25 January 2001. Since then, the WCAG WG has published nine Working Drafts, addressed more than 1,000 issues, and developed a variety of support information for the guidelines. This publication of WCAG 2.0 is accompanied by the following documents:

Understanding WCAG 2.0 - which provides information about
each Guideline as well as describing how to meet each Success Criteria.

Techniques for WCAG 2.0 - which includes sufficient
techniques for each success criteria for various Web technologies including
HTML, CSS, SMIL and scripting.

After Last Call, the WCAG WG believes that WCAG 2.0 will be ready to
move on to the remaining stages of the W3C Recommendation Track Process:

Candidate Recommendation - collect implementation experience
on use of WCAG 2.0 to design and evaluate Web content for accessibility;

Proposed Recommendation - seek endorsement of the
specification from W3C Member organizations;

Recommendation - published by W3C as a technical report
appropriate for widespread deployment and the promotion of W3C's mission.

Comments on this working draft are due on or before 31 May 2006. To comment, please use one of the following standard response formats.

We are starting to gather implementation examples during this Last
Call review process. Implementation examples are examples of pages or sites
that conform to the proposed WCAG 2.0 at various levels of conformance.

This Last Call draft of WCAG 2.0 addresses all the open issues against the previous Working Draft. For a detailed list of changes since the last publication of this document, please refer to the History of Changes to WCAG 2.0 Working Drafts.

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.

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 content 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 many other 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 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:

This introduction

Information about conformance to WCAG 2.0

Guidelines with success criteria for each guideline

"How to meet" links to information on intent, sufficient techniques, examples, and benefits for each success criterion

A link to information about the Working Group's approach to defining baseline assumptions about the technologies that are available to end users

Appendices containing definitions, a checklist, references, and other support information.

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

Quality assurance 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.

Note: The development of techniques documents is an ongoing process. Developers are encouraged to submit new techniques at any time.

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.

Note: Application notes are a future component that will be developed in conjunction with the Education and Outreach Working Group.

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 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. To assist readers, there is a How to Meet link beside every success criterion that puts readers one click away from detailed information on that success criterion and two clicks away from the specific technique descriptions related to the success criterion.

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 WCAG 2.0's release is Authoring
Tool Accessibility Guidelines 1.0. However, version 2.0 is nearing completion and it is based on WCAG 2.0. The latest version of the Authoring Tool Accessibility Guidelines 2.0 can be found at http://www.w3.org/TR/ATAG20.

The Role of User Agents

Web content is always rendered by a user agent. A user agent is any software that retrieves and renders Web content for users and includes assistive technologies. Web content that conforms to WCAG 2.0 is most likely to be rendered correctly by user agents that conform to the User Agent Accessibility Guidelines (UAAG). For more information about the relationship between WCAG 2.0 and other WAI accessibility guidelines, see Essential Components of Web Accessibility.

The Four Principles of Accessibility

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

Content must be perceivable

Interface components in the content must be operable

Content and controls must be understandable

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

Important New Terms Used in WCAG 2.0

WCAG 2.0 includes several important new terms. These terms are defined in the Glossary (Appendix A: Glossary), and links to the definitions are provided whenever these and other important terms are used in the success criteria. The terms are introduced briefly here to make this new vocabulary easier to understand.

"Web unit" is one of these important new terms. Web pages are the most common type of Web unit. The broader term was chosen because it covers Web applications and other types of content to which the word "page" may not apply. A Web unit is any collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as a URL). For example, A Web page containing several images and a style sheet is a typical Web unit.

Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the author is responsible for ensuring that the content is delivered in such a way that software can access it. This is important in order to allow assistive technologies to recognize it and present it to the user, even if the user requires a different sensory modality than the original. For example, some assistive technologies convert text into speech or braille. This will also allow content in the future to be translated into simpler forms for people with cognitive disabilities, or to allow access by other agent based technologies. This can happen only if the content itself can be programmatically determined.

WCAG 2.0 also introduces the term "baseline” which allows WCAG 2.0 to adapt to changing technologies and to the needs of different countries and environments. Baselines are described in more detail in the conformance section and in About Baselines for WCAG 2.0.

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.

Level 1 success criteria:

Achieve a minimum level of accessibility.

Can reasonably be applied to all Web content.

Level 2 success criteria:

Achieve an enhanced level of accessibility.

Can reasonably be applied to all Web content.

Level 3 success criteria:

Achieve additional accessibility enhancements.

Can not necessarily be applied to all Web content.

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 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, authors 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. Authors must ensure that all information and functionality of the Web content conforms to WCAG 2.0 assuming that user agents support all of the technologies in the baseline and that they are enabled. Non-baseline technologies can also be used, but all information and functionality of the Web content must conform both with all non-baseline technologies turned on and with the technologies turned off. Both conditions are necessary since some users many have browsers that support them while others may not.

Who sets baselines?

Baselines may be set by many different entities including (but not limited to) authors, organizations, 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 (for example, state, country, etc.). Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time.

Some examples of scenarios leading to different 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 authors 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 Web sites 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: Baselines are not specified in terms of specific user agents, but 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

Authors may use technologies that are not in the specified baseline provided that the authors do not rely exclusively on those technologies for conveying any information or functionality. Also, the presence of the other technologies must not block the ability of the users to access the content via the technologies in the baseline. Specifically, the following must be true:

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

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

when used with user agents that only support the baseline technologies

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

Conformance levels and the baseline

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 specified baseline.

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 specified baseline.

WCAG 2.0 conformance at level Triple-A (AAA) means that all Level 1, Level 2 and at least half (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 specified baseline.

If a success criterion relates to a feature, component or type of content 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 the conformance claim must include the following assertions:

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

Note: The correct date will replace "YYYYMMDD" when WCAG 2.0 is published as a W3C Recommendation.

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

The baseline used to make the conformance claim. (The baseline technologies can be listed in the conformance claim, or, if the baseline is published elsewhere, the conformance claim can cite the baseline and provide a URI pointing to it.)

Scope of the claim (a URI, list of URI's, or a set of URIs defined by a regular expression)

Optional components of a conformance claim:

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

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)

o All of the technologies that are 'relied upon' must be in the baseline.

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.

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

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 HTML 4.01. 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. Authored units are defined as "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 apply to only some parts of a Web site. 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 cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria.

While scoping can include and exclude parts of a site, processes (such as shopping) and authored units must be considered 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 claim can be made at that level for any Web unit in that 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.php). 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 1:
Linking to non-conforming content is not prohibited. Linking to non-conformant content is allowed, except when one of the following is true:

the content is rendered together with the Web page (or other Web unit), or

the content is itself a Web unit within the set of URIs to which the conformance claim applies, or

the content is a Web unit that is part of a process for which a claim is made.

Note 2:
In any of these cases, the content would 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 and meet some conformance level of WCAG 2.0. WCAG 2.0 does not require that full Web sites conform, although that is certainly desirable.

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 Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0.

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

How to refer to WCAG 2.0 from other documents

Information references

When referencing WCAG 2.0 in an informational fashion, the following format can be used.

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

When referencing WCAG 2.0 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:

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:

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.

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 success criteria in Level 2 and Level 3]" be met.

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

If Triple-A conformance to WCAG 2.0 is specified, then all Level 1, and all Level 2 success criteria as well as at least 50% of the Level 3 success criteria that apply to the content types used must be met.

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. References to techniques in support documents should be cited separately.

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

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

If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.

Level 3 Success Criteria for Guideline 1.4

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 four times (4x) quieter or louder. Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

Level 3 Success Criteria for Guideline 2.1

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 that 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 ten 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.

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

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]

Actions are reversible.

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

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

Guideline 3.2 Make the placement and functionality of content predictable.

Level 1 Success Criteria for Guideline 3.2

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]

Appendix A: Glossary (Normative)

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 (for example, clicking, selecting, moving, sizing). 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 by the fact that the outcome can only be achieved by moving the pointer in a smooth fashion at a certain rate. For example, in a watercolor program stroke width and opacity may depend 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.

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.

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.

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 dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.

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 device-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 audiovisual presentation by pausing the video so that there is time to add additional description

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

full multimedia text alternative 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.

functionality

processes and outcomes achievable through user action

general flash threshold

A sequence of flashes or rapidly changing image sequences where all three of the following occur:

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 x 768 pixels;

there are more than three flashes within any one-second period; and

the flashing is below 50 Hz.

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 operator. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. This applies only when the brightness of the darker image is below .80 of full scale white brightness.

phrase whose meaning cannot be deduced from the meaning of the individual words and the specific words cannot be changed without losing the meaning

Example 1:
In English, "kicking the bucket" means "dying". But the phrase cannot be changed 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 Dutch, "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

a message to be sent and received

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

information that is conveyed by color

information presented in a manner that depends entirely on the ability to perceive color

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 operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from 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.

serving only an aesthetic purpose, providing no information, and having no functionality.

real-time event

event that a) occurs at the same time as the viewing, b) is not completely generated by the content, and c) 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 all three of the following occur:

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 x 768 pixels.

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

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

same functionality

identical result when used

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 the 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 independent languages that are 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

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

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 is the availability of affordable user agents and assistive technologies which support the technology.

variations in presentations of 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

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

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

If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.

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 four times (4x) quieter or louder. Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

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

True

Success Criterion

Comments

L1

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 that 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 ten 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.

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]

Actions are reversible.

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

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

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]

L2

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]

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

Appendix C: Acknowledgements (Non-Normative)

This section is informative.

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.

Priority 1 checkpoints

This mapping shows how the WCAG 1.0 checkpoints relate to the WCAG 2.0 Last Call Working Draft released 27 April 2006. Note that WCAG 2.0 is still a draft and the WCAG 2.0 Guidelines and success criteria in no way supersede the checkpoints in WCAG 1.0.

The Web Content Accessibility Guidelines Working Group is working carefully to enable organizations and individuals that are currently using WCAG 1.0 (which remains a stable and referenceable document) to ensure that they will be able to make a smooth transition to WCAG 2.0 when it is released.

If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.

Images used as bullets are also covered in Guideline 1.3 with regard to CSS usage. For framesets, noframes is no longer required. For multimedia, alternatives (beyond labels) are covered under Guideline 1.2. ASCII art is non-text content.

2.1: Ensure that all information conveyed with color is also available without color, for example from context or markup.

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

Note: Identification of the language for individual words is no longer required.

6.1: Organize documents so they may be read without style sheets.
For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

This is baseline-dependent:

if style sheets are in your baseline, WCAG 1.0 checkpoint 6.1 is not required;

if style sheets are not in your baseline, then WCAG 1.0 checkpoint 6.1 is required at Level 1 (as it maps to Guideline 1.3 L1)

6.2: Ensure that equivalents for dynamic content are updated when the dynamic content changes.

Text alternatives are addressed in Guideline 1.1, 1.2, and 4.2. If providing a text alternative for content and that content changes, then the text alternative must also be changed or else you don't conform to Guideline 1.1, 1.2, and 4.2 anymore.

7.1: Until user agents allow users to control flickering, avoid causing the screen to flicker.

If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.

If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.

6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

For any technologies (scripts, applets, or other programmatic objects) not in the specified baseline, the following are true:

The Web content still conforms using user agents that only support the technologies that are in the baseline (i.e. the use of technologies that are not in the baseline does not "break" access to the Web content by user agents that don't support those technologies.)

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

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.
(Level 1)

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.
(Level 2)

And if you use multimedia (Priority 1)

WCAG 2.0 Success Criteria

1.3: Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.

11.4: If, after best efforts, you cannot create an accessible page,
provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

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.
(Level 1)

4.2.2Content meets the following criteria even if the content uses a technology that is not in the chosen baseline:
(Level 1)

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

Priority 2 checkpoints

In General (Priority 2)

WCAG 2.0 Success Criteria

2.2: Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].

Note: Validating to published formal grammars is a stronger requirement than unambiguous parsing required by Success Criterion 4.1.1 but is one of the sufficient techniques for this success criterion. Refer to How to Meet Success Criterion 4.1.1

7.4: Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.

2.2.1 For each time-out that is a function of the content, at least one of the following is true:
(Level 1)

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

the user is allowed to adjust the time-out over a wide range that 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 ten 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.

10.1: Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

3.2.1 When any component receives focus, it does not cause a change of context.
(Level 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.
(Level 1)

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.
(Level 2)

The "until user agents" clause has been satisfied, so it is no longer necessary to avoid movement altogether, as long as authors do not do anything to interfere with the user's ability to pause the content. The prohibition has therefore been replaced with this success criterion 2.2.3

8.1: Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies
[Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

Note: This technique is no longer needed for user agents but may be useful for people with cognitive disabilities.

11.3: Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

This checkpoint does not map to any WCAG 2.0 success criterion, though certain aspects may map to certain success criteria or to advisory item (see Situation B under How to Meet Success Criterion 4.2.1, for example). Content negotiation is discussed briefly in "Conformance to Web Content Accessibility Guidelines 2.0."

13.5: Provide navigation bars to highlight and give access to the navigation mechanism.

This checkpoint is not required by any success criterion in WCAG 2.0. It is a possible strategy to address SC 2.4.2 (level 2). If navigation bars are used, SC 3.2.3 (level 2) applies.

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.
(Level 2)

13.6: Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web units.
(Level 1)

Note: In WCAG 2.0, this requirement applies only to groups that are repeated on multiple delivery units.

13.7: If search functions are provided, enable different types of searches for different skill levels and preferences.

Note: This checkpoint does not directly map to any WCAG 2.0 Success Criterion and is not required. Some aspects relate to 2.4.2 (level 2) and 2.5.4 (level 3) as well as advisory items in Understanding WCAG 2.0.

13.8: Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

This checkpoint is not required by any Success Criterion in WCAG 2.0. . Part of this maps to optional techniqueStarting section headings with unique information for SC 2.4.5 (level 3).

Aspects of WCAG 1.0 Checkpoint 14.3 are required by WCAG 2.0 Guideline 3.2.3 (level 2), 3.2.4 (level 2). There is no Success Criterion in WCAG 2.0 that is as broad as WCAG 1.0 Checkpoint 14.3, so aspects of it do not relate.

This is no longer required for conformance, but a potentially useful technique.

10.3: Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.

WCAG 1.0 Checkpoint 10.3 is no longer required for conformance to WCAG 2.0.

Guideline 1.4

Guideline 2.4

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.
(Level 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:
(Level 2)

Actions are reversible.

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

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

Guideline 1.2

Guideline 1.4

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.
(Level 3)

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

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.
(Level 3)

2.2.5 Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency.
(Level 3)

2.2.6 When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.
(Level 3)