Authoring Tool Accessibility Guidelines 2.0

W3C Working Draft 14 March 2003

This version:

http://www.w3.org/TR/2003/WD-ATAG20-20030314/

Latest version:

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

Editors:

Jutta Treviranus - ATRC, University of Toronto

Charles McCathieNevile

Jan Richards - University of Toronto

Matt May - W3C

Copyright © 2003 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

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

• Abstract
• Status of this document
• 1. Introduction
  • 1.1 How the Guidelines are organized
  • 1.2 Checkpoint Priorities
  • 1.3 Conformance to these Guidelines
• 2. Guidelines
  • Guideline 1: Ensure that the tool itself is accessible
    • 1.1 Ensure that the authoring interface follows all operating environment conventions that benefit accessibility.
    • 1.2 Ensure that the authoring interface enables accessible editing of all element and object properties.
    • 1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup.
    • 1.4 Ensure that the authoring interface enables the author to edit the structure of the document.
    • 1.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure.
    • 1.6 Ensure the authoring interface allows the author to search within the editing views.
  • Guideline 2: Ensure that the tool is designed to produce accessible content
    • 2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task.
    • 2.2 Ensure that markup which the tool automatically generates is valid for the language the tool is generating.
    • 2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool.
    • 2.4 Ensure that the tool preserves all accessibility information during transformations and conversions.
    • 2.5 Ensure that when the tool automatically generates content it conforms to WCAG.
    • 2.6 Ensure that all pre-authored content for the tool conforms toWCAG.
    • 2.7 Allow the author to preserve markup not recognized by the tool.
  • Guideline 3: Support the author in the production of accessible content
    • 3.1 Prompt and assist the author to avoid accessibility problems when they add or edit content.
    • 3.2 Check for and inform the author of accessibility problems.
    • 3.3 Assist authors in correcting accessibility problems.
    • 3.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty.
    • 3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects.
    • 3.6 Provide the author with a summary of the document's accessibility status.
    • 3.7 Document all features of the tool that promote the production of accessible content.
    • 3.8 Document the process of using the tool to produce accessible content.
  • Guideline 4: Integrate accessibility solutions into the overall "look and feel"
    • 4.1 Ensure that the functionalities for checkpoints 3.1, 3.2, 3.5 and 3.6 are always clearly available to the author
    • 4.2 Ensure that accessible authoring practices supporting the minimum requirements for all WCAG checkpoints are among the most obvious and easily initiated by the author.
    • 4.3 Ensure that all functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool.
    • 4.4 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples.
• 3. Glossary of Terms and Definitions
• 4. Acknowledgments
• 5. References

1.3 How this document is organized

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

• Guideline 1: Ensure that the tool itself is accessible
• Guideline 2: Ensure that the tool is designed to produce accessible content
• Guideline 3: Support the author in the production of accessible content
• Guideline 4: Integrate accessibility solutions into the overall "look and feel"

Each guideline includes:

• The guideline number
• The statement of the guideline
• The rationale behind the guideline
• A list of checkpoints

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:

• The checkpoint number
• The statement of the checkpoint
• The priority of the checkpoint
• Checkpoint subtext, including:
  • a brief rationale for the checkpoint
  • a minimum basic functionality requirement that is normative
  • suggested functionality for more advanced implementation (this is optional)
  • references to further information and techniques

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.

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.

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.

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.

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

An authoring tool is a software program with standard user interface elements and as such must be designed according to relevant user interface accessibility guidelines. When custom interface components are created, it is essential that they be accessible through the standard access mechanisms for the relevant platform so that assistive technologies can be used with them.

Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document.

Authoring tools must also ensure that the author can navigate a document efficiently while editing. Authors who use screen readers, refreshable Braille displays, or screen magnifiers can make limited use (if any) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (especially people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation.

Note: Documentation, help files, and installation are part of the software and need to be available in an accessible form.

1.1 Ensure that the authoring interface follows all operating environment conventions that benefit accessibility. (This applies at three priority levels: [Priority 1] for standards and conventions that are essential to accessibility; [Priority 2] for those that are important to accessibility; [Priority 3] for those that are beneficial to accessibility.)

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:

This checkpoint requires all aspects of the authoring interface to be accessible to the author. The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. In many cases several sets of standards will be applicable.
http://www.w3.org/WAI/AU/wombatissues.html#issue7 there is no minimum requirement here]

1.2 Ensure that the authoring interface enables accessible editing of all 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: provide at least one accessible way to edit every element and object property supported by the tool.

1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1] @@THIS WAS 1.4@@

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: there must be some mechanism for changing the document display independently of the document markup.

There are a number of ways that this can be achieved, including supporting operating environment display preferences and allowing the author to specify an editing style sheet that is different from those included with the published document. In addition, there must be some means by which textual alternatives can be displayed to the author in place of non-text elements. http://www.w3.org/WAI/AU/wombatissues.html#issue8 - need to clean this paragraph up - some is techniques, plus wording and some is useful for the checkpoint]

Although there are many ways this can be achieved, there must be one way for the author to change the display of the content during authoring in a way that differs from the most likely rendering of the content.The author must be able to access the text alternatives in the place of any non-text elements.

1.4 Ensure that the authoring interface enables the author to edit the structure of the document [Priority 2] @@THIS WAS 1.3@@

Rationale:
@@JT's proposed text>@@ When using a screen reader, screen magnifier, on-screen keyboard or Braille display it is very difficult to get an overview of the document. Items are viewed and controlled sequentially at the
lowest level. To effectively edit a document, authors require the ability to flexibly collapse the document so that chunks of the document can be edited, moved or deleted at a less granular level.
@@JR's proposed text>@@ When documents are well structured, they are often easier to navigate for both the author (see Checkpoint 1.5) and the end-user. However, because some assistive technologies (e.g. screen reader, screen magnifier, on-screen keyboard, Braille display, etc.) may make it difficult to view the document as a whole, additional supports (e.g. a document trees display, etc.) are useful.

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

Success Criteria: the checkpoint requires that the author be able to copy, cut or paste an element and its content at any level of the document tree hierarchy and retain the content's hierarchical level.

1.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure. [Priority 2]

Rationale: Structure-based navigation should be provided to allow authors using screen readers, Braille displays, or keyboard alternatives to move quickly and accurately through appropriately structured documents.

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

Success Criteria: the author should be able to move from element to element. http://www.w3.org/WAI/AU/wombatissues.html#issue9: is this actually what we need?]

The author must be able to access the means to navigate the content via the document structure.

1.6 Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

Rationale: Search functions, such as simple string matching or more complex mechanisms that take advantage of the structure (elements, attributes, etc.) inherent in marked-up content, facilitate author navigation of content as it is being authored.@@check with group@@

Techniques: Implementation Techniques for Checkpoint 1.6, Evaluation Techniques for Checkpoint 1.6

Success Criteria:

The author must be able to access one way to search the content being authored and quickly move the editing focus to the occurrences.

The tool should allow basic text search with a choice of skipping or including markup.

The search function must able to move the editing focus immediately to the occurrences that it finds (one at a time s requested by the author)

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

The most basic determinant of the accessibility of Web content is the degree to which the authoring tool that produced it gives priority to markup validity and accessibility. Tools that generate and preserve high quality markup are well prepared to meet the other guidelines.

Generating standard markup:

Conformance with standards promotes interoperability and accessibility by making it easier to create specialized user agents that address the needs of users with disabilities. In particular, many assistive technologies used with browsers and multimedia players are only able to provide access to Web documents that use valid markup. Therefore, valid markup is an essential aspect of the accessibility compliance of an authoring tool.

Where applicable use W3C Recommendations, which have been reviewed to ensure accessibility and interoperability and which are relied upon by assistive technology developers. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.

2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]

Rationale: The W3C has implemented an accessibility review process for language recommendations that has resulted in addition of supports for accessibility within many of these languages as well as published Notes describing best use practices for some of the most popular languages. Because this process is ongoing, more recent versions of W3C language recommendations are likely to include better supports for accessibility than older ones. @@check with group@@

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

Success Criteria:

1. Provide an accessible reading of web content in available, relevant W3C recommended language format and provide accessible means for editing and writing in that language format.
2. The tool may use non-W3C formats in addition to the W3C Recommendations.
3. A W3C Recommendation is considered available to a specific version of an authoring tool, if the Recommendation has reached the Candidate Recommendation phase at least two (2) years before the version of the tool in question is released for use.
4. Whether a W3C Recommendation is appropriate depends on the features of the tool. Critical relevance criteria will depend on the task, but may include support for media, scripting, or styling. When comparing the appropriateness of W3C recommendations with other, non-W3C formats for a particular task, accessibility must be included as a comparison criteria.
5. Inform the author in marketing, packaging and other documentary material of the name and version of any W3C Recommendations used. This notice must specify whether the conformance with the Recommendation is full or partial.

2.2 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:

1. All markup strings written by the tool are valid as defined by the relevant W3C Recommendation or other format specification. This does not apply where the markup itself has been authored "by hand".
2. Markup strings that the tool writes as a result of the author selecting elements or attributes by name from lists, toolbar buttons, etc. are valid as defined by the relevant W3C Recommendation or other format specification.

Supporting accessible authoring practices:

If the tool automatically generates markup, many authors will be unaware of the accessibility status of the final content unless they expend extra effort to review it and make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, authoring tools are responsible for automatically generating accessible markup, and where appropriate, for guiding the author in producing accessible content.

Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format specifically intended for the Web such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. It is essential that these processes do not introduce inaccessible markup or remove other content intended to increase accessibility, particularly when a tool hides the markup changes from the author's view.

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:

1. A method for authoring "by hand" is provided (e.g. code editing view).

If authoring "by hand" is not provided then:

1. Tools that provide the author with choice as to how content will be marked up, must ensure accessible alternatives to every inaccessible choice.
2. Tools that generate content automatically always generate accessible markup. (In other words, the tool meets Checkpoint 2.5 to Relative Priority Level 3).

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:

1. When transformations or conversions move content from grammatically-rich to grammatically-poor languages or markups entities, the structure of the content may be flattened to the point where it is insufficient to allow the reversal of the transformation. The tool must utilize as much structural richness of the target language or markup entity as is possible.
2. When reversal of the transformation is not possible, the author is notified prior to the conversion or transformation.
3. Equivalent alternatives (e.g. labels, descriptions, etc.) are preserved during every transformation or conversion and is still available and useful for the purpose of providing equivalent information for the non-text element.
4. Structural information (e.g. heading, etc.) is preserved during every transformation or conversion and is still available and useful for navigation.
5. Separation of content from presentation is preserved during every transformation or conversion and is still separate from presentation to the degree possible in the new format.

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:

1. All markup strings written by the tool are accessible as defined by WCAG (see Note on Relative Priority), unless the markup has been authored "by hand".
2. Markup strings that the tool generates from author selections of elements and attributes by name (e.g. from lists. etc.) are accessible as defined by WCAG (see Note on Relative Priority).
3. This applies to the choice of markup type, file type, and markup practices.
4. The tool may provide the author with the option of disabling or altering the accessible defaults.

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:

1. All Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc) included with distribution of the tool or provided preferentially to @@authors using the tool@@CHANGED@@, must conform to WCAG (see Note on Relative Priority). Preferential offerings include those in the distribution file or media as well as those offered by the developer or its partners to which authors not using the tool would not have access, e.g., free clip art for registered owners.
2. Objects that require alternative descriptions (see WCAG) have this information stored internally (e.g. as text tracks) or externally (e.g. as files, database entries in a management system - see Checkpoint 3.4, etc.).

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.

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

Success Criteria:

1. All well-formed markup is preserved.
2. The author is queried for their consent before any unrecognized markup is removed or changed.

It is acceptable for a tool to refuse to open a document that contains markup that it cannot process, but that the author chooses to retain.

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:

Conformance with accessibility authoring practices is an authoring constraint that is little different, in principle, from the constraint to produce valid code or grammatical text. Since the role of 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. For example, tools may assist authors to follow specific practices by suggesting accessible authoring practices or prompting for information that cannot be generated automatically, such as equivalent alternatives (alternate text, descriptions, captions, etc.).

Many authoring tools already allow authors to create documents with little or no need for knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction when either the markup is hidden from the author or the author does not know how to correct it.

Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can choose how to configure the tool's accessibility features to support their regular work patterns are more likely to feel comfortable with their use of the tool and be receptive to interventions from the tool. (see guideline 4). 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. This choice is analogous to that offered in programming environments that allow authors to decide whether to check syntax during editing or at compilation.

3.1 Prompt and assist the author to avoid creating accessibility problems when they add or edit content. [Relative Priority]

Rationale: Appropriate assistance should increase the likelihood that typical users of the tool 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:

1. The authoring tool suggests accessible authoring practices where appropriate.
2. The authoring tool prompts (Important Definition) the typical author for information that cannot be generated automatically (e.g. equivalent alternatives (see Checkpoint 3.4).
3. Prompt may be combined with checking and repair, but must be made available to the author at least once prior to completion of authoring.

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:

1. Must provide at least one check (automated, semi-automated or manual) for each requirement of WCAG [WCAG].
2. A typical author is made aware of accessibility problems within the document.

3.3 Assist authors in correcting 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:

1. Context-sensitive help, semi-automated repairs or fully automated repairs are provided for each requirement of WCAG [WCAG].
2. A typical author is able to successfully correct any identified accessibility problem.

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:

1. For new non-text objects, the tool prompts the author to enter an appropriate equivalent alternative without providing a generated default entry.
2. Only an alternative that has been explicitly associated with an object is offered as a default entry for the author to approve.
3. In content authored by the typical author, there are no improperly generated alternatives.

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:

1. The tool recognizes when non-text objects have previously-authored alternative equivalents.
2. A typical author is able to reuse these previously-authored authored alternative equivalents when non-text objects are reused.

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:

1. A listing of the current accessibility problems is available.
2. From the summary, the typical author will be to tell whether their content meets the accessibility standard in question.

Promoting accessibility in help and documentation:

Some Web authors may not be familiar with accessibility issues that arise when creating Web content, while others may be authors familiar with these issues, but may not know how the tool can help to address them. Therefore, help and other supplied documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.

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:

1. All features that help create accessible content are documented in the help system.
2. A typical author, following a review of help and other supplied documentation will be aware of and able to use features of the tool that promote accessibility.

3.8 Document the process of using the tool to produce accessible content. [Relative Priority]

Rationale: Authors will be more likely to use features that promote accessibility, if they can integrate them into their existing authoring practices.

Techniques: Techniques for checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8

Success Criteria:

1. The documentation contains sample or suggested workflows which, if followed, are likely to increase the chance of higher levels of WCAG conformance than otherwise. This should include the name and nature of the features and when and how they should be used.
2. For tools that lack a particular accessibility-related feature, this workflow strategy will contain workarounds that are likely to achieve the same result.
3. A typical author should be able to find and understand this workflow documentation.

GUIDELINE 4: Integrate accessibility solutions into the overall "look and feel"

When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool.

4.1 Ensure that the functionalities for checkpoints 3.1, 3.2, 3.3 and 3.4 are always clearly available to the author [Priority 1]

Rationale: If the features that support accessibility authoring are difficult to find, activate or use, 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

See Also: ATAG Checkpoints 3.1, 3.2, and 3.3.

Success Criteria:

1. If accessibility-related functionalities (see Checkpoint 3.1, Checkpoint 3.2, and Checkpoint 3.3) are not already active by default, the mechanism for activating them must be available to the author: (1) at all times during authoring and (2) at most, one level down in the user interface (e.g. in the first level of a drop-down menu).
2. The configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functionalities must be designed so that (1) authors searching for the configuration mechanism will find it easily and (2) authors performing general configuration tasks will readily notice the configuration mechanism.
3. When these accessibility-related functionalities are combined with other functionalities in an authoring mechanism (i.e. one accessibility-related field in a general purpose dialog box), the design must allow (1) authors searching for the functionality to find it easily and (2) authors performing the other general purpose tasks to readily notice the functionality.

4.2 Ensure that accessible authoring practices supporting the minimum requirements for all WCAG checkpoints are among the most obvious and easily initiated by the author. [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:

1. When an authoring action does not necessarily demand a particular markup implementation (ex. changing the color of text), the markup implementation(s) that meet the minimum requirements of WCAG must have at least the same user interface visibility and at least the same ease of function activation (in terms of mouse clicks and keystrokes) as markup implementations that do not meet those requirements.
2. Whenever a tool provides a means for markup (that has not be authored "by hand") to be added into a document by one mouse click or keystroke, that markup must meet the minimum requirements of WCAG.

4.3 Ensure that any functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]

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:

1. The accessibility-related functionalities do not contrast with analagous functionality in the normal operation of the tool. For example, an accessibility checker is analagous to a spell checker, while a prompt for a accessibility-related label is analagous to a prompt for a document title. The following factors must be considered: (1) Visual Design: Design metaphors, artistic sophistication, sizes, fonts, colours, (2) Operation: The degree of automation, the approximate number of mouse clicks or keystrokes, (3) Complexity: The amount of author instruction required, and (4) Flexibility: The configurability of the functionality and its features.
2. The separation of accessibility-related functionalities from the normal authoring process, should be minimized.

4.4 Ensure that accessible authoring practices are integrated into documentation, including examples. [Priority ?] [@@ No longer relative - suggested P2]

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

Success Criteria:

1. All markup code examples must meet all requirements of WCAG, regardless of the purpose of the example.
2. Only the WCAG requirements appropriate to code segments of the content section in question are required. For example, no navigation mechanism is required for an example comprised of only one element,
3. All examples of the authoring tool interface, including screenshots of dialog boxes, code views, etc., included within the documentation must not violate any of the requirements of WCAG, regardless of the purpose of the example. For example, a screenshot of an image properties dialog that has been cropped so as to include a field for a short descriptive text label must ensure a text label is added to that field.

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 for publication. This includes software that enables authors to perform any of the following functions:@@check with group@@
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.