W3C

Authoring Tool Accessibility Guidelines 2.0

W3C Working Draft DD MM YYYY
- updated by Jan Richards: 19 Oct 2004

This version:
http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040625/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2004/WD-ATAG20-20040224/
Editors:
Jutta Treviranus - ATRC, University of Toronto
Charles McCathieNevile
Jan Richards - University of Toronto
Matt May - W3C

Abstract

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

Status of this document

This section describes the status of this document at the time of its publication. The latest status of this document series is maintained at the W3C.

This is a Public Working Draft of a document which will supersede the W3C Recommendation "Authoring Tool Accessibility Guidelines 1.0" [ATAG10]. It has been made available for review by W3C Members and other interested parties, in accordance with W3C Process. It is not endorsed by the W3C or its Members. It is inappropriate to refer to this document other than as a work in progress.

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 (e.g., Frequently Asked Questions (FAQ) about ATAG 2.0, issues, implementation reports, and test suites). Please consult the AUWG home page for more information.

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C 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). This is explained in Section 1.3.1.

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.

For information about the current activities of the working group, please refer to the AUWG home page.

Table of contents


1. Introduction

This document specifies requirements that, if satisfied by authoring tool developers, will lower barriers to accessibility. This document includes the following:

1.1 Definition of authoring tool

ATAG 2.0 defines an "authoring tool" as: any software or service that authors may use to create or modify Web content for publication.

In order 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 basic HTML editors have both code-level and WYSIWYG editing views):

1.1.1 Code-level Authoring Functions: Author has 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.

1.1.2 WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Author has control over entities that closely resemble the final appearance and behavior of the resulting Web content.
Examples: rendered document editors, bitmap graphics editors, etc.

1.1.3 Object Oriented Authoring Functions: Author has control over non-WYSIWYG entities that represent a functional abstraction from the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors, etc.

1.1.4 Indirect Authoring Functions: Authors have control of 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@@KM added@@, or programming implementation.
Examples: content management systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators, and conversion tools, etc.

1.2 Role of authoring tools in Web accessibility

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 a consumer of that Web content.

As an introduction to accessible authoring tool design, consider that the authors and consumers 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 consumers 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 Web content consumers beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require an alternative representation for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio equivalent to information they cannot view.

1.3 Relationship with other guidelines and standards

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:

In particular, ATAG 2.0 has a special normative relationship with the WCAG because WCAG serves as the accessibility benchmark against which the Web content produced by authoring tools can be judged. WCAG also serves as the accessibility benchmark for authoring interfaces that are Web-based.

In addition, while the W3C documents listed here provide robust coverage of Web-based technologies, the W3C has not published any documents specifically covering the accessibility of general-purpose software interfaces that are not Web-based. Instead of duplicating the high quality work that exists outside of W3C in this area, the Working Group has chosen to reference an International Organization for Standards (ISO) document that is under development, entitled: "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces (ISO TS 16071:2003)".

1.3.1 Relationship to "Web Content Accessibility Guidelines (WCAG)"

ATAG 2.0 depends on WCAG to act as an accessibility benchmark and define the terms "Accessible Web Content" and "Accessible Authoring Interface (Web-Based)".

At the time of publication, one version of WCAG is a W3C Recommendation, version 1.0 [WCAG10], and a second version of the guidelines is under development [WCAG20].

However, 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 whichever version of WCAG makes the most sense to use as the accessibility benchmark for a given authoring tool. The Working Group does recommend considering the following factors when deciding which on a WCAG version to use:

Note: The most important ATAG 2.0 references to WCAG occur within two types of Relative Priority checkpoints. The conformance section includes an explanation of how the normative WCAG references are to be resolved.

1.3.2 Relationship to "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces (ISO TS 16071:2003)"

For the reason stated above, ATAG 2.0 depends on the International Standards Organization (ISO) document titled "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces (ISO TS 16071:2003)" [ISO16071] to define the term "Accessible Authoring Interface (Not Web-Based)". The ISO document contains guidelines relevant to software and operating system accessibility. It is expected that final publication could occur in 2006.

Note: The most important ATAG 2.0 references to the ISO document occur within one type of Relative Priority checkpoint. The conformance section includes an explanation of the normative ISO reference.

1.4 How this document is organized

The four guidelines that reflect steps towards development of accessible authoring tools:

The first guideline addresses the accessibility of the authoring interface of the tool. The other three guidelines address the means by which Web content comes to be produced by the tool. These three guidelines build upon each other, with guideline 2 establishing core requirements, guideline 3 establishing key author support functionality and guideline 4 specifying general considerations for how any functionality related to accessibility should be integrated with the rest of the tool. Each guideline includes:

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:

A separate document, entitled "Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS], provides suggestions and examples of how to achieve the success criteria in this document.


2. The Authoring Tool Accessibility Guidelines

GUIDELINE 1: Make the tool itself @@authoring interface??@@ accessible

This guideline requires that the design of all aspects of the authoring tool, including the authoring interface, installation procedure, documentation, and help files, must be accessible. This entails ensuring that general-purpose accessibility requirements be followed when designing the authoring interface (Checkpoint 1.1) as well as other considerations specific to authoring interfaces.

The special nature of authoring interfaces dictates that special consideration be paid to several specific functions of the authoring interface design. These include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making use of document structure for navigation and editing (Checkpoint 1.4), and providing a searching mechanism for the editing views(Checkpoint 1.5).

An important distinction can be made between authoring interfaces that are Web-based and those that are not. Web-based authoring tools must meet the accessibility requirements set out within WCAG, whereas tools that are not Web based must meet the requirements of "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces (ISO TS 16071:2003)".

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines. [WCAG Relative Priority (Authoring Interface) for authoring tool interfaces that are also Web content; ISO16071 Relative Priority (Authoring Interface) for authoring tool interfaces that are not also Web content]

Rationale: If the authoring tool interface does not follow these conventions, the author who depends upon the techniques associated with the conventions is not likely to be able to use the tool.

Techniques: Implementation Techniques for Checkpoint 1.1, Evaluation Techniques for Checkpoint 1.1

1.2 Ensure that the authoring interface enables accessible editing of element and object properties. [WCAG Relative Priority (Authoring Interface) for authoring tool interfaces that are also Web content; ISO16071 Relative Priority (Authoring Interface) for authoring tool interfaces that are not also Web content]

Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays, or screen enhancers. The explicit property value should be accessible to those technologies that read text and support authors editing text.

Techniques: Implementation Techniques for Checkpoint 1.2, Evaluation Techniques for Checkpoint 1.2

Success Criteria:

  1. In authoring tool interfaces (that are also Web content), at least one editing method @@def?@@ for each element and object property that is editable@@def?@@ by the authoring tool must always be accessible (i.e. meet the requirements for authoring interface relative priority checkpoints (Web-based) to level 1, 2, or 3).
  2. In authoring tool interfaces (that are not also Web content), at least one editing method@@def?@@ for each element and object property that is editable@@def?@@ by the authoring tool must always be accessible (i.e. meet the requirements for authoring interface relative priority checkpoints (not Web-based) to Level 1, 2, or 3).
1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Rationale: Authors may require a set of display preferences to view and control the document that is different from the desired default display style for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques: Implementation Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint 1.3

Success Criteria:

  1. All editing views must always display @@def?@@ text equivalents @@def?@@ for any non-text content @@def?@@.
  2. All editing views must either respect @@def@@ operating system display @@def@@ settings (for color, contrast, size, and font) or, from within the authoring tool@@def?@@, provide a means of changing color, contrast, size, and font, @@how are these measured@@without affecting the content markup@@def?@@.@@color and contrast overlap, size and font overlap@@
1.4 Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale: Efficient authoring requires that the author be able to move quickly to arbitrary locations in the content and, once there, make modifications beyond character-by-character edits. This is usually best accomplished by making use of any explicit structure that may have been encoded with hierarchy-based markup. When explicit structure is unavailable, the implicit structure in the visual look and layout of content may sometimes be used.

Techniques: Implementation Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint 1.4

Success Criteria:

  1. In any element hierarchy@@def?@@, the author must always be able, with a device independent action@@def? - check with DIWG?@@, to move editing focus@@def?@@ from any structural element @@def?@@ to any element immediately above, immediately below, or at the same level in the hierarchy.
  2. In any element hierarchy@@def?@@, the author must always be able, with a device independent action@@def?@@, to select, copy, cut, and paste any element and its content @@def? + and subelements?@@.
1.5 Ensure that the authoring interface allows the author to search within the editing views. [Priority 2] @@"that" added (KM)@@

Rationale: Search functions 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 accessibility of the search function.

Techniques: Implementation Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint 1.5

Success Criteria:

  1. The Each authoring tool@@def?@@ must have a search function @@def?@@for all editing views@@how extensive?@@.
  2. The author must always be able to search for any text within all text equivalents@@def?@@ of any rendered @@def?@@non-text content.@@def?@@
  3. The author must always be able to specify whether to search content@@def?@@, markup@@def?@@, @@diff clear?@@or both.

GUIDELINE 2: Enable the production of accessible content

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 create valid, standards-based Web content, this can be rendered reliably by more user agents, including assistive technologies (Checkpoint 2.1). The next responsibility is to support formats that enable accessible content (Checkpoint 2.2).

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 ensuring that it is possible to author accessible content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).

2.1 Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]

Rationale: Following language specifications is the most basic requirement for accessible content production. When content is valid, it is easier to check and correct accessibility errors and user agents are better able to render the content properly and personalize the content to the needs of individual content consumer's devices.

Techniques: Implementation Techniques for Checkpoint 2.1, Evaluation Techniques for Checkpoint 2.1

Success Criteria:

  1. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to the applicable markup language specification.
2.2 Support formats that enable the creation of @@content that conforms to WCAG@@WCAG-conformant content. [Priority 1]

Rationale: Some formats enable the creation of web content that conforms to WCAG, while other formats may intrinsically preclude this possibility. This is achieved when a public WCAG techniques document explains how to meet each applicable WCAG checkpoint. Non-text formats may still meet this requirement if they support equivalent alternatives. Note that the format's WCAG techniques document must contain techniques that fully satisfy a given conformance level of WCAG in order to claim that level of eligibility for ATAG 2.0.

Techniques: Implementation Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint 2.2

Success Criteria:

  1. In order to give priority to a format, that format must have a published techniques document for meeting each WCAG checkpoint @@jr idea???: (that applies to the content that an authoring tool is capable of producing)@@. @@from techs@@
  2. The authoring tool must support at least one WCAG-capable format for each Web content type produced. @@???@@
  3. When format selection is automatic, the selected format must be WCAG-capable. @@???@@
2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]

Rationale: The ability to produce accessible Web content is the most basic requirement of this document.

Techniques: Implementation Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3

Success Criteria:

  1. Tools must always meet at least one of the following: (1) generate accessible content automatically, (2) provide the author with accessible options for every authoring task, or (3) provide a method for authoring "by hand"
2.4 Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]

Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language). Accessibility information should also be preserved.

Techniques: Implementation Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint 2.4

Success Criteria:

  1. During all transformations and conversions, all unrecognized markup and accessibility information must be preserved, unless prevented by limitations of the target format.
  2. When unrecognized markup or accessibility information cannot be preserved during a conversion or transformation, the author must be notified before any change is made.
2.5 Ensure that when the tool automatically generates content it conforms to WCAG. [WCAG Relative Priority (Web Content)]

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.

Techniques: Implementation Techniques for Checkpoint 2.5, Evaluation Techniques for Checkpoint 2.5

Success Criteria:

  1. All markup strings written automatically by the tool (i.e. not authored "by hand") must be accessible (i.e. meet the Web content checkpoints requirements to Level 1, 2, or 3). @@mm: maybe we should just say WCAG in the document and link to our section discussing this@@
  2. Unless the author explicitly instructs the authoring tool otherwise, all content generated by the tool must conform to WCAG. @@replaced by tech version@@
2.6 Ensure that all pre-authored content for the tool conforms to WCAG.@@ed: link to multiplexor@@[WCAG Relative Priority (Web Content)]

Rationale: Pre-authored content (e.g. templates, images, videos) is often included with authoring tools for the convenience of the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.

Techniques: Implementation Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6

Success Criteria:

  1. Any Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) preferentially licensed (i.e. better terms of use for users of tool than for others) for users of the tool, must be accessible (i.e. meet the Web content checkpoints requirements to Level 1, 2, or 3).

GUIDELINE 3: Support the author in the production of accessible content

Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7) and ensuring that documentation demonstrates authoring practices (Checkpoint 3.8) and workflow processes that result in accessible content (Checkpoint 3.9).

All functions that support accessible authoring practices should allow author preferences to be configurable to allow for different authoring styles. Custom configurations should improve use of the tool and make authors more receptive to assistive interventions from the authoring tool.

3.1 Prompt and assist the author to create accessible content. [WCAG Relative Priority (Web Content)]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create content that conforms to WCAG. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes, and authors.

Techniques: Implementation Techniques for Checkpoint 3.1, Evaluation Techniques for Checkpoint 3.1

Success Criteria:

  1. When the actions of the author risk creating Web content that is not accessible (i.e. fails to meet the Web content checkpoints requirements to Level 1, 2, or 3) (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must introduce the appropriate accessible authoring practice.
3.2 Check for and inform the author of accessibility problems. [WCAG Relative Priority (Web Content)]

Rationale: Authors may not notice or be able to identify accessibility problems. The tool can assist in their identification.

Techniques: Techniques for checkpoint 3.2, Evaluation Techniques for Checkpoint 3.2.

Success Criteria:

  1. The tool must provide a check (automated check, semi-automated check, or manual check) for detecting violations of each accessibility requirement (i.e. violations of the Web content checkpoints requirements to Level 1, 2, or 3).
3.3 Assist authors in repairing accessibility problems. [WCAG Relative Priority (Web Content)]

Rationale: Assistance by the tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.

Techniques: Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3

Success Criteria:

  1. The tool must provide a repair (automated repair, semi-automated repair, or manual repair) for correcting violations of each accessibility requirement (i.e. violations of the Web content checkpoints requirements to Level 1, 2, or 3).
3.4 Do not automatically generate equivalent alternatives @@need to synchronize with WCAG@@ or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 2]
@@do we to say "text-alternative" instead of equivalent alternative (like WCAG)@@

Rationale: Improperly generated alternatives can create accessibility problems and interfere with accessibility checking.

Techniques: Implementation Techniques for Checkpoint 3.4, Evaluation Techniques for Checkpoint 3.4

Success Criteria:

  1. When the author inserts an unrecognized non-text object, the tool must not insert an automatically generated text equivalent (e.g. label generated from the file name).
  2. When the author inserts a non-text object for which the tool has a previously authored equivalent (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.
3.5 Provide functionality for managing, editing, and reusing @@jr: and sharing: http://lists.w3.org/Archives/Public/w3c-wai-au/2004JulSep/0121.html@@ alternative equivalents. [Priority 3]

Rationale: Simplifying the initial production and later reuse of alternative equivalents will encourage authors to use them more frequently. In addition, such an alternative equivalent management system will facilitate meeting the requirements of Checkpoint 3.4.

Techniques: Implementation Techniques for Checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5

Success Criteria:

  1. When non-text objects have been previously inserted using the tool, the tool must suggest any previously authored textual equivalents for that non-text object. When objects, for which alternative equivalents have been previously provided, are inserted, the tool must always offer those alternative equivalents for reuse or modification.(@@replaced by tech version@@)
3.6 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: This summary will help the author to improve the accessibility status of their work, keep track of problems, and monitor progress.

Techniques: Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6.

Success Criteria:

  1. The tool must provide the author with an option to view a listing of all current accessibility problems.
3.7 Document all features of the tool that promote the production of accessible content. [Priority 2]

Rationale: Without documentation of the features that promote accessibility (e.g. prompts for alternates, code validators, accessibility checkers, etc.) authors may not find or use them.

Techniques: Techniques for checkpoint 3.7, Evaluation Techniques for Checkpoint 3.7.

Success Criteria:

  1. All features that play a role in creating accessible content must be documented in the help system.
3.8 Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 2]

Rationale: If accessible authoring is integrated into instruction and guidance offered by the tool (e.g. documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring as a common practice. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences. Authors are also more likely to use features that promote accessibility if they understand when and how to use them.

Techniques: Implementation Techniques for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8

Success Criteria:

  1. All examples of markup code and views of the authoring interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices.
3.9 Document the workflow process of using the tool to produce accessible content. [Priority 3]

Rationale: @@???@@MM action item

Techniques: Implementation Techniques for Checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9

Success Criteria:

  1. The documentation must contain suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool.
  2. For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for the missing feature.

GUIDELINE 4: Promote and integrate accessibility solutions

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), natural integration with the appearance and interactive style of the tool (Checkpoint 4.4), and sufficient configurability (Checkpoint 4.5).

4.1 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Rationale: Authors are most likely to use the first and easiest options.

Techniques: Implementation Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint 4.1

Success Criteria:

  1. When an authoring action has more than one markup implementation (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that meet the requirements of WCAG must have equal or higher prominence than those markup implementations that do not meet the WCAG requirements.
4.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author [Priority 2]

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 4.2, Evaluation Techniques for Checkpoint 4.2

Success Criteria:

  1. Continuously active processes @@move to glossary?@@ that implement accessibility prompting, checking, repair, and documentation functions must be enabled by default.@@rewording@@(e.g. a checker that underlines errors as they occur, a checker that runs at each save, a checker that runs every 10 minutes, etc.) that implement functions required by checkpoints 3.1, 3.2, 3.3 and 3.7 must be enabled by default.
  2. If the author chooses to disable these continuously active processes, then the tool must inform the author of the consequences of their choice.
  3. The accessibility prompting, checking, repair, and documentation must have at least the same prominence as prompting, checking, repair, and documentation for other information in the tool.
4.3. Ensure that accessibility prompting, checking, repair functions, and documentation are integrated into the workflow of Web content development. [Priority 2]

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 a workflow in which the author considers 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 4.3, Evaluation Techniques for Checkpoint 4.3

Success Criteria:

  1. Accessibility prompting must be integrated into all features that assist with author decision-making (e.g. templates, wizards, and instruction text). Accessibility checking, repair, and documentation functions must be made available before completion of any authoring workflow. @@agreed onAug. 2 Call@@
  2. Any mechanism that guides the author in sequencing authoring actions (e.g. design aids, wizards, templates, etc.) must integrate accessibility prompting, checking, repair functions, and documentation. @@are both criteria needed?@@
4.4 Ensure that accessibility prompting, checking, repair functions, and documentation are naturally integrated into the appearance and interactive style of the tool. [Priority 3]

Rationale: Most authors are reluctant to use features that depart from the conventions of a tool.

Techniques: Implementation Techniques for Checkpoint 4.4, Evaluation Techniques for Checkpoint 4.4

Success Criteria:

  1. The authoring interface for accessibility prompting, checking, repair, and documentation must match the authoring interface for comparable functions in terms of the following characteristics: (1) visual design (measured by design metaphors, artistic sophistication, sizes, fonts, colors), (2) operation (measured by degree of automation, number of actions for activation), and (3) comprehensiveness (measured by breadth and depth of functionality coverage).
4.5 Ensure that accessibility prompting, checking, repair, and documentation functions are configurable [Priority 3]

Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.

Techniques: Implementation Techniques for Checkpoint 4.5, Evaluation Techniques for Checkpoint 4.5

Success Criteria:

  1. All functions related to accessibility prompting, checking, repair, and documentation must match the other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of the number of options controllable by the author and the degree to which each option can be controlled.

3. Conformance

3.1 Conformance Scheme

"ATAG 2.0" allows authoring tools to claim conformance to any one of a number of conformance levels depending on the priority of the checkpoints that the authoring tool has met.

3.1.1 Conformance Levels

ATAG 2.0 provides for the following levels of conformance (see also Figure 1):

No Conformance
Authoring tool has not met all of the requirements of Conformance Level "A".
Conformance Level "A"
Authoring tool has met all Priority 1 checkpoints and has also met all of the relative checkpoints to at least Level 1.
Conformance Level "Double-A"
Authoring tool has met all Priority 1 and Priority 2 checkpoints and has also met all of the relative checkpoints to at least Level 2.
Conformance Level "Triple-A"
Authoring tool has met all Priority 1, Priority 2, and Priority 3 checkpoints and has also met all of the relative checkpoints to Level 3.
Figure 1: A graphical view of the requirements of the ATAG 2.0 Conformance Levels (described above).

A graphic that illustrates the levels of conformance as they are explained in  the text 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 rows labelled "No conformance", "Conformance Level 'A'", "Conformance Level 'Double-A'", and "Conformance Level 'Triple-A'". Bar charts super-imposed on the rows demonstrate that in order to meet each subsequent level, additional levels of checkpoints must be met

3.1.2 Checkpoint Priorities

Every checkpoint in ATAG 2.0 has been assigned one of three priority levels that indicate the importance (i.e. "essential", "important", or "beneficial") of the checkpoint in satisfying the guideline under which the checkpoint appears. The priority of a checkpoint determines whether that checkpoint must be met by a tool in order for that tool to achieve a particular ATAG 2.0 conformance level. The priority levels have been set based on the assumption that the typical author is a competent, but not necessarily expert, user of the authoring tool and that the author has little or no knowledge of accessibility. For example, the author is not expected to have read all of the documentation provided with an authoring tool, but is expected to know how to turn to the documentation for assistance.

The checkpoint priority levels used in ATAG 2.0 are:

Priority 1: These checkpoints are essential to satisfying the guidelines under which they appear.

Priority 2: These checkpoints are important to satisfying the guidelines under which they appear.

Priority 3: These checkpoints are beneficial to satisfying the guidelines under which they appear.

Relative Priority Checkpoints (3 types): The importance of these checkpoint types (i.e. "essential", "important", or "beneficial") depends on the requirements of external documents.

3.2 Claiming Conformance:

In order to claim that an authoring tool conforms to ATAG 2.0 the claimant must provide a conformance profile as well as conformance details.

3.2.1 Conformance Profiles

An authoring tool conforms to this document by satisfying the requirements identified by a conformance profile. A conformance profile includes the following assertions:

  1. Required: The guidelines title/version and URI of the guidelines: "Authoring Tool Accessibility Guidelines 2.0" (http://www.w3.org/@@@@)
  2. Required: The conformance level satisfied: "A", "Double-A", or "Triple-A"
  3. Required: The title/version and URI for the WCAG document that was used as the Web content accessibility benchmark for determining the level of relative priority checkpoints: e.g. "Web Content Accessibility Guidelines 2.0" (http://www.w3.org/@@@@)
  4. Required: The formats produced by the tool. For each format include the URI of the published WCAG techniques document, if one exists: e.g. "HTML Techniques for WCAG 2.0" (http://www.w3.org/@@@@)
  5. Optional: A description of the authoring tool that identifies the types of authoring tool functions that are present in the tool.

3.2.2 Conformance Details

An ATAG 2.0 conformance claim must include a description of how the authoring tool meets each of the checkpoints that are required for the conformance level specified by the conformance profile. In the case of relative priority checkpoints, this description is required to be a point-by-point accounting of the requirements in the external document. A checkpoint is considered to have been met when the tool satisfies all of the normative success criteria listed for that checkpoint.

3.2.3 Notes on Making a Conformance Claim

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

Claimants

  1. Claimants may be anyone (e.g., developers, journalists, or other third parties).
  2. Claimants are solely responsible for the validity of their claims, keeping claims up to date, and proper use of the conformance icons.
  3. Claimants are expected to modify or retract any conformance claim if it may be demonstrated that the claim is not valid.
  4. Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation that is available.

Publishing Claims

  1. Conformance claims may be published anywhere (e.g., on the Web or in paper documentation).
  2. The existence of a conformance claim does not imply that the W3C has reviewed the claim or assured its validity. As of the publication of this document, W3C does not act as an assuring party, but it may do so in the future, or it may establish recommendations for assuring parties.
  3. If usability tests are referenced, the details of the testing methods and results must also be published. @@rework of a note about usability@@

Bundling Tools for Conformance Claims

A conformance claim may cover more than one tool used in conjunction (e.g. a markup editor and an evaluation and repair tool or a multimedia editor with a custom plug-in), each of which may or may not conform with ATAG 2.0 by themselves, as long as:

  1. The tools are distributed together.
  2. The workflow used to determine the conformance of the tool bundle is typical of how the tools are used together.

Conformance Icons:

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


4. Glossary

This glossary is normative. However, some terms (or parts of explanations of terms) may not have an impact on conformance.

a b c d e f g h i j k l m n o p q r s t u v w x y z

Accessible
Within these guidelines, there are three types of accessibility:
Accessibility
???
Accessibility Information
Any information that is necessary for an accessible authoring practice including, but is not limited to, equivalent alternative information.
Accessibility Problem (Authoring Interface (Not Web-Based))
An aspect of a non-Web-based authoring tool interface that fails to meet a success criteria of the checkpoints of Guideline 1. The severity of the problem is defined by the ATAG 2.0 priority level of the failed checkpoint. Two of the checkpoints have Relative Priorities that refer to ISO16071.
Accessibility Problem (Authoring Interface (Web-Based))
An aspect of a non-Web-based authoring tool interface that fails to meet a success criteria of the checkpoints of Guideline 1. The severity of the problem is defined by the ATAG 2.0 priority level of the failed checkpoint. Two of the checkpoints have Relative Priorities that refer to WCAG via "Resolving ATAG References to WCAG" [WCAG-REFS].
Accessibility Problem (Web Content)
Web content that fails to meet some requirement of the Web Content Accessibility Guidelines. The severity of the problem in the context of ATAG 2.0 is defined Relative Priority checkpoints that refer to WCAG via the "Resolving ATAG References to WCAG" [WCAG-REFS] document.
Accessible Authoring Practice
Web content modifications made by the author or the tool that increase the likelihood of producing accessible Web content.
Accessible Authoring Interface (Not Web-Based)
Authoring tool interface, that is not Web-based, with no authoring tool interface accessibility problems.
Accessible Authoring Interface (Web-Based)
Authoring tool interface, that is Web-based, with no authoring tool interface accessibility problems.
Accessible Web Content
Web content with no Web content accessibility problems.
Alert
An "alert" draws the author's attention to an event or situation. It may require a response from the author.
Attribute
This document uses the term "attribute" as used in SGML and XML [XML]: Element types may be defined as having any number of attributes. Some attributes are integral to the accessibility of content (e.g., the "alt", "title", and "longdesc" attributes in HTML).
Auditory Description
An "auditory description" provides information about actions, body language, graphics, and scene changes in a video. Auditory descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An auditory description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The auditory description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track.
Author
For the purposes of this document, an author is a user of an authoring tool. This may include content authors, designers, programmers, publishers, testers, etc.
Authored "by hand"
When the author specifies the precise text string, as by typing into a text editor.
Authoring Action
???
Authoring Interface
The display and control mechanism available to an author to communicate with and operate the authoring tool software. Authoring tool interfaces may we Web-Based (i.e. consisting of Web content) or not.
Authoring Tool
See "Definition of authoring tool"
Captions
"Captions" are essential equivalent alternatives for movie audio. Captions consist of a text transcript of the auditory track of the movie (or other video presentation) that is synchronized with the video and auditory tracks. Captions are generally rendered graphically and benefit people who can see but are deaf, hard-of-hearing, or cannot hear the audio.
Configurability
???@@new dfn@@
Continuously Active Process
???@@new dfn@@
Conversion Tool
A "conversion tool" is any application or application feature (e.g.,"Save as HTML") that transforms convert in one format to another format (such as a markup language).
Checking
The process by which web content is evaluated for accessibility problems. This applies to evaluations performed automatically or with assistance from the author. The evaluation may be performed at specific times or be performed on an continuous basis as Web content is modified. For more information on checking, see checkpoint 3.2.
Display
???
Document
A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML application).
Documentation
Documentation: Documentation refers to information that supports the use of an authoring tool. This information may be found electronically or otherwise and includes manuals, installation instructions, help mechanisms, sample workflows, and tutorials, etc..
Editable@@???@@
???
Editing Method@@???@@
???
Editing View
An "editing view" is a view provided by the authoring tool that allows editing.
Element
An "element" is any identifiable object within a document, for example, a character, word, image, paragraph, or spreadsheet cell. In [HTML4] and [XML], an element refers to a pair of tags and their content, or an "empty" tag - one that requires no closing tag or content.
Equivalent Alternative
Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the content consumer. Equivalent alternatives play an important role in accessible authoring practices since certain types of content may not be accessible to all authoring content consumers (e.g., video, images, audio, etc.). Authors are encouraged to provide text equivalents for non-text content since text may be rendered as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, or as graphical text for individuals who are deaf or do not have a disability. For more information about equivalent alternatives, please refer to the Web Content Accessibility Guidelines [WCAG-REFS].
Format
???
Inform
To "inform" is to make the author aware of an event or situation through alert, prompt, sound, flash, or other means.
Information Icon
Any graphic that an author can select to receive additional information.
Markup
Set of tags that specify the characteristics of a document. Markup can be presentational, structural or semantic.
Markup Language
Authors encode information using a "markup language" such as HTML [HTML4], SVG [SVG], or MathML [MATHML].
Normative
What is identified as "normative" is required for conformance (noting that one may conform in a variety of well-defined ways to this document). What is identified as "informative" (sometimes, "non-normative") is never required for conformance. @@NEW-from UAAG@@
Object
???
Presentation Markup
"Presentation markup" is markup language that encodes information about the desired presentation or layout of the content. For example, Cascading Style Sheets [CSS1], [CSS2] can be used to control fonts, colors, aural rendering, and graphical positioning. Presentation markup should not be used in place of structural markup to convey structure. For example, authors should mark up lists in HTML with proper list markup and style them with CSS (e.g., to control spacing, bullets, numbering, etc.). Authors should not use other CSS or HTML incorrectly to lay out content graphically so that it resembles a list.
Prominence
The "prominence" of a control in the authoring interface is a heuristic measure of the degree to which users take notice of the control when operating the system. In these guidelines, "prominence" refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a control include:
  • Control Size: Larger controls or controls surrounded by more whitespace may appear to be conferred higher importance.
  • Control Order: Without any other forms of organization, most people will read interface items in a "localized" reading order (i.e. left to right and top to bottom; right to left and top to bottom, etc.). The higher visibility of items that occur early in the reading order confers higher apparent importance.
  • Control Grouping: Grouping input fields (e.g. in a vertical list, etc.) can change the reading order and the related judgments of importance.
  • Advanced Options: When the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance.
  • Highlighting: Controls may be distinguished from others using icons, color, styling, etc. When these methods are used, it is important to ensure that that they are consistent with the overall look and feel of the authoring tool interface (see Checkpoint 4.4). (An additional consideration is that in order to meet ATAG Checkpoint 1.1, the highlighting must be implemented so that it is available through the appropriate API (MSAA, Java Accessibility API, GNOME accessibility, etc.), allowing an author with disabilities to access the highlighting through assistive devices).
Prompt
In this document prompt does not refer to the narrow software sense of a "prompt," rather it is used as a verb meaning to urge, suggest, and encourage. The form and timing that this prompting takes can be user configurable. "Prompting" does not depend upon the author to seek out the support but is initiated by the tool. "Prompting" is more than checking, correcting, and providing help and documentation as encompassed in guideline 3 @@???@@. The goal of prompting the author is to encourage, urge, and support the author in creating meaningful equivalent text without causing frustration that may cause the author to avoid access options. Prompting should be implemented in such a way that it causes a positive disposition and awareness on the part of the author toward accessible authoring practices.
Property
A "property" is a piece of information about an element, for example structural information (e.g., it is item number 7 in a list, or plain text) or presentation information (e.g., that it is marked as bold, its font size is 14). In XML and HTML, properties of an element include the type of the element (e.g., IMG or DL), the values of its attributes, and information associated by means of a style sheet. In a database, properties of a particular element may include values of the entry, and acceptable data types for that entry.
Repairing
The process by which Web content is modified to solve accessibility problems. This applies to modifications performed automatically or with assistance from the author. For more information on repairing, see checkpoint 3.3.
Structural Markup
"Structural markup" is markup language that encodes information about the structural role of elements of the content. For example, headings, sections, members of a list, and components of a complex diagram can be identified using structural markup. Structural markup should not be used incorrectly to control presentation or layout. For example, authors should not use the BLOCKQUOTE element in HTML [HTML4]to achieve an indentation visual layout effect. Structural markup should be used correctly to communicate the roles of the elements of the content and presentation markup should be used separately to control the presentation and layout.
Transcript
A "transcript" is a text representation of sounds in an audio clip or an auditory track of a multimedia presentation. A "collated text transcript" for a video combines (collates) caption text with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the visual track). Collated text transcripts are essential for individuals who are deaf-blind and rely on Braille for access to movies and other content.
Techniques
Informative suggestions and examples for ways in which the success criteria of a checkpoint might be satisfied.
Transformation
A "transformation" is a process that changes a document or object into another, equivalent, object according to a discrete set of rules. This includes conversion tools, software that allows the author to change the DTD defined for the original document to another DTD, and the ability to change the markup of lists and convert them into tables.
Typical Author
A typical author is a hypothetical individual who possesses levels of authoring knowledge, tool proficiency, and experience with accessibility issues that fall at the mean of the levels measured from a large random sample of actual users of an authoring tool.
User Agent
A "user agent" is software that retrieves and renders Web content. User agents include browsers, plug-ins for a particular media type, and some assistive technologies.
View
Authoring tools may render the same content in a variety of ways; each rendering is called a "view". Some authoring tools will have several different types of view, and some allow views of several documents at once. For instance, one view may show raw markup, a second may show a structured tree, a third may show markup with rendered objects while a final view shows an example of how the document may appear if it were to be rendered by a particular browser. A typical way to distinguish views in a graphic environment is to place each in a separate window.
Web Content
???
WCAG-Conformant
???
WCAG-Capable Format
A format is WCAG-capable when a public WCAG techniques document explains how to meet each applicable WCAG checkpoint. Non-text formats may still be WCAG-capable if they support equivalent alternatives. Note that the format's WCAG techniques document must contain techniques that fully satisfy a given conformance level of WCAG in order to claim that level of eligibility for ATAG 2.0.
Workflow
The customary sequence of steps or tasks that are followed to produce a deliverable.

5. References

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.

5.1 How to refer to this document

There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):

  1. References to a specific version of "Authoring Tool Accessibility Guidelines 2.0." For example, use the "this version" URI to refer to the current document: http://www.w3.org/TR/@@@@@.
  2. References to the latest version of "Authoring Tool Accessibility Guidelines 2.0." Use the "latest version" URI to refer to the most recently published document in the series: http://www.w3.org/TR/ATAG20/.

In almost all cases, references (either by name or by link) should be to a specific version of the document. W3C will make every effort to make this document indefinitely 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/@@@@@@@@">
"Authoring Tool Accessibility Guidelines 1.0,"</a></cite>
J. Treviranus, C. McCathieNevile, J. Richards, M. May, eds.,
W3C Recommendation, @@Date@@.
The <a href="http://www.w3.org/TR/ATAG20/">latest
version</a> of this document is available at
http://www.w3.org/TR/ATG20/.</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.

5.2 Normative references

A document appears in this section if at least one reference to the document appears in a checkpoint success criteria.

[ISO16071]
ISO/TS 16071:2002(E) - Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces. ISO's Web site is http://www.iso.ch.
[WCAG10]
@@@@
[WCAG20]
"Web Content Accessibility Guidelines 2.0 (Working Draft)," W. Chisholm, G. Vanderheiden, and J. White, editors. The latest version of the Web Content Accessibility Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note: This document is still a working draft.

5.3Informative references

[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[ATAG10-TECHS]
"Techniques for Authoring Tool Accessibility", J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile editors. The latest version is available at http://www.w3.org/TR/ATAG10-TECHS.
[ATAG20-TECHS]
"Techniques for Authoring Tool Accessibility 2.0", J. Treviranus, J. Richards, C. McCathieNevile, and M. May, editors. The latest version is available at http://www.w3.org/TR/ATAG20-TECHS.
[CONFORMANCE]
"Conformance icons for ATAG 1.0". Information about ATAG 1.0 conformance icons is available at http://www.w3.org/WAI/ATAG10-Conformance.
[CSS1]
"CSS, level 1 Recommendation," B. Bos and H. Wium Lie, editors., 17 December 1996, revised 11 January 1999. This CSS1 Recommendation is http://www.w3.org/TR/1999/REC-CSS1-19990111. The latest version of CSS1 is available at http://www.w3.org/TR/REC-CSS1. Note: CSS1 has been superseded by CSS2. Tools should implement the CSS2 cascade in particular.
[CSS2]
"CSS, level 2 Recommendation," B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, editors., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[HTML4]
"HTML 4.01 Recommendation," D. Raggett, A. Le Hors, and I. Jacobs, editors., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is available at http://www.w3.org/TR/html4.
[MATHML]
"Mathematical Markup Language," P. Ion and R. Miner, editors., 7 April 1998, revised 7 July 1999. This MathML 1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available at http://www.w3.org/TR/REC-MathML.
[PWD-USE-WEB]
"How People With Disabilities Use the Web," J. Brewer, editor, 4 January 2001. The latest version of How People with Disabilities Use the Web is available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
[RDF10]
"Resource Description Framework (RDF) Model and Syntax Specification," O. Lassila, R. Swick, editors. The 22 February 1999 Recommendation is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF 1.0 is available at http://www.w3.org/TR/REC-rdf-syntax.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)," J. Ferraiolo, editor. The latest version of the SVG specification is available at http://www.w3.org/TR/SVG.
[UAAG10-TECHS]
"Techniques for User Agent Accessibility Guidelines 1.0," J. Gunderson and I. Jacobs, editors. The latest version of Techniques for User Agent Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/UAAG10-TECHS/.
[WCAG-REFS]
ATAG 2.0 References to WCAG, J. Treviranus, J. Richards, and M. May, editors.
[XML]
"The Extensible Markup Language (XML) 1.0," T. Bray, J. Paoli, C. M. Sperberg-McQueen, editors., 10 February 1998. This XML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-xml-19980210. The latest version of the XML specification is available at http://www.w3.org/TR/REC-xml.

6. Acknowledgments

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), Liddy Nevile, 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, Graham Oliver, 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.

Level Double-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0