Essential Components of Web Accessibility

7/29/2019 Essential Components of Web Accessibility

1/113

Essential Components of Web Accessibility

Introduction

How the Components Relate

Interdependencies Between Components

Guidelines for Different Components

This document shows how Web accessibility depends on several components

working together and how improvements in specific components could substantially

improve Web accessibility. It also shows how the WAI guidelines address these

components.

Introduction

It is essential that several different components of Web development andinteraction work together in order for the Web to be accessible to people with

disabilities. These components include:

content - the information in a Web page or Web application, including:

natural information such as text, images, and sounds

code or markup that defines structure, presentation, etc.

Web browsers, media players, and other "user agents"

assistive technology, in some cases - screen readers, alternative keyboards,switches, scanning software, etc.

users' knowledge, experiences, and in some cases, adaptive strategies using the

Web

developers - designers, coders, authors, etc., including developers with disabilities

and users who contribute content

authoring tools - software that creates Web sites

evaluation tools - Web accessibility evaluation tools, HTML validators, CSSvalidators, etc.

How the Components Relate


2/113

Web developers usually use authoring tools and evaluation tools to create Web

content.

People ("users") use Web browsers, media players, assistive technologies, or other

"user agents" to get and interact with the content.

Interdependencies Between Components

There are significant interdependencies between the components; that is, the

components must work together in order for the Web to be accessible. Forexample, for alternative text on images:

Technical specifications address alternative text (for example, HTML defines the

alternative text attribute (alt) of the image element (img))

WAI guidelines - WCAG, ATAG, and UAAG, described below - define how to

implement alternative text for accessibility in the different components

Developers provide the appropriate alternative text wording

Authoring tools enable, facilitate, and promote providing alternative text in a Webpage

Evaluation tools are used to help check that alternative text exists

User agents provide human and machine interface to the alternative text

Assistive technologies provide human interface to the alternative text in various

modalities


3/113

Users know how to get the alternative text from their user agent and/or assistive

technology as needed

The Implementation Cycle

When accessibility features are effectively implemented in one component, the

other components are more likely to implement them.

When Web browsers, media players, assistive technologies, and other user agents

support an accessibility feature, users are more likely to demand it and developers

are more likely to implement it in their content.

When developers want to implement an accessibility feature in their content, theyare more likely to demand that their authoring tool make it easy to implement.

When authoring tools make a feature easy to implement, developers are more

likely to implement it in their content.

When an accessibility feature is implemented in most content, developers and users

are more likely to demand that user agents support it.

When One Component is Weak

If an accessibility feature is not implemented in one component, there is littlemotivation for the other components to implement it when it does not result in an

accessible user experience. For example, developers are unlikely to implement an

accessibility feature that authoring tools do not support and that most browsers or

assistive technologies do not implement consistently.


4/113

If one component has poor accessibility support, sometimes other components can

compensate through "work-arounds" that require much more effort and are not

good for accessibility overall. For example,

developers can do more work to compensate for some lack of accessibility support

in authoring tools; for example, coding markup directly instead of through a tool

users can do more work to compensate for some lack of accessibility support in

browsers, media players, and assistive technology and lack of accessibility of

content; for example, using different browsers or assistive technologies to

overcome different accessibility issues

However, in most cases the works-arounds are not implemented and the result is

still poor accessibility. Additionally, sometimes poor accessibility support in one

component cannot be reasonably overcome by other components and the result is

inaccessibility, making it impossible for some people with disabilities to use a

particular Web site, page, or feature.

Guidelines for Different Components

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) develops

Web accessibility guidelines for the different components:

Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools

Web Content Accessibility Guidelines (WCAG) addresses Web content, and is used

by developers, authoring tools, and accessibility evaluation tools


5/113

User Agent Accessibility Guidelines (UAAG) addresses Web browsers and media

players, including some aspects of assistive technologies

WAI guidelines are based on the fundamental technical specifications of the Web,

and are developed in coordination with:

W3C technical specifications (HTML, XML, CSS, SVG, SMIL, etc.)

Document Information

Version: 1.3 August 2005

Editor: Shawn Lawton Henry. Graphic artist: Michael Duffy. This information is

under development with the Education and Outreach Working Group (EOWG).

[Contacting WAI] Feedback welcome [email protected]

Copyright 1994-2010 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.

Authoring Tool Accessibility Guidelines (ATAG) 2.0

W3C Working Draft 08 July 2010
mailto:[email protected]:[email protected]:[email protected]:[email protected]


6/113

This version:

http://www.w3.org/TR/2010/WD-ATAG20-20100708/

Latest version:

http://www.w3.org/TR/ATAG20/

Previous version:

http://www.w3.org/TR/2009/WD-ATAG20-20091029/

Editors:

Jan Richards, Adaptive Technology Resource Centre, University of Toronto

Jeanne Spellman, W3C

Jutta Treviranus, Adaptive Technology Resource Centre, University of Toronto

Previous Editors:

Matt May (until June 2005 while at W3C)

Copyright 2010 W3C (MIT, ERCIM, Keio), All Rights Reserved. W3C liability,

trademark and document use rules apply.

Abstract

This specification provides guidelines for designing web content authoring tools that

are both (1) more accessible to authors with disabilities and (2) designed to enable,

support, and promote the production of accessible web content by all authors.

The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of

accessibility guidelines published by the W3C Web Accessibility Initiative (WAI).

Status of This Document

W3C Public Working Draft of ATAG 2.0

This is the W3C Last Call Working Draft of 8 July 2010. This draft integrates

changes made as a result of comments received on the 29 October 2009 PublicWorking Draft.

Publication as a Last Call Working Draft indicates that the Authoring Tool

Accessibility Guidelines Working Group (AUWG) believes it has addressed all

substantive issues and that the document is stable. The first public Working Draft of

ATAG 2.0 was published 14 March 2003. Since then, the AUWG has published nine


7/113

Working Drafts and one previous Last Call Working Draft, addressed hundreds of

issues and developed implementation support information for the guidelines. See

How WAI Develops Accessibility Guidelines through the W3C Process for more

background on document maturity levels.

Substantial changes from the 29 October 2009 draft include:

The ATAG Working Group (AUWG) has approved a number of requests for changes

to improve the clarity of the document.

The conformance section now specifically waives "accessibility-supported ways of

using technologies" from WCAG 2.0 for evaluating ATAG 2.0 conformance, because

WCAG 2.0 accessibility support is typically not evaluated until the content is

created.

The success criteria "B.2.1.1 Decision Support" has been changed to clarify the

responsibilities of the developer of the authoring tool as to which technologiesrequire warnings, and to link to the conformance claim for more information.

The success criteria "B.2.2.1 Check Accessibility (WCAG Level A)" has been

changed to make it more flexible. The authoring tool will now require a check for

success criteria that the author has the ability to violate, instead of being required

to test every success criteria.

The Working Group seeks feedback on the following points for this draft:

Does ATAG 2.0 address the shortcomings of ATAG 1.0?

Since authoring tool developers will need to use ATAG 2.0 in conjunction with

WCAG 2.0, are the documents sufficiently similar in style and approach to be

effective?

Do users with disabilities think that their needs have been addressed with regard to

Section A?

Is the conformance claim process usable by developers of authoring tool software?

Comments on this working draft are due on or before 2 September 2010.

Comments on the draft should be sent to [email protected] (Public

Archive).

The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to

publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool

Accessibility Guidelines (ATAG) 1.0 [ATAG10] is the stable, referenceable version.

This Working Draft does not supersede ATAG 1.0.


8/113

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

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

AUWG is 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 other documents at any time. It is inappropriate to cite this document as other

than work in progress.

Patents

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

Abstract

Status of This Document

Introduction

ATAG 2.0 Layers of Guidance

Understanding Levels of Conformance

Integration of Accessibility Features

ATAG 2.0 Guidelines

PART A: Make the authoring tool user interface accessible


9/113

Principle A.1: Authoring tool user interfaces must follow applicable accessibility

guidelines

Principle A.2: Editing views must be perceivable

Principle A.3: Editing views must be operable

Principle A.4: Editing views must be understandable

PART B: Support the production of accessible content

Principle B.1: Production of accessible content must be enabled

Principle B.2: Authors must be supported in the production of accessible content

Principle B.3: Accessibility solutions must be promoted and integrated

Conformance

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

Levels of Conformance

Conformance Claims

"Progress Towards Conformance" Statement

Disclaimer

Appendix A: Glossary

Appendix B: How to refer to ATAG 2.0 from other documents

Appendix C: References

Appendix D: Acknowledgments

Appendix E: Checklist

Appendix F: Comparison of ATAG 1.0 guidelines to ATAG 2.0

Introduction

This section is informative.

This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version

2.0. This document includes recommendations for assisting authoring tool

developers to make the authoring tools that they develop more accessible to people

with disabilities, including blindness and low vision, deafness and hearing loss,


10/113

learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and

others.

Accessibility, from an authoring tool perspective, includes addressing the needs of

two (potentially overlapping) user groups with disabilities:

authors of web content, whose needs are met by ensuring that the authoring tool

user interface itself is accessible (addressed by Part A of the guidelines), and

end users of web content, whose needs are met by ensuring that all authors are

enabled, supported, and guided towards producing accessible web content

(addressed by Part B of the guidelines).

Notes:

The term "authoring tools" has a specific definition in ATAG 2.0. The definition,

which includes several normative notes, appears in the Glossary.

ATAG 2.0 recommends that authoring tools be capable of producing web content

that conforms with WCAG 2.0. However, WCAG 2.0 notes that even content that

conforms to the highest level of WCAG 2.0 (i.e., Level AAA) may not be "accessible

to individuals with all types, degrees, or combinations of disability, particularly in

the cognitive language and learning areas". Development of authoring tools that

address more specialized needs is encouraged, but is beyond the scope of this

document.

ATAG 2.0 does not include standard usability recommendations, except where they

have a significantly greater impact on people with disabilities than on other people.

Authoring tools are just one aspect of web accessibility. For an overview of the

different components of accessibility and how they work together see:

Essential Components of Web Accessibility

Web Content Accessibility Guidelines (WCAG) Overview

User Agent Accessibility Guidelines (UAAG) Overview

ATAG 2.0 Layers of Guidance

The individuals and organizations that may use ATAG 2.0 vary widely and include

authoring tool developers, authoring tool users (authors), authoring tool

purchasers, and policy makers. In order to meet the varying needs of this audience,

several layers of guidance are provided including two parts, overall principles,

general guidelines, testable success criteria and an Implementing ATAG 2.0

document.


11/113

Parts: ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessible

authoring tools. Part A relates to ensuring the accessibility of authoring tool user

interfaces to authors with disabilities. Part B relates to ensuring support by

authoring tools for the creation, by any author (not just those with disabilities), of

web content that is accessible to end users with disabilities. Each part includes

normative applicability notes that apply to all of the success criteria within that part

(see Part A Applicability Notes, Part B Applicability Notes).

Principles: Each of the two parts includes 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 authoring

tools more accessible to both authors and end users of web content with different

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

objectives to help authoring tool developers understand the success criteria. Each

guideline includes a brief rationale for why the guideline was included.

Success Criteria: For each guideline, testable success criteria are provided to allow

ATAG 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, multiple

levels of full and partial conformance are defined (see Levels of Conformance).

Implementing ATAG 2.0 document: The Implementing ATAG 2.0 document provides

additional non-normative information for each success criterion, including a

description of the intent of the success criterion, examples and links to relatedresources.

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

the Implementing ATAG 2.0 document) work together to provide guidance on how

to make authoring tools more accessible. Authoring tool developers are encouraged

to review all of the layers.

Understanding Levels of Conformance

In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in

the development of authoring tools is as simple as possible, ATAG 2.0 shares WCAG2.0's three level conformance model: Level A (lowest), AA (middle), AAA (highest).

As with WCAG 2.0, there are a number of conditions that must be met for a success

criterion to be included in ATAG 2.0. These include:

For Part A, all success criteria must present authoring tool user interface-related

accessibility issues. In other words, the user interface issue must cause a


12/113

proportionately greater problem for authors with disabilities than it causes authors

without disabilities and must be specific to authoring tool software, as opposed to

software in general.

For Part B, all success criteria must present accessible web content production

issues. In other words, the issue must be specific to the production of accessibleweb content by authoring tools, as opposed to the production of web content in

general.

All success criteria must also be testable. This is important since otherwise it would

not be possible to determine whether an authoring tool met or failed to meet the

success criteria. The success criteria can be tested by a combination of machine

and human evaluation as long as it is possible to determine whether a success

criterion has been satisfied with a high level of confidence.

The success criteria were assigned to one of the three levels of conformance by the

Working Group after taking into consideration a wide range of interacting issues.

Some of the common factors evaluated when setting the level in Part A included:

whether the success criterion is essential (in other words, if the success criterion is

not met, then even assistive technology cannot make the authoring tool user

interface accessible)

whether it is possible to satisfy the success criterion for all types of authoring tools

that the success criteria would apply to (e.g., text editors, WYSIWYG editors,

content management systems, etc.)

whether the success criterion would impose limits on the "look-and-feel" and/or

function of authoring tools (e.g., limits on the function, design, aesthetic or

freedom of expression of authoring tool developers)

whether there are workarounds for authors with disabilities if the success criterion

is not met

Some of the common factors evaluated when setting the level in Part B included:

whether the success criterion is essential (in other words, if the success criterion is

not met, then even authors with a high degree of accessibility expertise would be

unlikely to produce accessible web content using an authoring tool)

whether it is possible to satisfy the success criterion for the production of all web

content technologies that the success criteria would apply to.

whether the success criterion requires features that would reasonably be used by

authors.


13/113

whether the success criterion would impose limits on the "look-and-feel" and/or

function of authoring tools (e.g., limits on the function, design, aesthetic or

freedom of expression of authoring tool developers)

Integration of Accessibility Features

When implementing ATAG 2.0, it is recommended that authoring tool developers

closely integrate features that support accessible authoring with the "look-and-feel"

of other features 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;

and

reduce the likelihood of author confusion.

Guidelines

The success criteria and applicability notes in this section are normative.

PART A: Make the authoring tool user interface accessible

Applicability Notes:

Scope of authoring tool user interface: The Part A success criteria apply to all

aspects of the authoring tool user interface that are under the control of the

authoring tool developer. This includes views of the web content being edited and

features that are independent of the content being edited, such as menus, button

bars, status bars, user preferences, documentation, etc.

Reflected web content accessibility problems: The authoring tool is responsible for

ensuring that editing views display the web content being edited in a way that is

accessible to authors with disabilities (e.g., ensuring that a text alternative in the

content can be programmatically determined). However, where an authoring tool

user interface accessibility problem is caused directly by a web content accessibility

problem in the content being edited (e.g., if an image in the content lacks a label),

then this would not be considered a deficiency in the accessibility of the authoring

tool user interface.

User agent features: Web-based authoring tools may rely on user agent features

(e.g., keyboard navigation, find functions, display preferences, undo features, etc.)

to satisfy success criteria. If a conformance claim is made, the claim cites the user

agent.


14/113

Features for meeting Part A must be accessible: The Part A success criteria apply to

the entire authoring tool user interface, including any features added to meet the

success criteria in Part A (e.g., documentation, search functions, etc.). The only

exemption is for preview features, as long as they meet Guideline A.3.7. Previews

are treated differently than editing views because all authors, including those with

disabilities, benefit when preview features accurately reflect the actual functionality

of user agents.

PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility

guidelines

Guideline A.1.1: [For the authoring tool user interface] Ensure that web-based

functionality is accessible. [Implementing A.1.1]

Rationale: When authoring tools or parts of authoring tools (e.g., an online help

system) are web-based, conforming to WCAG 2.0 will facilitate access by all

authors, including those using assistive technologies.

A.1.1.1 Web-Based Accessible (WCAG Level A): Web-based authoring tool user

interfaces conform to WCAG 2.0 Level A. (Level A) [Implementing A.1.1.1]

A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user

interfaces conform to WCAG 2.0 Level AA. (Level AA) [Implementing A.1.1.2]

A.1.1.3 Web-Based Accessible (WCAG Level AAA): Web-based authoring tool user

interfaces conform to WCAG 2.0 Level AAA. (Level AAA) [Implementing A.1.1.3]

Guideline A.1.2: [For the authoring tool user interface] Ensure that non-web-basedfunctionality is accessible. [Implementing A.1.2]

Rationale: When authoring tools or parts of authoring tools are non-web-based

(e.g., a client-side file uploader for a web-based content management system),

following existing accessibility standards and/or platform conventions that support

accessibility will facilitate access by all authors, including those using assistive

technologies.

A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces

follow accessibility standards and/or platform conventions that support accessibility.

(Level A) [Implementing A.1.2.1]

Note: If a conformance claim is made, the claim cites the accessibility standards

and/or platform conventions that were followed.

PRINCIPLE A.2: Editing views must be perceivable


15/113

Guideline A.2.1: [For the authoring tool user interface] Make alternative content

available to authors. [Implementing A.2.1]

Rationale: Some authors require access to alternative content in order to interact

with the web content that they are editing.

A.2.1.1 Recognized Alternative Content: If recognized alternative content is

available for editing view content renderings, then the alternative content is

provided to authors. (Level A) [Implementing A.2.1.1]

Guideline A.2.2: [For the authoring tool user interface] Editing view presentation

can be programmatically determined. [Implementing A.2.2]

Rationale: Some authors need access to the editing view presentation because this

may be used to convey both status information added by the authoring tool (e.g.,

underlining misspelled words) and, within content renderings, information about the

end user experience of the web content being edited.

A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation

of web content to provide additional information to authors, then that additional

information can be programmatically determined. (Level A) [Implementing A.2.2.1]

A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG

view) renders any of the following presentation properties for text, then those

properties can be programmatically determined: (Level A) [Implementing A.2.2.2]

(a) Text Font; and

(b) Text Style (e.g., italic, bold); and

(c) Text Color; and

(d) Text Size.

A.2.2.3 Access to Text Presentation (Enhanced): If an editing view (e.g., WYSIWYG

view) renders any presentation properties for text, then those properties can be

programmatically determined. (Level AAA) [Implementing A.2.2.3]

Guideline A.2.3: [For the authoring tool user interface] Ensure the independence of

authors' display preferences. [Implementing A.2.3]

Rationale: Some authors need to set their own display settings in a way that differs

from the presentation that they want to define for the published web content.

A.2.3.1 Independence of Display: Authors can set their own display settings for

editing views (including WYSIWYG views) without affecting the web content to be

published. (Level A) [Implementing A.2.3.1]


16/113

PRINCIPLE A.3: Editing views must be operable

Guideline A.3.1: [For the authoring tool user interface] Provide keyboard access to

authoring features. [Implementing A.3.1]

Rationale: Some authors with limited mobility or visual disabilities are not able to

use a mouse, and instead require full keyboard access.

A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is

operable through a keyboard interface, except where editing web content properties

that encode continuous input. (Level A) [Implementing A.3.1.1]

Note 1: This exception relates to the nature of web content, not the usual input

technique. For example, setting the path of a freehand curve is exempt, while

setting the endpoints of a straight line is not.

Note 2: This should not be interpreted as discouraging mouse input or other input

methods in addition to the keyboard interface.

A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented as follows:


(a) In the Authoring Tool User Interface: If keyboard focus can be moved to a

component using the keyboard, then focus can be moved away from that

component using standard keyboard navigation commands (e.g., TAB key); and

(b) In Editing Views that Render Web Content: If an editing view renders web

content (e.g., WYSIWYG view), then a documented keyboard command is provided

that will always restore keyboard focus to a known location (e.g., the menus).

A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)

[Implementing A.3.1.3]

A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is

operable through a keyboard interface. (Level AAA) [Implementing A.3.1.4]

A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be

customized. (Level AAA) [Implementing A.3.1.5]

A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls can be

presented with any associated keyboard commands. (Level AAA) [Implementing

A.3.1.6]

Guideline A.3.2: [For the authoring tool user interface] Provide authors with enough

time. [Implementing A.3.2]


17/113

Rationale: Some authors who have difficulty typing, operating the mouse, or

processing information can be prevented from using systems with short time limits

or requiring a fast reaction speed, such as clicking on a moving target.

A.3.2.1 Data Saved (Minimum): If the authoring tool includes authoring session

time limits, then the authoring tool saves all submitted content edits made byauthors. (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 of the following is true: (Level A) [Implementing A.3.2.2]

(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

a wide 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 seconds

to extend the time limit with a simple action (e.g., "press the space bar"), and

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

a collaborative authoring system), and no alternative to the time limit is possible;

or

(e) Essential Exception: The time limit is essential and extending it would invalidate

the activity; or

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

A.3.2.3 Static Pointer Targets: User interface components that accept pointer input

are either stationary or 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 save all

content edits made by authors. (Level AAA) [Implementing A.3.2.4]

Guideline A.3.3: [For the authoring tool user interface] Help authors avoid flashing

that could cause seizures. [Implementing A.3.3]

Rationale: Flashing can cause seizures in authors with photosensitive seizure

disorder.

A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in

editing views can be turned off. (Level A) [Implementing A.3.3.1]


18/113

Guideline A.3.4: [For the authoring tool user interface] Enhance navigation and

editing via content structure. [Implementing A.3.4]

Rationale: Some authors who have difficulty typing or operating the mouse benefit

when authoring tools make use of the structure present in web content to simplify

the tasks of navigation and editing the content.

A.3.4.1 Edit By Structure: Editing views for structured web content include editing

mechanism(s) that can make use of the structure. (Level A) [Implementing

A.3.4.1]

A.3.4.2 Navigate By Structure: Editing views for structured web content include

navigation mechanism(s) that can make use of the structure. (Level A)

[Implementing A.3.4.2]

Guideline A.3.5: [For the authoring tool user interface] Provide text search of the

content. [Implementing A.3.5]

Rationale: Some authors who have difficulty typing or operating the mouse benefit

from the ability to use text search to navigate to arbitrary points within the web

content being authored.

A.3.5.1 Text Search: Authors can perform text searches of web content as follows:

(Level AA) [Implementing A.3.5.1]

(a) Search All Editable: Any information that is text and that the authoring tool can

modify is searchable, including: text content, text alternatives for non-text content,

metadata, markup elements and attributes;

Note: If the current editing view is not able to display the results of a search, then

the authoring tool may provide a mechanism to switch to a different editing view to

display the results;

and

(b) Bi-Directional: The search can be made forwards or backwards; and

(c) Case Sensitive: The search can be in both case sensitive and case insensitive

modes.

Guideline A.3.6: [For the authoring tool user interface] Manage preference settings.

[Implementing A.3.6]


19/113

Rationale: Providing the ability to save and reload sets of keyboard and display

preference settings benefits authors who have needs that differ over time (e.g., due

to fatigue).

A.3.6.1 Save Settings: Any authoring tool display settings and control settings are

saved between authoring sessions. (Level AA) [Implementing A.3.6.1]

A.3.6.2 Respect Platform Settings: The authoring tool respects platform display

settings and control settings. (Level AA) [Implementing A.3.6.2]

Note: As per Success Criterion A.2.3.1, authors' display settings must still be

independent of the web content being edited.

A.3.6.3 Multiple Sets: Authors can save and reload multiple sets of any authoring

tool display settings and control settings. (Level AAA) [Implementing A.3.6.3]

A.3.6.4 Preferences Assistance: The authoring tool includes a mechanism to help

authors configure any preference settings related to Part A of this document. (Level

AAA) [Implementing A.3.6.4]

Guideline A.3.7: [For the authoring tool user interface] Ensure that previews are as

accessible as existing user agents. [Implementing A.3.7]

Rationale: Preview features are provided in many authoring tools because the

workflow of authors often includes periodically checking how user agents will

display the web content to end users. Authors with disabilities need to be able to

follow the same workflow.

A.3.7.1 Return Mechanism: If a preview is provided, then authors can return from

the preview using only keyboard commands. (Level A) [Implementing A.3.7.1]

A.3.7.2 Preview: If a preview is provided, then at least one of the following is true:


(a) Third-Party User Agent: The preview makes use of an existing third-party user

agent; or

(b) UAAG (Level A): The preview conforms to the User Agent Accessibility

Guidelines Level A [UAAG].

PRINCIPLE A.4: Editing views must be understandable

Guideline A.4.1: [For the authoring tool user interface] Help authors avoid and

correct mistakes. [Implementing A.4.1]


20/113

Rationale: Some authors who have difficulty making fine movements may be prone

to making unintended actions.

A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an

"undo" function or include a warning to authors that the action is irreversible.


Note 1: It is acceptable to collect a series of text entry actions (e.g., typed words, a

series of backspaces) into a single reversible authoring action.

Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to

make all previous authoring actions irreversible.

A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are

either reversible or include a warning to authors that the action is irreversible.


A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent

"undo" action(s). (Level AA) [Implementing A.4.1.3]

Guideline A.4.2: [For the authoring tool user interface] Document the user interface

including all accessibility features. [Implementing A.4.2]

Rationale: Some authors may not be able to understand or operate the authoring

tool user interface without proper accessible documentation.

A.4.2.1 Document Accessibility Features: All features that are specifically required

to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are

documented. (Level A) [Implementing A.4.2.1]

A.4.2.2 Document All Features: All features of the authoring tool are documented.

(Level AA) [Implementing A.4.2.2]

PART B: Support the production of accessible content

Applicability Notes:

Author availability: Any Part B success criteria that refer to authors only apply

during authoring sessions.

Applicability after the end of an authoring session: For author-generated content,

the requirements of Part B only apply during authoring sessions. For example, if the

author includes a third-party feed in their web content, the authoring tool is not

required to provide checking for web content accessibility problems in that feed

after the end of the authoring session. In contrast, for automatically-generated

content, Part B continues to apply after the end of the authoring session. For


21/113

example, if the site-wide templates of a content management system are updated,

these would be required to meet the accessibility requirements for automatically-

generated content.

Authoring systems: As per the ATAG 2.0 definition of authoring tool, several

software 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 and repair tool).

Features for meeting Part B must be accessible: The Part A success criteria apply to

the entire authoring tool user interface, including any features added to meet the

success criteria in Part B (e.g., checking tools, repair tools, tutorials,

documentation, etc.).

Multiple author roles: Some authoring tools include multiple author roles, each with

different views and content editing permissions (e.g., a content management

system may separate the roles of designers, content authors, and quality assurers).

In these cases, the Part B success criteria apply to the authoring tool as a whole,

not to the view provided to any particular author role.

PRINCIPLE B.1: Production of accessible content must be enabled

Guideline B.1.1: Support web content technologies that enable the creation of

content that is accessible. [Implementing B.1.1]

Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web

content requirements. To support accessible web content production, at minimum,

it must be possible to produce web content that conforms with WCAG 2.0 using the

authoring tool.

B.1.1.1 Accessible Content Production (WCAG Level A): Authors can use the

authoring tool to produce web content that conforms to WCAG 2.0 Level A. (Level

A) [Implementing B.1.1.1]

B.1.1.2 Accessible Content Production (WCAG Level AA): Authors can use the

authoring tool to produce web content that conforms to WCAG 2.0 Level AA. (Level

AA) [Implementing B.1.1.2]

B.1.1.3 Accessible Content Production (WCAG Level AAA): Authors can use the

authoring tool to produce web content that conforms to WCAG 2.0 Level AAA.

(Level AAA) [Implementing B.1.1.3]

Guideline B.1.2: Ensure that the authoring tool preserves accessibility information.

[Implementing B.1.2]


22/113

Rationale: Accessibility information is critical to maintaining comparable levels of

accessibility between the input and output of web content transformations.

B.1.2.1 Preserve Accessibility Information (Minimum): Any accessibility information

(WCAG 2.0 Level A) recognized in the input to any web content transformation is

preserved as accessibility information in the output, if allowed by the web contenttechnology of the output. (Level A) [Implementing B.1.2.1]

B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content

technology of the output of a web content transformation cannot preserve

recognized accessibility information (WCAG 2.0 Level A) (e.g., saving a structured

graphic to a raster image format), then at least one of the following are true: (Level

A) [Implementing B.1.2.2]

(a) Option to Save: authors have the option to save the accessibility information in

another way (e.g., as a "comment", as a backup copy of the input); or

(b) Warning: authors are warned that this will result in web content accessibility

problems in the output.

B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information

(up to WCAG 2.0 Level AAA) recognized in the input to any web content

transformation is preserved as accessibility information in the output. (Level AA)

[Implementing B.1.2.3]

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any

author-generated content for any reason, then at least one of the following is true:

(Level AA) [Implementing B.1.2.4]

(a) Preserve Accessibility Information: The authoring tool only automatically deletes

web content that it can detect is not accessibility information; or

(b) Notification Option: Authors have the option to receive notification before

deletion; or

(c) No Deletion Option: Authors have the option to prevent automatic deletion by

the authoring tool.

Guideline B.1.3: Ensure that automatically generated content is accessible.[Implementing B.1.3]

Rationale: Authoring tools that automatically generate content that is not accessible

impose additional repair tasks on authors.


23/113

See Also: If accessibility information is required from authors during the automatic

generation process, see Guideline B.2.1. If templates or other pre-authored content

are involved, see Guideline B.2.5.

B.1.3.1 Accessible Auto-Generated Content (WCAG Level A): If the authoring tool

automatically generates content, then that web content conforms to WCAG 2.0Level A prior to publishing. (Level A) [Implementing B.1.3.1]

Note: This success criterion only applies to the automated behavior specified by the

authoring tool developer. It does not apply when actions of authors prevent

generation of accessible web content (e.g., authors might set less strict

preferences, ignore prompts for accessibility information, provide faulty accessibility

information, write their own automated scripts, etc.).

B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool

automatically generates content, then that web content conforms to WCAG 2.0

Level AA prior to publishing. (Level AA) [Implementing B.1.3.2]


authoring tool developer. It does not apply when actions of the authors prevent




B.1.3.3 Accessible Auto-Generated Content (Level AAA): If the authoring tool

automatically generates content, then that web content conforms to WCAG 2.0

Level AAA prior to publishing. (Level AAA) [Implementing B.1.3.3]


authoring tool developer. It does not apply when actions of the authors prevent




PRINCIPLE B.2: Authors must be supported in the production of accessible

content

Guideline B.2.1: Guide authors to create accessible content. [Implementing B.2.1]

Rationale: By guiding authors from the outset towards the creation and

maintenance of accessible web content, web content accessibility problems are

mitigated and less repair effort is required.

B.2.1.1 Decision Support: If the authoring tool provides the option of producing a

web content technology for publishing for which the authoring tool does not provide


24/113

support for the production of accessible content, then both of the following are

true: (Level A) [Implementing B.2.1.1]

(a) Warning: Authors are warned that the authoring tool does not provide support

for the production of accessible content for that technology; and

(b) List: From the warning, authors can access a list of technologies for which the

authoring tool does provide support for the production of accessible content.

B.2.1.2 Set Accessible Properties: Mechanisms that set web content properties

(e.g., attribute values, etc.) also can be used to set the accessibility-related

properties. (Level A) [Implementing B.2.1.2]

B.2.1.3 Other Technologies: If the authoring tool can insert web content that it

cannot subsequently edit, then authors can associate accessibility information with

that web content. (Level A) [Implementing B.2.1.3]

Guideline B.2.2: Assist authors in checking for accessibility problems.


Rationale: Accessibility checking as an integrated function of the authoring tool

helps make authors aware of web content accessibility problems during the

authoring process, so they can be immediately addressed.

B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool provides authors

with the ability to add or modify web content so that any WCAG 2.0 Level A

Success Criterion can be violated, then accessibility checking for those success

criteria is provided (e.g., an HTML authoring tool that inserts images should checkfor alternative text; a video authoring tool with the ability to edit text tracks should

check for captions). (Level A) [Implementing B.2.2.1]

Note: Automated and semi-automated checking is possible (and encouraged) for

many types of web content accessibility problems. However, manual checking is the

minimum requirement to meet this success criterion. In manual checking, the

authoring tool provides authors with instructions for detecting problems, which

authors must carry out by themselves. For more information on checking, see

Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.

B.2.2.2 Availability: Checking is available prior to publishing in a manner

appropriate to the workflow of the authoring tool. (Level A) [Implementing B.2.2.2]

B.2.2.3 Help Authors Decide: For any checks that require author judgment to

determine whether a potential web content accessibility problem is correctly

identified (i.e., manual checking and semi-automated checking), instructions are


25/113

provided to help authors decide whether it is correctly identified. (Level A)


B.2.2.4 Help Authors Locate: For any checks that require author judgment to

determine whether a potential web content accessibility problem is correctly

identified (i.e., manual checking and semi-automated checking), the relevantcontent is identified (e.g., highlighting the affected content, displaying line

numbers, etc.) (Level A) [Implementing B.2.2.4]

B.2.2.5 Check Accessibility (WCAG Level AA): If the authoring tool provides authors

with the ability to add or modify web content so that any WCAG 2.0 Level AA

Success Criterion can be violated, then accessibility checking for those success

criteria is provided. (Level AA) [Implementing B.2.2.5]







B.2.2.6 Status Report: Authors can receive an accessibility status report based on

the results of the accessibility checks. (Level AA) [Implementing B.2.2.6]

Note: The format of the accessibility status is not specified. For example, the status

might be a listing of problems detected or a WCAG 2.0 conformance level, etc.

B.2.2.7 Metadata Production: Authors have the option of associating accessibility

checking results with the web content as metadata. (Level AA) [Implementing

B.2.2.7]

Note: The metadata format that is implemented will dictate the nature of the

associated results (e.g., specific check results, summary conformance claims, etc.)

B.2.2.8 Check Accessibility (WCAG Level AAA): If the authoring tool provides

authors with the ability to add or modify web content so that any WCAG 2.0 Level

AAA Success Criterion can be violated, then accessibility checking for those success

criteria is provided. (Level AAA) [Implementing B.2.2.8]








26/113

Guideline B.2.3: Assist authors in repairing accessibility problems. [Implementing

B.2.3]

Rationale: Repair as an integral part of the authoring process greatly enhances the

utility of checking and increases the likelihood that accessibility problems will be

properly addressed.

B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web

content accessibility problem that is identifiable during checking (as required by

Guideline B.2.2), repair assistance is provided. (Level A) [Implementing B.2.3.1]

Note: Automated and semi-automated repair is possible (and encouraged) for many

types of web content accessibility problems. However, manual repair is the

minimum requirement to meet this success criterion. In manual repair, the

authoring tool provides authors with instructions for repairing problems, which

authors must carry out by themselves. For more information on repair, see

Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.

B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web


Success Criterion B.2.2.5), repair assistance is provided. (Level AA) [Implementing

B.2.3.2]



minimum requirement to meet this success criterion. In manual repair, the

authoring tool provides authors with instructions for repairing problems, which



B.2.3.3 Repair Accessibility (WCAG Level AAA): For each WCAG 2.0 Level AAA web


Success Criterion B.2.2.8), repair assistance is provided. (Level AAA)




minimum requirement to meet this success criterion. In manual repair, theauthoring tool provides authors with instructions for repairing problems, which



Guideline B.2.4: Assist authors with managing alternative content for non-text

content. [Implementing B.2.4]


27/113

Rationale: Improperly generated alternative content can create accessibility

problems and interfere with accessibility checking.

See Also: This guideline applies when non-text content is specified by authors (e.g.,

inserts an image). When non-text content is automatically added by the authoring

tool, see Guideline B.1.3.

B.2.4.1 Editable: Authors are able to modify alternative content for non-text

content. This includes types of alternative content that may not typically be

displayed on screen by user agents. (Level A) [Implementing B.2.4.1]

B.2.4.2 Automated Suggestions: During the authoring session, the authoring tool

can automatically suggest alternative content for non-text content only under the

following conditions: (Level A) [Implementing B.2.4.2]

(a) Author Control: Authors have the opportunity to accept, modify, or reject the

suggested alternative content prior to insertion; and

(b) Relevant Sources: The suggested alternative content is only derived from

sources designed to fulfill the same purpose (e.g., suggesting the value of an

image's "description" metadata field as a long description).

B.2.4.3 Let User Agents Repair: After the end of an authoring session, the

authoring tool does not attempt to repair alternative content for non-text content

using text value that is equally available to user agents (e.g., the filename is not

used). (Level A) [Implementing B.2.4.3]

B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain

text alternative content that they enter (e.g., short text labels, long descriptions)

stored for future reuse. (Level AA) [Implementing B.2.4.4]

Guideline B.2.5: Assist authors with accessible templates and other pre-authored

content. [Implementing B.2.5]

Rationale: Providing accessible templates and other pre-authored content (e.g., clip

art, synchronized media, widgets, etc.) can have several benefits, including:

immediately improving the accessibility of web content being edited, reducing theeffort required of authors, and demonstrating the importance of accessible web

content.

B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically

selects templates or pre-authored content, then the selections conform to WCAG

2.0 Level A when used. (Level A) [Implementing B.2.5.1]


28/113

Note: Templates may not pass accessibility checks due to their inherent

incompleteness. The accessibility status of a template should instead be measured

by the accessibility of completed web content (in the final web content technology)

created when the template is used properly.

B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates,then there are accessible template options for a range of template uses. (Level A)


B.2.5.3 Templates Accessible (WCAG Level AA): If the authoring tool automatically


2.0 Level AA when used. (Level AA) [Implementing B.2.5.3]





B.2.5.4 Template Selection Mechanism: If authors are provided with a template

selection mechanism, then both of the following are true: (Level AA) [Implementing

B.2.5.4]

(a) Indicate: The selection mechanism indicates the accessibility status of

templates (if known); and

(b) Prominence: Any accessible template options are at least as prominent as other

template options.

B.2.5.5 New Templates: If authors can use the authoring tool to create new

templates for use by a template selection mechanism, they have the option to

record the accessibility status of the new templates. (Level AA) [Implementing

B.2.5.5]

B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a

selection 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) [Implementing B.2.5.6]

(a) Indicate: The selection mechanism indicates the accessibility status of the pre-

authored content (if known); and

(b) Prominence: Any accessible options are at least as prominent as other pre-

authored content options.


29/113

B.2.5.7 Templates in Repository: If the authoring tool provides a repository of

templates, then each of the templates has a recorded accessibility status. (Level

AAA) [Implementing B.2.5.7]

B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a

repository of pre-authored content, then each of the content objects has a recordedaccessibility status. (Level AAA) [Implementing B.2.5.8]

B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically


2.0 Level AAA when used. (Level AAA) [Implementing B.2.5.9]





PRINCIPLE B.3: Accessibility solutions must be promoted and integrated

Guideline B.3.1: Ensure that accessible authoring actions are given prominence.


Rationale: When authors are learning a new authoring tool, they may find and learn

to use the first authoring action they encounter that achieves their intended

outcome. Since they may be unaware of the issue of accessibility, it is preferable

that accessible web content be an additional unintended outcome, rather than

inaccessible content.

B.3.1.1 Accessible Options Prominent (WCAG Level A): If authors are provided with

a choice of authoring actions for achieving the same authoring outcome (e.g.,

styling text), then options that will result in web content conforming to WCAG 2.0

Level A are at least as prominent as options that will not. (Level A) [Implementing

B.3.1.1]

B.3.1.2 Accessible Options Prominent (WCAG Level AA): If authors are provided

with a choice of authoring actions for achieving the same authoring outcome (e.g.,


Level AA are at least as prominent as options that will not. (Level AA)


B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If authors are provided

with a choice of authoring actions for achieving the same authoring outcome (e.g.,


Level AAA are at least as prominent as options that will not. (Level AAA)



30/113

Guideline B.3.2: Ensure that features of the authoring tool supporting the

production of accessible content are available. [Implementing B.3.2]

Rationale: The accessible content support features will be more likely to be used if

they are turned on and are afforded reasonable prominence within the authoring

tool user interface.

B.3.2.1 Active by Default: All accessible content support features are turned on by

default. (Level A) [Implementing B.3.2.1]

B.3.2.2 Reactivate Option: If authors turn off an accessible content support feature,

then they can always turn the feature back on. (Level A) [Implementing B.3.2.2]

B.3.2.3 Deactivation Warning: If authors turn off an accessible content support

feature, then the authoring tool informs them that this may increase the risk of

content accessibility problems. (Level AA) [Implementing B.3.2.3]

B.3.2.4 At Least as Prominent: Accessible content support features are at least as

prominent as comparable features related to other types of web content problems

(e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)


Guideline B.3.3: Ensure that features of the authoring tool supporting the

production of accessible content are documented. [Implementing B.3.3]

Rationale: Without documentation of the features that support the production of

accessible content (e.g., prompts for text alternatives, accessibility checking tools),

some authors may not be able to use them.

B.3.3.1 Instructions: Instructions for using the accessible content support features

appear in the documentation. (Level A) [Implementing B.3.3.1]

B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible authoring process

that is specific to the authoring tool is provided. (Level AAA) [Implementing

B.3.3.2]

Guideline B.3.4: Ensure that any authoring practices demonstrated in

documentation are accessible. [Implementing B.3.4]

Rationale: Demonstrating accessible authoring as routine practice will encourage its

acceptance by some authors.

B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the

documentation (e.g., markup, screen shots of WYSIWYG editing views)

demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)



31/113

B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples in the

documentation (e.g., markup, screen shots of WYSIWYG editing views)

demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AA)


B.3.4.3 Model Accessible Practice (WCAG Level AAA): A range of examples in thedocumentation (e.g., markup, screen shots of WYSIWYG editing views)

demonstrate WCAG 2.0 Level AAA accessible authoring practices. (Level AAA)


Conformance

This section is normative.

Conformance means that the authoring tool satisfies the success criteria defined in

the guidelines section. This conformance section describes conformance and lists

the conformance requirements.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

Because WCAG 2.0 [WCAG20] is the most recent W3C Recommendation regarding

web content accessibility, ATAG 2.0 frequently refers to WCAG 2.0 conformance in

order to set requirements for (1) the accessibility of web-based authoring tool user

interfaces (in Part A) and (2) how authors should be enabled, supported, and

guided towards producing accessible web content (in Part B).

Note on "accessibility-supported ways of using technologies":

Part of conformance to WCAG 2.0 is the requirement that "only accessibility-

supported ways 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' assistive technology and (2) the web content technology has accessibility-

supported user agents that are available to end users.

This concept is not easily extended to authoring tools because many authoring tools

can be installed and used in a variety of environments with differing availabilities

for assistive technologies and user agents (e.g., private intranets versus public

websites, monolingual sites versus multilingual sites, etc.). Therefore:

For the purposes of ATAG 2.0 conformance, the accessibility-supported requirement

is waived.


32/113

Once an authoring tool has been installed and put into use, it is possible to assess

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 the authoring tool's conformance with ATAG 2.0.

Conformance Requirements

In order for an authoring tool to conform to ATAG 2.0, all of the following

conformance requirements must be satisfied:

Conformance Levels:

Authoring tools may conform "fully" or "partially" to ATAG 2.0. In either case, the

level of conformance depends on the level of the success criteria that have been

satisfied.

"Full" ATAG 2.0 Conformance: This type of conformance is intended to be used

when developers have considered the accessibility of the authoring tools from both

the perspective of authors (Part A: Make the authoring tool user interface

accessible) and the perspective of end users of web content produced by the

authoring tools (Part B: Support the production of accessible content):

Full ATAG 2.0 Conformance at Level A

The authoring tool satisfies all of the Level A success criteria.

Full ATAG 2.0 Conformance at Level AA

The authoring tool satisfies all of the Level A and Level AA success criteria.

Full ATAG 2.0 Conformance at Level AAA

The authoring tool satisfies all of the success criteria.

And the Part A Applicability Notes and Part B Applicability Notes have been applied.

"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of

conformance is intended to be used when developers have initially focused on the

accessibility of the authoring tool to authors (Part A: Make the authoring tool userinterface accessible):

Partial ATAG 2.0 Conformance Level A: Authoring Tool User Interface

The authoring tool satisfies all of the Level A success criteria in Part A. Nothing is

implied about Part B.


33/113

Partial ATAG 2.0 Conformance Level AA: Authoring Tool User Interface

The authoring tool satisfies all of the Level A and Level AA success criteria in Part A.

Nothing is implied about Part B.

Partial ATAG 2.0 Conformance Level AAA: Authoring Tool User Interface

The authoring tool satisfies all of the success criteria in Part A. Nothing is implied

about Part B.

And the Part A Applicability Notes have been applied.

"Partial" ATAG 2.0 Conformance: Content Production: This type of conformance is

intended to be used when developers have initially focused on the accessibility of

the web content produced by the authoring tool to end users (Part B: Support the

production of accessible content):

Partial ATAG 2.0 Conformance Level A: Content Production

The authoring tool satisfies all of the Level A success criteria in Part B. Nothing is

implied about Part A.

Partial ATAG 2.0 Conformance Level AA: Content Production

The authoring tool satisfies all of the Level A and Level AA success criteria in Part B.

Nothing is implied about Part A.

Partial ATAG 2.0 Conformance Level AAA: Content Production

The authoring tool satisfies all of the success criteria in Part B. Nothing is implied

about Part A.

And the Part B Applicability Notes have been applied.

Note: The Working Group remains committed to the guiding principle that:

"Everyone should have the ability to create and access web content". Therefore, it

is recommended that "Partial" Conformance be claimed only as a step towards

"Full" Conformance.

Web Content Technologies Produced:

Authoring tools conform to ATAG 2.0 with respect to the production of specific web

content technologies (e.g., Full Level A conformance with respect to the production

of XHTML 1.0, Partial Level AA Conformance: Content Production with respect to

the production of SVG 1.1).


34/113

If an authoring tool is capable of producing multiple web content technologies, then

the conformance may include only a subset of these technologies as long as the

subset includes any technologies that the developer either sets for automatically-

generated content or sets as the default for author-generated content. The subset

may include "interim" formats that are not intended for publishing to end users, but

this is not required.

When Success Criterion B.2.1.1 refers to web content technologies for which the

authoring tool provides support for the production of accessible content, it is

referring to this subset.

Conformance Claims (Optional)

If a conformance claim is made, then the conformance claim must meet the

following conditions and include the following information (authoring tools can

conform to ATAG 2.0 without making a claim):

Conditions on Conformance Claims

At least one version of the conformance claim must be published on the web as a

document meeting Level A of WCAG 2.0. A suggested metadata description for this

document is "ATAG 2.0 Conformance Claim".

Whenever the claimed conformance level is published (e.g., product information

web site), the URI for the on-line published version of the conformance claim must

be included.

The existence of a conformance claim does not imply that the W3C has reviewedthe claim or assured its validity.

Claimants may be anyone (e.g., authoring tool developers, journalists, other third

parties).

Claimants are solely responsible for the accuracy of their claims (including claims

that include products for which they are not responsible) and keeping claims up to

date.

Claimants are encouraged to claim conformance to the most recent version of the

Authoring Tool Accessibility Guidelines Recommendation.

Required Components of an ATAG 2.0 Conformance Claim

Claimant name and affiliation.

Date of the claim.

Guidelines title, version and URI


35/113

Conformance level satisfied.

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 user interface or

documentation).

Note: If the authoring tool is a collection of software components (e.g., a markup

editor, an image editor, and a validation tool), then information must be provided

separately for each component, although the conformance claim will treat them as

a whole. As stated above, the Claimant has sole responsibility for the conformance

claim, not the developer of any of the software components.

Web content technologies produced.

A list of the web content technologies produced by the authoring tool that the

Claimant is including in the conformance claim. For each web content technology,provide information on how the web content technology might be used to create

accessible web content (e.g., provide links to technology-specific techniques).

A list of any web content technologies produced by the authoring tool that the

Claimant is not including in the conformance claim.

Declarations: For each success criterion:

A declaration of whether or not the success criterion has been satisfied; or

A declaration that the success criterion is not applicable and a rationale for why not.

Platform(s): The platform(s) upon which the authoring tool was evaluated:

For user agent platform(s) (used to evaluate web-based authoring tool user

interfaces): provide the name and version information of the user agent(s).

For platforms that are not user agents (used to evaluate non-web-based authoring

tool user interfaces): provide the name and version information of the platform(s)

(e.g., operating system, etc.) and the name and version of the platform

accessibility architecture(s) employed.

Optional Components of an ATAG 2.0 Conformance Claim

A description of the authoring tool that identifies the types of editing views that it

includes.

A description of how the ATAG 2.0 success criteria were met where this may not be

obvious.


36/113

"Progress Towards Conformance" Statement

Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0

conformance level are encouraged to publish a statement on progress towards

conformance. This statement would be the same as a conformance claim except

that this statement would specify an ATAG 2.0 conformance level that is beingprogressed towards, rather than one already satisfied, and report the progress on

success criteria not yet met. The author of a "Progress Towards Conformance"

Statement is solely responsible for the accuracy of their statement. Developers are

encouraged to provide expected timelines for meeting outstanding success criteria

within the Statement.

Disclaimer

Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result of any

ATAG 2.0 conformance claim that has not been published under the authority of the

W3C, WAI, or AUWG.

Appendix A: Glossary

This section is normative.

This appendix contains definitions for all of the significant/important/unfamiliar

terms used in the normative parts of this specification, including terms used in the

Conformance section. Please consult http://www.w3.org/TR/qaframe-spec/ for

more information on the role of definitions in specification quality.

Accessibility problem

ATAG 2.0 refers to two types of accessibility problems:

authoring tool user interface accessibility problem: An aspect of an authoring tool

user interface that does not meet a success criterion in Part A of ATAG 2.0.

web content accessibility problem: An aspect of web content that does not meet a

WCAG 2.0 success criterion.

accessibility information

Any information that web content is required to contain in order to conform with a

particular level of WCAG 2.0 (e.g., text alternatives for images, role and state

information for widgets, relationships within complex tables, captions for audio).

accessible content support features

Any features of an authoring tool that directly support authors in increasing the

accessibility of the content being edited (i.e., features added to meet any of the


37/113

success criteria in Principle B.2: Authors must be supported in the production of

accessible content).

Alternative content

Web content that is used in place of other content that a person may not be able to

access. Alternative content fulfills essentially the same function or purpose as the

original content. Examples include text alternatives for non-text content, captions

for audio, audio descriptions for video, sign language for audio, media alternatives

for time-based media. See WCAG 2.0 for more information.

ASCII art

A picture created by a spatial arrangement of characters or glyphs (typically from

the 95 printable characters defined by ASCII).

Assistive technology

Software (or hardware), separate from the authoring tool, that provides

functionality to meet the requirements of users with disabilities. Some authoring

tools may also provide direct accessibility features. Examples of assistive

technologies include, but are not limited to, 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 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


38/113

The technology of sound reproduction. Audio can be created synthetically (including

speech synthesis), recorded from real world sounds, or both.

authors

People who use an authoring tool to create or modify web content for use by other

people. This may include content authors, designers, programmers, publishers,

testers, etc. working either alone or collaboratively (see also Part B Applicability

Note 5). A person only qualifies as an author of some given content if (1) the

authoring tool supports the relevant web content technology used to implement

that content and (2) the person has author permission for that content.

author permission

Whether a person has a right to modify given web content. In other words, whether

they qualify as an author of the content. Some authoring tools are capable of

managing authoring permissions in order to prevent unauthorized modifications.

authoring action

Any action that authors can take using the authoring tool user interface that results

in creating or editing web content (e.g., typing text, deleting, inserting an element,

applying a template). Most authoring tool user interfaces also enable actions that

do not edit content (e.g., setting preferences, viewing documentation).

authoring outcome

The content or content modifications that result from authoring actions. Authoring

outcomes are cumulative (e.g., text is entered, then styled, then made into a link,

then given a title).

authoring practice

An approach that authors follow to achieve a given authoring outcome. (e.g.,

controlling presentation with style sheets). Depending on the design of an authoring

tool, authoring practices may be chosen by the authors or by the authoring tool. An

accessible authoring practice is one in which the authoring outcome conforms to

WCAG 2.0. Some accessible authoring practices require accessibility information.

authoring session

A state of the authoring tool in which web content can be edited by an author. The

end of an authoring session is the point at which the author has no further

opportunity to make changes without starting another session. The end of an

authoring session may be determined by authors (e.g., closing a document,

publishing) or by the authoring tool (e.g., when the authoring tool transfers editing


39/113

permission to another author on a collaborative system). Note that the end of the

authoring session is distinct from publishing. Automatic content generation may

continue after the end of both the authoring session and initial publishing (e.g.,

content management system updates).

authoring tool

Any software, or collection of software components, that authors can use to create

or modify web content for use by other people.

Examples of authoring tools: ATAG 2.0 applies to a wide variety of web content

generating applications, including, but not limited to:

web page authoring tools (e.g., WYSIWYG HTML editors)

software for directly editing source code (see note below)

software for converting to web content technologies (e.g., "Save as HTML" featuresin office suites)

integrated development environments (e.g., for web application development)

software that generates web content on the basis of templates, scripts, command-

line input or "wizard"-type processes

software for rapidly updating portions of web pages (e.g., blogging, wikis, online

forums)

software for generating/managing entire web sites (e.g., content managementsystems, courseware tools, content aggregators)

email clients that send messages in web content technologies

multimedia authoring tools

debugging tools for web content

software for creating mobile web applications

Web-based and non-web-based: ATAG 2.0 applies equally to authoring tools of web

content that are web-based, non-web-based or a combination (e.g., a non-web-based markup editor with a web-based help system, a web-based content

management system with a non-web-based file uploader client).

Real-time publishing: ATAG 2.0 applies to authoring tools with workflows that

involve real-time publishing of web content (e.g., some collaborative tools). For

these authoring tools, conformance to Part B of ATAG 2.0 may involve some


40/113

combination of real-time accessibility supports and additional accessibility supports

available after the real-time authoring session (e.g., the ability to add captions for

audio that was initially published in real-time). For more information, see the

Implementing ATAG 2.0 - Appendix E: Real-time content production.

Text Editors: ATAG 2.0 is not intended to apply to simple text editors that can beused to edit source content, but that include no support for the production of any

particular web content technology. In contrast, ATAG 2.0 can apply to more

sophisticated source content editors that support the production of specific web

content technologies (e.g., with syntax checking, markup prediction, etc.).

authoring tool user interface

The display and control mechanism that authors use to operate the authoring tool

software. 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 authoring tool user

interface that are not implemented as web content and instead run directly on a

platform that is not a user agent, such as Windows, Mac OS, Java Virtual Machine,

etc.

authoring tool user interface (web-based): Any parts of an authoring tool user

interface that are implemented using web content technologies and are accessed by

authors vi

Essential Components of Web Accessibility

Documents

Transcript of Essential Components of Web Accessibility