Copyright ©2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification provides guidelines for designing authoring tools that lower barriers to Web accessibility for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible authoring 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 a W3C Last Call Working Draft of a specification which will supersede the W3C Recommendation "Authoring Tool Accessibility Guidelines 1.0" [ATAG10]. The Authoring Tool Accessibility Guidelines Working Group plans to submit this specification for consideration as a W3C Candidate Recommendation after examining feedback to this draft. Comments on this specification should be sent to w3c-wai-au@w3.org, the Working Group's public email list. This list is archived and acceptance of this archiving policy is requested automatically upon first post. To subscribe to this list, send email to w3c-wai-au-request@w3.org with the word "subscribe" in the subject line. Comments are accepted until 7 January 2005.
This document has been produced by the Authoring Tool Accessibility Guidelines Working Group (AUWG). The goals of the Working Group are described in the AUWG charter. The AUWG is part of the WAI Technical Activity.
The AUWG also provides additional resources to support this document such as Frequently Asked Questions (FAQ) about ATAG 2.0, issues, implementation reports, and test suites. Please consult the AUWG home page for more information.
This document was produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
This draft refers non-normatively to the Techniques for Authoring Tool Accessibility Guidelines 2.0 [ATAG20-TECHS].
This draft refers normatively to ATAG 2.0 References to various versions of the Web Content Accessibility Guidelines (WCAG) as well as the requirements in an ISO document that is currently titled "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces". This is explained in Section 1.4.
The AUWG expects the ATAG 2.0 to be backwards-compatible with ATAG 1.0, or at most to make only minor changes in requirements. Before this document reaches last call, the Working Group will publish a detailed analysis of the differences in requirements.
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.
Please send comments about this document to the public mailing list: w3c-wai-au@w3.org (public archives). Please note that this document may contain typographical errors. It was published as soon as possible since review of the content itself is important, although noting typographical errors is also helpful.
This document specifies requirements that, if satisfied by authoring tool developers, will lower barriers to accessibility. This document includes the following:
These guidelines cover a wide range of recommendations for assisting authoring tool software developers in making authoring tools, as well as the content that the authoring tools generate, more accessible to all potential Web content users and authors, especially people with disabilities .
These guidelines have been written to address the requirements of many different audiences, including, but not limited to: policy makers, technical administrators, and those who develop/manage content. Every attempt has been made to make this document as readable and usable as possible while still retaining the accuracy and clarity needed in a technical specification.
[PROPOSED] 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. A collection of software components are any software products used together (e.g. base tool and plug-in) or separately (e.g. markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products.
ATAG 2.0 defines an "authoring tool" as: any software or service
that authors may use to create or modify Web content for publication.
To illustrate the range of this term as it is used in these guidelines, an authoring function categorization scheme has been developed. The scheme is used primarily within the Techniques document [ATAG20-TECHS] to call out examples that may be of interest to developers of particular types of tools. It is important to note that many authoring tools will include authoring functions that fall into one or more of the categories (e.g. many HTML editors have both code-level and WYSIWYG authoring functions):
Code-level Authoring Functions: Authors have full control over all aspects of the resulting Web content that have bearing on the final outcome. This covers, but is not limited to plain text editing, as this category also covers the manipulation of symbolic representations that are sufficiently fine-grained to allow the author the same freedom of control as plain text editing (e.g. graphical tag placeholders).
Examples: text editors, text editors enhanced with graphical tags, etc.WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Authors have control over entities that closely resemble the final appearance and behavior of the resulting Web content.
Examples: rendered document editors, bitmap graphics editors, etc.Object Oriented Authoring Functions: Authors have control over functional abstractions of the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors, objects which represent web implementations for graphical widgets (menus, etc.) etc.Indirect Authoring Functions: Authors have control over only high-level parameters related to the automated production of the resulting Web content. This may include interfaces that assist the author to create and organize Web content without the author having control over the markup, structure, or programming implementation.
Examples: content management systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators, conversion tools, model-based authoring tools, etc.
The guiding principle of ATAG 2.0 is that:
Everyone should have the ability to create and access Web content.
Authoring tools play a crucial role in achieving this principle because the design of the tool's authoring interface determines who can access the tool as a Web content author and the accessibility of the resulting Web content determines who can be an end-user of that Web content.
As an introduction to accessible authoring tool design, consider that the authors and end-users of Web content may be using the tool and its output in contexts that are very different from that which you may regard as typical. For example, authors and end-users may:
For more information, see "How People with Disabilities Use the Web" [PWD-USE-WEB].
Designing authoring tools for accessibility will have benefits for authors and end-users beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require an equivalent alternative for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio alternative to information they cannot view.
The guidelines are divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes guidelines and associated checkpoints related to ensuring accessibility of the authoring tool user interface. Part B contains guidelines and checkpoints related to ensuring support for creation of accessible Web content by the tool. The guidelines both parts include the following:
Each checkpoint listed under a guideline is intended to be sufficiently specific to be verifiable, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to satisfy it. Each checkpoint definition includes the following parts. Some parts are normative (i.e., relate to conformance); others are informative only:
ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The documents in this series reflect an accessibility model in which format designers, Web content authors, and software developers have roles in ensuring that users with disabilities have access to the Web. The accessibility-related interests of these stakeholders intersect and complement each other as follows:
ATAG 2.0 depends on WCAG to act as a benchmark for judging the accessibility of Web content and Web-based authoring interfaces and also to define the terms "Accessible Web Content" and "Accessible Authoring Interface".
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]. @@revisit this@@
Note that within the guidelines section of ATAG 2.0, references are made to WCAG without an associated version number. This has been done to allow developers to select, for the conformance profile, whichever version of WCAG is most appropriate for the circumstances of a given authoring tool. The Working Group does recommend considering the following factors when deciding on which WCAG version to use:
ATAG 2.0 allows authoring tools to claim conformance to one of three conformance levels. The level achieved depends on the priority of the checkpoints that the authoring tool has satisfied.
Figure 1: A graphical view of the requirements of the ATAG 2.0 Conformance Levels (described above).
Long Description (to be hidden later): A graphic that illustrates the levels of conformance as they are explained in the text of the conformance level section. The graphic is a table with four rows and three columns. The header row labels are "Ladder of ATAG 2.0 Conformance Levels", "Regular Priority Checkpoints" and "Relative Priority Checkpoints". The data rows are labeled "Level 'Triple-A' (highest) ", "Level 'Double-A'", and "Level 'A' (lowest) ". Bars superimposed across the rows demonstrate that in order to meet each higher level, additional regular priority checkpoints must be met as well as increasing levels of relative priority checkpoints.
Each checkpoint has been assigned a priority level that indicates the importance of the checkpoint in satisfying the guideline under which the checkpoint appears. The priority of a checkpoint determines whether that checkpoint must be met in order for an authoring tool to achieve a particular conformance level. There are three levels of "regular priority" checkpoints as well as a special class of "relative priority" checkpoints that rely on WCAG as a benchmark for determining accessibility.
The importance of the relative checkpoints depends on the requirements defined by whichever version of WCAG the evaluator has defined in the conformance profile. These checkpoints can be met to one of three levels:
A conformance claim (with or without an accompanying ATAG 2.0 conformance icon) is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile. The claim must be supported by a listing of conformance details.
An authoring tool conforms to this document by satisfying the requirements identified by a conformance profile. A conformance profile includes the following assertions:
ATAG 2.0 requires Content Type-Specific WCAG Benchmark documents to be specified in the conformance profile for each content type covered by the conformance claim. Each benchmark document must meet the following conditions:
There are currently no conformance icons available for this draft specification. If it becomes a Recommendation, it is expected that there will be conformance icons like those available for ATAG 1.0.
Note: The requirement in this section apply to all parts of the authoring tool interface except for the content view of built-in preview features (see checkpoint A.?.4 for more information).
Rationale:Authors must be able to have access to authoring tool functionality that is implemented as Web content.
Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (i.e. Web-based help features, etc.). However, for most Web-based authoring tools the requirement will cover the majority of functionality in the tool and overlap most of the other requirements in Part A of the guidelines.
Techniques: Implementation Techniques for Checkpoint A.0.1
Success Criteria:
Rationale: People who have difficulty perceiving non-text content can often access the same information if it is conveyed using a text alternative (by assistive technology or braille, for example).
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.1.1
Success Criteria:
Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring 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.
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.1.2
Success Criteria:
Rationale: Some authors require alternative display configurations to use the authoring interface.
Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Note 2: The success criteria for this checkpoint are based on the capabilities of platforms (e.g. operating systems, browsers, GUI toolkits, etc.), however developers are free to provide additional configuration.
Techniques: Implementation Techniques for Checkpoint A.1.3
Success Criteria:
Rationale: Authors may require a set of display preferences to view and control the document that is different from the display styles that they want to define for the published document (e.g. a particular text-background combination that differs from the published version).
Techniques: Implementation Techniques for Checkpoint
Success Criteria:
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 accomodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.
Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.2.2
Success Criteria:
Rationale: Authors who have limited mobility require quick access to the actions that they use frequently.
Techniques: Implementation Techniques for Checkpoint A.2.1
Success Criteria:
Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
Note 1: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.
Note 2: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.2.3
Success Criteria:
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.2.4
Success Criteria:
Rationale: It is often more efficient to navigate and edit via the structure in Web content.
Techniques: Implementation Techniques for Checkpoint A.2.5
Success Criteria:
Rationale: Search functions within the editing views facilitate author navigation of content as it is being authored by allowing the author to move 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.
Techniques: Implementation Techniques for Checkpoint A.2.6
Success Criteria:
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: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.2.7
Success Criteria:
Rationale: When a large number of configuration settings are available, authors working on shared systems benefit from the ability to save and later reload a personal settings file.
Techniques: Implementation Techniques for Checkpoint
Success Criteria:
Rationale: The workflow of many authoring tools includes periodically checking a preview of how content will appear to end users in a browser. Authors with disabilities need to have access to a preview so that they can check all aspects of their work (i.e. not just the accessibility of that work). For this reason the preview needs to be as, but not more, accessible than the target browser(s).
Note 1: This requirement serves, for the preview features only, in lieu of the other user interface accessibility requirements in Part A.
Note 2: In addition, it is expected that the operation of the preview accessibility features will be constrained by the accessibility and/or completeness of the content.
Techniques: Implementation Techniques for Checkpoint
Success Criteria:
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.
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.3.1
Success Criteria:
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.
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.3.2
Success Criteria:
Rationale: While intuitive authoring interface design is valuable to many users, some users may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, a user who is blind may not find a graphical authoring interface intuitive without supporting documentation.
Techniques: Implementation Techniques for Checkpoint A.3.4
Success Criteria:
Rationale: Assistive technologies (e.g. screen readers, screen magnifiers, etc.) used by many authors with disabilities rely on software applications to provide data and control via prescribed communication protocols.
Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.
Techniques: Implementation Techniques for Checkpoint A.4.1
Success Criteria:
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.
The first responsibility is to support formats that enable accessible content (Checkpoint 2.1). Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that support this include preserving accessible or unknown content (Checkpoint 2.2), automatically generating accessible content (Checkpoint 2.3), and including accessible pre-authored content (Checkpoint 2.4).
Rationale: Content types with published content type-specific WCAG benchmark documents facilitate the creation of Web content that can be assessed for accessibility with WCAG.
Techniques: Implementation Techniques for Checkpoint B.1.1
Success Criteria:
Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions or transformations. Accessibility information should also be preserved.
Techniques: Implementation Techniques for Checkpoint B.1.2
Success Criteria:
Rationale: Authoring tools that automatically generate content that does not conform to WCAG are a source of accessibility problems.
Note: WCAG includes a markup validity requirement.
Techniques: Implementation Techniques for Checkpoint B.1.3
Success Criteria:
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.
Techniques: Implementation Techniques for Checkpoint B.1.4
Success Criteria:
This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring that accessibility practices and features are given authoring interface priority (Checkpoint 4.1), clear availability (Checkpoint 4.2), workflow integration (Checkpoint 4.3), and sufficient configurability (Checkpoint 4.4).
Note: In addition to the normative requirements of this guideline, implementers should consider one other issue: the integration of accessibility features, such as prompting, checking and repair 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. Moreover, the effectiveness of the solutions are perhaps better judged by the markeplace than by a set of stringent requirements.
Rationale: Authors are most likely to use the first and easiest option for a given authoring task.
Techniques: Implementation Techniques for Checkpoint B.3.1
Success Criteria:
Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used. Ideally, these features should be turned on by default.
Techniques: Implementation Techniques for Checkpoint B.3.2
Success Criteria:
Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports the author in considering accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analogous to internationalization, which is much easier when it is considered from the beginning rather than handled last.
Techniques: Implementation Techniques for Checkpoint B.3.3
Success Criteria:
Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.
Techniques: Implementation Techniques for Checkpoint B.3.4
Success Criteria:
This glossary is normative. However, some terms (or parts of explanations of terms) may not have an impact on conformance.
alt", "title",
and "longdesc"
attributes in HTML).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. Normative references are highlighted and identified through markup.
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 [XHTML10] paragraph including a reference to this specific document might be written:
<p> <cite><a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122"> "Authoring Tool Accessibility Guidelines 1.0",</a></cite> J. Treviranus, C. McCathieNevile, J. Richards, M. May, eds., W3C Recommendation, 16 November 2004. The <a href="http://www.w3.org/TR/2004/WD-ATAG20-20041122/">latest version</a> of this document is available at http://www.w3.org/TR/2004/WD-ATAG20-20041122/. </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.
A document appears in this section if at least one reference to the document appears in a checkpoint success criteria.
The active participants of the Authoring Tool Accessibility Guidelines Working Group who authored this document were: Tim Boland (National Institute for Standards and Technology), Barry A. Feigenbaum (IBM), Karen Mardahl (STC), Matt May (Team Contact, W3C), Greg Pisocky (Adobe), Jan Richards (Adaptive Technology Resource Centre, University of Toronto), Roberto Scano (IWA/HWG), and Jutta Treviranus (Chair of the working group, Adaptive Technology Resource Centre, University of Toronto)
Many thanks to the following people who have contributed to the AUWG through review and comment: 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, 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.