Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0

For further information about Working Group decisions, please consult the minutes of AUWG Meetings.

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.

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.

A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR.

Introduction

This document has been divided into a multi-part hypertext document to keep individual pages to a manageable size. There are publishing conventions used to identify various features and parts of the document. Some of these will be used to provide multiple views of the techniques - for example implementation techniques for a particular kind of tool, or references for particular techniques. Other conventions are used to ensure that this document is compatible with ATAG version 1.0 or will be compatible with ATAG wombat with a minimum of difficulty or change.

Implementation Technique Listings

Guideline 1: Ensure that the tool itself is accessible

• Techniques for checkpoint 1.1: Ensure that the authoring interface follows applicable software accessibility guidelines.[ISO16071 Relative Priority]
• Techniques for checkpoint 1.2: Ensure that the authoring interface enables accessible editing of element and object properties. [ISO16071 Relative Priority]
• Techniques for checkpoint 1.3: Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]
• Techniques for checkpoint 1.4: Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]
• Techniques for checkpoint 1.5: Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

Guideline 2: Enable the production of accessible content

• Techniques for checkpoint 2.1: Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]
• Techniques for checkpoint 2.2: Support formats that enable the creation of WCAG-conformant content. [Priority 2].
• Techniques for checkpoint 2.3: Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
• Techniques for checkpoint 2.4: Ensure that the tool preserves all unrecognized markup and accessibility information during transformations, and conversions. [Priority 1]
• Techniques for checkpoint 2.5: Ensure that when the tool automatically generates content it conforms to the WCAG.[WCAG Relative Priority]
• Techniques for checkpoint 2.6: Ensure that all pre-authored content for the tool conforms to WCAG. [WCAG Relative Priority]

Guideline 3: Support the production of accessible content

• Techniques for checkpoint 3.1: Prompt and assist the author to create accessible content. [Relative Priority]
• Techniques for checkpoint 3.2: Check for and inform the author of accessibility problems. [Relative Priority]
• Techniques for checkpoint 3.3: Assist authors in repairing accessibility problems. [Relative Priority]
• Techniques for checkpoint 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]
• Techniques for checkpoint 3.5: Provide functionality for managing, editing, and reusing equivalent alternatives for multimedia objects. [Priority 3]
• Techniques for checkpoint 3.6: Provide the author with a summary of the document's accessibility status. [Priority 3]
• Techniques for checkpoint 3.7: Document all features of the tool that promote the production of accessible content. [Priority 1]
• Techniques for checkpoint 3.8: Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 2]
• Techniques for checkpoint 3.9: Document the workflow process of using the tool to produce accessible content. [Priority 3]

Guideline 4: Integrate accessibility content related features

• Techniques for checkpoint 4.2 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]
• Techniques for checkpoint 4.3 Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 2]
• Techniques for checkpoint 4.X Ensure that accessibility prompting, checking, repair and documentation functions are configurable [Priority 2]
• Techniques for checkpoint 4.1. Ensure that accessibility prompting, checking, repair functions and documentation are integrated into the workflow of Web Content development. [Priority 2]
• Techniques for checkpoint 4.4 Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the appearance and interactive style of the tool. [Priority 3]

Other technique documents

References

Applicability of Techniques to Different Kinds of Authoring Tools

The techniques are applicable to all kinds of authoring tools, including those that are insertable components of other authoring tools. For example, if an authoring tool for designing on-line courses (courseware) has a prefabricated chat facility that the instructor can drag on to their page, this component must comply with all the techniques for accessible authoring interface (guideline 1) and accessible Web content output (guidelines 2-4).

Authoring tool categories

Note: For the purposes of these techniques, authoring tools may fall into one or more of the following categories. For example, an HTML authoring tool that has both a text editor and a "browser" view will fall under two categories, Code-level Authoring Functions and WYSIWYG Authoring Functions.

1. Code-level Authoring Functions: Author has full control over all aspects of the resulting Web content that have bearing on the final outcome. This covers, but is not limited to plain text editing, as this category also covers the manipulation of symbolic representations that are sufficiently fine-grained to allow the author the same freedom of control as plain text editing (e.g. graphical tag placeholders).
   Examples: Text editors, text editors enhanced with graphical tags, etc.
2. WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Author has control over entities that closely resemble the final appearance and behaviour of the resulting Web content.
   Examples: Rendered Web page editors, bitmap graphics editors, etc.
3. Object Oriented Authoring Functions: Author has control over non-WYSIWYG entities that represent a functional abstraction from the low level aspects of the resulting Web content.
   Examples: timelines, waveforms, vector-based graphic editors, etc.
4. Indirect Authoring Functions: Authors have control of only high-level parameters related to the automated production of the resulting Web content.This may include interfaces that assist the author to create and organize Web content without the author having control over the markup or programming implementation.
   Examples: Content managment systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators and conversion tools, etc

Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References