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 Ensure that the authoring interface enables the author to edit the structure of the document.
    • 1.4 Allow the display preferences of the authoring interface to be changed without affecting the document markup.
    • 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 user
    • 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.
[@@issue 7 there is no minimum requirement here]

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

Note This checkpoint is a special case of checkpoint 1.1 that is especially important to authoring tools.

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 Ensure that the authoring interface enables the author to edit the structure of the document [Priority 2]

Note This checkpoint is a special case of checkpoint 1.1 that is especially important to authoring tools.

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

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.4 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Note: This checkpoint applies primarily to WYSIWYG markup editing tools and requires that the author be able to view the content, as it is being authored, in a way that differs from the presumed default appearance of the rendered content.

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

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. [@@Issue 8 - 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.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure. [Priority 2]

Rationale: simplify navigation for the author.

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. [@@Issue 9: 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 facilitate author navigation of content as it is being authored. Most markup editing tools will already provide a search function, other authoring tools (i.e. multimedia editors, etc.) may not. The purpose of this checkpoint is to encourage authoring tool developers to include search functions into their tools in order to facilitate navigation of the content as it is authored. This search capability may be as simple as a string matching "find" function in a basic text editor or as complex as search functions that take advantage of the structure (elements, attributes, etc.) inherent in marked-up content.

As this is a checkpoint within Guideline 1 (Ensure that the Authoring Tool is Accessible to Authors with Disabilities) there is one other implicit requirement: that is that 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).

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.

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: Many of the W3C language recommendations have been designed with accessibility as a goal. In addition, the W3C has published Notes for some of its most popular language recommendations, describing best use practices. As a result, building accessibility-aware authoring tools for W3C languages should be easier than for other language formats that lack these supports.

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: The most basic support for accessibility is ensuring that it is at least possible for the author to produce accessible content. Without this posssibility, further efforts are futile. The simplest way to assure this possibility exists is to allow authoring "by hand", so that well-informed authors can work around any accessibility shortcomings in the automatic generation of markup. Tools that only generate markup automatically must ensure the accessibility of all generated markup in order to meet this requirement.

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: Once an author has made the effort to add accessible content, either manually or with the aid of the authoring tool, he or she does not wish to discard that content when converting (i.e. taking content encoded in one markup language and re-encoding it in another) or transforming it (i.e. modifying the encoding of content without changing the markup language). Note: Differences in grammatical richness must be taken into account, between markup languages in the case of conversions, and between markup entities in the case of transformations.

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. If the tool includes checking and correction features, the author must use them or others to correct errors which were completely under the control of the tool. If the tool does not include checking and correction tools, the result is almost certainly WCAG non-conformant documents.

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 is included with authoring tools for the convenience of the author. Including WCAG conformant pre-authored content increases that convenience by (1) ensuring that authors can use any of the content without concern for the accessibility implications and (2) prevents each individual author from having to compose their own version of alternative content when this task could have been done just once by the distributor. Pre-authored content may include accessible markup and content for templates, alt text, long descriptions for images, captions, auditory descriptions and collated text transcriptions for multimedia objects, and accessible design and functional alternatives for applets and scripts, etc.

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 the users of the tool, 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 users to decide whether to check syntax during editing or at compilation.

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

Rationale: Appropriate assistance should result in typical tool users following accessible authoring practices. Different tools will accomplish this goal in ways appropriate to their products, processes and users.

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: Once accessibility problems are present, a means of detecting them will be necessary.

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: Once accessibility problems have been found, authors may need help to correct them properly.

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 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 a 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: encourage authoring tools to notify authors of accessibility problems in a coherent way.

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: As with any feature, documentation of all the accessibility related features of the tool (dialog boxes, utility, code views, etc.) will facilitate authors in finding and using them effectively.

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 the accessibility features of the tool effectively if they have a workflow strategy for integrating the new accessibility related tasks into the Web content authoring that they already perform.

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.5 and 3.6 are always clearly available to the user [Priority 1]

Rationale: The user must be easily able to turn on accessibility support functionality.

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: For accessibility-related functionality to be accepted by authors, it must be integrated as seamlessly as possible.

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 all 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: User interfaces can increase the probability that authors will use accessible authoring practices, even when less accessible alternatives are provided by the tool for reasons of completeness.

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 creating accessible content is a naturally integrated part of the documentation, including examples. [Priority ?] [@@ No longer relative - suggested P2]

Rationale: This checkpoint promotes the production of accessible content by implicitly demonstrating to the author that all content, regardless of purpose, should comply with the WCAG guidelines.

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

An "authoring tool" is any software that is used to produce content for publishing on the Web. Authoring tools include:

• Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors);
• Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages);
• Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML);
• Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages);
• Tools for site management or site publication, including tools that automatically generate Web sites dynamically from a database, on-the-fly conversion and Web site publishing tools;
• Tools for management of layout (e.g., CSS formatting tools).

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.