CITY OF WEST LAFAYETTE REQUEST FOR PROPOSAL

ENTERPRISE RESOURCE PLANNING SYSTEM ADDENDUM #2

DATE: April 1, 2013 Question #1: Would you be able to provide a copy of the WC3 WAI’s Web Content Accessibility Guidelines 2.0 referenced in your RFP? Answer: The Web Content Accessibility Guidelines 2.0. are attached. Other related information follows. The website this info can be found at is: http://www.w3.org/

Web Content Accessibility Guidelines (WCAG) 2.0

[contents]

Web Content Accessibility Guidelines (WCAG) 2.0

W3C Recommendation 11 December 2008

This version:http://www.w3.org/TR/2008/REC-WCAG20-20081211/

Latest version:http://www.w3.org/TR/WCAG20/

Previous version:http://www.w3.org/TR/2008/PR-WCAG20-20081103/

Editors:Ben Caldwell, Trace R&D Center, University of Wisconsin-MadisonMichael Cooper, W3CLoretta Guarino Reid, Google, Inc.Gregg Vanderheiden, Trace R&D Center, University of Wisconsin-Madison

Previous Editors:Wendy Chisholm (until July 2006 while at W3C)John Slatin (until June 2006 while at Accessibility Institute, University of Texas at Austin)Jason White (until June 2005 while at University of Melbourne)

Please refer to the errata for this document, which may include normative corrections.

See also translations.

This document is also available in non-normative formats, available from Alternate Versions of Web

Content Accessibility Guidelines 2.0.

Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and

document use rules apply.

Abstract

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making

Web content more accessible. Following these guidelines will make content accessible to a wider range

of people with disabilities, including blindness and low vision, deafness and hearing loss, learning

disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and

combinations of these. Following these guidelines will also often make your Web content more usable to

users in general.

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, is provided in separate documents. See Web Content

Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and

educational material.

WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a

W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG

2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also

recommends that Web accessibility policies reference WCAG 2.0.

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

This is the Web Content Accessibility Guidelines (WCAG) 2.0 W3C Recommendation from the Web

Content Accessibility Guidelines Working Group.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups

and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable

document and may be used as reference material or cited from another document. W3C's role in making

the Recommendation is to draw attention to the specification and to promote its widespread deployment.

This enhances the functionality and interoperability of the Web.

WCAG 2.0 is supported by the associated non-normative documents, Understanding WCAG 2.0 and

Techniques for WCAG 2.0. Although those documents do not have the formal status that WCAG 2.0

itself has, they provide information important to understanding and implementing WCAG.

The Working Group requests that any comments be made using the provided online comment form. If

this is not possible, comments can also be sent to public-comments-wcag20@w3.org. The archives for

the public comments list are publicly available. Comments received on the WCAG 2.0 Recommendation

cannot result in changes to this version of the guidelines, but may be addressed in errata or future

versions of WCAG. The Working Group does not plan to make formal responses to comments. Archives

of the WCAG WG mailing list discussions are publicly available, and future work undertaken by the

Working Group may address comments received on this document.

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of

the WCAG Working Group are discussed in the WCAG Working Group charter. The WCAG Working

Group is part of the WAI Technical Activity.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C

maintains a public list of any patent disclosures made in connection with the deliverables of the group;

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) must disclose the information in

accordance with section 6 of the W3C Patent Policy.

Table of Contents

IntroductionWCAG 2.0 Layers of Guidance

WCAG 2.0 Supporting Documents

Important Terms in WCAG 2.0

WCAG 2.0 Guidelines1 Perceivable

1.1 Provide text alternatives for any non-text content so that it can be changed intoother forms people need, such as large print, braille, speech, symbols or simplerlanguage.

1.2 Provide alternatives for time-based media.

1.3 Create content that can be presented in different ways (for example simplerlayout) without losing information or structure.

1.4 Make it easier for users to see and hear content including separating foregroundfrom background.

2 Operable2.1 Make all functionality available from a keyboard.

2.2 Provide users enough time to read and use content.

2.3 Do not design content in a way that is known to cause seizures.

2.4 Provide ways to help users navigate, find content, and determine where they are.

3 Understandable3.1 Make text content readable and understandable.

3.2 Make Web pages appear and operate in predictable ways.

3.3 Help users avoid and correct mistakes.

4 Robust4.1 Maximize compatibility with current and future user agents, including assistivetechnologies.

ConformanceConformance Requirements

Conformance Claims (Optional)

Statement of Partial Conformance - Third Party Content

Statement of Partial Conformance - Language

Appendices

Appendix A: Glossary (Normative)

Appendix B: Acknowledgments

Appendix C: References

Introduction

This section is informative.

Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible

to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory,

physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines

cover a wide range of issues, they are not able to address the needs of people with all types, degrees,

and combinations of disability. These guidelines also make Web content more usable by older

individuals with changing abilities due to aging and often improve usability for users in general.

WCAG 2.0 is developed through the W3C process in cooperation with individuals and organizations

around the world, with a goal of providing a shared standard for Web content accessibility that meets the

needs of individuals, organizations, and governments internationally. WCAG 2.0 builds on WCAG 1.0

[WCAG10] and is designed to apply broadly to different Web technologies now and in the future, and to

be testable with a combination of automated testing and human evaluation. For an introduction to

WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.

Web accessibility depends not only on accessible content but also on accessible Web browsers and

other user agents. Authoring tools also have an important role in Web accessibility. For an overview of

how these components of Web development and interaction work together, see:

Essential Components of Web Accessibility

User Agent Accessibility Guidelines (UAAG) Overview

Authoring Tool Accessibility Guidelines (ATAG) Overview

WCAG 2.0 Layers of Guidance

The individuals and organizations that use WCAG vary widely and include Web designers and

developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying

needs of this audience, several layers of guidance are provided including overall principles, general

guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques,

and documented common failures with examples, resource links and code.

Principles - At the top are four principles that provide the foundation for Web accessibility:

perceivable, operable, understandable, and robust. See also Understanding the Four Principles

of Accessibility.

Guidelines - Under the principles are guidelines. The 12 guidelines provide the basic goals that

authors should work toward in order to make content more accessible to users with different

disabilities. The guidelines are not testable, but provide the framework and overall objectives to

help authors understand the success criteria and better implement the techniques.

Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.0

to be used where requirements and conformance testing are necessary such as in design

specification, purchasing, regulation, and contractual agreements. In order to meet the needs of

different groups and different situations, three levels of conformance are defined: A (lowest), AA,

and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels

of Conformance.

Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the

WCAG 2.0 document itself, the working group has also documented a wide variety of techniques.

The techniques are informative and fall into two categories: those that are sufficient for meeting

the success criteria and those that are advisory. The advisory techniques go beyond what is

required by the individual success criteria and allow authors to better address the guidelines.

Some advisory techniques address accessibility barriers that are not covered by the testable

success criteria. Where common failures are known, these are also documented. See also

Sufficient and Advisory Techniques in Understanding WCAG 2.0.

All of these layers of guidance (principles, guidelines, success criteria, and sufficient and advisory

techniques) work together to provide guidance on how to make content more accessible. Authors are

encouraged to view and apply all layers that they are able to, including the advisory techniques, in order

to best address the needs of the widest possible range of users.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with

all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.

Authors are encouraged to consider the full range of techniques, including the advisory techniques, as

well as to seek relevant advice about current best practice to ensure that Web content is accessible, as

far as possible, to this community. Metadata may assist users in finding content most suitable for their

needs.

WCAG 2.0 Supporting Documents

The WCAG 2.0 document is designed to meet the needs of those who need a stable, referenceable

technical standard. Other documents, called supporting documents, are based on the WCAG 2.0

document and address other important purposes, including the ability to be updated to describe how

WCAG would be applied with new technologies. Supporting documents include:

1. How to Meet WCAG 2.0 - A customizable quick reference to WCAG 2.0 that includes all of the

guidelines, success criteria, and techniques for authors to use as they are developing and

evaluating Web content.

2. Understanding WCAG 2.0 - A guide to understanding and implementing WCAG 2.0. There is a

short "Understanding" document for each guideline and success criterion in WCAG 2.0 as well as

key topics.

3. Techniques for WCAG 2.0 - A collection of techniques and common failures, each in a separate

document that includes a description, examples, code and tests.

4. The WCAG 2.0 Documents - A diagram and description of how the technical documents are

related and linked.

See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.0

supporting material, including education resources related to WCAG 2.0. Additional resources covering

topics such as the business case for Web accessibility, planning implementation to improve the

accessibility of Web sites, and accessibility policies are listed in WAI Resources.

Important Terms in WCAG 2.0

WCAG 2.0 includes three important terms that are different from WCAG 1.0. Each of these is introduced

briefly below and defined more fully in the glossary.

Web Page

It is important to note that, in this standard, the term "Web page" includes much more than

static HTML pages. It also includes the increasingly dynamic Web pages that are emerging on

the Web, including "pages" that can present entire virtual interactive communities. For

example, the term "Web page" includes an immersive, interactive movie-like experience found

at a single URI. For more information, see Understanding "Web Page".

Programmatically Determined

Several success criteria require that content (or certain aspects of content) can be

"programmatically determined." This means that the content is delivered in such a way that

user agents, including assistive technologies, can extract and present this information to users

in different modalities. For more information, see Understanding Programmatically Determined.

Accessibility Supported

Using a technology in a way that is accessibility supported means that it works with assistive

technologies (AT) and the accessibility features of operating systems, browsers, and other user

agents. Technology features can only be relied upon to conform to WCAG 2.0 success criteria

if they are used in a way that is "accessibility supported". Technology features can be used in

ways that are not accessibility supported (do not work with assistive technologies, etc.) as long

as they are not relied upon to conform to any success criterion (i.e., the same information or

functionality is also available another way that is supported).

The definition of "accessibility supported" is provided in the Appendix A: Glossary section of

these guidelines. For more information, see Understanding Accessibility Support.

WCAG 2.0 Guidelines

This section is normative.

Principle 1: Perceivable - Information and user interface components mustbe presentable to users in ways they can perceive.

Guideline 1.1 Text Alternatives: Provide text alternativesfor any non-text content so that it can be changed intoother forms people need, such as large print, braille,speech, symbols or simpler language.

Understanding Guideline 1.1

1.1.1 Non-text Content: All non-text content that is presented to the user

has a text alternative that serves the equivalent purpose, except for the

situations listed below. (Level A)

Controls, Input: If non-text content is a control or accepts user

input, then it has a name that describes its purpose. (Refer to

Guideline 4.1 for additional requirements for controls and content that

accepts user input.)

Time-Based Media: If non-text content is time-based media, then

text alternatives at least provide descriptive identification of the non-

text content. (Refer to Guideline 1.2 for additional requirements for

media.)

Test: If non-text content is a test or exercise that would be invalid if

presented in text, then text alternatives at least provide descriptive

identification of the non-text content.

Sensory: If non-text content is primarily intended to create a specific

sensory experience, then text alternatives at least provide descriptive

identification of the non-text content.

CAPTCHA: If the purpose of non-text content is to confirm that

content is being accessed by a person rather than a computer, then

text alternatives that identify and describe the purpose of the non-text

content are provided, and alternative forms of CAPTCHA using output

modes for different types of sensory perception are provided to

accommodate different disabilities.

Decoration, Formatting, Invisible: If non-text content is pure

decoration, is used only for visual formatting, or is not presented to

users, then it is implemented in a way that it can be ignored by

assistive technology.

How to Meet 1.1.1 Understanding 1.1.1

Guideline 1.2 Time-based Media: Provide alternatives fortime-based media.

Understanding Guideline 1.2

1.2.1 Audio-only and Video-only (Prerecorded): For prerecorded audio-

only and prerecorded video-only media, the following are true, except when

the audio or video is a media alternative for text and is clearly labeled as

such: (Level A)

Prerecorded Audio-only: An alternative for time-based media is

provided that presents equivalent information for prerecorded audio-

How to Meet 1.2.1 Understanding 1.2.1

only content.

Prerecorded Video-only: Either an alternative for time-based media

or an audio track is provided that presents equivalent information for

prerecorded video-only content.

1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded

audio content in synchronized media, except when the media is a media

alternative for text and is clearly labeled as such. (Level A)

How to Meet 1.2.2 Understanding 1.2.2

1.2.3 Audio Description or Media Alternative (Prerecorded): An

alternative for time-based media or audio description of the prerecorded

video content is provided for synchronized media, except when the media

is a media alternative for text and is clearly labeled as such. (Level A)

How to Meet 1.2.3 Understanding 1.2.3

1.2.4 Captions (Live): Captions are provided for all live audio content in

synchronized media. (Level AA)How to Meet 1.2.4

Understanding 1.2.4

1.2.5 Audio Description (Prerecorded): Audio description is provided for

all prerecorded video content in synchronized media. (Level AA)How to Meet 1.2.5

Understanding 1.2.5

1.2.6 Sign Language (Prerecorded): Sign language interpretation is

provided for all prerecorded audio content in synchronized media. (Level

AAA)

How to Meet 1.2.6 Understanding 1.2.6

1.2.7 Extended Audio Description (Prerecorded): Where pauses in

foreground audio are insufficient to allow audio descriptions to convey the

sense of the video, extended audio description is provided for all

prerecorded video content in synchronized media. (Level AAA)

How to Meet 1.2.7 Understanding 1.2.7

1.2.8 Media Alternative (Prerecorded): An alternative for time-based

media is provided for all prerecorded synchronized media and for all

prerecorded video-only media. (Level AAA)

How to Meet 1.2.8 Understanding 1.2.8

1.2.9 Audio-only (Live): An alternative for time-based media that presents

equivalent information for live audio-only content is provided. (Level AAA)How to Meet 1.2.9

Understanding 1.2.9

Guideline 1.3 Adaptable: Create content that can bepresented in different ways (for example simpler layout)without losing information or structure.

Understanding Guideline 1.3

1.3.1 Info and Relationships: Information, structure, and relationships

conveyed through presentation can be programmatically determined or are

available in text. (Level A)

How to Meet 1.3.1 Understanding 1.3.1

1.3.2 Meaningful Sequence: When the sequence in which content is How to Meet 1.3.2

presented affects its meaning, a correct reading sequence can be

programmatically determined. (Level A)

Understanding 1.3.2

1.3.3 Sensory Characteristics: Instructions provided for understanding

and operating content do not rely solely on sensory characteristics of

components such as shape, size, visual location, orientation, or sound.

(Level A)

Note: For requirements related to color, refer to Guideline 1.4.

How to Meet 1.3.3 Understanding 1.3.3

Guideline 1.4 Distinguishable: Make it easier for users tosee and hear content including separating foregroundfrom background.

Understanding Guideline 1.4

1.4.1 Use of Color: Color is not used as the only visual means of

conveying information, indicating an action, prompting a response, or

distinguishing a visual element. (Level A)

Note: This success criterion addresses color perception specifically.

Other forms of perception are covered in Guideline 1.3 including

programmatic access to color and other visual presentation coding.

How to Meet 1.4.1 Understanding 1.4.1

1.4.2 Audio Control: If any audio on a Web page plays automatically for

more than 3 seconds, either a mechanism is available to pause or stop the

audio, or a mechanism is available to control audio volume independently

from the overall system volume level. (Level A)

Note: Since any content that does not meet this success criterion can

interfere with a user's ability to use the whole page, all content on the

Web page (whether or not it is used to meet other success criteria) must

meet this success criterion. See Conformance Requirement 5: Non-

Interference.

How to Meet 1.4.2 Understanding 1.4.2

1.4.3 Contrast (Minimum): The visual presentation of text and images of

text has a contrast ratio of at least 4.5:1, except for the following: (Level

AA)

Large Text: Large-scale text and images of large-scale text have a

contrast ratio of at least 3:1;

Incidental: Text or images of text that are part of an inactive user

interface component, that are pure decoration, that are not visible to

anyone, or that are part of a picture that contains significant other

visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no

minimum contrast requirement.

How to Meet 1.4.3 Understanding 1.4.3

1.4.4 Resize text: Except for captions and images of text, text can be

resized without assistive technology up to 200 percent without loss of

content or functionality. (Level AA)

How to Meet 1.4.4 Understanding 1.4.4

1.4.5 Images of Text: If the technologies being used can achieve the

visual presentation, text is used to convey information rather than images

of text except for the following: (Level AA)

Customizable: The image of text can be visually customized to the

user's requirements;

Essential: A particular presentation of text is essential to the

information being conveyed.

Note: Logotypes (text that is part of a logo or brand name) are considered

essential.

How to Meet 1.4.5 Understanding 1.4.5

1.4.6 Contrast (Enhanced): The visual presentation of text and images of

text has a contrast ratio of at least 7:1, except for the following: (Level

AAA)

Large Text: Large-scale text and images of large-scale text have a

contrast ratio of at least 4.5:1;

Incidental: Text or images of text that are part of an inactive user

interface component, that are pure decoration, that are not visible to

anyone, or that are part of a picture that contains significant other

visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no

minimum contrast requirement.

How to Meet 1.4.6 Understanding 1.4.6

1.4.7 Low or No Background Audio: For prerecorded audio-only content

that (1) contains primarily speech in the foreground, (2) is not an audio

CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily

musical expression such as singing or rapping, at least one of the following

is true: (Level AAA)

No Background: The audio does not contain background sounds.

Turn Off: The background sounds can be turned off.

20 dB: The background sounds are at least 20 decibels lower than

the foreground speech content, with the exception of occasional

sounds that last for only one or two seconds.

Note: Per the definition of "decibel," background sound that meets

this requirement will be approximately four times quieter than the

foreground speech content.

How to Meet 1.4.7 Understanding 1.4.7

1.4.8 Visual Presentation: For the visual presentation of blocks of text, a

mechanism is available to achieve the following: (Level AAA)

1. Foreground and background colors can be selected by the user.

2. Width is no more than 80 characters or glyphs (40 if CJK).

3. Text is not justified (aligned to both the left and the right margins).

4. Line spacing (leading) is at least space-and-a-half within paragraphs,

and paragraph spacing is at least 1.5 times larger than the line

spacing.

5. Text can be resized without assistive technology up to 200 percent in

a way that does not require the user to scroll horizontally to read a

line of text on a full-screen window.

How to Meet 1.4.8 Understanding 1.4.8

1.4.9 Images of Text (No Exception): Images of text are only used for How to Meet 1.4.9

Principle 2: Operable - User interface components and navigation must beoperable.

pure decoration or where a particular presentation of text is essential to the

information being conveyed. (Level AAA)

Note: Logotypes (text that is part of a logo or brand name) are considered

essential.

Understanding 1.4.9

Guideline 2.1 Keyboard Accessible: Make all functionalityavailable from a keyboard.

Understanding Guideline 2.1

2.1.1 Keyboard: All functionality of the content is operable through a

keyboard interface without requiring specific timings for individual

keystrokes, except where the underlying function requires input that

depends on the path of the user's movement and not just the endpoints.

(Level A)

Note 1: This exception relates to the underlying function, not the input

technique. For example, if using handwriting to enter text, the input

technique (handwriting) requires path-dependent input but the underlying

function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse

input or other input methods in addition to keyboard operation.

How to Meet 2.1.1 Understanding 2.1.1

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component

of the page using a keyboard interface, then focus can be moved away

from that component using only a keyboard interface, and, if it requires

more than unmodified arrow or tab keys or other standard exit methods,

the user is advised of the method for moving focus away. (Level A)

Note: Since any content that does not meet this success criterion can

interfere with a user's ability to use the whole page, all content on the

Web page (whether it is used to meet other success criteria or not) must

meet this success criterion. See Conformance Requirement 5: Non-

Interference.

How to Meet 2.1.2 Understanding 2.1.2

2.1.3 Keyboard (No Exception): All functionality of the content is

operable through a keyboard interface without requiring specific timings for

individual keystrokes. (Level AAA)

How to Meet 2.1.3 Understanding 2.1.3

Guideline 2.2 Enough Time: Provide users enough timeto read and use content.

Understanding Guideline 2.2

2.2.1 Timing Adjustable: For each time limit that is set by the content, at

least one of the following is true: (Level A)

Turn off: The user is allowed to turn off the time limit before

encountering it; or

Adjust: The user is allowed to adjust the time limit before

encountering it over a wide range that is at least ten times the length

of the default setting; or

Extend: The user is warned before time expires and given at least 20

seconds to extend the time limit with a simple action (for example,

"press the space bar"), and the user is allowed to extend the time

limit at least ten times; or

Real-time Exception: The time limit is a required part of a real-time

event (for example, an auction), and no alternative to the time limit is

possible; or

Essential Exception: The time limit is essential and extending it

would invalidate the activity; or

20 Hour Exception: The time limit is longer than 20 hours.

Note: This success criterion helps ensure that users can complete tasks

without unexpected changes in content or context that are a result of a

time limit. This success criterion should be considered in conjunction with

Success Criterion 3.2.1, which puts limits on changes of content or

context as a result of user action.

How to Meet 2.2.1 Understanding 2.2.1

2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating

information, all of the following are true: (Level A)

Moving, blinking, scrolling: For any moving, blinking or scrolling

information that (1) starts automatically, (2) lasts more than five

seconds, and (3) is presented in parallel with other content, there is a

mechanism for the user to pause, stop, or hide it unless the

movement, blinking, or scrolling is part of an activity where it is

essential; and

Auto-updating: For any auto-updating information that (1) starts

automatically and (2) is presented in parallel with other content, there

is a mechanism for the user to pause, stop, or hide it or to control

the frequency of the update unless the auto-updating is part of an

activity where it is essential.

Note 1: For requirements related to flickering or flashing content, refer to

Guideline 2.3.

Note 2: Since any content that does not meet this success criterion can

interfere with a user's ability to use the whole page, all content on the

Web page (whether it is used to meet other success criteria or not) must

meet this success criterion. See Conformance Requirement 5: Non-

Interference.

Note 3: Content that is updated periodically by software or that is

streamed to the user agent is not required to preserve or present

information that is generated or received between the initiation of the

pause and resuming presentation, as this may not be technically

possible, and in many situations could be misleading to do so.

How to Meet 2.2.2 Understanding 2.2.2

Note 4: An animation that occurs as part of a preload phase or similar

situation can be considered essential if interaction cannot occur during

that phase for all users and if not indicating progress could confuse users

or cause them to think that content was frozen or broken.

2.2.3 No Timing: Timing is not an essential part of the event or activity

presented by the content, except for non-interactive synchronized media

and real-time events. (Level AAA)

How to Meet 2.2.3 Understanding 2.2.3

2.2.4 Interruptions: Interruptions can be postponed or suppressed by the

user, except interruptions involving an emergency. (Level AAA)How to Meet 2.2.4

Understanding 2.2.4

2.2.5 Re-authenticating: When an authenticated session expires, the

user can continue the activity without loss of data after re-authenticating.

(Level AAA)

How to Meet 2.2.5 Understanding 2.2.5

Guideline 2.3 Seizures: Do not design content in a waythat is known to cause seizures.

Understanding Guideline 2.3

2.3.1 Three Flashes or Below Threshold: Web pages do not contain

anything that flashes more than three times in any one second period, or

the flash is below the general flash and red flash thresholds. (Level A)

Note: Since any content that does not meet this success criterion can

interfere with a user's ability to use the whole page, all content on the

Web page (whether it is used to meet other success criteria or not) must

meet this success criterion. See Conformance Requirement 5: Non-

Interference.

How to Meet 2.3.1 Understanding 2.3.1

2.3.2 Three Flashes: Web pages do not contain anything that flashes

more than three times in any one second period. (Level AAA)How to Meet 2.3.2

Understanding 2.3.2

Guideline 2.4 Navigable: Provide ways to help usersnavigate, find content, and determine where they are.

Understanding Guideline 2.4

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of

content that are repeated on multiple Web pages. (Level A)How to Meet 2.4.1

Understanding 2.4.1

2.4.2 Page Titled: Web pages have titles that describe topic or purpose.

(Level A)How to Meet 2.4.2

Understanding 2.4.2

2.4.3 Focus Order: If a Web page can be navigated sequentially and the

navigation sequences affect meaning or operation, focusable componentsHow to Meet 2.4.3

Understanding 2.4.3

Principle 3: Understandable - Information and the operation of userinterface must be understandable.

receive focus in an order that preserves meaning and operability. (Level A)

2.4.4 Link Purpose (In Context): The purpose of each link can be

determined from the link text alone or from the link text together with its

programmatically determined link context, except where the purpose of the

link would be ambiguous to users in general. (Level A)

How to Meet 2.4.4 Understanding 2.4.4

2.4.5 Multiple Ways: More than one way is available to locate a Web

page within a set of Web pages except where the Web Page is the result

of, or a step in, a process. (Level AA)

How to Meet 2.4.5 Understanding 2.4.5

2.4.6 Headings and Labels: Headings and labels describe topic or

purpose. (Level AA)How to Meet 2.4.6

Understanding 2.4.6

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of

operation where the keyboard focus indicator is visible. (Level AA)How to Meet 2.4.7

Understanding 2.4.7

2.4.8 Location: Information about the user's location within a set of Web

pages is available. (Level AAA)How to Meet 2.4.8

Understanding 2.4.8

2.4.9 Link Purpose (Link Only): A mechanism is available to allow the

purpose of each link to be identified from link text alone, except where the

purpose of the link would be ambiguous to users in general. (Level AAA)

How to Meet 2.4.9 Understanding 2.4.9

2.4.10 Section Headings: Section headings are used to organize the

content. (Level AAA)

Note 1: "Heading" is used in its general sense and includes titles and

other ways to add a heading to different types of content.

Note 2: This success criterion covers sections within writing, not user

interface components. User Interface components are covered under

Success Criterion 4.1.2.

How to Meet 2.4.10 Understanding 2.4.10

Guideline 3.1 Readable: Make text content readable andunderstandable.

Understanding Guideline 3.1

3.1.1 Language of Page: The default human language of each Web page

can be programmatically determined. (Level A)How to Meet 3.1.1

Understanding 3.1.1

3.1.2 Language of Parts: The human language of each passage or phrase

in the content can be programmatically determined except for proper

names, technical terms, words of indeterminate language, and words or

phrases that have become part of the vernacular of the immediately

surrounding text. (Level AA)

How to Meet 3.1.2 Understanding 3.1.2

3.1.3 Unusual Words: A mechanism is available for identifying specific

definitions of words or phrases used in an unusual or restricted way,

including idioms and jargon. (Level AAA)

How to Meet 3.1.3 Understanding 3.1.3

3.1.4 Abbreviations: A mechanism for identifying the expanded form or

meaning of abbreviations is available. (Level AAA)How to Meet 3.1.4

Understanding 3.1.4

3.1.5 Reading Level: When text requires reading ability more advanced

than the lower secondary education level after removal of proper names and

titles, supplemental content, or a version that does not require reading

ability more advanced than the lower secondary education level, is

available. (Level AAA)

How to Meet 3.1.5 Understanding 3.1.5

3.1.6 Pronunciation: A mechanism is available for identifying specific

pronunciation of words where meaning of the words, in context, is

ambiguous without knowing the pronunciation. (Level AAA)

How to Meet 3.1.6 Understanding 3.1.6

Guideline 3.2 Predictable: Make Web pages appear andoperate in predictable ways.

Understanding Guideline 3.2

3.2.1 On Focus: When any component receives focus, it does not initiate

a change of context. (Level A)How to Meet 3.2.1

Understanding 3.2.1

3.2.2 On Input: Changing the setting of any user interface component

does not automatically cause a change of context unless the user has

been advised of the behavior before using the component. (Level A)

How to Meet 3.2.2 Understanding 3.2.2

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated

on multiple Web pages within a set of Web pages occur in the same

relative order each time they are repeated, unless a change is initiated by

the user. (Level AA)

How to Meet 3.2.3 Understanding 3.2.3

3.2.4 Consistent Identification: Components that have the same

functionality within a set of Web pages are identified consistently. (Level

AA)

How to Meet 3.2.4 Understanding 3.2.4

Principle 4: Robust - Content must be robust enough that it can beinterpreted reliably by a wide variety of user agents, including assistive

3.2.5 Change on Request: Changes of context are initiated only by user

request or a mechanism is available to turn off such changes. (Level AAA)How to Meet 3.2.5

Understanding 3.2.5

Guideline 3.3 Input Assistance: Help users avoid andcorrect mistakes.

Understanding Guideline 3.3

3.3.1 Error Identification: If an input error is automatically detected, the

item that is in error is identified and the error is described to the user in

text. (Level A)

How to Meet 3.3.1 Understanding 3.3.1

3.3.2 Labels or Instructions: Labels or instructions are provided when

content requires user input. (Level A)How to Meet 3.3.2

Understanding 3.3.2

3.3.3 Error Suggestion: If an input error is automatically detected and

suggestions for correction are known, then the suggestions are provided to

the user, unless it would jeopardize the security or purpose of the content.

(Level AA)

How to Meet 3.3.3 Understanding 3.3.3

3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that

cause legal commitments or financial transactions for the user to occur,

that modify or delete user-controllable data in data storage systems, or

that submit user test responses, at least one of the following is true: (Level

AA)

1. Reversible: Submissions are reversible.

2. Checked: Data entered by the user is checked for input errors and

the user is provided an opportunity to correct them.

3. Confirmed: A mechanism is available for reviewing, confirming, and

correcting information before finalizing the submission.

How to Meet 3.3.4 Understanding 3.3.4

3.3.5 Help: Context-sensitive help is available. (Level AAA) How to Meet 3.3.5 Understanding 3.3.5

3.3.6 Error Prevention (All): For Web pages that require the user to

submit information, at least one of the following is true: (Level AAA)

1. Reversible: Submissions are reversible.

2. Checked: Data entered by the user is checked for input errors and

the user is provided an opportunity to correct them.

3. Confirmed: A mechanism is available for reviewing, confirming, and

correcting information before finalizing the submission.

How to Meet 3.3.6 Understanding 3.3.6

technologies.

Conformance

This section is normative.

This section lists requirements for conformance to WCAG 2.0. It also gives information about how to

make conformance claims, which are optional. Finally, it describes what it means to be accessibility

supported, since only accessibility-supported ways of using technologies can be relied upon for

conformance. Understanding Conformance includes further explanation of the accessibility-supported

concept.

Conformance Requirements

In order for a Web page to conform to WCAG 2.0, all of the following conformance requirements must be

satisfied:

1. Conformance Level: One of the following levels of conformance is met in full.

Level A: For Level A conformance (the minimum level of conformance), the Web page satisfies

all the Level A Success Criteria, or a conforming alternate version is provided.

Level AA: For Level AA conformance, the Web page satisfies all the Level A and Level AA

Success Criteria, or a Level AA conforming alternate version is provided.

Level AAA: For Level AAA conformance, the Web page satisfies all the Level A, Level AA and

Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.

Guideline 4.1 Compatible: Maximize compatibility withcurrent and future user agents, including assistivetechnologies.

Understanding Guideline 4.1

4.1.1 Parsing: In content implemented using markup languages, elements

have complete start and end tags, elements are nested according to their

specifications, elements do not contain duplicate attributes, and any IDs

are unique, except where the specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their

formation, such as a closing angle bracket or a mismatched attribute

value quotation mark are not complete.

How to Meet 4.1.1 Understanding 4.1.1

4.1.2 Name, Role, Value: For all user interface components (including but

not limited to: form elements, links and components generated by scripts),

the name and role can be programmatically determined; states, properties,

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

Note: This success criterion is primarily for Web authors who develop or

script their own user interface components. For example, standard HTML

controls already meet this success criterion when used according to

specification.

How to Meet 4.1.2 Understanding 4.1.2

Note 1: Although conformance can only be achieved at the stated levels, authors are encouraged to

report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved

level of conformance.

Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire

sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

2. Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be

achieved if part of a Web page is excluded.

Note 1: For the purpose of determining conformance, alternatives to part of a page's content are

considered part of the page when the alternatives can be obtained directly from the page, e.g., a long

description or an alternative presentation of a video.

Note 2: Authors of Web pages that cannot conform due to content outside of the author's control may

consider a Statement of Partial Conformance.

3. Complete processes: When a Web page is one of a series of Web pages presenting a process (i.e.,

a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the

process conform at the specified level or better. (Conformance is not possible at a particular level if any

page in the process does not conform at that level or better.)

Example: An online store has a series of pages that are used to select and purchase products. All

pages in the series from start to finish (checkout) conform in order for any page that is part of the

process to conform.

4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of

using technologies are relied upon to satisfy the success criteria. Any information or functionality that is

provided in a way that is not accessibility supported is also available in a way that is accessibility

supported. (See Understanding accessibility support.)

5. Non-Interference: If technologies are used in a way that is not accessibility supported, or if they are

used in a non-conforming way, then they do not block the ability of users to access the rest of the page.

In addition, the Web page as a whole continues to meet the conformance requirements under each of

the following conditions:

1. when any technology that is not relied upon is turned on in a user agent,

2. when any technology that is not relied upon is turned off in a user agent, and

3. when any technology that is not relied upon is not supported by a user agent

In addition, the following success criteria apply to all content on the page, including content that is not

otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of

the page:

1.4.2 - Audio Control,

2.1.2 - No Keyboard Trap,

2.3.1 - Three Flashes or Below Threshold, and

2.2.2 - Pause, Stop, Hide.

Note: If a page cannot conform (for example, a conformance test page or an example page), it cannot

be included in the scope of conformance or in a conformance claim.

For more information, including examples, see Understanding Conformance Requirements.

Conformance Claims (Optional)

Conformance is defined only for Web pages. However, a conformance claim may be made to cover one

page, a series of pages, or multiple related Web pages.

Required Components of a Conformance Claim

Conformance claims are not required. Authors can conform to WCAG 2.0 without making a claim.

However, if a conformance claim is made, then the conformance claim must include the following

information:

1. Date of the claim

2. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.0 at

http://www.w3.org/TR/2008/REC-WCAG20-20081211/"

3. Conformance level satisfied: (Level A, AA or AAA)

4. A concise description of the Web pages, such as a list of URIs for which the claim is made,

including whether subdomains are included in the claim.

Note 1: The Web pages may be described by list or by an expression that describes all of the

URIs included in the claim.

Note 2: Web-based products that do not have a URI prior to installation on the customer's Web

site may have a statement that the product would conform when installed.

5. A list of the Web content technologies relied upon.

Note: If a conformance logo is used, it would constitute a claim and must be accompanied by the

required components of a conformance claim listed above.

Optional Components of a Conformance Claim

In addition to the required components of a conformance claim above, consider providing additional

information to assist users. Recommended additional information includes:

A list of success criteria beyond the level of conformance claimed that have been met. This

information should be provided in a form that users can use, preferably machine-readable

metadata.

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

A list of user agents, including assistive technologies that were used to test the content.

Information about any additional steps taken that go beyond the success criteria to enhance

accessibility.

A machine-readable metadata version of the list of specific technologies that are relied upon.

A machine-readable metadata version of the conformance claim.

Note 1: Refer to Understanding Conformance Claims for more information and example conformance

claims.

Note 2: Refer to Understanding Metadata for more information about the use of metadata in

conformance claims.

Statement of Partial Conformance - Third Party Content

Sometimes, Web pages are created that will later have additional content added to them. For example,

an email program, a blog, an article that allows users to add comments, or applications supporting user-

contributed content. Another example would be a page, such as a portal or news site, composed of

content aggregated from multiple contributors, or sites that automatically insert content from other

sources over time, such as when advertisements are inserted dynamically.

In these cases, it is not possible to know at the time of original posting what the uncontrolled content of

the pages will be. It is important to note that the uncontrolled content can affect the accessibility of the

controlled content as well. Two options are available:

1. A determination of conformance can be made based on best knowledge. If a page of this type is

monitored and repaired (non-conforming content is removed or brought into conformance) within

two business days, then a determination or claim of conformance can be made since, except for

errors in externally contributed content which are corrected or removed when encountered, the

page conforms. No conformance claim can be made if it is not possible to monitor or correct non-

conforming content;

OR

2. A "statement of partial conformance" may be made that the page does not conform, but could

conform if certain parts were removed. The form of that statement would be, "This page does not

conform, but would conform to WCAG 2.0 at level X if the following parts from uncontrolled

sources were removed." In addition, the following would also be true of uncontrolled content that

is described in the statement of partial conformance:

a. It is not content that is under the author's control.

b. It is described in a way that users can identify (e.g., they cannot be described as "all parts

that we do not control" unless they are clearly marked as such.)

Statement of Partial Conformance - Language

A "statement of partial conformance due to language" may be made when the page does not conform,

but would conform if accessibility support existed for (all of) the language(s) used on the page. The form

of that statement would be, "This page does not conform, but would conform to WCAG 2.0 at level X if

accessibility support existed for the following language(s):"

Appendix A: Glossary

This section is normative.

abbreviation

shortened form of a word, phrase, or name where the abbreviation has not become part of the

language

Note 1: This includes initialisms and acronyms where:

1. initialisms are shortened forms of a name or phrase made from the initial letters of words

or syllables contained in that name or phrase

Note 1: Not defined in all languages.

Example 1: SNCF is a French initialism that contains the initial letters of the Société

Nationale des Chemins de Fer, the French national railroad.

Example 2: ESP is an initialism for extrasensory perception.

2. acronyms are abbreviated forms made from the initial letters or parts of other words (in a

name or phrase) which may be pronounced as a word

Example: NOAA is an acronym made from the initial letters of the National Oceanic and

Atmospheric Administration in the United States.

Note 2: Some companies have adopted what used to be an initialism as their company name. In

these cases, the new name of the company is the letters (for example, Ecma) and the word is no

longer considered an abbreviation.

accessibility supported

supported by users' assistive technologies as well as the accessibility features in browsers and

other user agents

To qualify as an accessibility-supported use of a Web content technology (or feature of a

technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users'

assistive technology (AT). This means that the way that the technology is used has been

tested for interoperability with users' assistive technology in the human language(s) of the

content,

AND

2. The Web content technology must have accessibility-supported user agents that are

available to users. This means that at least one of the following four statements is true:

a. The technology is supported natively in widely-distributed user agents that are also

accessibility supported (such as HTML and CSS);

OR

b. The technology is supported in a widely-distributed plug-in that is also accessibility

supported;

OR

c. The content is available in a closed environment, such as a university or corporate

network, where the user agent required by the technology and used by the

organization is also accessibility supported;

OR

d. The user agent(s) that support the technology are accessibility supported and are

available for download or purchase in a way that:

does not cost a person with a disability any more than a person without a

disability and

is as easy to find and obtain for a person with a disability as it is for a person

without disabilities.

Note 1: The WCAG Working group and the W3C do not specify which or how much support by

assistive technologies there must be for a particular use of a Web technology in order for it to be

classified as accessibility supported. (See Level of Assistive Technology Support Needed for

"Accessibility Support".)

Note 2: Web technologies can be used in ways that are not accessibility supported as long as

they are not relied upon and the page as a whole meets the conformance requirements, including

Conformance Requirement 4: Only Accessibility-Supported Ways of Using Technologies and

Conformance Requirement 5: Non-Interference, are met.

Note 3: When a Web Technology is used in a way that is "accessibility supported," it does not

imply that the entire technology or all uses of the technology are supported. Most technologies,

including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the

uses of the technology that are accessibility supported can be relied upon to meet WCAG

requirements.

Note 4: When citing Web content technologies that have multiple versions, the version(s)

supported should be specified.

Note 5: One way for authors to locate uses of a technology that are accessibility supported would

be to consult compilations of uses that are documented to be accessibility supported. (See

Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology

vendors, or others may document accessibility-supported ways of using Web content

technologies. However, all ways of using technologies in the documentation would need to meet

the definition of accessibility-supported Web content technologies above.

alternative for time-based media

document including correctly sequenced text descriptions of time-based visual and auditory

information and providing a means for achieving the outcomes of any time-based interaction

Note: A screenplay used to create the synchronized media content would meet this definition

only if it was corrected to accurately represent the final synchronized media after editing.

ambiguous to users in general

the purpose cannot be determined from the link and all information of the Web page presented to

the user simultaneously with the link (i.e., readers without disabilities would not know what a link

would do until they activated it)

Example: The word guava in the following sentence "One of the notable exports is guava" is a

link. The link could lead to a definition of guava, a chart listing the quantity of guava exported or a

photograph of people harvesting guava. Until the link is activated, all readers are unsure and the

person with a disability is not at any disadvantage.

ASCII art

picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable

characters defined by ASCII).

assistive technology (as used in this document)

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to

provide functionality to meet the requirements of users with disabilities that go beyond those

offered by mainstream user agents

Note 1: functionality provided by assistive technology includes alternative presentations (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).

Note 2: Assistive technologies often communicate data and messages with mainstream user

agents by using and monitoring APIs.

Note 3: The distinction between mainstream user agents and assistive technologies is not

absolute. Many mainstream user agents provide some features to assist individuals with

disabilities. The basic difference is that mainstream user agents target broad and diverse

audiences that usually include people with and without disabilities. Assistive technologies target

narrowly defined populations of users with specific disabilities. The assistance provided by an

assistive technology is more specific and appropriate to the needs of its target users. The

mainstream user agent may provide important functionality to assistive technologies like retrieving

Web content from program objects or parsing markup into identifiable bundles.

Example: Assistive technologies that are important in the context of this document include the

following:

screen magnifiers, and other visual reading assistants, which are used by people with

visual, perceptual and physical print disabilities to change text font, size, spacing, color,

synchronization with speech, etc. in order to improve the visual readability of rendered text

and images;

screen readers, which are used by people who are blind to read textual information through

synthesized speech or braille;

text-to-speech software, which is used by some people with cognitive, language, and

learning disabilities to convert text into synthetic speech;

speech 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 (including alternate keyboards that use head pointers, single

switches, sip/puff and other special input devices.);

alternative pointing devices, which are used by people with certain physical disabilities to

simulate mouse pointing and button activations.

audio

the technology of sound reproduction

Note: Audio can be created synthetically (including speech synthesis), recorded from real world

sounds, or both.

audio description

narration added to the soundtrack to describe important visual details that cannot be understood

from the main soundtrack alone

Note 1: Audio description of video provides information about actions, characters, scene changes,

on-screen text, and other visual content.

Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See

also extended audio description.)

Note 3: Where all of the video information is already provided in existing audio, no additional audio

description is necessary.

Note 4: Also called "video description" and "descriptive narration."

audio-only

a time-based presentation that contains only audio (no video and no interaction)

blinking

switch back and forth between two visual states in a way that is meant to draw attention

Note: See also flash. It is possible for something to be large enough and blink brightly enough at

the right frequency to be also classified as a flash.

blocks of text

more than one sentence of text

CAPTCHA

initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart"

Note 1: CAPTCHA tests often involve asking the user to type in text that is displayed in an

obscured image or audio file.

Note 2: A Turing test is any system of tests designed to differentiate a human from a computer. It

is named after famed computer scientist Alan Turing. The term was coined by researchers at

Carnegie Mellon University. [CAPTCHA]

captions

synchronized visual and/or text alternative for both speech and non-speech audio information

needed to understand the media content

Note 1: Captions are similar to dialogue-only subtitles except captions convey not only the

content of spoken dialogue, but also equivalents for non-dialogue audio information needed to

understand the program content, including sound effects, music, laughter, speaker identification

and location.

Note 2: Closed Captions are equivalents that can be turned on and off with some players.

Note 3: Open Captions are any captions that cannot be turned off. For example, if the captions

are visual equivalent images of text embedded in video.

Note 4: Captions should not obscure or obstruct relevant information in the video.

Note 5: In some countries, captions are called subtitles.

Note 6: Audio descriptions can be, but do not need to be, captioned since they are descriptions

of information that is already presented visually.

changes of context

major changes in the content of the Web page that, if made without user awareness, can disorient

users who are not able to view the entire page simultaneously

Changes in context include changes of:

1. user agent;

2. viewport;

3. focus;

4. content that changes the meaning of the Web page.

Note: A change of content is not always a change of context. Changes in content, such as an

expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless

they also change one of the above (e.g., focus).

Example: Opening a new window, moving focus to a different component, going to a new page

(including anything that would look to a user as if they had moved to a new page) or significantly

re-arranging the content of a page are examples of changes of context.

conformance

satisfying all the requirements of a given standard, guideline or specification

conforming alternate version

version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

a. the conforming version can be reached from the non-conforming page via an

accessibility-supported mechanism, or

b. the non-conforming version can only be reached from the conforming version, or

c. the non-conforming version can only be reached from a conforming page that also

provides a mechanism to reach the conforming version

Note 1: In this definition, "can only be reached" means that there is some mechanism, such as a

conditional redirect, that prevents a user from "reaching" (loading) the non-conforming page

unless the user had just come from the conforming version.

Note 2: The alternate version does not need to be matched page for page with the original (e.g.,

the conforming alternate version may consist of multiple pages).

Note 3: If multiple language versions are available, then conforming alternate versions are required

for each language offered.

Note 4: Alternate versions may be provided to accommodate different technology environments or

user groups. Each version should be as conformant as possible. One version would need to be

fully conformant in order to meet conformance requirement 1.

Note 5: The conforming alternative version does not need to reside within the scope of

conformance, or even on the same Web site, as long as it is as freely available as the non-

conforming version.

Note 6: Alternate versions should not be confused with supplementary content, which support the

original page and enhance comprehension.

Note 7: Setting user preferences within the content to produce a conforming version is an

acceptable mechanism for reaching another version as long as the method used to set the

preferences is accessibility supported.

See Understanding Conforming Alternate Versions

content (Web content)

information and sensory experience to be communicated to the user by means of a user agent,

including code or markup that defines the content's structure, presentation, and interactions

context-sensitive help

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

Note: Clear labels can act as context-sensitive help.

contrast ratio

(L1 + 0.05) / (L2 + 0.05), where

L1 is the relative luminance of the lighter of the colors, and

L2 is the relative luminance of the darker of the colors.

Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

Note 2: Because authors do not have control over user settings as to how text is rendered (for

example font smoothing or anti-aliasing), the contrast ratio for text can be evaluated with anti-

aliasing turned off.

Note 3: For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect to

the specified background over which the text is rendered in normal usage. If no background color

is specified, then white is assumed.

Note 4: Background color is the specified color of content over which the text is to be rendered in

normal usage. It is a failure if no background color is specified when the text color is specified,

because the user's default background color is unknown and cannot be evaluated for sufficient

contrast. For the same reason, it is a failure if no text color is specified when a background color

is specified.

Note 5: When there is a border around the letter, the border can add contrast and would be used

in calculating the contrast between the letter and its background. A narrow border around the

letter would be used as the letter. A wide border around the letter that fills in the inner details of

the letters acts as a halo and would be considered background.

Note 6: WCAG conformance should be evaluated for color pairs specified in the content that an

author would expect to appear adjacent in typical presentation. Authors need not consider

unusual presentations, such as color changes made by the user agent, except where caused by

authors' code.

correct reading sequence

any sequence where words and paragraphs are presented in an order that does not change the

meaning of the content

emergency

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

safety, or property

essential

if removed, would fundamentally change the information or functionality of the content, and

information and functionality cannot be achieved in another way that would conform

extended audio description

audio description that is 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 and the pauses between dialogue/narration are too short.

flash

a pair of opposing changes in relative luminance that can cause seizures in some people if it is

large enough and in the right frequency range

Note 1: See general flash and red flash thresholds for information about types of flash that are not

allowed.

Note 2: See also blinking.

functionality

processes and outcomes achievable through user action

general flash and red flash thresholds

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of

the following are true:

1. there are no more than three general flashes and / or no more than three red flashes

within any one-second period; or

2. the combined area of flashes occurring concurrently occupies no more than a total of .006

steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field

on the screen) at typical viewing distance

where:

A general flash is defined as a pair of opposing changes in relative luminance of 10% or

more of the maximum relative luminance where the relative luminance of the darker image is

below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease,

or a decrease followed by an increase, and

A red flash is defined as any pair of opposing transitions involving a saturated red.

Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating

checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing

distance) on a side does not violate the thresholds.

Note 1: For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the

displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good

estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17

inch screen at 22-26 inches). (Higher resolutions displays showing the same rendering of the

content yield smaller and safer images so it is lower resolutions that are used to define the

thresholds.)

Note 2: A transition is the change in relative luminance (or relative luminance/color for red

flashing) between adjacent peaks and valleys in a plot of relative luminance (or relative

luminance/color for red flashing) measurement against time. A flash consists of two opposing

transitions.

Note 3: The current working definition in the field for "pair of opposing transitions involving a

saturated red" is where, for either or both states involved in each transition, R/(R+ G + B) >=

0.8, and the change in the value of (R-G-B)x320 is > 20 (negative values of (R-G-B)x320 are set to

zero) for both transitions. R, G, B values range from 0-1 as specified in “relative luminance”

definition. [HARDING-BINNIE]

Note 4: Tools are available that will carry out analysis from video screen capture. However, no tool

is necessary to evaluate for this condition if flashing is less than or equal to 3 flashes in any one

second. Content automatically passes (see #1 and #2 above).

human language

language that is spoken, written or signed (through visual or tactile means) to communicate with

humans

Note: See also sign language.

idiom

phrase whose meaning cannot be deduced from the meaning of the individual words and the

specific words cannot be changed without losing the meaning

Note: idioms cannot be translated directly, word for word, without losing their (cultural or

language-dependent) meaning.

Example 1: 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 2: In Japanese, the phrase "さじを投げる" literally translates into "he throws a spoon,"

but it means that there is nothing he can do and finally he gives up.

Example 3: 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.

image of text

text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular

visual effect

Note: This does not include text that is part of a picture that contains significant other visual

content.

Example: A person's name on a nametag in a photograph.

informative

for information purposes and not required for conformance

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

input error

information provided by the user that is not accepted

Note: This includes:

1. Information that is required by the Web page 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: A keyboard interface allows users to provide keystroke input to programs even if the

native technology does not contain a keyboard.

Example: A touchscreen 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 or other component with a text alternative that is presented to a user to identify a component

within Web content

Note 1: A label is presented to all users whereas the name may be hidden and only exposed by

assistive technology. In many (but not all) cases the name and the label are the same.

Note 2: The term label is not limited to the label element in HTML.

large scale (text)

with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese,

Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce

the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may

be done by a user.

Note 3: The actual size of the character that a user sees is dependent both on the author-defined

size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and

18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body

text (assuming that the body font is 100%), but authors would need to check this for the

particular fonts in use. When fonts are defined in relative units, the actual point size is calculated

by the user agent for display. The point size should be obtained from the user agent, or

calculated based on font metrics as the user agent does, when evaluating this success criterion.

Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major

browsers for unspecified text would be a reasonable size to assume for the font. If a level 1

heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to

assume it is large text. Relative scaling can be calculated from the default sizes in a similar

fashion.

Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print

(14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the

"equivalent" sizes would be the minimum large print size used for those languages and the next

larger standard large print size.

legal commitments

transactions where the person incurs a legally binding obligation or benefit

Example: A marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing

up for the army, a contract of any type, etc.

link purpose

nature of the result obtained by activating a hyperlink

live

information captured from a real-world event and transmitted to the receiver with no more than a

broadcast delay

Note 1: A broadcast delay is a short (usually automated) delay, for example used in order to give

the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow

significant editing.

Note 2: If information is completely computer generated, it is not live.

lower secondary education level

the two or three year period of education that begins after completion of six years of school and

ends nine years after the beginning of primary education

Note: This definition is based on the International Standard Classification of Education

[UNESCO].

mechanism

process or technique for achieving a result

Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be

provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.

media alternative for text

media that presents no more information than is already presented in text (directly or via text

alternatives)

Note: A media alternative for text is provided for those who benefit from alternate representations

of text. Media alternatives for text may be audio-only, video-only (including sign-language video),

or audio-video.

name

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

Note 1: The name may be hidden and only exposed by assistive technology, whereas a label is

presented to all users. In many (but not all) cases, the label and the name are the same.

Note 2: This is unrelated to the name attribute in HTML.

navigated sequentially

navigated in the order defined for advancing focus (from one element to the next) using a keyboard

interface

non-text content

any content that is not a sequence of characters that can be programmatically determined or

where the sequence is not expressing something in human language

Note: This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which

uses character substitution), and images representing text

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.

on a full-screen window

on the most common sized desktop/laptop display with the viewport maximized

Note: Since people generally keep their computers for several years, it is best not to rely on the

latest desktop/laptop display resolutions but to consider the common desktop/laptop display

resolutions over the course of several years when making this evaluation.

paused

stopped by user request and not resumed until requested by user

prerecorded

information that is not live

presentation

rendering of the content in a form to be perceived by users

primary education level

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

education

Note: This definition is based on the International Standard Classification of Education

[UNESCO].

process

series of user actions where each action is required in order to complete an activity

Example 1: Successful use of a series of Web pages on a shopping site requires users to view

alternative products, prices and offers, select products, submit an order, provide shipping

information and provide payment information.

Example 2: An account registration page requires successful completion of a Turing test before

the registration form can be accessed.

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different user agents,

including assistive technologies, can extract and present this information to users in different

modalities

Example 1: Determined in a markup language from elements and attributes that are accessed

directly by commonly available assistive technology.

Example 2: Determined from technology-specific data structures in a non-markup language and

exposed to assistive technology via an accessibility API that is supported by commonly available

assistive technology.

programmatically determined link context

additional information that can be programmatically determined from relationships with a link,

combined with the link text, and presented to users in different modalities

Example: In HTML, information that is programmatically determinable from a link in English

includes text that is in the same paragraph, list, or table cell as the link or in a table header cell

that is associated with the table cell that contains the link.

Note: Since screen readers interpret punctuation, they can also provide the context from the

current sentence, when the focus is on a link in that sentence.

programmatically set

set by software using methods that are supported by user agents, including assistive technologies

pure decoration

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

Note: Text is only purely decorative if the words can be rearranged or substituted without

changing their purpose.

Example: The cover page of a dictionary has random words in very light text in the background.

real-time event

event that a) occurs at the same time as the viewing and b) is not completely generated by the

content

Example 1: A Webcast of a live performance (occurs at the same time as the viewing and is not

prerecorded).

Example 2: An on-line auction with people bidding (occurs at the same time as the viewing).

Example 3: Live humans interacting in a virtual world using avatars (is not completely generated

by the content and occurs at the same time as the viewing).

relationships

meaningful associations between distinct pieces of content

relative luminance

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for

lightest white

Note 1: For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R +

0.7152 * G + 0.0722 * B where R, G and B are defined as:

if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ̂2.4

if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ̂2.4

if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ̂2.4

and RsRGB, GsRGB, and BsRGB are defined as:

RsRGB = R8bit/255

GsRGB = G8bit/255

BsRGB = B8bit/255

The " "̂ character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).

Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it

is known that another color space will be used to process and display the content, authors

should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success

Criterion 1.4.3.

Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are

dithered at the source, the average values of the colors that are dithered should be used (average

R, average G, and average B).

Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

Note 5: A MathML version of the relative luminance definition is available.

relied upon (technologies that are)

the content would not conform if that technology is turned off or is not supported

role

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

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

satisfies a success criterion

the success criterion does not evaluate to 'false' when applied to the page

section

A self-contained portion of written content that deals with one or more related topics or thoughts

Note: A section may consist of one or more paragraphs and include graphics, tables, lists and

sub-sections.

set of Web pages

collection of Web pages that share a common purpose and that are created by the same author,

group or organization

Note: Different language versions would be considered different sets of Web pages.

sign language

a language using combinations of movements of the hands and arms, facial expressions, or body

positions to convey meaning

sign language interpretation

translation of one language, generally a spoken language, into a sign language

Note: True sign languages are independent languages that are unrelated to the spoken

language(s) of the same country or region.

specific sensory experience

a sensory experience that is not purely decorative and does not primarily convey important

information or perform a function

Example: Examples include a performance of a flute solo, works of visual art etc.

structure

1. The way the parts of a Web page are organized in relation to each other; and

2. The way a collection of Web pages is organized

supplemental content

additional content that illustrates or clarifies the primary content

Example 1: An audio version of a Web page.

Example 2: An illustration of a complex process.

Example 3: A paragraph summarizing the major outcomes and recommendations made in a

research study.

synchronized media

audio or video synchronized with another format for presenting information and/or with time-based

interactive components, unless the media is a media alternative for text that is clearly labeled as

such

technology (Web content)

mechanism for encoding instructions to be rendered, played or executed by user agents

Note 1: As used in these guidelines "Web Technology" and the word "technology" (when used

alone) both refer to Web Content Technologies.

Note 2: Web content technologies may include markup languages, data formats, or programming

languages that authors may use alone or in combination to create end-user experiences that

range from static Web pages to synchronized media presentations to dynamic Web applications.

Example: Some common examples of Web content technologies include HTML, CSS, SVG,

PNG, PDF, Flash, and JavaScript.

text

sequence of characters that can be programmatically determined, where the sequence is

expressing something in human language

text alternative

Text that is programmatically associated with non-text content or referred to from text that is

programmatically associated with non-text content. Programmatically associated text is text

whose location can be programmatically determined from the non-text content.

Example: An image of a chart is described in text in the paragraph after the chart. The short text

alternative for the chart indicates that a description follows.

Note: Refer to Understanding Text Alternatives for more information.

used in an unusual or restricted way

words used in such a way that requires users to know exactly which definition to apply in order to

understand the content correctly

Example: The term "gig" means something different if it occurs in a discussion of music concerts

than it does in article about computer hard drive space, 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 presents Web content for users

Example: Web browsers, media players, plug-ins, and other programs — including assistive

technologies — that help in retrieving, rendering, and interacting with Web content.

user-controllable

data that is intended to be accessed by users

Note: This does not refer to such things as Internet logs and search engine monitoring data.

Example: Name and address fields for a user's account.

user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note 1: Multiple user interface components may be implemented as a single programmatic

element. Components here is not tied to programming techniques, but rather to what the user

perceives as separate controls.

Note 2: User interface components include form elements and links as well as components

generated by scripts.

Example: An applet has a "control" that can be used to move through content by line or page or

random access. Since each of these would need to have a name and be settable independently,

they would each be a "user interface component."

video

the technology of moving or sequenced pictures or images

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

video-only

a time-based presentation that contains only video (no audio and no interaction)

viewport

object in which the user agent presents content

Note 1: The user agent presents content through one or more viewports. Viewports include

windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another

viewport (e.g., nested frames). Interface components created by the user agent such as prompts,

menus, and alerts are not viewports.

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

visually customized

the font, size, color, and background can be set

Web page

a non-embedded resource obtained from a single URI using HTTP plus any other resources that

are used in the rendering or intended to be rendered together with it by a user agent

Note 1: Although any "other resources" would be rendered together with the primary resource,

they would not necessarily be rendered simultaneously with each other.

Note 2: For the purposes of conformance with these guidelines, a resource must be "non-

embedded" within the scope of conformance to be considered a Web page.

Example 1: A Web resource including all embedded images and media.

Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The

program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a

calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but

do not change the URI of the page as a whole.

Example 3: A customizable portal site, where users can choose content to display from a set of

different content modules.

Example 4: When you enter "http://shopping.example.com/" in your browser, you enter a movie-

like interactive shopping environment where you visually move around in a store dragging products

off of the shelves around you and into a visual shopping cart in front of you. Clicking on a product

causes it to be demonstrated with a specification sheet floating alongside. This might be a single-

page Web site or just one page within a Web site.

Appendix B: Acknowledgments

This section is informative.

This publication has been funded in part with Federal funds from the U.S. Department of Education,

National Institute on Disability and Rehabilitation Research (NIDRR) 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.

Additional information about participation in the Web Content Accessibility Guidelines Working Group

(WCAG WG) can be found on the Working Group home page.

Participants active in the WCAG WG at the time of publication

Bruce Bailey (U.S. Access Board)

Frederick Boland (NIST)

Ben Caldwell (Trace R&D Center, University of Wisconsin)

Sofia Celic (W3C Invited Expert)

Michael Cooper (W3C)

Roberto Ellero (International Webmasters Association / HTML Writers Guild)

Bengt Farre (Rigab)

Loretta Guarino Reid (Google)

Katie Haritos-Shea

Andrew Kirkpatrick (Adobe)

Drew LaHart (IBM)

Alex Li (SAP AG)

David MacDonald (E-Ramp Inc.)

Roberto Scano (International Webmasters Association / HTML Writers Guild)

Cynthia Shelly (Microsoft)

Andi Snow-Weaver (IBM)

Christophe Strobbe (DocArch, K.U.Leuven)

Gregg Vanderheiden (Trace R&D Center, University of Wisconsin)

Other previously active WCAG WG participants and other contributors to WCAG 2.0

Shadi Abou-Zahra, Jim Allan, Jenae Andershonis, Avi Arditti, Aries Arditi, Mike Barta, Sandy Bartell,

Kynn Bartlett, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Patrice Bourlon, Judy

Brewer, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Tomas Caspers, Roberto Castaldo,

Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M

Clark, Joe Clark, James Coltham, James Craig, Tom Croucher, Nir Dagan, Daniel Dardailler, Geoff

Deering, Pete DeVasto, Don Evans, Neal Ewers, Steve Faulkner, Lainey Feingold, Alan J. Flavell,

Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Greg Gay, Becky Gibson, Al Gilman,

Kerstin Goldsmith, Michael Grade, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric

Hansen, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Chris Hofstader,

Yvette Hoitink, Carlos Iglesias, Ian Jacobs, Phill Jenkins, Jyotsna Kaki, Leonard R. Kasday, Kazuhito

Kidachi, Ken Kipness, Marja-Riitta Koivunen, Preety Kumar, Gez Lemon, Chuck Letourneau, Scott

Luebking, Tim Lacy, Jim Ley, William Loughborough, Greg Lowney, Luca Mascaro, Liam McGee, Jens

Meiert, Niqui Merret, Alessandro Miele, Mathew J Mirabella, Charles McCathieNevile , Matt May, Marti

McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Bruno von Niman, Tim Noonan, Sebastiano

Nutarelli, Graham Oliver, Sean B. Palmer, Sailesh Panchang, Nigel Peck, Anne Pemberton, David

Poehlman, Adam Victor Reed, Chris Ridpath, Lee Roberts, Gregory J. Rosmaita, Matthew Ross,

Sharron Rush, Gian Sampson-Wild, Joel Sanda, Gordon Schantz, Lisa Seeman, John Slatin, Becky

Smith, Jared Smith, Neil Soiffer, Jeanne Spellman, Mike Squillace, Michael Stenitzer, Jim Thatcher,

Terry Thompson, Justin Thorp, Makoto Ueki, Eric Velleman, Dena Wainwright, Paul Walsch, Takayuki

Watanabe, Jason White.

Appendix C: References

This section is informative.

CAPTCHAThe CAPTCHA Project, Carnegie Mellon University. The project is online athttp://www.captcha.net.

HARDING-BINNIE

Harding G. F. A. and Binnie, C.D., Independent Analysis of the ITC Photosensitive EpilepsyCalibration Test Tape. 2002.

IEC-4WDIEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems andEquipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.

sRGB"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S.Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available athttp://www.w3.org/Graphics/Color/sRGB.html.

UNESCO

International Standard Classification of Education, 1997. A copy of the standard is available athttp://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm.

WCAG10Web Content Accessibility Guidelines 1.0, G. Vanderheiden, W. Chisholm, I. Jacobs, Editors,W3C Recommendation, 5 May 1999, http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.

The latest version of WCAG 1.0 is available at http://www.w3.org/TR/WAI-WEBCONTENT/.

Checklist for WCAG 2.0

Authoring Tool Accessibility Guidelines (ATAG) 2.0

[Contents] [Implementing]

Authoring Tool Accessibility Guidelines (ATAG)2.0

W3C Working Draft 10 April 2012

This version:

http://www.w3.org/TR/2012/WD-ATAG20-20120410/Latest version:

http://www.w3.org/TR/ATAG20/Previous version:

http://www.w3.org/TR/2011/WD-ATAG20-20110721/Editors:

Jan Richards, Inclusive Design Institute, OCAD UniversityJeanne Spellman, W3CJutta Treviranus, Inclusive Design Institute, OCAD University

Previous Editors:Matt May (until June 2005 while at W3C)

Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark anddocument use rules apply.

Abstract

This specification provides guidelines for designing web content authoring tools that areboth (1) more accessible to authors with disabilities and (2) designed to enable,support, and promote the production of more accessible web content by all authors.

The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series ofaccessibility guidelines published by the W3C Web Accessibility Initiative (WAI).

Status of This Document

May be Superseded

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

W3C Public Working Draft of ATAG 2.0

This is the W3C Last Call Working Draft of 10 April 2012. This draft integrates changesmade as a result of comments received on the 21 July 2011 Working Draft, the 26 April2011 Working Draft and the 8 July 2010 Last Call Working Draft. The Authoring ToolAccessibility Guidelines Working Group (AUWG) has refined ATAG 2.0 with thecontributions of public commenters. Changes in this draft:

Publication as a Last Call Working Draft indicates that the Authoring Tool AccessibilityGuidelines Working Group (AUWG) believes it has addressed all substantive issuesand that the document is stable. The first public Working Draft of ATAG 2.0 waspublished 14 March 2003. Since then, the AUWG has published nine Working Draftsand one previous Last Call Working Draft, addressed hundreds of issues anddeveloped implementation support information for the guidelines. See How WAIDevelops Accessibility Guidelines through the W3C Process for more background ondocument maturity levels.

Changes in this draft include:

1. Conformance - added a conformance note to clarify unrecognized content isexempt from success criteria that require semantics when the semantic data ismissing (e.g., text that describes an image is only considered to be a textalternative when this role is encoded within markup).

2. Device Independence - added a note to A.3.1.1 Keyboard Access to clarify thatthis success criterion applies to any keyboard interface, and was not restricted tothe presence of a hardware keyboard.

3. Preview Conformance - clarified that A.3.7.1 Preview (Minimum) (b) conforms toUAAG 1.0, instead of UAAG.

4. Accessibility Feature Documentation - added clarification and conditions toA.4.2.1 Describe Accessibility Features and A.4.2.2 Document All Features toenhance the ability to test if the feature qualifies as an accessibility feature.

5. Copy-Paste functions - added success criterion B.1.2.2 Copy-Paste Inside

Authoring Tool that copy-paste functions within the tool preserve accessibilityinformation.

6. Accessible Technologies - Removed B.2.2.3 Technology Decision Supportafter feedback that it would be burdensome to the user and added B.4.1.3 FeatureAvailability Information to inform the user if technology options within the authoringtool did not produce accessible content.

7. Conformance Requirements - added Success Criteria Satisfaction forspecialized authoring tools that may only implement a subset of ATAG appropriateto their limited functionality. Added conditional clauses to success criteria to clarifywhen conformance is not applicable.

8. Definitions - added the definition of accessible content; added a note and

Appendix to Implementing ATAG 2.0 on accessibility information; addedreversible authoring action; clarified author generated content; clarified contenttransformations; and expanded the definition of keyboard interface to clearlyinclude virtual keyboards.

The working group would particularly appreciate feedback on the following issues:

Does the new Partial Conformance (Process Components) option providereasonable coverage with respect to tools that perform only a small role in contentauthoring?Does the new Partial Conformance (Platform Limitations) option provide areasonable mechanism for situations in which platform shortcomings prevent fullconformance by authoring tools on the platform?Does the new formulation of guideline B.1.2 (Ensure accessibility information ispreserved) provide reasonable guidance when authoring tools transform content orcopy/paste content?

Comments on this working draft are due on or before 5 June 2012. Comments on thedraft should be sent to public-atag2-comments@w3.org (Public Archive).

The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publishATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool AccessibilityGuidelines (ATAG) 1.0 [ATAG10] is the stable, referenceable version. This WorkingDraft does not supersede ATAG 1.0.

Web Accessibility Initiative

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

No Endorsement

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 otherdocuments at any time. It is inappropriate to cite this document as other than work inprogress.

Patents

This document was produced by a group operating under the 5 February 2004 W3CPatent Policy. W3C maintains a public list of any patent disclosures made in connectionwith the deliverables of the group; that page also includes instructions for disclosing apatent. An individual who has actual knowledge of a patent which the individual believescontains Essential Claim(s) must disclose the information in accordance with section 6of the W3C Patent Policy.

Table of Contents

AbstractStatus of This DocumentIntroduction

ATAG 2.0 Layers of GuidanceLevels of ConformanceIntegration of Accessibility Features

ATAG 2.0 GuidelinesA. Make the authoring tool user interface accessible

A.1. Authoring tool user interfaces must follow applicable accessibilityguidelines

A.1.1. (For the authoring tool user interface) Ensure that web-based functionality is accessibleA.1.2. (For the authoring tool user interface) Ensure that non-web-based functionality is accessible

A.2. Editing-views must be perceivableA.2.1. (For the authoring tool user interface) Make alternativecontent available to authorsA.2.2. (For the authoring tool user interface) Editing-viewpresentation can be programmatically determined

A.3. Editing-views must be operableA.3.1. (For the authoring tool user interface) Provide keyboardaccess to authoring featuresA.3.2. (For the authoring tool user interface) Provide authors withenough timeA.3.3. (For the authoring tool user interface) Help authors avoidflashing that could cause seizuresA.3.4. (For the authoring tool user interface) Enhance navigationand editing via content structureA.3.5. (For the authoring tool user interface) Provide text searchof the contentA.3.6. (For the authoring tool user interface) Manage preferencesettingsA.3.7. (For the authoring tool user interface) Ensure that previewsare at least as accessible as in-market user agents

A.4. Editing-views must be understandableA.4.1. (For the authoring tool user interface) Help authors avoidand correct mistakesA.4.2. (For the authoring tool user interface) Document the userinterface including all accessibility features

B. Support the production of accessible contentB.1. Fully automatic processes must produce accessible content

B.1.1. Ensure automatically specified content is accessibleB.1.2. Ensure accessibility information is preserved

B.2. Authors must be supported in producing accessible contentB.2.1. Ensure accessible content production is possible

B.2.2. Guide authors to produce accessible contentB.2.3. Assist authors with managing alternative content for non-text contentB.2.4. Assist authors with accessible templatesB.2.5. Assist authors with accessible pre-authored content

B.3. Authors must be supported in improving the accessibility ofexisting content

B.3.1. Assist authors in checking for accessibility problemsB.3.2. Assist authors in repairing accessibility problems

B.4. Authoring tools must promote and integrate their accessibilityfeatures

B.4.1. Ensure the availability of features that support theproduction of accessible contentB.4.2. Ensure that documentation promotes the production ofaccessible content

Implementing ATAG 2.0 ConformanceConformance Requirements

Success Criteria SatisfactionRelationship to the Web Content Accessibility Guidelines (WCAG) 2.0Conformance Options and LevelsWeb Content Technologies ProducedLive Publishing Authoring Tools

Conformance Claims (Optional)Required Components of a Conformance ClaimOptional Components of a Conformance Claim

DisclaimerAppendix A: GlossaryAppendix B: How to refer to ATAG 2.0 from other documentsAppendix C: ReferencesAppendix D: Acknowledgments

Introduction

This section is informative.

This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version2.0. This document includes recommendations for assisting authoring tool developers tomake their authoring tools more accessible to people with disabilities, includingblindness and low vision, deafness and hearing loss, learning disabilities, cognitivelimitations, motor difficulties, speech difficulties, and others.

Accessibility, from an authoring tool perspective, includes addressing the needs of twooverlapping user groups with disabilities:

authors of web content, whose needs are met by ensuring that authoring tool userinterfaces are more accessible (addressed by Part A of the Guidelines), andend users of web content, whose needs are met by ensuring that all authors are

enabled, supported, and guided by the authoring tools that they use towardproducing accessible web content (WCAG) (addressed by Part B of theGuidelines).

It is important to note that, while the requirements for meeting these two sets of userneeds are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that, in reality, they are deeply inter-connected. For example,when a user participates in an online forum, they frequently author content that is thenincorporated with other content authored by other users. Accessibility problems in eitherthe authoring user interface or the content produced by the other forum users wouldreduce the overall accessibility of the forum.

Notes:

1. The term "authoring tools" has a specific definition in ATAG 2.0. The definition,which includes several normative notes, appears in the Glossary.

2. The term "accessible content (WCAG)" (and related terms, such as "accessibletemplate (WCAG)") is used by ATAG 2.0 to refer to "content that would conform toWCAG 2.0, at either Level A, AA, or AAA, assuming that any web contenttechnologies relied upon to satisfy the WCAG 2.0 success criteria areaccessibility supported. The definition of the term reflects the WCAG 2.0 note thateven content that conforms to the highest level of WCAG 2.0 (i.e., Level AAA) maynot be "accessible to individuals with all types, degrees, or combinations ofdisability". For more information, see "Relationship to the Web ContentAccessibility Guidelines (WCAG) 2.0".

3. ATAG 2.0 does not include standard usability recommendations, except wherethey have a significantly greater impact on people with disabilities than on otherpeople.

4. Authoring tools are just one aspect of web accessibility. For an overview of thedifferent components of web accessibility and how they work together see:

Essential Components of Web AccessibilityWeb Content Accessibility Guidelines (WCAG) OverviewUser Agent Accessibility Guidelines (UAAG) Overview

ATAG 2.0 Layers of Guidance

The individuals and organizations that may use ATAG 2.0 vary widely and includeauthoring tool developers, authoring tool users (authors), authoring tool purchasers, andpolicy makers. In order to meet the varying needs of this audience, several layers ofguidance are provided:

Parts: ATAG 2.0 is divided into two parts, each reflecting a key aspect of

accessibility with respect to authoring tools. Part A relates to the accessibility ofauthoring tool user interfaces to authors with disabilities. Part B relates to supportby authoring tools for the creation, by any author (not just those with disabilities), ofweb content that is more accessible to end users with disabilities. Both partsinclude normative "Conformance Applicability Notes" that apply to all of thesuccess criteria within that part (see Part A Conformance Applicability Notes and

Part B Conformance Applicability Notes).Principles: Under each part are several high-level principles that organize the

guidelines.Guidelines: Under the principles are guidelines. The guidelines provide the basic

goals that authoring tool developers should work toward in order to make authoringtools more accessible to both authors and end users of web content with differentdisabilities. The guidelines are not testable, but provide the framework and overallobjectives to help authoring tool developers understand the success criteria. Eachguideline includes a brief rationale for why the guideline was included.Success Criteria: For each guideline, testable success criteria are provided toallow ATAG 2.0 to be used where requirements and conformance testing arenecessary, such as in design specification, purchasing, regulation, and contractualagreements. In order to meet the needs of different groups and different situations,multiple levels of full and partial conformance are defined (see Levels ofConformance).Implementing ATAG 2.0 document: The Implementing ATAG 2.0 documentprovides additional non-normative information for each success criterion, includinga description of the intent of the success criterion, examples and links to relatedresources.

Levels of Conformance

In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in thedevelopment of authoring tools is as simple as possible, ATAG 2.0 shares WCAG 2.0'sthree level conformance model: Level A (lowest), AA (middle), AAA (highest). For moreinformation, see Understanding Levels of Conformance.

Integration of Accessibility Features

When implementing ATAG 2.0, authoring tool developers should carefully integratefeatures that support more accessible authoring into the same "look-and-feel" as otherfeatures of the authoring tool. Close integration has the potential to:

produce a more seamless product;leverage the existing knowledge and skills of authors;make authors more receptive to new accessibility-related authoring requirements;andreduce the likelihood of author confusion.

Guidelines

The success criteria and the conformance applicability notes in this section arenormative.

PART A: Make the authoring tool user interface accessible

Part A Conformance Applicability Notes:

1. Scope of "authoring tool user interface": The Part A success criteria apply to allaspects of the authoring tool user interface that are concerned with producing the"included" web content technologies. This includes views of the web content beingedited and features that are independent of the content being edited (e.g., menus,button bars, status bars, user preferences, documentation).

2. Reflected content accessibility problems: The authoring tool is responsible forensuring that editing-views display the web content being edited in a way that ismore accessible to authors with disabilities (e.g., ensuring that text alternatives inthe content can be programmatically determined). However, where an authoringtool user interface accessibility problem is caused directly by the content beingedited (e.g., if an image in the content lacks a text alternative), then this would notbe considered a deficiency in the accessibility of the authoring tool user interface.

3. Developer control: The Part A success criteria only apply to the authoring tooluser interface as it is provided by the developer. They do not apply to anysubsequent modifications by parties other than the authoring tool developer (e.g.,user modifications of default settings, third-party plug-ins).

4. User agent features: Web-based authoring tools may rely on user agent features(e.g., keyboard navigation, find functions, display preferences, undo features) tosatisfy success criteria. Conformance claims are optional, but any claim that ismade must record the user agent(s).

5. Accessibility of features provided to meet Part A: The Part A success criteriaapply to the entire authoring tool user interface, including any features added tomeet the success criteria in Part A (e.g., documentation, search functions). Theonly exemption is for preview features, as long as they meet the relevant successcriteria in Guideline A.3.7. Previews are treated differently than editing-viewsbecause all authors, including those with disabilities, benefit when previewfeatures accurately reflect the functionality of user agents that are actually in use byend users.

6. Unrecognizable content: When success criteria require authoring tools to treatweb content according to semantic criteria, the success criteria do not apply whenthese semantics are missing (e.g., text that describes an image is only consideredto be a text alternative when this role is encoded within markup).

PRINCIPLE A.1: Authoring tool user interfaces mustfollow applicable accessibility guidelines

Guideline A.1.1: (For the authoring tool user interface) Ensure thatweb-based functionality is accessible. [Implementing A.1.1]

Rationale: When authoring tools (or parts of authoring tools) are web-based,conforming to WCAG 2.0 will facilitate access by all authors, including those usingassistive technologies.

A.1.1.1 Web-Based Accessible (WCAG): If the authoring tool contains web-based userinterfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria.(Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A andAA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Implementing A.1.1.1

Guideline A.1.2: (For the authoring tool user interface) Ensure thatnon-web-based functionality is accessible. [Implementing A.1.2]

Rationale: When authoring tools (or parts of authoring tools) are non-web-based,following existing platform accessibility guidelines and implementing communicationwith platform accessibility services facilitates access by all authors, including thoseusing assistive technologies.

A.1.2.1 Accessibility Guidelines: If the authoring tool contains non-web-based userinterfaces, then those non-web-based user interfaces follow user interface accessibilityguidelines for the platform. (Level A)

Note: The (optional) explanation of conformance claim results should record the userinterface accessibility guidelines that were followed.

Implementing A.1.2.1

A.1.2.2 Platform Accessibility Services: If the authoring tool contains non-web-baseduser interfaces, then those non-web-based user interfaces implement communicationwith platform accessibility services. (Level A)

Note: The (optional) explanation of conformance claim results should record theplatform accessibility service(s) that were implemented.

Implementing A.1.2.2

PRINCIPLE A.2: Editing-views must be perceivable

Guideline A.2.1: (For the authoring tool user interface) Makealternative content available to authors. [Implementing A.2.1]

Rationale: Some authors require access to alternative content in order to interact withthe web content that they are editing.

A.2.1.1 Text Alternatives for Rendered Non-Text Content: If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-textcontent can be programmatically determined. (Level A)

Implementing A.2.1.1

A.2.1.2 Alternatives for Rendered Time-Based Media: If an editing-view renders time-based media, then at least one of the following is true: (Level A)

(a) Option to Render: The authoring tool provides the option to render alternatives

for the time-based media; or(b) User Agent Option: Authors have the option to preview the time-based media ina user agent that is able to render the alternatives.

Implementing A.2.1.2

Guideline A.2.2: (For the authoring tool user interface) Editing-viewpresentation can be programmatically determined. [ImplementingA.2.2]

Rationale: Some authors need access to details about the editing-view presentation,via their assistive technology, when that presentation is used to convey statusmessages (e.g., underlining misspelled words) or provide information about how theend user will experience the web content being edited.

A.2.2.1 Editing-View Status Indicators: If an editing-view adds status indicators to thecontent being edited, then the status messages being indicated can beprogrammatically determined. (Level A)

Note: Status indicators may indicate errors (e.g., spelling errors), tracked changes,hidden elements, or other information.

Implementing A.2.2.1

A.2.2.2 Access to Rendered Text Properties: If an editing-view renders any textformatting properties that authors can also edit using the editing-view, then theproperties can be programmatically determined. (Level AA)

Implementing A.2.2.2

PRINCIPLE A.3: Editing-views must be operable

Guideline A.3.1: (For the authoring tool user interface) Providekeyboard access to authoring features. [Implementing A.3.1]

Rationale: Some authors with limited mobility or visual disabilities are not able to usea mouse and instead require keyboard interface access to all of the functionality of theauthoring tool.

A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operablethrough a keyboard interface without requiring specific timings for individual keystrokes,except where the underlying function requires input that depends on the path of the user'smovement and not just the endpoints. (Level A)

Note 1: Keyboard interfaces are programmatic services provided by many platformsthat allow operation in a device independent manner. This success criterion does notimply the presence of a hardware keyboard.Note 2: The path exception relates to the underlying function, not the input technique.

For example, if using handwriting to enter text, the input technique (handwriting)requires path-dependent input, but the underlying function (text input) does not. Thepath exception encompasses other input variables that are continuously sampled frompointing devices, including pressure, speed, and angle.Note 3: This success criterion does not forbid and should not discourage other inputmethods (e.g., mouse, touch) in addition to keyboard operation.

Implementing A.3.1.1

A.3.1.2 No Keyboard Traps: If keyboard focus can be moved to a component using akeyboard interface, then focus can be moved away from that component using only akeyboard interface, and, if it requires more than unmodified arrow or tab keys or otherstandard exit methods, authors are advised of the method for moving focus away. (LevelA)

Implementing A.3.1.2

A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includesmechanisms to make keyboard access more efficient than sequential keyboard access.(Level AA)

Implementing A.3.1.3

A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is operablethrough a keyboard interface without requiring specific timings for individual keystrokes.(Level AAA)

Implementing A.3.1.4

A.3.1.5 Customize Keyboard Access: If the authoring tool includes keyboard commands,then those keyboard commands can be customized. (Level AAA)

Implementing A.3.1.5

A.3.1.6 Present Keyboard Commands: If the authoring tool includes keyboardcommands, then the authoring tool provides a way for authors to determine the keyboardcommands associated with authoring tool user interface components. (Level AAA)

Implementing A.3.1.6

Guideline A.3.2: (For the authoring tool user interface) Provideauthors with enough time. [Implementing A.3.2]

Rationale: Some authors who have difficulty typing, operating the mouse, orprocessing information can be prevented from using systems with short time limits orthat require fast reaction speeds, such as clicking on a moving target.

A.3.2.1 Auto-Save (Minimum): If the authoring tool includes authoring session time limits,then the authoring tool can be set to automatically save web content edits made usingthe authoring tool before the session time limits are reached. (Level A)

Implementing A.3.2.1

A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one ofthe following is true: (Level A)

(a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or(b) Adjust: Authors are allowed to adjust the time limit before encountering it over awide range that is at least ten times the length of the default setting; or

(c) Extend: Authors are warned before time expires and given at least 20 secondsto extend the time limit with a simple action (e.g., "press the space bar"), andauthors are allowed to extend the time limit at least ten times; or(d) Real-time Exception: The time limit is a required part of a real-time event (e.g., acollaborative authoring system), and no alternative to the time limit is possible; or(e) Essential Exception: The time limit is essential and extending it would invalidatethe activity; or(f) 20 Hour Exception: The time limit is longer than 20 hours.

Implementing A.3.2.2

A.3.2.3 Static Input Components: If authoring tool user interface components acceptinput and move, then authors can pause the movement. (Level A)

Implementing A.3.2.3

A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to automaticallysave web content edits made using the authoring tool. (Level AAA)

Implementing A.3.2.4

Guideline A.3.3: (For the authoring tool user interface) Help authorsavoid flashing that could cause seizures. [Implementing A.3.3]

Rationale: Flashing can cause seizures in authors with photosensitive seizuredisorder.

A.3.3.1 Static View Option: If the authoring tool contains editing-views that render visualtime-based content, then those editing-views can be paused and can be set to not playautomatically. (Level A)

Implementing A.3.3.1

Guideline A.3.4: (For the authoring tool user interface) Enhancenavigation and editing via content structure. [Implementing A.3.4]

Rationale: Some authors who have difficulty typing or operating the mouse benefitwhen authoring tools make use of the structure present in web content to simplifynavigating and editing the content.

A.3.4.1 Navigate By Structure: If editing-views expose the markup elements in the webcontent being edited, then the markup elements (e.g., source code, content renderings)are selectable and navigation mechanisms are provided to move the selection focusbetween elements. (Level AA)

Implementing A.3.4.1

A.3.4.2 Navigate by Programmatic Relationships: If editing-views allow editing ofprogrammatic relationships within web content, then mechanisms are provided thatsupport navigation between the related content. (Level AAA)

Note: Depending on the web content technology and the nature of the authoring tool,relationships may include, but are not limited to, element nesting, headings, labeling,

programmatic definitions, and ID relationships.

Implementing A.3.4.2

Guideline A.3.5: (For the authoring tool user interface) Provide textsearch of the content. [Implementing A.3.5]

Rationale: Some authors who have difficulty typing or operating the mouse benefitfrom the ability to use text search to navigate to arbitrary points within the web contentbeing edited.

A.3.5.1 Text Search: If the authoring tool provides an editing-view of text-based content,then the editing-view enables text search, such that all of the following are true: (LevelAA)

(a) All Editable Text: Any text content that is editable by the editing-view issearchable (including alternative content); and(b) Match: Matching results can be made visible to authors and given focus; and(c) No Match: Authors are informed when no results are found; and(d) Two-way: The search can be made forwards or backwards.

Implementing A.3.5.1

Guideline A.3.6: (For the authoring tool user interface) Managepreference settings. [Implementing A.3.6]

Rationale: Some authors need to set their own display settings in a way that differsfrom the presentation that they want to define for the published web content. Providingthe ability to save and reload sets of keyboard and display preference settingsbenefits authors who have needs that differ over time (e.g., due to fatigue).

A.3.6.1 Independence of Display: If the authoring tool includes display settings forediting-views, then the authoring tool allows authors to adjust these settings withoutmodifying the web content being edited. (Level A)

Implementing A.3.6.1

A.3.6.2 Save Settings: If the authoring tool includes display and/or control settings, thenthese settings can be saved between authoring sessions. (Level AA)

Implementing A.3.6.2

A.3.6.3 Apply Platform Settings: The authoring tool respects changes in platform displayand control settings, unless authors select more specific display and control settingsusing the authoring tool. (Level AA)

Implementing A.3.6.3

A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, thenthe authoring tool provides the option of saving and reloading multiple configurations ofsettings. (Level AAA)

Implementing A.3.6.4

Guideline A.3.7: (For the authoring tool user interface) Ensure thatpreviews are at least as accessible as in-market user agents.[Implementing A.3.7]

Rationale: Preview features are provided by many authoring tools because theworkflow of authors often includes periodically checking how user agents will displaythe web content to end users. Authors with disabilities need the same opportunity tocheck their work.

A.3.7.1 Preview (Minimum): If a preview is provided, then at least one of the following istrue: (Level A)

(a) In-Market User Agent: The preview renders content using a user agent that is in-market; or(b) UAAG (Level A): The preview conforms to the User Agent Accessibility

Guidelines 1.0 Level A [UAAG].

Implementing A.3.7.1

A.3.7.2 Preview (Enhanced): If a preview is provided, then authors can specify whichuser agent performs the preview. (Level AAA)

Implementing A.3.7.2

PRINCIPLE A.4: Editing-views must be understandable

Guideline A.4.1: (For the authoring tool user interface) Help authorsavoid and correct mistakes. [Implementing A.4.1]

Rationale: Some authors with disabilities may be more susceptible to input errors dueto factors such as difficulty making fine movements and speech recognition systemerrors.

A.4.1.1 Content Changes Reversible (Minimum): All authoring actions are eitherreversible or the authoring tool requires author confirmation to proceed. (Level A)

Implementing A.4.1.1

A.4.1.2 Settings Change Confirmation: If the authoring tool provides mechanisms forchanging authoring tool user interface settings, then those mechanisms can reverse thesetting changes, or the authoring tool requires author confirmation to proceed. (Level A)

Implementing A.4.1.2

A.4.1.3 Content Changes Reversible (Enhanced): Authors can sequentially reverse aseries of reversible authoring actions. (Level AAA)

Note: It is acceptable to clear the authoring action history at the end of authoringsessions.

Implementing A.4.1.3

Guideline A.4.2: (For the authoring tool user interface) Document theuser interface including all accessibility features. [Implementing A.4.2]

Rationale: Some authors may not be able to understand or operate the authoring tooluser interface without documentation.

A.4.2.1 Describe Accessibility Features: For each authoring tool feature that is used tomeet Part A of ATAG 2.0, at least one of the following is true: (Level A)

(a) Described in the documentation: Use of the feature is explained in the authoringtool's documentation; or(b) Described in the interface: Use of the feature is explained in the authoring tooluser interface; or(c) Platform service: The feature is a service provided by an underlying platform; or(d) Not used by authors: The feature is not used directly by authors (e.g., passinginformation to a platform accessibility service).

Note: The accessibility of the documentation is covered by Guideline A.1.1 andGuideline A.1.2.

Implementing A.4.2.1

A.4.2.2 Document All Features: For each authoring tool feature, at least one of thefollowing is true: (Level AA)

(a) Described in the documentation: Use of the feature is explained in the authoringtool's documentation; or(b) Described in the interface: Use of the feature is explained in the authoring tooluser interface; or(c) Platform service: The feature is a service provided by an underlying platform; or(d) Not used by authors: The feature is not used directly by authors (e.g., passinginformation to a platform accessibility service).

Note: The accessibility of the documentation is covered by Guideline A.1.1 andGuideline A.1.2.

Implementing A.4.2.2

PART B: Support the production of accessible content

Part B Conformance Applicability Notes:

1. Author availability: Any Part B success criteria that refer to authors only applyduring authoring sessions.

2. Developer control: The Part B success criteria only apply to the authoring tool as itis provided by the developer. This does not include subsequent modifications byparties other than the authoring tool developer (e.g., third-party plug-ins, user-defined templates, user modifications of default settings).

3. Applicability after the end of an authoring session: Authoring tools areresponsible for the web content accessibility (WCAG) of web content that theyautomatically generate after the end of an author's authoring session (see SuccessCriterion B.1.1.1). For example, if the developer changes the site-wide templates

of a content management system, these would be required to meet theaccessibility requirements for automatically-generated content. Authoring tools arenot responsible for changes to the accessibility of content that the author causes,whether it is author-generated or automatically-generated by another system thatthe author has specified (e.g., a third-party feed).

4. Authoring systems: As per the ATAG 2.0 definition of authoring tool, severalsoftware tools (identified in any conformance claim) can be used in conjunction tomeet the requirements of Part B (e.g., an authoring tool could make use of a third-party software accessibility checking tool).

5. Accessibility of features provided to meet Part B: The Part A success criteriaapply to the entire authoring tool user interface, including any features that must bepresent to meet the success criteria in Part B (e.g., checking tools, repair tools,tutorials, documentation).

6. Multiple authoring roles: Some authoring tools include multiple author roles, eachwith different views and content editing permissions (e.g., a content managementsystem may separate the roles of designers, content authors, and qualityassurers). In these cases, the Part B success criteria apply to the authoring tool asa whole, not to the view provided to any particular authoring role. Accessiblecontent support features should be made available to any authoring role where itwould be useful.

7. Unrecognizable content: When success criteria require authoring tools to treatweb content according to semantic criteria, the success criteria do not apply whenthese semantics are missing (e.g., text that describes an image is only consideredto be a text alternative when this role is encoded within markup).

PRINCIPLE B.1: Fully automatic processes must produceaccessible content

Guideline B.1.1: Ensure automatically specified content is accessible.[Implementing B.1.1]

Rationale: If authoring tools automatically specify web content with accessibilityproblems (WCAG), then additional repair tasks are imposed on authors.

B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG): If the authoring toolprovides the functionality for automatically generating web content after the end of anauthoring session, authors can specify that the content be accessible web content(WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: This success criterion applies only to automatic processes specified by theauthoring tool developer. It does not apply when author actions prevent generation ofaccessible web content (WCAG).

Implementing B.1.1.1

B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG): If the authoring

tool provides the functionality for automatically generating web content during anauthoring session, then at least one of the following is true: (Level A to meet WCAG 2.0Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; LevelAAA to meet all WCAG 2.0 success criteria)

(a) Accessible: The content is accessible web content (WCAG) without author input;or(b) Prompting: During the automatic generation process, authors are prompted forany required accessibility information (WCAG); or(c) Automatic Checking: After the automatic generation process, accessibilitychecking is automatically performed; or(d) Checking Suggested: After the automatic generation process, the authoring toolprompts authors to perform accessibility checking.

Note 1: Automatic generation includes automatically selecting templates for authors.Note 2: This success criterion applies only to automatic processes specified by theauthoring tool developer. It does not apply when author actions prevent generation ofaccessible web content (WCAG).

Implementing B.1.1.2

Guideline B.1.2: Ensure accessibility information is preserved.[Implementing B.1.2]

Rationale: Accessibility information (WCAG) is critical to maintaining comparablelevels of web content accessibility (WCAG) between the input and output of webcontent transformations.

B.1.2.1 Restructuring and Recoding Transformations (WCAG): If the authoring toolprovides restructuring transformations or re-coding transformations, and if equivalentmechanisms exist in the web content technology of the output, then at least one of thefollowing is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meetWCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

(a) Preserve: Accessibility information (WCAG) is preserved in the output; or(b) Warning: Authors have the default option to be warned that accessibilityinformation (WCAG) may be lost (e.g., when saving a vector graphic into a rasterimage format); or(c) Automatic Checking: After the transformation, accessibility checking isautomatically performed; or(d) Checking Suggested: After the transformation, the authoring tool promptsauthors to perform accessibility checking.

Note 1: For text alternatives for non-text content, see Success Criterion B.1.2.4.Note 2: This success criteria only applies when the output technology is "included" forconformance.

Implementing B.1.2.1

B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG): If the authoring tool supports copyand paste of structured content, then any accessibility information (WCAG) in the copiedcontent is preserved when the authoring tool is both the source and destination of thecopy-paste. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG

2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Implementing B.1.2.2

B.1.2.3 Optimizations Preserve Accessibility: If the authoring tool provides optimizingweb content transformations, then any accessibility information (WCAG) in the input ispreserved in the output. (Level A).

Implementing B.1.2.3

B.1.2.4 Text Alternatives for Non-Text Content are Preserved: If the authoring toolprovides web content transformations that preserve non-text content in the output, thenany text alternatives for that non-text content are also preserved, if equivalentmechanisms exist in the web content technology of the output. (Level A).

Note: This success criteria only applies when the output technology is "included" forconformance.

Implementing B.1.2.4

PRINCIPLE B.2: Authors must be supported in producingaccessible content

Guideline B.2.1: Ensure accessible content production is possible.[Implementing B.2.1]

Rationale: To support accessible web content (WCAG) production, at minimum, itmust be possible to produce web content that conforms with WCAG 2.0 using theauthoring tool.

B.2.1.1 Accessible Content Possible (WCAG): If the authoring tool places restrictions onthe web content that authors can specify, then those restrictions do not prevent WCAG2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria;Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

Implementing B.2.1.1

Guideline B.2.2: Guide authors to produce accessible content.[Implementing B.2.2]

Rationale: By guiding authors from the outset toward the creation and maintenance ofaccessible web content (WCAG), web content accessibility problems (WCAG) aremitigated and less repair effort is required.

B.2.2.1 Accessible Option Prominence (WCAG): If authors are provided with a choice ofauthoring actions for achieving the same authoring outcome (e.g., styling text), thenoptions that will result in accessible web content (WCAG) are at least as prominent asoptions that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet

WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Implementing B.2.2.1

B.2.2.2 Setting Accessibility Properties (WCAG): If the authoring tool providesmechanisms to set web content properties (e.g., attribute values), then mechanisms arealso provided to set web content properties related to accessibility information (WCAG).(Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A andAA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: Success Criterion B.4.1.4 addresses the prominence of the mechanisms.

Implementing B.2.2.2

Guideline B.2.3: Assist authors with managing alternative content fornon-text content. [Implementing B.2.3]

Rationale: Improperly generated alternative content can create web contentaccessibility problems (WCAG) and interfere with accessibility checking.

See Also: This guideline applies when non-text content is specified by authors (e.g.,inserting an image). When non-text content is automatically added by the authoringtool, see Guideline B.1.1.

B.2.3.1 Alternative Content is Editable (WCAG): If the authoring tool provides functionalityfor adding non-text content, then authors are able to modify programmatically associatedtext alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria;Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

Implementing B.2.3.1

B.2.3.2 Conditions on Automated Suggestions: If the authoring tool automaticallysuggests text alternatives for non-text content during the authoring session, then the textalternatives may only be suggested under the following conditions: (Level A)

(a) Author Control: Authors have the opportunity to accept, modify, or reject thesuggested text alternatives prior to insertion; and(b) Relevant Sources: The suggested text alternatives are only derived fromsources designed to fulfill the same purpose (e.g., suggesting the value of animage's "description" metadata field as a long description).

Implementing B.2.3.2

B.2.3.3 Let User Agents Repair: If the authoring tool provides automatic repair of textalternatives for non-text content after the end of an authoring session, then the authoringtool avoids using text values that would also be available to user agents. (Level A)

Note: Examples of text values that are also available to user agents, and should beavoided, include the filename, the file format, and generic phrases (e.g. "image").

Implementing B.2.3.3

B.2.3.4 Save for Reuse: If the authoring tool provides the functionality for adding non-text content, when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)

(a) Save and Suggest: The text alternatives are automatically saved and suggested

by the authoring tool, if the same non-text content is reused; and(b) Edit Option: The author has the option to edit or delete the saved textalternatives.

Implementing B.2.3.4

Guideline B.2.4: Assist authors with accessible templates.[Implementing B.2.4]

Rationale: Providing accessible templates (WCAG) can have several benefits,including: immediately improving the accessibility of the web content (WCAG) ofbeing edited, reducing the effort required of authors, and demonstrating theimportance of accessible web content (WCAG).

B.2.4.1 Accessible Template Options (WCAG): If the authoring tool provides templates,then there are accessible template (WCAG) options for a range of template uses. (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AAsuccess criteria; Level AAA to meet all WCAG 2.0 success criteria)

Implementing B.2.4.1

B.2.4.2 Identify Template Accessibility (Minimum): If the authoring tool includes atemplate selection mechanism and provides any non-accessible template (WCAG)options, then the templates are provided such that the template selection mechanismcan display distinctions between the accessible and non-accessible options. (Level AA)

Note: The distinction can involve providing information for the accessible templates,the non-accessible templates or both.

Implementing B.2.4.2

B.2.4.3 Author-Created Templates: If the authoring tool includes a template selectionmechanism and allows authors to create new non-accessible templates (WCAG), thenauthors can enable the template selection mechanism to display distinctions betweenaccessible and non-accessible templates that they create. (Level AA)

Note: The distinction can involve providing information for the accessible templates(WCAG), the non-accessible templates or both.

Implementing B.2.4.3

B.2.4.4 Identify Template Accessibility (Enhanced): If the authoring tool provides anynon-accessible templates (WCAG) options and does not include a template selectionmechanism, then the non-accessible templates include accessibility warnings within thetemplates. (Level AAA)

Implementing B.2.4.4

Guideline B.2.5: Assist authors with accessible pre-authored content.[Implementing B.2.5]

Rationale: Providing accessible (WCAG) pre-authored content (e.g., clip art,synchronized media, widgets) can have several benefits, including: immediately

improving the accessibility of web content (WCAG) being edited, reducing the effortrequired of authors, and demonstrating the importance of accessible web content(WCAG).

B.2.5.1 Pre-Authored Content Selection Mechanism: If authors are provided with aselection mechanism for pre-authored content other than templates (e.g., clip art gallery,widget repository, design themes), then both of the following are true: (Level AA)

(a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and(b) Prominence: Any accessible (WCAG) options are at least as prominent as otherpre-authored content options.

Implementing B.2.5.1

B.2.5.2 Pre-Authored Content Accessibility Status: If the authoring tool provides arepository of pre-authored content, then each of the content objects has a recordedaccessibility status. (Level AAA)

Implementing B.2.5.2

PRINCIPLE B.3: Authors must be supported in improvingthe accessibility of existing content

Guideline B.3.1: Assist authors in checking for accessibility problems.[Implementing B.3.1]

Rationale: When accessibility checking is an integrated function of the authoring tool,it helps make authors aware of web content accessibility problems (WCAG) duringthe authoring process, so they can be immediately addressed.

B.3.1.1 Checking Assistance (WCAG): If the authoring tool provides authors with theability to add or modify web content in such a way that a WCAG 2.0 success criterioncan be violated, then accessibility checking for that success criterion is provided (e.g.,an HTML authoring tool that inserts images should check for alternative text; a videoauthoring tool with the ability to edit text tracks should check for captions). (Level A tomeet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA successcriteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: Automated and semi-automated checking is possible (and encouraged) formany types of web content accessibility problems (WCAG). However, manualchecking is the minimum requirement to meet this success criterion. In manualchecking, the authoring tool provides authors with instructions for detecting problems,which authors must carry out by themselves. For more information on checking, seeImplementing ATAG 2.0 - Appendix B: Levels of Checking Automation.

Implementing B.3.1.1

B.3.1.2 Help Authors Decide: If the authoring tool provides checks that require authors todecide whether a potential web content accessibility problem (WCAG) is correctlyidentified (i.e., manual checking and semi-automated checking), then instructions are

provided from the check that describe how to decide. (Level A)

Implementing B.3.1.2

B.3.1.3 Help Authors Locate: If the authoring tool provides checks that require authors todecide whether a potential web content accessibility problem (WCAG) is correctlyidentified (i.e., manual checking and semi-automated checking), then the relevantcontent is identified to the authors. (Level A)

Note: Depending on the nature of the editing-view and the scope of the potential webcontent accessibility problem (WCAG), identification might involve highlightingelements or renderings of elements, displaying line numbers, or providing instructions.

Implementing B.3.1.3

B.3.1.4 Status Report: If the authoring tool provides checks, then authors can receive anaccessibility status report based on the results of the accessibility checks. (Level AA)

Note: The format of the accessibility status report is not specified and they mightinclude a listing of problems detected or a WCAG 2.0 conformance level, etc..

Implementing B.3.1.4

B.3.1.5 Programmatic Association of Results: If the authoring tool provides checks, thenthe authoring tool can programmatically associate accessibility checking results with theweb content that was checked. (Level AA)

Implementing B.3.1.5

Guideline B.3.2: Assist authors in repairing accessibility problems.[Implementing B.2.3]

Rationale: When repair as an integral part of the authoring process, it greatlyenhances the utility of checking and increases the likelihood that web contentaccessibility problems (WCAG) will be properly addressed.

B.3.2.1 Repair Assistance (WCAG): If checking (see Success Criterion B.3.1.1) candetect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) areprovided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: Automated and semi-automated repair is possible (and encouraged) for manytypes of web content accessibility problems (WCAG). However, manual repair is theminimum requirement to meet this success criterion. In manual repair, the authoringtool provides authors with instructions for repairing problems, which authors must carryout by themselves. For more information on repair, see Implementing ATAG 2.0 -Appendix C: Levels of Repair Automation.

Implementing B.3.2.1

PRINCIPLE B.4: Authoring tools must promote andintegrate their accessibility features

Guideline B.4.1: Ensure the availability of features that support theproduction of accessible content. [Implementing B.4.1]

Rationale: The accessible content support features will be more likely to be used, ifthey are turned on and are afforded reasonable prominence within the authoring tooluser interface.

B.4.1.1 Features Active by Default: All accessible content support features are turned onby default. (Level A)

Implementing B.4.1.1

B.4.1.2 Option to Reactivate Features: If authors can turn off an accessible contentsupport feature, then they can turn the feature back on. (Level A)

Implementing B.4.1.2

B.4.1.3 Feature Availability Information: If the authoring tool supports production of anyweb content technologies for publishing for which the authoring tool does not providesupport for the production of accessible web content (WCAG), then this is documented.(Level AA)

Note: This success criterion concerns the presence or absence of support features,such as accessibility checkers, not any intrinsic property of web content technologies.

Implementing B.4.1.3

B.4.1.4 Feature Deactivation Warning: If authors turn off an accessible content supportfeature, then the authoring tool informs them that this may increase the risk of contentaccessibility problems (WCAG). (Level AA)

Implementing B.4.1.4

B.4.1.5 Feature Prominence: All accessible content support features are at least asprominent as features related to either invalid markup, syntax errors, spelling errors orgrammar errors. (Level AA)

Implementing B.4.1.5

Guideline B.4.2: Ensure that documentation promotes the productionof accessible content. [Implementing B.4.2]

Rationale: Some authors need support in determining how to use accessible contentproduction features (e.g. how to respond to prompts for text alternatives, how to useaccessibility checking tools). Demonstrating accessible authoring as routine practice,or at least not demonstrating inaccessible practices, will help to encourageacceptance of accessibility by some authors.

B.4.2.1 Model Practice (WCAG): A range of examples in the documentation (e.g.,markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoringpractices (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meetWCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Implementing B.4.2.1

B.4.2.2 Feature Instructions: Instructions for using any accessible content support

features appear in the documentation. (Level A)

Implementing B.4.2.2

B.4.2.3 Tutorial: The authoring tool provides a tutorial for an accessible authoringprocess that is specific to that authoring tool. (Level AAA)

Implementing B.4.2.3

B.4.2.4 Instruction Index: The authoring tool documentation contains an index to theinstructions for using any accessible content support features. (Level AAA)

Implementing B.4.2.4

Conformance

This section is normative.

Conformance means that the authoring tool satisfies the applicable success criteriadefined in the guidelines section. This conformance section describes conformance andlists the conformance requirements.

Conformance Requirements

This section is normative.

Success Criteria Satisfaction

The first step in determining ATAG 2.0 conformance is to assess whether the SuccessCriteria have been satisfied. The potential answers are:

Not Applicable: The ATAG 2.0 definition of authoring tool is inclusive and, assuch, it covers software with a wide range of capabilities and contexts ofoperation. In order to take into account authoring tools with limited feature sets(e.g., a photo editor, a CSS editor, a status update field in a social networkingapplication), many of the ATAG 2.0 success criteria are conditional, applying onlyto authoring tools with the given features(s). If a conformance claim is made, anexplanation of why the success criterion is not applicable is required.Yes: In the case of some success criteria, this will include a Level (A, AA, or AAA)

with reference to WCAG 2.0. If a conformance claim is made, an explanation isoptional, but strongly recommended.No: If a conformance claim is made, an explanation is optional, but stronglyrecommended.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

At the time of publishing, WCAG 2.0 [WCAG20] is the current W3C Recommendationregarding web content accessibility. For this reason, ATAG 2.0 refers to WCAG 2.0when setting requirements for (1) the accessibility of web-based authoring tool userinterfaces (in Part A) and (2) how authors should be enabled, supported, and guided

toward producing web content that is more accessible to end users with disabilities (inPart B).

In particular, ATAG 2.0 refers to WCAG 2.0 within its definition of the term "accessiblecontent" (and related terms, such as "accessible template"). The definition of"accessible content" is content that would conform to WCAG 2.0, at either Level A, AA,or AAA, under the assumption that any web content technologies that are relied upon tosatisfy the WCAG 2.0 success criteria are accessibility supported. The phrase "at eitherLevel A, AA, or AAA" takes into account that the definition of "accessible content" candiffer depending on the context of use (e.g. in a Level A success criterion of ATAG 2.0versus in a Level AAA success criterion). The definition also includes two notes:

The first is "[i]f accessibility support for the relied upon technologies is lacking,then the content will not conform to WCAG 2.0 and one or more groups of end-users with disabilities will likely experience difficulty accessing the content."The second is "[c]onformance to WCAG 2.0, even at the highest level (i.e., LevelAAA), still may not make content 'accessible to individuals with all types, degrees,or combinations of disability'." In order to highlight success criteria or definedterms in ATAG 2.0 that depend on WCAG 2.0, they are marked with theparenthetical: "(WCAG)".

Note on "accessibility-supported ways of using technologies":

Part of conformance to WCAG 2.0 is the requirement that "only accessibility-supportedways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria.Any information or functionality that is provided in a way that is not accessibility

supported is also available in a way that is accessibility supported." In broad terms,WCAG 2.0 considers a web content technology to be "accessibility supported" when (1)the way that the web content technology is used is supported by users' assistivetechnology and (2) the web content technology has accessibility-supported user agentsthat are available to end users.

This concept is not easily extended to authoring tools because many authoring tools canbe installed and used in a variety of environments with differing availabilities for assistivetechnologies and user agents (e.g., private intranets versus public websites, monolingualsites versus multilingual sites). Therefore:

ATAG 2.0 does not include the accessibility-supported requirement.As a result, ATAG 2.0 success criteria do not refer to WCAG 2.0"conformance", but instead refer to "meeting WCAG 2.0 successcriteria".

Once an authoring tool has been installed and put into use, it would be possible toassess the WCAG 2.0 conformance of the web content that the authoring tool produces,including whether the WCAG 2.0 accessibility-supported requirement is met. However,this WCAG 2.0 conformance assessment would be completely independent of theauthoring tool's conformance with ATAG 2.0.

Conformance Options and Levels

There are two types of conformance, each with three levels:

ATAG 2.0 Conformance (Level A, AA, or AAA)

This conformance option may be selected when an authoring tools can be used toproduce accessible web content (WCAG) without additional tools or components. Thelevel of conformance is determined as follows:

Level A: The authoring tool satisfies all of the applicable Level A success criteria.Level AA: The authoring tool satisfies all of the applicable Level A and Level AA

success criteria.Level AAA: The authoring tool satisfies all of the applicable success criteria.

Note 1: The Part A Conformance Applicability Notes and Part B ConformanceApplicability Notes must be applied. Note 2: If the minimum conformance level (Level A) has not been achieved (i.e., at leastone applicable Level A success criterion has not been met), it is still beneficial to publisha statement specifying which success criteria were met.

Partial ATAG 2.0 Conformance - Process Component (Level A, AA, or AAA)

This conformance option may be selected when an authoring tool would requireadditional tools or components in order to conform as a complete authoring system. Thisoption may be used for components with very limited functionality (e.g. a plug-in) up tonearly complete systems (e.g. a markup editor that only lacks accessibility checkingfunctionality).

The level of conformance (A, AA, or AAA) is determined as above except that, for any"no" answers, the tool must not prevent the success criteria from being met by anotherauthoring process component as part of a complete authoring system.

Note 1: Authoring tools would not be able to meet partial conformance if they preventadditional authoring process components from meeting the failed success criteria (e.g.,for security reasons).Note 2: The Part A Conformance Applicability Notes and Part B ConformanceApplicability Notes must be applied.

Partial ATAG 2.0 Conformance - Platform Limitations (Level A, AA, or AAA)

This conformance option may be selected when an authoring tool is unable to meet oneor more success criteria because of intrinsic limitations of the platform (e.g., lacking aplatform accessibility service). The (optional) explanation of conformance claim resultsshould explain what platform features are missing.

Web Content Technologies Produced:

Authoring tools conform to ATAG 2.0 with respect to the production of specific webcontent technologies (e.g., Level A Conformance with respect to the production ofXHTML 1.0).

If an authoring tool is capable of producing multiple web content technologies, then theconformance may include only a subset of these technologies as long as the subsetincludes both any technologies that the developer sets for automatically-generatedcontent or that the developer sets as the default for author-generated content. The subsetmay include "interim" formats that are not intended for publishing to end users, but this isnot required.

Live publishing authoring tools:

ATAG 2.0 may be applied to authoring tools with workflows that involve live authoring ofweb content (e.g., some collaborative tools). Due to the challenges inherent in real-timepublishing, conformance to Part B of ATAG 2.0 for these authoring tools may involvesome combination of support before (e.g., support in preparing accessible slides),during (e.g., live captioning as WCAG 2.0 requires at Level AA) and after the liveauthoring session (e.g., the ability to add a transcript to the archive of a presentation thatwas initially published in real-time). For more information, see the Implementing ATAG2.0 - Appendix E: Authoring Tools for Live Web Content.

Conformance Claims (Optional)

Note: As with any software application, authoring tools can be collections ofcomponents. A conformance claim can only be made by a responsible entity. Any otherattempted "claims" are, in fact, reviews.

Required Components of a Conformance Claim

1. Date of the claim.

2. Guidelines title, version and URI "Authoring Tool Accessibility Guidelines 2.0 at@@"

3. Conformance level satisfied.4. Authoring tool information: The name of the authoring tool and sufficient

additional information to specify the version (e.g., vendor name, version number(or version range), required patches or updates, human language of the userinterface or documentation).

Note: If the authoring tool is a collection of software components (e.g., amarkup editor, an image editor, and a validation tool), then information mustbe provided separately for each component, although the conformance claimwill treat them as a whole.

5. Platform(s): The platform(s) upon which the authoring tool operates:

For user agent platform(s) (used to evaluate web-based authoring tooluser interfaces): provide the name and version information of the user

agent(s).For platforms that are not user agents (used to evaluate non-web-basedauthoring tool user interfaces): provide the name and version information ofthe platform(s) (e.g., desktop operating system, mobile operating system,cross-OS environment) and the name and version of the platformaccessibility service(s) employed.

6. A list of the web content technologies produced by the authoring tool thatare included in the claim. If there are any web content technologies produced bythe authoring tool that are not included in the conformance claim, these must belisted separately.

7. Results for each of the success criteria: Yes, No, Not Applicable

Optional Components of a Conformance Claim

In addition to the required components of a conformance claim above, considerproviding additional information to assist authors. Recommended additional informationincludes:

1. An explanation of the success criteria results (Yes, No). (stronglyrecommended)

2. Information about how the web content technologies produced can be used tocreate accessible web content (e.g., links to technology-specific WCAG 2.0techniques).

3. Information about any additional steps taken that go beyond the success criteria toenhance accessibility.

4. A machine-readable metadata version of the conformance claim.5. A description of the authoring tool that identifies the types of editing-views that it

includes.

Disclaimer

Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result of anyATAG 2.0 conformance claim that has not been published under the authority of theW3C, WAI, or AUWG.

Appendix A: Glossary

This section is normative.

This appendix contains definitions for all of the significant/important/unfamiliar termsused in the normative parts of this specification, including terms used in theConformance section. Please consult http://www.w3.org/TR/qaframe-spec/ for moreinformation on the role of definitions in specification quality.

accessibility problemsATAG 2.0 recognizes two types of accessibility problems:

authoring tool user interface accessibility problems: Aspects of anauthoring tool user interface that does not meet a success criterion in Part Aof ATAG 2.0.web content accessibility problems (WCAG): Aspects of web contentthat does not meet a WCAG 2.0 success criterion (Level A, AA or AAA).

accessibility information (WCAG)Information that web content must contain in order to meet a WCAG 2.0 successcriterion (Level A, AA or AAA). Examples include: programmatically associatedalternative content (e.g., text alternatives for images), role and state information forwidgets, relationships within complex tables).Note: For the purposes of ATAG 2.0, only programmatically determinableinformation qualifies. For additional examples, see Appendix A of theImplementing ATAG 2.0 document.

accessible content support featuresAny features of an authoring tool that directly support authors in increasing theaccessibility of the web content being edited. These are features that must bepresent to meet the success criteria in Part B of ATAG 2.0.

alternative contentWeb content that is used in place of other content that some people are not able toaccess. Alternative content fulfills essentially the same function or purpose as theoriginal content. WCAG 2.0 recognizes several general types of alternative content(for more information see WCAG 2.0):

text alternatives for non-text content: Text that is programmaticallyassociated with non-text content or referred to from text that isprogrammatically associated with non-text content. For example, an imageof a chart might have two text alternatives: a description in the paragraphafter the chart and a short text alternative for the chart indicating in words thata description follows.alternatives for time-based media: Web content that serves the samefunction or purpose as one or more tracks in a time based mediapresentation. This includes: captions, audio descriptions, extended audiodescriptions, sign language interpretation as well as correctly sequencedtext descriptions of time-based visual and auditory information that also iscapable of achieving the outcomes of any interactivity in the time-basedpresentation.media alternative for text: Media that presents no more information than isalready presented in text (directly or via text alternatives). A media alternativefor text is provided for those who benefit from alternate representations oftext. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.

Importantly, from the perspective of authoring tools, alternative content may or maynot be:

programmatically associated: Alternative content whose location andpurpose can be programmatically determined from the original content for

which it is serving as an alternative. For example, a paragraph might serveas a text alternative for an image, but it is only programmatically associatedif this relationship is properly encoded (e.g., by "aria-labeledby").

Note: ATAG 2.0 typically refers to programmatically associated alternative content.ASCII art

A picture created by a spatial arrangement of characters or glyphs (typically fromthe 95 printable characters defined by ASCII).

assistive technologySoftware (or hardware), separate from the authoring tool, that provides functionalityto meet the requirements of users with disabilities. Some authoring tools may alsoprovide direct accessibility features. Examples include:

screen magnifiers, and other visual reading assistants, which are used bypeople with visual, perceptual and physical print disabilities to change textfont, size, spacing, color, synchronization with speech, etc. in order improvethe visual readability of rendered text and images;screen readers, which are used by people who are blind to read textualinformation through synthesized speech or Braille;text-to-speech software, which is used by some people with cognitive,language, and learning disabilities to convert text into synthetic speech;speech recognition software, which may be used by people who have somephysical disabilities;alternative keyboards, which are used by people with certain physicaldisabilities to simulate the keyboard (including alternate keyboards that usehead pointers, single switches, sip/puff and other special input devices);alternative pointing devices, which are used by people with certain physicaldisabilities to simulate mouse pointing and button activations.

audioThe technology of sound reproduction. Audio can be created synthetically(including speech synthesis), recorded from real-world sounds, or both.

author actions preventing generation of accessible web contentWhen the actions of authors prevents authoring tools from generating accessibleweb content (WCAG). Examples include: turning off accessibility options, ignoringprompts for accessibility information (WCAG), providing faulty accessibilityinformation (WCAG) at prompts, modifying the authoring tool (e.g., via scripting,macros), and installing plug-ins.

authorsPeople who use authoring tools to create or modify web content. The term maycover roles such as content authors, designers, programmers, publishers, testers,etc. (see also Part B Conformance Applicability Note 6: Multiple authoring roles).Some authoring tools control who may be an author by managing authorpermissions.

author permissionAuthorization that allows modification of given web content.

authoring actionAny action that authors can take using the authoring tool user interface that results

in editing web content (e.g., typing text, deleting, inserting an element, applying atemplate). In contrast, most authoring tool user interfaces also enable actions thatdo not edit content (e.g., saving, publishing, setting preferences, viewingdocumentation).

reversible authoring action is an authoring action that can be immediatelyand completely undone by the authoring tool upon a cancel request by anauthor. Examples of cancel requests include: "cancel", "undo", "redo" (whenit used to reverse "undo"), "revert", and "roll-back"

Note: It is acceptable to collect a series of text entry actions (e.g., typedwords, a series of backspaces) into a single reversible authoring action..

authoring outcomeThe content or content modifications that result from authoring actions. Authoringoutcomes are cumulative (e.g., text is entered, then styled, then made into a link,then given a title).

authoring practiceAn approach that authors follow to achieve a given authoring outcome. (e.g.,controlling presentation with style sheets). Depending on the design of anauthoring tool, authoring practices may be chosen by the authors or by theauthoring tool. Authoring practices may or may not be:

accessible authoring practices (WCAG): An authoring practice in whichthe authoring outcome conforms to WCAG 2.0 at Level A, AA, or AAA.Some accessible authoring practices require accessibility information(WCAG).

authoring sessionA state of the authoring tool in which web content can be edited by an author.

end of an authoring session: The point at which the author has no furtheropportunity to make changes without starting another session. The end of anauthoring session may be determined by authors (e.g., closing a document,publishing) or by the authoring tool (e.g., when the authoring tool transfersediting permission to another author on a collaborative system). Note that theend of the authoring session is distinct from publishing. Automatic contentgeneration may continue after the end of both the authoring session andinitial publishing (e.g., content management system updates).

authoring toolAny web-based or non-web-based application(s) that can be used by authors(alone or collaboratively) to create or modify web content for use by other people(other authors or end users). Note 1: "application(s)": ATAG 2.0 may be conformed to by stand-aloneapplications or by collections of applications. If a conformance claim is made, thenthe claim must provide identifying information for each application and also for anyrequired extensions, plug-ins, etc.

Note 2: "alone or collaboratively": Multiple authors may contribute to the creationof web content and, depending on the authoring tool, each author may work with

different views of the content and different author permissions. Note 3: "to create or modify web content": This clause rules out software thatcollects data from a person for other purposes (e.g., online grocery order form)and then creates web content from that data (e.g., a web-based warehouse order)without informing the person (however, WCAG 2.0 would still apply). This clausealso rules out software used to create content exclusively in non-web contenttechnologies. Note 4: "for use by other people": This clause rules out the many web applicationsthat allow people to modify web content that only they themselves experience (e.g.,web-based email display settings) or that only provide input to automatedprocesses (e.g., library catalog search page). Examples of software that are generally considered authoring tools under ATAG2.0:

web page authoring tools (e.g., WYSIWYG HTML editors)software for directly editing source codesoftware for converting to web content technologies (e.g., "Save as HTML"features in office document applications)integrated development environments (e.g., for web applicationdevelopment)software that generates web content on the basis of templates, scripts,command-line input or "wizard"-type processessoftware for rapidly updating portions of web pages (e.g., blogging, wikis,online forums)software for generating/managing entire web sites (e.g., contentmanagement systems, courseware tools, content aggregators)email clients that send messages using web content technologiesmultimedia authoring toolssoftware for creating mobile web applications

Examples of software that are not considered authoring tools under ATAG 2.0 (inall cases, WCAG 2.0 still applies if the software is web-based):

customizable personal portals: ATAG 2.0 does not apply because the webcontent being edited is only available to the owner of the portale-commerce order forms: ATAG 2.0 does not apply because the purpose ofan e-commerce order form is to order a product, not communicate with otherpeople via web content, even if the data collected by the form actually doesresult in web content (e.g., online tracking pages)stand-alone accessibility checkers: ATAG 2.0 does not apply because astand-alone accessibility checker with no automated or semi-automatedrepair functionality does not actually modify web content. An accessibilitychecker with repair functionality or that is considered as part of a largerauthoring process would be considered an authoring tool.

authoring tool user interfaceThe display and control mechanism that authors use to operate the authoring toolsoftware. User interfaces may be non-web-based or web-based or a combination

(e.g., a non-web-based authoring tool might have web-based help pages):

authoring tool user interface (non-web-based): Any parts of an authoringtool user interface that are not implemented as web content and instead rundirectly on a platform that is not a user agent (e.g., Windows, Mac OS, JavaVirtual Machine).authoring tool user interface (web-based): Any parts of an authoring tooluser interface that are implemented using web content technologies and areaccessed by authors via a user agent.

Authoring tool user interfaces may or may not be:

accessible authoring tool user interfaces: Authoring tool user interfacesthat meet the success criteria of a level in Part A of ATAG 2.0.

checking, accessibilityThe process by which web content is evaluated for web content accessibilityproblems (WCAG). ATAG 2.0 recognizes three types of checking, based onincreasing levels of automation of the tests:

manual checking: Checking in which the tests are carried out by authors.This includes the case where authors are aided by instructions or guidanceprovided by the authoring tool, but where authors must carry out the actualtest procedure.semi-automated checking: Checking in which the tests are partially carriedout by the authoring tool, but where authors' input or judgment is still requiredto decide or help decide the outcome of the tests.automated checking: Checking in which the tests are carried outautomatically by the authoring tool without any intervention by authors. Anauthoring tool may support any combination of checking types.

collection of software componentsAny software programs that are used either together (e.g., base tool and plug-in)or separately (e.g., markup editor, image editor, and validation tool), regardless ofwhether there has been any formal collaboration between the developers of thesoftware components.

content (web content)Information and sensory experience to be communicated to the end user by meansof a user agent, including code or markup that defines the content's structure,presentation, and interactions. In ATAG 2.0, the term is primarily used to refer tothe output that is produced by the authoring tool. Content produced by authoringtools may include web applications, including those that act as web-basedauthoring tools. Content may or may not be:

accessible content (WCAG): Content that would conform to WCAG 2.0, ateither Level A, AA, or AAA, assuming that any web content technologiesrelied upon to satisfy the WCAG 2.0 success criteria are accessibilitysupported.

Note 1: If accessibility support for the relied upon technologies is

lacking, then the content will not conform to WCAG 2.0 and one ormore groups of end users with disabilities will likely experiencedifficulty accessing the content.Note 2: Conformance to WCAG 2.0, even at the highest level (i.e.,Level AAA), still may not make content "accessible to individuals withall types, degrees, or combinations of disability".

content being edited: The web content that an author can modify during anauthoring session. The content being edited may be a complete piece ofcontent (e.g., image, style sheet) or only part of a larger piece of content(e.g., a status update). The content being edited only includes content in webcontent technologies that the authoring tool supports (e.g., a WYSIWYGHTML editor allows editing of the HTML content of a web page editable, butnot the images).

content propertiesThe individual pieces of information that make up the web content (e.g., theattributes and contents of elements, stylesheet information).

content (structured)Web content that includes machine-readable internal structure (e.g., markupelements), as opposed to unstructured content, such as raster image formats orplain human language text.

content generation (content authoring, content editing)The act of specifying the actual web content that will be rendered, played orexecuted by the end user's user agent. While the precise details of how content iscreated in any given system may vary widely, responsibility for the generation ofcontent can be any combination of the following:

author generated content: Web content for which authors are fullyresponsible. The author may only be responsible down to a particular level(e.g., when asked to type a text label, the author is responsible for the text,but not for how the label is marked up; when typing markup in a sourceediting-view, the author is not responsible for the fact that UNICODE is usedto encode the text ).automatically generated content: Web content for which developer-programmed functionality is fully responsible (e.g., what markup to outputwhen an author requests to start a new document, automatically correctingmarkup errors).third-party content generation: Web content for which a third-party authoris responsible (e.g., community shared templates).

content renderingUser interface functionality that authoring tools present if they render, play orexecute the web content being edited. ATAG 2.0 recognizes several types ofcontent renderings:

conventional renderings (or "WYSIWYG"): When content is rendered in away that is similar to the default rendering a user agent would create from thesame content. While "WYSIWYG", standing for "What-you-see-is-what-you-

get" is the common term, differences between user agents and end usersettings mean that in reality there is no single typical end user experience; orunconventional renderings: When content is rendered differently than itwould be in a typical user agent (e.g., rendering an audio file as a graphicalwavefront); orpartial renderings: When some aspects of the content are rendered,played, or executed, but not others (e.g., a frame-by-frame video editorrenders the graphical, but not the timing aspects, of a video).

content transformationsProcesses that take content in one web content technology or non-web contenttechnology (e.g., a word processing format) as input and produce content that hasbeen optimized, restructured or recoded:

Optimizing Content Transformations: Transformations in which thecontent technology is not changed and the structural features of the contenttechnology that are employed also stay the same. Changes would not beexpected to result in information loss (e.g., removing whitespace, replacingin-line styles with an external stylesheet).Restructuring Content Transformations: Transformations in which thecontent technology stays the same, but the structural features of thetechnology used to markup the content are changed (e.g., linearizing tables,splitting a document into pages.Recoding Content Transformations: Transformations in which the contenttechnology used to encode the content is changed (e.g., HTML to XHTML, aword processing format to HTML).

Note: Clipboard operations, in which content is copied to or pasted from theplatform clipboard, are not considered content transformations.

control settingsSettings that relate to how authors operate the authoring tool, for example usingthe keyboard or mouse.

developerAny entities or individuals responsible for programming the authoring tool. Thisincludes the programmers of any additional software components included by theClaimant in the conformance claim. In some cases, development of the authoringtool is complete before authors can use it to publish web content. However, inother cases (e.g., some web-based authoring tools), the developer may continueto modify the authoring tool even after content has been published, such that thecontent experienced by the end user is modified.

direct accessibility featuresFeatures of an authoring tool that provide functionality to meet the requirements ofauthors with disabilities (e.g., keyboard navigation, zoom features, text-to-speech).Additional or specialized functionality may still be provided by external assistivetechnology.

display settingsSettings that relate to how authors perceive the authoring tool. These include:

audio display settings: the characteristics of audio output of music, soundsand speech. Examples include volume, speech voices, voice speed, andvoice emphasis.visual display settings: the characteristics of the on-screen rendering oftext and graphics. Examples include fonts, sizes, colors, spacing,positioning, and contrast.tactile display settings: the characteristics of haptic output. Examplesinclude the magnitude of the haptic forces and the types of vibration.

documentationAny information that supports the use of an authoring tool. This information may beprovided electronically or otherwise and includes help, manuals, installationinstructions, sample work flows, tutorials, etc.

document objectThe internal representation of data in the source by a non-web based authoringtool or user agent. The document object may form part of a platform accessibilityservice that enables communication with assistive technologies. Web-basedauthoring tools are considered to make use of the document object that ismaintained by the user agent.

elementA pair of markup tags and its content, or an "empty tag" (one that requires noclosing tag or content).

end userA person who interacts with web content once it has been authored. This includespeople using assistive technologies.

human languageLanguage that is spoken, written or signed (through visual or tactile means) tocommunicate with humans.

informativeFor information purposes and not required for conformance.

keyboard interfaceKeyboard interfaces are programmatic services provided by many platforms thatallow operation in a device independent manner. A keyboard interface can allowkeystroke input even if particular devices do not contain a hardware keyboard(e.g., a touchscreen-controlled device can have a keyboard interface built into itsoperating system to support onscreen keyboards as well as external keyboardsthat may be connected).

Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualifyas operation through a keyboard interface because these emulators use pointingdevice interfaces, not keyboard interfaces.

keyboard trapA user interface situation in which a keyboard interface may be used to movefocus to, but not from, a user interface component or group of components.

labelText or other component with a text alternative that is presented to users to identifya component. A label is presented to all users whereas the name may be hiddenand only exposed by assistive technology. In many (but not all) cases the name andthe label are the same.

liveInformation captured from a real-world event that is published with no more than abroadcast delay. Note: A broadcast delay is a short (usually automated) delay, for example used inorder to give the broadcaster time to queue or censor the audio (or video) feed,but not sufficient to allow significant editing.

markup languageA system of text annotations (e.g., elements in HTML) and processing rules thatmay be used to specify the structure, presentation or semantics of content.Examples of markup languages include HTML and SVG.

markup of some content is the set of annotations that appear in the content.

nameText by which software can identify a user interface component to the author or enduser. The name may be hidden and only exposed by assistive technology,whereas a label is presented to all users. In many (but not all) cases, the label andthe name are the same.

non-text contentAny content that is not a sequence of characters that can be programmaticallydetermined or where the sequence is not expressing something in humanlanguage. This includes ASCII Art (which is a pattern of characters), emoticons,and images representing text.

normativeRequired for conformance. One may conform in a variety of well-defined ways toATAG 2.0. Content identified as "informative" or "non-normative" is never requiredfor conformance.

optionWhen an author is presented with choices.

default option: A setting or value for an option that is assignedautomatically by the authoring tool and remains in effect unless canceled orchanged by the author.

platformThe software environment within which the authoring tool operates. Platformsprovide a consistent operational environment on top of lower level softwareplatforms or hardware. For web-based authoring user interfaces, the most relevantplatform will be a user agent (e.g., browser). For non-web-based user interfaces,the range of platforms includes, but may not be limited to, desktop operatingsystems (e.g., GNOME desktop on Linux, Mac OS, Windows), mobile operatingsystems (e.g., Android, BlackBerry, iOS, Windows Phone), or cross-OSenvironments (e.g., Java), etc..Note 1: Many platforms mediate communication between applications operatingon the platform and assistive technology via a platform accessibility service. Note 2: Accessibility guidelines for developers exist for many platforms.

platform accessibility serviceA programmatic interface that is specifically engineered to provide communication

between applications and assistive technologies (e.g., MSAA, IAccessible2 andUI Automation for Windows applications, AXAPI for Mac OS X applications,GNOME Accessibility Toolkit API for GNOME applications, Java Access for Javaapplications). On some platforms, it may be conventional to enhancecommunication further by implementing a document object.

plug-inA program that runs as part of the authoring tool (e.g., a third-party checking andrepair tool) and that is not part of web content being edited. Authors generallychoose to include or exclude plug-ins from their authoring tool.

presentationRendering of the content in a form to be perceived by authors or end users.

programmatically determined (programmatically determinable)Information that is encoded in a way that allows different software, includingassistive technologies, to extract and present the information in differentmodalities. ATAG 2.0 uses this term in two contexts:

Processing content: Whether the authoring tool is able to extract informationfrom the web content (e.g., to extract the language of content from themarkup).Communication between the authoring tool and assistive technology: Fornon-web-based user interfaces, this means making use of platformaccessibility services, APIs, and, in some cases, document object models.For web-based user interfaces, this means ensuring that the user agent canpass on the information (e.g., through the use of ARIA).

prominenceA heuristic measure of how likely users are to notice a user interface component ina user interface that they are operating. Prominence is affected by numerousfactors, including: the number of navigation steps required, the reading orderposition, visual properties (e.g., size, spacing, color), and even the modality of use(e.g., mouse vs. keyboard use).

at least as prominent: For ATAG 2.0, a user interface component A isconsidered to be "at least as prominent" as another component B when,from a default state, component A becomes displayed (and enabled) withthe same number or less "opening" actions than are required for componentB to become displayed (and enabled).Note 1: When a container is open, all of the enabled components in thecontainer (e.g., items in a list, items in a menu, buttons in a toolbar, allcomponents in a dialog box) are considered to be displayed (and thereforeare at least as prominent as each other), even if the container must bescrolled for them to become visible. This takes into account that differentscreen sizes and author settings will affect which components are visible at agiven time.Note 2: "Opening actions" are actions made by authors on componentswithin the user interface that result in new components becoming displayedor enabled. For example: (a) keyboard shortcut to a top-level menu item todisplay a sub-menu, (b) keyboard selection on a button to display a dialog

box, (c) mouse click on a checkbox to enable previously disabled sub-items,etc.. Actions that do not cause new components to become actionable (e.g.,moving focus, scrolling a list), are not counted as "opening actions".Note 3: Keyboard shortcuts to components in closed containers are notcounted as "opening actions" because the components have no prominencewhen they are not displayed. The same is true when authors must use"search" to reveal components in closed containers.Note 4: The "default state" is the state of the authoring tool at the beginningof an authoring session as set by the developer. The default state of manydocument authoring tools is an editing-view.

promptAny authoring tool initiated request for a decision or piece of information fromauthors. The term covers requests that must be responded to immediately (e.g.modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelledword).

publishingAny point at which the authors or authoring tool make web content available to endusers (e.g., uploading a web page, committing a change in a wiki, live streaming).

rangeMore than one item within a multi-item set.Informative Note: ATAG 2.0 uses the term "range" in several success criteria inwhich absolute measurements may not be practical (e.g., the set of all helpdocumentation examples, the set of all templates). While the strict testablerequirement is the definition "More than one item within a multi-item set",implementers are strongly encouraged to implement the success criteria morebroadly.

relationshipsMeaningful associations between distinct pieces of content.

repair (accessibility)The process by which web content accessibility problems that have been identifiedwithin web content are resolved. ATAG 2.0 recognizes three types of repair, basedon increasing levels of automation:

manual repair: Where the repairs are carried out by authors. This includesthe case where authors are aided by instructions or guidance provided bythe authoring tool, but where authors carry out the actual repair procedure;semi-automated repair: Where the repairs are partially carried out by theauthoring tool, but where authors' input or judgment is still required tocomplete the repair; andautomated repair: Where the repairs are carried out automatically by theauthoring tool without any intervention by authors.

restrictions, restricted web content authoringWhen the web content that authors can specify with an authoring tool either mustinclude or must not include certain content (e.g., elements, attributes, widgets).Many authoring tools restrict authoring in some way, which can either benefitaccessibility (e.g., if text alternatives for non-text content are required) or detract

from accessibility (e.g., if attributes for defining text alternatives are not available).In contrast, authoring tools that allow unrestricted web content authoring do notrequire any particular content to be included or not included (e.g., many sourceediting-views).

roleText or a number by which software can identify the function of a component withinweb content (e.g., a string that indicates whether an image functions as ahyperlink, command button, or check box).

sequential keyboard accessUsing a keyboard interface to navigate the focus one-by-one through all of theitems in an ordered set (e.g., menu items, form fields) until the desired item isreached and activated. This is in contrast to direct keyboard access methods suchas keyboard shortcuts and the use of bypass links.

technology (web content)A mechanism for encoding instructions to be rendered, played or executed by useragents. Web content technologies may include markup languages, data formats,or programming languages that authors may use alone or in combination to createend user experiences that range from static web pages to multimediapresentations to dynamic web applications. Some common examples of webcontent technologies include HTML, CSS, SVG, PNG, PDF, Flash, Silverlight, Flexand JavaScript.

templatesContent patterns that are filled in by authors or the authoring tool to producecontent for end users (e.g., document templates, content management templates,presentation themes). Often templates will pre-specify at least some authoringdecisions.

accessible templates (WCAG): Templates that can be filled in to createweb content that meets the WCAG 2.0 success criteria (Level A, AA orAAA), when both of the following are true:

a. The author correctly follows any instructions provided (e.g., correctlyresponding to prompts, correctly replacing highlighted placeholders);and

b. No further authoring occursNote: Under these conditions, some templates will result in completely emptydocuments, which are considered accessible by default.

template selection mechanismA function beyond standard file selection that allows authors to select templates touse as the basis for new content or to apply to existing content.

tutorialA type of documentation that provides step-by-step instructions for performingmulti-part tasks.

user agentAny software that retrieves, renders and facilitates end user interaction with webcontent. Examples include web browsers, browser plug-ins, and media players.

user interface componentA part of the user interface or content display (including content renderings) that is

perceived by authors as a single control for a distinct function.video

The technology of moving pictures or images. Video can be made up of animatedor photographic images, or both.

viewA user interface function that authors use to interact with the web content beingedited. ATAG 2.0 categorizes views according to whether they support editing:

editing-views: View in which some or all of the content is editable; orpreviews: Views in which no authoring actions are provided (i.e., the view isnot editable). Typically, the purpose of previews is to present content as itwould appear to end users of user agents. In these cases, previews may beimplemented using existing user agents or they may attempt to emulatesome user agent functionality.

ATAG 2.0 also recognizes several approaches to presenting the content in a view:

source views: The content is presented in unrendered form (e.g., plain texteditors); orrendered views: Content renderings (conventional, unconventional orpartial) are presented; orproperty views: Only properties of the content are presented. The authoringtool then uses these properties to automatically generate the content to bepublished (e.g., CMS calendar widget that generates a calendar from thenumeric month and year).

workflowA customary sequence of steps or tasks that authors follow to produce a contentdeliverable. If an authoring tool is composed of a collection of softwarecomponents, then its workflows may include use of one or more of thecomponents.

Appendix B: How to refer to ATAG 2.0 from other documents

This section is informative.

There are two recommended ways to refer to the "Authoring Tool AccessibilityGuidelines 2.0" (and to W3C documents in general):

1. References to a specific version of "Authoring Tool Accessibility Guidelines 2.0."For example, use the "this version" URI to refer to the current document:http://www.w3.org/TR/2012/WD-ATAG20-20120410/

2. References to the latest version of "Authoring Tool Accessibility Guidelines 2.0."Use the "latest version" URI to refer to the most recently published document in theseries: http://www.w3.org/TR/ATAG20/.

In almost all cases, references (either by name or by link) should be to a specific version

of the document. W3C will make every effort to make this document indefinitely availableat its original address in its original form. The top of this document includes the relevantcatalog metadata for specific references (including title, publication date, "this version"URI, editors' names, and copyright information).

An XHTML 1.0 paragraph including a reference to this specific document might bewritten:

<p><cite><a href="http://www.w3.org/TR/2012/WD-ATAG20-20120410/">"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>J. Richards, J. Spellman, J. Treviranus, eds.,W3C Recommendation, http://www.w3.org/TR/ATAG20/.The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> ofthis document is available at http://www.w3.org/TR/ATAG20/.</p>

For very general references to this document (where stability of content and anchors isnot required), it may be appropriate to refer to the latest version of this document. Othersections of this document explain how to build a conformance claim.

Appendix C: References

This section is informative.

For the latest version of any W3C specification please consult the list of W3CTechnical Reports at http://www.w3.org/TR/. Some documents listed below may havebeen superseded since the publication of this document.

[ATAG10]"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I.Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation isavailable at http://www.w3.org/TR/2000/REC-ATAG10-20000203/.

[UAAG]"User Agent Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen,eds.17 December 2002. This W3C Recommendation is available athttp://www.w3.org/TR/2002/REC-UAAG10-20021217/.

[WCAG20]"Web Content Accessibility Guidelines 2.0 ", B. Caldwell, M. Cooper, L. GuarinoReid, and G. Vanderheiden.

Appendix D: Acknowledgments

Appendix Editors:

Jan Richards (Adaptive Technology Resource Centre, University of Toronto)Jeanne Spellman (W3C)Roberto Scano (IWA/HWG)

Participants active in the AUWG at the time of publication:

Tim Boland (National Institute for Standards and Technology)Alastair Campbell (Nomensa)Cherie Ekholm (Microsoft)Alex Li (Microsoft)Alessandro Miele (Invited Expert)Sueann Nichols (IBM)Greg Pisocky (Adobe)Jan Richards (Inclusive Design Institute, OCAD University)Andrew Ronksley (RNIB)Roberto Scano (IWA/HWG)Jeanne Spellman (W3C)Jutta Treviranus (WG Chair; Inclusive Design Institute, OCAD University)

Other previously active AUWG participants and other contributors toATAG 2.0:

Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, GeoffDeering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, Phill Jenkins, LenKasday, Marjolein Katsma, William Loughborough, Karen Mardahl, Matt May, CharlesMcCathieNevile, Ann McMeekin, Matthias Müller-Prove, Liddy Nevile, Graham Oliver,Wendy Porch, Sarah Pulis, Bob Regan, Chris Ridpath, Andrew Ronksley, GregoryRosmaita, Dana Simberkoff, Reed Shaffner, Michael Squillace, Heather Swayne, GreggVanderheiden, Carlos Velasco, and Jason White.

This document would not have been possible without the work of those who contributedto ATAG 1.0.

This publication has been funded in part with Federal funds from the U.S. Department ofEducation, National Institute on Disability and Rehabilitation Research (NIDRR) undercontract number ED-OSE-10-C-0067. The content of this publication does notnecessarily reflect the views or policies of the U.S. Department of Education, nor doesmention of trade names, commercial products, or organizations imply endorsement bythe U.S. Government.

[Contents]

Developing Organizational Policies on Web Accessibility

Define scope of website(s)

Set milestones

Define monitoring, conformance claims, and follow-up process

Provide for integration and updating of policy

Introduction

This document addresses considerations that can arise when developing organizational policies on web

accessibility.

Organizational policies can be very simple, or very comprehensive.

Example of simple policy:

"[This organization] is committed to ensuring accessibility of its website for people with disabilities. All thepages on our website will conform to W3C WAI's Web Content Accessibility Guidelines 2.0, Level AA

conformance."

Example of comprehensive policy:

"[This organization] is committed to ensuring accessibility of its website for people with disabilities. New

and updated web content produced by our organization will conform to W3C WAI's Web ContentAccessibility Guidelines 2.0, Level A conformance, by [date]. Existing web content produced by our

organization, and new, updated, and existing web content provided for our site by third-party developers,will conform to Level AA conformance by [date]. We will initiate an internal monitoring program by

[date]. Vendors supplying software used to develop our site will be required to provide information by[date] on conformance to W3C WAI's Authoring Tool Accessibility Guidelines [latest version],

Conformance Level A. Our home page and our 'about this site' page will include links to this policy. Wewill review this policy in the future to consider updating it to reference later versions of W3C's accessibility

guidelines."

Since there are existing governmental policies which apply to some kinds of websites in some countries,organizations should ensure that their policies at least require the minimum accessibility mandated by any policieswhich already apply to their sites.

The following sections address considerations in setting organizational policy in more detail.

Reference guidelines clearly

The term "WAI Guidelines" is non-specific, as it can refer to any one of the three accessibility guidelines

produced by W3C WAI. Provide a clear reference to the specific guidelines document with whichconformance is expected:

Web Content Accessibility Guidelines (WCAG) is the W3C WAI specification which explains how

to make websites accessible.Authoring Tool Accessibility Guidelines (ATAG) is the W3C WAI specification which explains

how to make software better support the production of accessible web content.User Agent Accessibility Guidelines (UAAG) is the specification which explains how to makeaccessible browsers and multimedia players.

Organizations wishing to require conformance to the latest version of the standards may specifyconformance without specifying a version number.

See Referencing and Linking to WAI Guidelines and Technical Documents for more information.

Specify conformance level

Specify an expected level of conformance for website(s). For example:

"Conformance to WCAG 2.0, Level" sets the expectation that a website would fulfill all Level Asuccess criteria, which address absolute barriers to accessing content on a website.

"Conformance to WCAG 2.0, Level AA" sets the expectation that a website would fulfill all LevelA and Level AA success criteria, which address absolute and substantial barriers to accessing

content on a website."Conformance to WCAG 2.0, Level AAA" sets the expectation that a website would fulfill all LevelA, Level AA, and Level AAA success criteria, which address absolute, substantial, and minor

barriers to accessing content on a website.Specify an expected level of conformance for authoring tools used by the organization, or by third party

developers, to produce content for the organization's website."Conformance to ATAG [version number], Level A" sets the expectation that web authoring

software acquired by an organization can fulfill all Level A success criteria for accessibility of thesoftware user interface and support for production of accessible content. [See example under "#5

Set milestones" below.][To add to terms of subcontract]: "[Subcontracted web developer] will consider the use of ATAG

[version number]-conformant software where available. If not using ATAG-conformant authoringtools, [subcontracted web developer] will ensure that all content and templates generated for [thisorganization's] production of content is WCAG 2.0, Level AA-conformant, and contains no

markup that will interfere with generation of WCAG-conformant content.See "Selecting and Using Authoring Tools for Web Accessibility" for additional detail.

Define scope of website(s)

Specify to what extent this organization's requirements should apply to new, updated, and existing webpages. For example:

"This policy applies to all new, updated, and existing web pages."

Specify to what extent requirements should apply to web pages provided by a third-party (subcontractor,

or other information provider, but as part of main site). The website's users may need access to primary

and to third-party content equally. It may take additional effort to educate and get compliance from third-party content developers. For example:

"This policy applies to all web content produced or updated by [this organization]. In addition, [this

organization] is taking the following steps to ensure accessibility of content provided by third-party

developers [NOTE that for some sites, accessibility of third-party content may be essential tocomplying with government policy]:

informing third-party developers of [this organization's] policy on web accessibility;

providing links to information and resources on implementing web accessibility;

providing the following incentives to providers of WCAG 2.0 Level AA-conformant

content...;monitoring and providing feedback on inaccessible third-party content;

seeking alternative third-party content providers where original providers continue to provide

non-conformant content.

Set milestones

Set a date by which the organizations website(s) will meet a given conformance level. For example:

"By [date] [this organization's] websites will meet WCAG 2.0, Level AA conformance."

In some cases it may be practical to phase in accessibility by addressing all of level A success criteriarapidly, since these can be absolute barriers if not addressed; then phasing in level AA success criteria

with the next round of site improvements [no later than a specified date]; with level AAA success criteria

left as optional. For example:"By [first date] [this organization's] websites will meet WCAG 2.0, Level A conformance; and by

[second date] [this organization's] websites will meet WCAG 2.0, Level AA conformance."

Consider how to address questions of priorities that may arise especially for websites with a large number

of pages. Do not make assumptions about which areas of a website or which web services people withdisabilities are interested in or not. For example:

"This policy applies to all areas of this organization's internal and external websites, including legacy

content."

Or, "This policy applies to all areas of this organization's internal and external websites, with priorityto [specify which areas] areas of the site; however, all areas of the site are expected to conform to

[specify conformance level] by [second date].

Consider setting date(s) for accessibility support in software. For example: "By [first date], all vendors of authoring tools used by [this company] should provide information

regarding their plans for ATAG [version number] conformance in future versions of their software.

By [second date] [this company] will preferentially purchase ATAG-conformant authoring tools."

Consider setting dates for browser and multimedia conformance, without restricting people's ability to useadaptive browsers.

"By [date], all vendors of browsers and multimedia players used by [this company] should provide

information regarding their plans for UAAG [version number] conformance in future versions of

their software. By [second date] [this company] will preferentially purchase UAAG-conformantbrowsers and multimedia players.

Consider setting dates for establishing internal resources for training, technical assistance, monitoring,

and/or an internal web page with links to such resources.

Define monitoring, conformance claims, and follow-up process

Specify a recommended process and schedule for reviewing the organization's website for accessibility.

For example:

"Each department will review all areas of the organizations' website under its control using theprocess described at Evaluating Web Sites for Accessibility, and will review all new material that it

publishes by using the same process."

Each section of the website will include links for feedback on the site; this information will be

compiled and considered during the review process."

Specify whether or not conformant pages, or sections of a website, should be labeled as such. Forexample:

"The introductory page for sections of the website that have been determined to be conformant

according to [link] process should display the [WCAG 2.0 Level A logo] or bear the following

statement ["this page conforms to..."]Consider specifying a periodic review of areas of the website by an internal department with the authority

to follow up on non-conformant areas of the website. For example:

"[This organization] will conduct periodic reviews of the website and any department with non-conforming web pages will be asked to correct the problem within two weeks. Further problems in

accessibility of an area will result in [specify as appropriate]"

Provide for integration and updating of policy

If the organization has or is developing an overall policy for websites, for instance establishing best

practices for use of web standards, support for a privacy policy, internationalization, use of metadata,

usability, etc., it can be useful to incorporate accessibility in the overall policy, rather than to establish

accessibility as a stand-alone policy.Organizations referencing a specific version number, such as ATAG 1.0, may want to incorporate

mechanisms to review and update, or to automatically update, their policies when the next version in

finalized as a W3C Recommendation.

Document Information

Status: Published: October 2002, minor updates in September 2011 (to account for WCAG 2.0 language;

otherwise, not edited).

Editor: Judy Brewer and the Education and Outreach Working Group (EOWG).

[WAI Site Map] [Help with WAI Website] [Search] [Contacting WAI]

Feedback welcome to wai-eo-editors@w3.org (a publicly archived list) or wai@w3.org (a WAI staff-only

list).

Copyright © 1994-2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark,

document use and software licensing rules apply. Your interactions with this site are in accordance with our

public and Member privacy statements.

Action Plan

Suggestive Action Plan

Establish a policy that your web pages will be accessible and create a process for implementation.

Ensure that all new and modified web pages and content are accessible:

o Check the HTML1 of all new web pages. Make sure that accessible elements are used, including alt tags, long descriptions, and captions, as needed.

o If images are used, including photos, graphics, scanned images, or

image maps, make sure to include alt tags and/or long descriptions for each.

o If you use online forms and tables, make those elements accessible.

o When posting documents on the website, always provide them in

HTML or a text-based format (even if you are also providing them in another format, such as Portable Document Format (PDF)).

Develop a plan for making your existing web content more accessible. Describe your plan on an accessible web page. Encourage input on improvements, including which pages should be given high priority for change. Let citizens know about the standards or guidelines that are being used. Consider making the more popular web pages a priority.

Ensure that in-house staff and contractors responsible for web page and content development are properly trained.

Provide a way for visitors to request accessible information or services by posting a telephone number or E-mail address on your home age. Establish procedures to assure a quick response to users with disabilities who are trying to obtain information or services in this way.

Periodically enlist disability groups to test your pages for ease of use; use this information to increase accessibility.