W3C

Authoring Tool Accessibility Guidelines 2.0

Working Draft 31 October 2003

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

Abstract

This specification provides guidelines for Web authoring tool developers. Its purpose is two-fold: to assist developers in designing authoring tools that produce accessible Web content and to assist developers in creating an accessible authoring interface.

Authoring tools can enable, encourage, and assist users ("authors") in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. It is as important that all people be able to author content as it is for all people to have access to it. The tools used to create this information, therefore, must also be accessible. Implementation of these guidelines will contribute to the proliferation of Web content that can be read by a broader range of readers and authoring tools that can be used by a broader range of authors in a wider range of contexts with more devices.

This document is part of a series of accessibility documents 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. Other documents may supersede this document. 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) as part of the Web Accessibility Initiative (WAI). The goals of the Working Group are discussed in the AUWG charter.

The Working Group maintains a list of patent disclosures and issues related to ATAG 2.0.

A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR/. The AUWG is part of the WAI Technical Activity.

This draft refers to the Web Content Accessibility Guidelines (WCAG) for specification of accessible content and refers non-normatively to the Techniques for Authoring Tool Accessibility [ATAG20-TECHS]. The working group has provided a reference called ATAG 2.0 References to WCAG [ WCAG-REFS] mapping the ATAG checkpoints to WCAG 1.0 and the January 2003 draft of WCAG 2.0, currently a W3C Working Draft.

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.

The working group maintains an ATAG 2.0 Issues List.

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. This page includes an explanation of the inter-relation of each document as well as minutes and previous drafts.

Table of contents


1. Introduction

1.1 Definition of Authoring Tool

Any software or service that authors may use to create or modify Web content for publication. This includes software that enables authors to perform any of the following functions:
1. Text Editing: Authors manipulate plain text data (e.g. markup text, program code, etc.). [ Example 1]
2. Symbol-Level Editing: Authors manipulate symbols (not WYSIWYG renderings) that represent low-level functional groups in the underlying plain text data (e.g. symbols in place of markup elements, programming code operations, multi-element placeholder, etc.) .[ Example 2]
3. WYSIWYG Editing: Authors manipulate browser-like renderings of the underlying plain text data (e.g. rendered text, images, etc. in place of markup elements). [ Example 3]
4. Graphics Editing: Authors manipulate renderings of object-oriented graphics (e.g. rendered lines, etc. in place of markup elements in a drawing program, animation tool stage, etc.). [ Example 4]
5. Content Management: Authors exercise control of changes to Web content across whole documents or groups of documents, rather than at the level of individual instances of content (e.g. site building wizards, site management tools, courseware, content aggregators, etc.). [ Example 5]
6. Constrained Editing: Authors make highly constrained inputs that are structured and styled according to static templates (e.g. guest books, message boards, etc.). [ Example 6]
7. Timeline Editing: Authors manipulate time-dependent Web content (e.g. animation, music, etc.) using a user interface that represents a series of frames. [ Example 7]
8. Format Conversion: Authors are assisted in causing Web content encoded in one format to become encoded in another (e.g. saving Web content created in one format in a different format, importing Web content from a different format, etc.) [ Example 8]

1.2 Role of authoring tools in Web accessibility

Everyone should have the ability to create and access Web content.

Authoring tools are pivotal in achieving this principle. The accessibility of authoring tools determines who can create Web content and the output of authoring tools determines who can access Web content.

The guidelines set forth in this document will benefit people regardless of disability. This includes people who need to use their eyes for another task and are unable to view a screen, people in environments where the use of sound is not practical, and people who use small mobile devices with small screens, no keyboard, or no mouse.

The guidelines promote the following goals:

The accessibility of authoring tools is defined primarily by existing specifications for accessible software. The accessibility of authoring tool output is defined by the Web Content Accessibility Guidelines (WCAG).

1.3 How this document is organized

This document contains four guidelines that reflect the goals of accessible authoring tool design:

Each guideline includes:

Each checkpoint 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. The checkpoints specify requirements for meeting the guidelines. Each checkpoint includes:

A separate document, entitled "Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS], provides suggestions and examples of how to achieve the recommendations in this document. Another document [ATAG20-CHECKLIST] lists all checkpoints, ordered by priority, for convenient reference.

1.4 Checkpoint priorities

Each checkpoint in the specification has been assigned one of the following priority levels to indicate the importance of the checkpoint in satisfying the guidelines:

Priority 1
The checkpoint is essential.
Priority 2
The checkpoint is important.
Priority 3
The checkpoint is beneficial.
Relative Priority (Level 1, 2, or 3)
The importance of the checkpoint depends on the specific requirements of WCAG and is therefore relative to priorities assigned in those guidelines.

Note: The choice of priority level for each checkpoint is based on the assumption that the 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, but is expected to know how to turn to the documentation for assistance.

1.5 Conformance

An ATAG conformance claim for an authoring tool must indicate which of the following conformance levels has been met:

Conformance Level "A"
Tool has met all Priority 1 checkpoints and has also met all Relative Priority checkpoints to at least Level 1.
Conformance Level "Double-A"
Tool has met all Priority 1 and 2 checkpoints and has also met all Relative Priority checkpoints to at least Level 2.
Conformance Level "Triple-A"
Tool has met all checkpoints and has also met all Relative Priority checkpoints to Level 3.

In the above, "meeting the checkpoints" means satisfying all of the success criteria associated with that particular checkpoint.

For the purposes of ATAG 2.0 conformance claims, tools may be bundled together (e.g. a markup editor and a evaluation and repair tool or a multimedia editor with a custom plug-in), however, this has two important consequences:

  1. The bundled tools must be distributed together in order for each to maintain that conformance claim.
  2. Bundled tools may have more difficulty meeting the checkpoints in Guideline 4 (Integrate accessibility solutions into the overall "look and feel") than single, integrated tools.

Satisfying certain success criteria may involve usability issues and as such may require integrating aspects of usability testing.

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.

1.6 Accessible authoring processes

From the standpoint of accessibility, Web authoring is a process that may involve one or more tools in parallel or in sequence. In order to ensure that the Web content produced as a result of a Web authoring process is accessible, developers and purchasers should choose tools that are either ATAG 2.0 conformant or ATAG 2.0-"Friendly". ATAG-"Friendly" tools are tools which, although they do not conform with ATAG, are also very unlikely to degrade the accessibility of Web content. For example, an ATAG-friendly tool is one that converts the URI locations in a Web page from absolute to relative prior to publishing.

In some cases, strategic ordering of the tools in a Web authoring process may increase the likelihood of producing accessible content. For example, a markup editor that does not conform to ATAG might be used before an ATAG conformant evaluation and repair tool. While this is, of course, preferable to not addressing accessibility at all, the original markup tool is still considered ATAG non-conformant. Considering the markup editor and evaluation and repair tool together is possible, but due to the low likelihood of proper integration between the tools, the result is unlikely to be a high level of ATAG conformance.

2. Guidelines

GUIDELINE 1: Ensure that the tool itself is accessible

This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces.

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines (Software Accessibility Guidelines, WCAG). ([Priority 1] for required elements of the software accessibility guidelines; [Priority 3] for recommended elements of the software accessibility guidelines.)

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

Success Criteria:

  1. The authoring interface must pass the Software Accessibility Guidelines testing criteria. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)

Specific considerations when designing an accessible authoring interface

Note: This is proposed text.
The special nature of authoring interfaces dictates several other accessible user interface design considerations. The checkpoint requirements for this section 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 the use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5).

1.2 Ensure that the authoring interface enables accessible editing of element and object properties. [Priority 1]

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 which read text and support authors editing text.

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

Success Criteria:

  1. At least one editing method must pass the Software Accessibility Guidelines testing criteria for each element and object property editable by the tool. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)
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 display text equivalents for any non-text content
  2. All editing views must either respect operating system display settings (for color, contrast, size, and font) or, from within the tool, provide a means of changing color, contrast, size and font, without affecting the content markup.
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: (updated 22 July)

  1. In any element hierarchy, the author must be able to move editing focus from any structural element to any element immediately above, immediately below or in the same level in the hierarchy.
  2. In any element hierarchy, the author must be able to select, copy, cut and paste any element with its content.
1.5 Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

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: (updated 22 July)

  1. The authoring tool must have a search function for all editing views.
  2. The author must be able to search for text within all text equivalents of any rendered non-text content.
  3. The author must be able to specify whether to search content, markup, or both.

GUIDELINE 2: Ensure that the tool is designed to produce accessible content

Note: This is proposed text.
This guideline requires that authoring tools must generate standard markup and support accessible authoring practices. Meeting these requirements is an essential pre-requisite to the higher level functions required in the next guideline.

Generating standard markup:

Note: This is proposed text.
Conformance with standards enables content to be rendered more reliably by more user agents, including assistive technologies used by people with disabilities. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that have been formulated to enable accessible content (Checkpoint 2.2).

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 users' devices.

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

Success Criteria: (updated 22 July)

  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 Give priority to formats that enable the creation of WCAG-conformant content. [Priority 1]

Rationale: Part of what we mean by this is that if multiple formats are supported, that those that enable the creation of WCAG-conformant content are given priority.(??) NOTE: The tool may use other formats.

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.

Supporting accessible authoring practices:

Note: This is proposed text.
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 for this section include ensuring the possibility of accessible content production (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4 and 2.7), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).

2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]

Rationale: If it is at least possible for the author to produce accessible content, then well-informed authors may be able to work around any accessibility short-comings in the rest of the authoring tool.

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

Success Criteria: (updated 22 July)

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

Rationale: Authors will be discouraged from adding accessibility information if it is discarded 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).

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

Success Criteria: (updated 22 July)

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

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: (updated 22 July)

  1. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to WCAG.
2.6 Ensure that all pre-authored content for the tool conforms to WCAG. [Relative Priority]

Rationale: Pre-authored content (e.g. templates, images, videos, etc.) is often included with authoring tools for the convenience of the author. Ensuring that pre-authored content is WCAG conformant increases that convenience by ensuring that authors can use any of the content without concern for the accessibility implications and relieving subsequent authors from having to compose their own version of alternative content.

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

Success Criteria: (updated 22 July)

  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 conform to WCAG.
2.7 Allow the author to preserve markup not recognized by the tool. [Priority 2]

Rationale: Markup that is not recognized by an authoring tool may have been added to enhance accessibility. Also, newer XML-based languages, such as XHTML 1.1, allow authors to include multiple languages in a single document, via namespaces. In the future, documents may contain metadata, including accessibility information, in another namespace. Authoring tools must not strip this information when it is encountered.

Techniques: Implementation Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint 2.7

Success Criteria: (updated 22 July)

  1. When unrecognized markup (e.g. external entity, unrecognized element or attribute name) is detected, the tool must query the author for consent to modify the markup. If the author refuses, and the markup cannot be processed, the tool must refuse to open the markup for editing.

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

Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to effect the accessibility of content, either positively, if the author is purposefully following accessibility guidelines, or negatively, if the author is not. In order to manage these effects, authoring tools should support the author by guiding them to follow accessibility authoring practices as they produce that content that involves an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility-related documentation.

Guiding the author to produce accessible content:

Note: This is proposed text.
Conformance with accessibility authoring practices is an authoring constraint, analogous to producing valid code or grammatical text. Since the role of any authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. The checkpoint requirements for this section include prompting and assisting the author to create accessible content, especially for information that cannot be generated automatically, such as descriptions of graphics (Checkpoint 3.1), checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3).

Implementation Note: All functions added to support accessible authoring should be flexible enough to take into account different authoring styles. When authors can configure accessibility features to support their regular work patterns, they will be more likely to feel comfortable with their use and be more receptive to interventions from the tool. For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session.

3.1 Prompt and assist the author to create accessible content. [Relative Priority]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. 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: (updated 22 July)

  1. When the actions of the author risk creating accessibility problems (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must intervene to introduce the appropriate accessible authoring practice. This intervention may proceed according to a user-configurable schedule.
  2. The intervention must occur at least once before completion of authoring (e.g. final save, publishing, etc.).
3.2 Check for and inform the author of accessibility problems. [Relative Priority]

Rationale: Authors may not notice or be able to identify accessibility problems.

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

Success Criteria: (updated 22 July)

  1. The tool must provide a check ( automated check, semi-automated check or manual check) for detecting violations of each requirement of WCAG.
3.3 Assist authors in repairing accessibility problems. [Relative Priority]

Rationale: Assistance may expedite the task of correcting some authors' accessibility problems, while other authors may be unable to correct accessibility problems without this help.

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

Success Criteria: (updated 22 July)

  1. The tool must provide a repair (automated repair, semi-automated repair or manual repair) for correcting violations of each requirement of WCAG.

Specific considerations when providing this guidance

Note: This is proposed text.
When guiding the author towards the creation of accessible content, several specific factors should must be considered. The checkpoint requirements for this section include taking care not to automatically include inappropriate equivalent alternatives (Checkpoint 3.4), providing automated means for managing equivalent alternatives (Checkpoint 3.5), and providing accessibility status summaries (Checkpoint 3.6).

3.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

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: (updated 22 July)

  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 alternative equivalents for multimedia objects. [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: (updated 22 July)

  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.
3.6 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: This summary will prompt the author to: improve the accessibility status; keep track of problems; and monitor progress.

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

Success Criteria: (updated 22 July)

  1. The tool must provide the author with an option to view a listing of all current accessibility problems.

Promoting accessibility in help and documentation:

Note: This is proposed text.
Because authors are likely to differ widely in their familiarity with Web content accessibility issues, the help and documentation of the authoring tool must address several types of use. The checkpoint requirements for this section include documenting accessible content promoting features (Checkpoint 3.7), ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint 3.8), and including suggested workflow instructions for using the tool to produce accessible content (Checkpoint 3.9).

3.7 Document all features of the tool that promote the production of accessible content. [Priority 1]

Rationale: Without documention 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: (updated 22 July)

  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 authors must look somewhere special for information on accessible authoring practices, they may be unlikely to make the effort. Familiarity with these practices will be promoted by their integration.

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

Success Criteria: (updated 22 July)

  1. All examples of markup code and views of the user 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]Note: The term "workflow" still needs definition.

Rationale: Authors will be more likely to use features that promote accessibility if they understand when and how to use them.

Techniques: Techniques for checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9

Success Criteria: (updated 22 July)

  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 that feature.

GUIDELINE 4: Promote and integrate accessibility solutions

Note: This is proposed text.
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 the availability of accessibility-related functions (Checkpoint 4.1), ensuring the priority for accessible means of completing for an authoring tasks (Checkpoint 4.2) and ensuring that accessibility-related functions fit into the overall look and feel of the tool (Checkpoint 4.3).

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

Success Criteria: (updated 22 July)

  1. When a tool provides a means for markup to be added with a single mouse click or keystroke, that markup must meet the requirements of WCAG unless the markup was authored "by hand".
  2. When an authoring action has several markup implementations (e.g. changing the color of text with presentation markup or style sheets), those markup implementation(s) that meet the requirements of WCAG must be equal to or higher on all of the following scales than those markup implementations that do not meet the WCAG requirements:
    • Prominence of location (in "power tools" such as floating menus, toolbars, etc.)
    • Position in layout (top to bottom and left to right in menus, dialog boxes, etc. )
    • Size of control (measured as screen area)
    • Actions to activate (number of mouse clicks or keystrokes)
4.2 Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 1]

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.1, Evaluation Techniques for Checkpoint 4.1

Success Criteria:

  1. Continuously active processes (e.g. a checker that underlines errors as they occur, a checker that activates at a save, a checker that 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. User-initiated processes (e.g. a checker that the user requests each time) that implement functions required by checkpoints 3.1, 3.2, 3.3 and 3.7 must be available to the author at *all times during authoring* with no more steps than other *high-priority functions*.
  4. When the functions required by checkpoints 3.1, 3.2, 3.3 and 3.7 are combined with other authoring functions (e.g. an accessibility-related field in a general purpose dialog box), the resulting design must include all accessibility-related functions in the top level of the combined user interface.
4.X Ensure that accessible authoring practices are integrated into the overall workflow when an author develops Web Content. (Priority 2) [@@ed. new checkpoint - text by JT - needs approval@@]

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.

Success Criteria:

  1. ??? Jutta & Wendy Action Item
4.4 Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into appearance and interactive style of the tool. [Priority 2 or 3?]

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

Techniques: Implementation Techniques for Checkpoint 4.3, Evaluation Techniques for Checkpoint 4.3

Success Criteria: (updated 22 July)

  1. The mechanisms for accessibility prompting, checking, repair and documentation must be similar to comparable mechanisms in terms the following characteristics:
    • visual design (design metaphors, artistic sophistication, sizes, fonts, colors)
    • operation (degree of automation, number of actions for activation
    • configurability (number and types of features

 

USABILITY STUDY OVERRIDE FOR GUIDELINE 4

 

 

 

 

3. Glossary of Terms and Definitions

Accessibility (Also: Accessible)
Within these guidelines,"accessible Web content" and "accessible authoring tool" mean that the content and tool can be used by people regardless of disability. To understand the accessibility issues relevant to authoring tool design, consider that many authors may be creating content in contexts very different from your own:
  • They may not be able to see, hear, move, or may not be able to process some types of information easily or at all;
  • They may have difficulty reading or comprehending text;
  • They may not have or be able to use a keyboard or mouse;
  • They may have a text-only display, or a small screen.
Accessible design will benefit people in these different authoring scenarios and also many people who do not have a physical disability but who have similar needs. For example, someone may be working in a noisy environment and thus require an alternative representation of audio information. Similarly, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs as some users with disabilities.
Accessibility Information
"Accessibility information" is content, including information and markup, that is used to improve the accessibility of a document. Accessibility information includes, but is not limited to, equivalent alternative information.
Accessibility Problem (Also: Inaccessible Markup)
Inaccessible Web content or authoring tools cannot be used by some people with disabilities. The Web Content Accessibility Guidelines 2.0 [ WCAG20] describes how to create accessible Web content.
Accessible Authoring Practice
"Accessible authoring practices" improve the accessibility of Web content. Both authors and tools engage in accessible authoring practices. For example, authors write clearly, structure their content, and provide navigation aids. Tools automatically generate valid markup and assist authors in providing and managing appropriate equivalent alternatives.
Alert
An "alert" draws the author's attention to an event or situation. It may require a response from the author.
Alternative Information (Also: Equivalent Alternative)
Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. Equivalent alternatives play an important role in accessible authoring practices since certain types of content may not be accessible to all users (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 2.0 [ WCAG20].
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.
Authored "by hand"
When the author specifies the precise text string, as by typing into a text editor.
Authoring Tool
Any software or service that authors may use to create or modify Web content. This includes software that enables authors to perform any of the following functions:
1. Text Editing: Authors manipulate plain text data (e.g. markup text, program code, etc.). [ Example 1]
2. Symbol-Level Editing: Authors manipulate symbols (not WYSIWYG renderings) that represent low-level functional groups in the underlying plain text data (e.g. symbols in place of markup elements, programming code operations, multi-element placeholder, etc.) .[ Example 2]
3. WYSIWYG Editing: Authors manipulate browser-like renderings of the underlying plain text data (e.g. rendered text, images, etc. in place of markup elements). [ Example 3]
4. Graphics Editing: Authors manipulate renderings of object-oriented graphics (e.g. rendered lines, etc. in place of markup elements in a drawing program, animation tool stage, etc.). [ Example 4]
5. Content Management: Authors exercise control of changes to Web content across whole documents or groups of documents, rather than at the level of individual instances of content (e.g. site building wizards, site management tools, courseware, content aggregators, etc.). [ Example 5]
6. Constrained Editing: Authors make highly constrained inputs that are structured and styled according to static templates (e.g. guest books, message boards, etc.). [ Example 6]
7. Timeline Editing: Authors manipulate time-dependent Web content (e.g. animation, music, etc.) using a user interface that represents a series of frames. [ Example 7]
8. Format Conversion: Authors are assisted in causing Web content encoded in one format to become encoded in another (e.g. saving Web content created in one format in a different format, importing Web content from a different format, etc.) [ Example 8]
Captions
"Captions" are essential text equivalents 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.
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).
Check for
As used in checkpoint 4.1,"check for" can refer to three types of checking:
  1. In some instances, an authoring tool will be able to check for accessibility problems automatically. For example, checking for validity ( checkpoint 2.2) or testing whether an image is the only content of a link.
  2. In some cases, the tool will be able to "suspect" or "guess" that there is a problem, but will need confirmation from the author. For example, in making sure that a sensible reading order is preserved a tool can present a linearized version of a page to the author.
  3. In some cases, a tool must rely mostly on the author, and can only ask the author to check. For example, the tool may prompt the author to verify that equivalent alternatives for multimedia are appropriate. This is the minimal standard to be satisfied. Subtle, rather than extensive, prompting is more likely to be effective in encouraging the author to verify accessibility where it cannot be done automatically.
Document
A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML application).
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.
Inform
To "inform" is to make the author aware of an event or situation through alert, prompt, sound, flash, or other means.
Markup Language
Authors encode information using a "markup language" such as HTML [HTML4], SVG [ SVG], or MathML [ MATHML].
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.
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 guidelines 4, 5, 6. 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.
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.
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.
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.

4. Acknowledgments

Many thanks to the following people who have contributed through review and comment: Giorgio Brajnik, Daniel Dardailler, Katie Haritos-Shea, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Liddy Nevile, Matthias Müller-Prove, Graham Oliver, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Carlos Velasco.

This document would not have been possible without the work of those who contributed to The Authoring Tool Accessibility Guidelines 1.0

5. References

For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR.

[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.
[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.
[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/.
[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.
[WCAG-REFS]
ATAG 2.0 References to WCAG, J. Treviranus, J. Richards, and M. May, editors.
[WOMBAT-CHECKLIST]
Not available.
[WOMBAT-TECHS]
" Implementation Techniques for Authoring Tools Accessibility Guidelines 'Wombat'," Jutta Treviranus, Charles McCathieNevile, Jan Richards, Matt May. Note: ATAG20-TECHS supersedes this document. .
[ATAG20-TECHS]
" Implementation Techniques for Authoring Tools Accessibility Guidelines 2.0," Jutta Treviranus, Charles McCathieNevile, Jan Richards, Matt May. Note: This document is still a working group draft.
[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.

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