[Contents] [Techniques] [Checklist]
Copyright ©2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as enabling, supporting, and promoting the production of accessible Web content by all authors.
"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).
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 an internal Editor's Draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.
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.
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.
This section is informative, except where noted.
You are reading the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting developers to make their authoring tools more accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech difficulties, and others. However, even content that completely conforms to WCAG may not be fully accessible to every person with a disability.
In order to acheive accessibility authoring tools must address the needs of two (potentially overlapping) user groups:
The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.
Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by ATAG 2.0, either directly or through assistive technologies, the ATAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.
These guidelines have been written to address the requirements of many different audiences, including, but not limited to:
An attempt has been made to make this document as readable and usable as possible for that diverse audience, while still retaining the accuracy and clarity needed in a technical specification.
ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The relationship between these documents is explained in "Essential Components of Web Accessibility" [COMPONENTS]. For more information on the topic of accessibility, see "How People with Disabilities Use the Web" [PWD-USE-WEB].
This ATAG 2.0 document itself consists of:
This section is normative.
ATAG 2.0 defines an "authoring tool" as any software, or collection of software components, that authors use to create or modify Web content for publication.
The following categories are an informative illustration of the range of tools covered by ATAG 2.0. The categories are used primarily in the Techniques document [ATAG20-TECHS] to mark examples that may be of interest to developers of particular types of tools. Note: Many authoring tools include authoring functions from more than one category (e.g., an HTML editor with both code-level and WYSIWYG editing views):
At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. Note that the two versions have somewhat different Conformance Models.
The Web Content Accessibility Guidelines (WCAG) is the W3C-WAI Recommendation that defines requirements for making Web content accessible to a wide range of people with disabilities. ATAG 2.0 includes a Web Content Accessibility "Benchmark" section that refers to WCAG as the "highly recommended" guideline for judging the accessibility of Web content (see the term "Accessible Web Content") and Web-based authoring tool user interface functionality (see the term "Accessible Authoring Tool User Interface").
The developer of an authoring tool select whichever version of WCAG is most appropriate for the circumstances of a given product, as long as the choice is recorded in the conformance profile. However, consideration should be given to the following when deciding which WCAG version to use:
This section is normative.
The guidelines are divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes principles and associated guidelines that are related to ensuring accessibility of the authoring tool user interface. Part B contains principles and guidelines related to ensuring support for creation of accessible Web content by the tool. The principles in both parts include the following:
Each guideline listed under a principle is intended to be specific enough to be verifiable, while still allowing developers the freedom to meet the guideline in a way that is suitable for their own authoring tools. Each guideline definition includes the following parts. Some parts are normative (i.e., relate to conformance), while others are informative only:
The guidelines in Part A are intended to increase the accessibility of the authoring experience for authors with disabilities. For this reason, the requirements are narrowly focused on the accessibility of the user interface that authors uses to operate the tool. The accessibility of the Web content produced is addressed in Part B.
Note for tools with previews: The requirement in this section apply to all parts of the authoring tool user interface except for the content view of any built-in preview features (see Guideline A.3.9 for requirements on previews). In general, the configuration of the preview mode is not defined by the configuration of the editing views.
Assistive technologies (e.g., screen readers, screen magnifiers, on-screen keyboards, voice recognition systems) can only provide augmented display and control to their users if the relevant information is made available by authoring tools using common protocols.
Rationale: In addition to generally improving the accessiblity of the authoring tool user interface, implementing user interfaces using accessible Web content facilitates communication with assistive technologies via user agents.
Rationale: Assistive technologies that are used by many authors with disabilities (e.g., screen readers, screen magnifiers, on-screen keyboards, voice recognition systems) rely on the authoring tool to provide data and control via prescribed communication protocols.
Note: This guideline does not apply to Web-Based tools since their communication to assistive technologies is covered by Guideline A.1.1.
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to perceive its user interface controls.
Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information, since text is more easily transformed between various display methods (e.g., magnification and enhancement, text-to-speech, Braille output)
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring tool user interface can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions, and people who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: Some authors require alternative display configurations to use the authoring tool user interface that may differ from the presentation the author intends to define for the published content (e.g., providing a high contrast setting to edit content that is not intended to be high contrast).
Note: The success criteria for this guideline are based on the capabilities of platforms (e.g., operating systems, user agents, GUI toolkits) as defined in the conformance profile, however developers are free to provide additional configuration.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: Separating content and structure from presentation allows the user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors without losing any of the information or structure. For example, information can be presented via speech or Braille (text) that was primarily intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to operate its user interface controls.
Rationale: Some individuals have difficulty manipulating graphical input devices such as a mouse or trackball. Providing alternate means of navigating the user interface that does not rely on such devices provides an accommodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.
Note 1: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.
Note 2: Also see Guideline A.3.1 when choosing keystrokes.
For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the keyboard navigation functios of the user agent to satisfy some of these success criteria, as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Authors who have limited mobility require quick access to the items that they use frequently.
Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
Note: Some time limits may be imposed by external systems. This guideline only applies to time limits within the control of the authoring tool.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: It is often efficient to make use of the structure that may be inherent within certain content in order to navigate editing views and perform edits. This is particularly important for people who are using a slow interface such as a small Braille device, speech output, or a single switch input device. It is equivalent to the ability provided by a mouse interface to move rapidly around the document.
Rationale: Search functions within the editing views facilitate author navigation of content as it is being authored by allowing authors to move the focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the efficiency of the search function.
For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "find" function of the user agent to help perform the searches, as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Authors who have difficulty making fine movements may be prone to making unintended actions. All authors benefit from the ability to easily recover from mistakes.
Note: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single author action.
For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "undo" function of the user agent to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area), as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Providing the ability to save and reload sets of keyboard and display preference settings is a benefit to authors using tools intended to be used by multiple authors as well as authors who have keyboard and display preference settings preferences that differ with fatigue, etc..
Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how content will appear to end users in a user agent. In order to enable authors with disabilities to follow the same workflow as other authors, they must have access to any preview features that exist.
Note 1: Authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this guideline.
Note 2: It is understood that the accessibility of the content display of a preview will be negatively affected if the content being rendered is inaccessible or incomplete. For example, a missing image label will result in an inaccessible image, which is useful information to the author.
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to understand the user interface controls that they can perceive and operate.
Rationale: Authors are often familiar with accessibility conventions employed by the other applications built on a platform. Departures from those conventions have the tendency to disorient authors by creating an unfamiliar environment.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: Authors who may become disoriented easily will have less difficulty when consistent and predictable responses to author actions are provided. In general, consistent interfaces will benefit all authors to some degree.
For Web-based authoring tool user interface functionality: Meeting Guideline A.1.1 will serve to meet this guideline.
Rationale: While intuitive user interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.
The guidelines in Part B are intended to increase the accessibility of the Web content produced by any author to end users with disabilities. While the requirements in this part do not deal with the accessibility of the authoring tool user interface, it should be noted that any of the features (e.g., checker, tutorial) added to meet Part B must also meet the user interface accessibility requirements of Part A.
The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.
Rationale: Content types with published content type-specific Web content accessibility benchmarks facilitate the creation of Web content that can be assessed for accessibility.
Rationale: Accessibility information is critical to maintaining comparable levels of accessibility across transformations and conversions.
Rationale: Authoring tools that automatically generate content that does not conform to WCAG are a source of accessibility problems.
Note: If accessibility information is required from authors during the automatic generation process, Guideline B.2.1 applies.
Rationale: Pre-authored content, such as templates, images, and videos, is often included with authoring tools for use by the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.
Note: If accessibility information is required from authors during use, Guideline B.2.1 applies.
This guideline includes guidelines that require authoring tools to raise the profile of accessible authoring, while at the same time, integrating functions related to accessibility in order to encourage authors to make them common practice.
Note: In addition to the normative requirements of this guideline, implementers should also consider close integration of features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:
However, whenever new features are introduced into an authoring tool, striking the right design balance between the similarity with existing features and the provision of new functionality is often more of an art than a science.
Rationale: Authors are most likely to use the first and easiest authoring action they encounter in the authoring tool user interface that achieves their intended authoring outcome.
Rationale: Early and consistent support for accessible design requires less effort than retro-fitting. This may be especially true for sequential processes that have a specific beginning and end.
Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used.
Rationale: The accessible content support features will be more adaptable to the work habits of authors if they can be turned on and off easily, as authors need them.
Rationale: Without documentation of the features that support the production of accessible content (e.g., prompts for alternatives, accessibility checkers), authors may not be able to find or use them.
Rationale: Demonstrating accessible authoring as common practice will encourage its acceptance by some authors.
This section is normative.
Conformance means that the authoring tool satisfies the success criteria defined in the guidelines section. This section outlines the conformance scheme used throughout this document.
Authoring tools may claim full conformance to ATAG 2.0 at one of three conformance levels. The level achieved depends on the level of the success crieteria that have been satisfied. The full conformance levels are:
In addition, a Partial Conformance claim option is available in cases where an authoring tool has satisfied all of the success criteria at a specified level in one of the two Parts of the document (i.e. "Part A: Make the authoring tool user interface accessible" and "Part B: Support the production of accessible content"). The partial conformance levels are:
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 as a step towards full conformance.
Each success criteria is assigned one of three (3) levels.
(If a guideline success criterion is not applicable to an authoring tool, then that success criterion is treated as met for conformance purposes as long as a rartionale is provided.)
The purpose of the Web Content Accessibility "Benchmark" document is to precisely specify the evaluator's interpretation of what "accessible Web content" means with respect to the particular content type(s) that are produced by the authoring tool or are used to implement Web-based user interface functionality of the authoring tool (if applicable). This precise interpretation helps the evaluator to judge the completeness and consistency of accessibility-related authoring tool functions that must interoperate, such as accessibility prompting, evaluation, and repair functions. In addition, because the Benchmark must be made public, it allows claims to be more fully checked for accuracy.
A Benchmark document must be publicly published on the Web (the URI will appear in the conformance claim) @@under a license that permits it to be copied (so that it can be included in other conformance claims), although not necessarily modified@@.
The benchmark document must include:
Note on other Accessibility Standards: ATAG 2.0 addresses how authoring tools can be designed to encourage authors to create accessible content. While the Working Group highly recommends the W3C-WAI Web Content Accessibility Guidelines due to the quality of the document and the process under which it was developed, other Recommendations, Standards, and Regulations with the same goal exist in jurisdictions and organizations around the world.
A Web Content Accessibility Benchmark document may be based on informative documents, such as WCAG Techniques, and should not therefore be considered "normative". Instead, the document serves as a "relied upon" reference for a particular conformance claim when it is included in that claim. The reference helps the evaluator to judge the completeness and consistency of accessibility-related authoring tool functions that must interoperate, such as accessibility prompting, evaluation, and repair functions.
A Benchmark can be created by any any person, company or other organization. However, in the interest of being able to directly compare the evaluations of authoring tools that produce the same content types, the Working Group suggests checking to see if a Benchmark document has already been published, before creating a new one.
The Working Group suggests the following:
A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile.
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 being progressed 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???@@
This section is normative.
This section is informative.
There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):
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 available at its original address in its original form. The top of this document includes the relevant catalog 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 be written:
<p>
<cite><a href="http://www.w3.org/TR/2007/REC-ATAG20-20070430/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, eds.,
W3C Recommendation, 30 April 2007.
The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> of this document is available at http://www.w3.org/TR/ATAG20/.</p>
For very general references to this document (where stability of content and anchors is not required), it may be appropriate to refer to the latest version of this document. Other sections of this document explain how to build a conformance claim.
This section is informative.
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[HTML4]" link to the corresponding entries in this section. These labels are also identified as references through markup.
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.
This document would not have been possible without the work of those who contributed to ATAG 1.0.
This publication has been funded in part with Federal funds from the U.S. Department of Education under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
[Contents] [Techniques] [Checklist]