Contents | Part A | Part B | References

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0

Editor's Draft 11 July 2006

This version:
http://www.w3.org/WAI/AU/2006/WD-ATAG20techs-20060711/WD-ATAG20techs-20060711.html
Latest version:
http://www.w3.org/WAI/AU/2006/techs/techs.html
Editors:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto
Tim Boland - NIST

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

Abstract

This document provides non-normative information to authoring tool developers who wish to satisfy the checkpoints of "Authoring Tool Accessibility Guidelines 2.0" [ATAG20]. It includes suggested techniques, sample strategies in deployed tools, and references to other accessibility resources (such as platform-specific software accessibility guidelines) that provide additional information on how a tool may satisfy each ATAG 2.0 checkpoint.

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. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The Working Group (AUWG) intends to publish Implementation Techniques for ATAG 2.0 as a W3C Note.

The Working Group expects to update this document in response to queries raised by implementers of the Guidelines, for example to cover new technologies. Suggestions for additional techniques are welcome.

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the Working Group are discussed in the Working Group charter. The AUWG is part of the WAI Technical Activity.

1. Introduction

You are reading the Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0). While the guidelines provide a generic description of the requirements for authoring tools that are accessible to people with disabilities, these implementation techniques provide an interpretation of the guidelines as they apply to real tools. This interpretation represents the best thinking of the Authoring Tool Accessibility Guidelines Working Group (AUWG) and as such is a good guide to achieve conformance to ATAG 2.0. The Working Group encourages developers to implement these techniques where appropriate. However, these techniques do not provide a final definition of ATAG conformance and it is possible to meet guideline requirements without following these techniques and thus this document is informative. As new methods of conforming to the guidelines come to the attention of the Working Group, these techniques will be updated.

Note on examples: For illustrative purposes, the techniques document includes examples, many containing mock screenshots (the mock screenshots have all been created by the Working Group to avoid being seen to favor a particular product). While the examples have been chosen to be as informative as possible, many of them are specific to certain types of authoring tool functions. In order to assist developers in determining the relevance of the examples to the different categories, each is marked with one or more of the following category icons (Note: A particular tool may fall more than one category. For example, an HTML editor might have both a code-level editing view and a WYSIWYG editing view):

  1. Applicable to Code-Level authoring functions Code-level Authoring Functions: Authors have 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, some wikis, etc.
  2. Applicable to 'what you see is what you get' authoring functions WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Authors have control over entities that closely resemble the final appearance and behavior of the resulting Web content. Examples: rendered document editors, bitmap graphics editors, etc.
  3. Applicable to Object-Oriented authoring functions Object Oriented Authoring Functions: Authors have control over functional abstractions of the low level aspects of the resulting Web content. Examples: timelines, waveforms, vector-based graphic editors, objects which represent web implementations for graphical widgets (e.g., menu widgets) etc.
  4. Applicable to Indirect authoring functions Indirect Authoring Functions: Authors have control over only high-level parameters related to the automated production of the resulting Web content. This may include interfaces that assist the author to create and organize Web content without the author having control over the markup, structure, or programming implementation. Examples: content management systems, site building wizards, site management tools, courseware, blogging tools, content aggregators, conversion tools, model-based authoring tools, etc.

2. Implementation Techniques

PART A: Make the authoring tool user interface accessible

Guideline A.1 Authoring Tool User Interface must be Perceivable

Guideline A.2 Authoring Tool User Interface must be Operable

Guideline A.3 Authoring Tool User Interface must be Understandable

Guideline A.4 Authoring Tool User Interface must be Access System Friendly

PART B: Support the production of accessible content

Guideline B.1 Enable the production of accessible content

Guideline B.2 Support the author in the production of accessible content

Guideline B.3 Promote and integrate accessibility solutions

Notes:

3. Glossary

This glossary is normative. Some definitions may differ from those in other WAI documents. The definitions here serve the goals of this Recommendation.

accessibility problem, authoring tool user interface
An authoring tool user interface accessibility problem is an aspect of an authoring tool user interface that fails to meet one of the checkpoint success criteria in Part A. The severity of a given problem is reflected in the priority of the checkpoint.
accessibility problem, Web content
A Web content accessibility problem is an aspect of Web content that fails to meet some requirement of WCAG. The severity of a given problem is relative and is determined by reference to WCAG.
accessible Web content
Web content (e.g., output of an authoring tool) that conforms to WCAG.
accessible authoring tool user interface
For Web-based functionality, this is an authoring tool user interface that conforms to WCAG. For non-Web-based functionality this is an authoring tool user interface that meets the success criteria in Part A. The severity of a given problem is reflected in the priority of the checkpoints.
accessibility information
Accessibility information is the information that is necessary and sufficient for undertaking an accessible authoring practice. For a particular content type, this information may include, but is not limited to, equivalent alternatives.
accessible authoring practice
An accessible authoring practice is any authoring activity (e.g., inserting an element, setting an attribute value), by either the author or the authoring tool, that corrects an existing Web content accessibility problem or does not cause a Web content accessibility problem to be introduced.
accessible content support features
All features of the tool that play a role in satisfying the success criteria for checkpoints B.2.1, B.2.2, B.2.3, B.2.5, B.2.6 and B.2.7.
alert
An alert makes the author aware of events or actions that require a response. The author response is not necessarily required immediately. The events or actions that trigger an alert may have serious consequences if ignored.
audio description
Audio description (also called "Described Video") is an equivalent alternative that provides auditory information about actions, body language, graphics, and scene changes in a video. Audio 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 audio description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The audio description must be synchronized with the auditory track of a video presentation, usually with descriptions occurring during natural pauses in the auditory track.
author
An author is the term used for the user of an authoring tool. This may include content authors, designers, programmers, publishers, testers, etc.
authored "by hand"
Authoring by hand is a situation in which the author specifies Web content at the level to be interpreted by the user agent (e.g., typing into a text editor, choosing an element by name from a list).
authoring action
An authoring action is any action that the author takes using the authoring tool user interface with the intention of adding or modifying Web content (e.g., typing text, inserting an element, launching a wizard).
authoring tool user interface
The user interface of the authoring tool is the display and control mechanism that the author uses to communicate with and operate the authoring tool software. Authoring tool interfaces may include (Note: tools may include both types of interfaces):
  • Web-based functionality: That part of an authoring tool user interface that is implemented using a content type and rendered on a user agent. Some authoring tools are fully Web-based (e.g., on-line content management system) others have components that are Web-based (e.g., a stand-alone markup editor with on-line help pages).
  • non-Web-based functionality: That part of an authoring tool user interface that runs directly on application execution environments such as Windows, MacOS, Java Virtual Machine etc.
Most authoring tool user interfaces are composed of two parts:
  • content display: The rendering of the content to the author in the editing view or preview. This might be as marked-up content (i.e., in a code-level view), input field content (e.g., in an indirect view, dialog boxes), or as rendered text, images, etc. (i.e., in a WYSIWYG editing view).
  • editing interface: All of the parts of the user interface that are not the content display (e.g., authoring tool menus, button bars, editing view, pop-up menus, floating property bars, palettes, documentation windows, cursor). These parts surround and in some cases are superimposed on the content display. Preview views are not included in the editing interface because they are not editable.

Figure 2: An illustration of the parts of the authoring tool user interface as used in ATAG 2.0.
A graphic that illustrates the parts of the authoring tool user interface as they are explained in the text, above. A long description appears below the graphic.
The graphic is a highly simplified representation of how the user interface of some GUI authoring tools are organized. The illustration includes four different views of the content: three editing views (a code-level editing view, a WYSIWYG editing view and an indirect editing view) and a preview view . Those parts of the user interface that are "editing interface" are colored dark blue, while the editing views are light blue and the content display is a mauve color. In the code-level editing view, the entire text entry area is considered the editing view and only the text within it is the content display. For the WYSIWYG editing view, since the background of the editing view is actually controlled by the content display (e.g., a rendered background color from the content - although see Checkpoint A.1.3) it too is considered to be content display. In the indirect editing view (and similarly for the dialog boxes used by many tools), the user is constrained to only providing some specific information (in this case some image attribute values and a long description). The text areas that collect this information are considered to be editing views while the text they contain is considered to be content display. The non-editable preview contains no editing view, just content display.

authoring tool
See "Definition of authoring tool".
available programmatically
Capable of providing information to other software (including assistive technologies) by following relevant accessibility platform architectures (e.g., MSAA, Java Access) or, if the available accessibility platform architectures are insufficient, following some other published interoperability mechanism (custom-created by the developer, if necessary).
captions
Captions are equivalent alternatives that consist of a text transcript of the auditory track of a movie (or other video presentation) and that is synchronized with the video and auditory tracks. Captions are generally rendered graphically. They benefit people who are deaf or hard-of-hearing, and anyone who cannot hear the audio (for example, someone in a noisy environment).
checking, accessibility
Accessibility checking (or "accessibility evaluation") is the process by which Web content is evaluated for Web content accessibility problems. ATAG 2.0 identifies three types of checking, based on increasing levels of automation: manual checking in which the authoring tool only provides instructions for authors to follow in order to identify problems; semi-automated checking in which the authoring tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists; and automated checking in which the authoring tool is able to check for problems automatically, with no human intervention required. An authoring tool may support any combination of checking types.
completion of authoring
Completion of authoring is the point in time at which an authoring session ends and the author has no opportunity to make further changes. This may be when an author chooses to "save and exit", or "publish", or it may occur automatically at the end of a wizard, etc.
content type
A content type is a data format, programming or markup language that is intended to be retrieved and rendered by a user agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations). The usage of the term is a subset of WCAG 2.0's [WCAG20] current usage of the term "Technology".
conversion
A conversion is a process that takes as input, content in one content type and produces as output, content in another content type (e.g., "Save as HTML" functions).
document
A document is a structure of elements along with any associated content; the elements used are defined by a markup language.
documentation
Documentation refers to any information that supports the use of an authoring tool. This information may be found electronically or otherwise and includes help, manuals, installation instructions, sample workflows, and tutorials, etc.
editing view
An editing view is a view provided by the authoring tool that allows editing by the author (e.g., code-level editing view, WYSIWYG editing view).
element
Element is used in the same sense as in HTML [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.
end user
An end user is a person who interacts with Web content once it has been authored. In some cases, the author and end user is the same person.
equivalent alternative
An equivalent alternative is content that is an acceptable substitute for other content that a person may not be able to access. An equivalent alternative fulfills essentially the same function or purpose as the original content upon presentation. Equivalent alternatives include text alternatives and synchronized alternatives. Text alternatives present a text version of the information conveyed in non-text objects such as graphics and audio clips. The text alternative is considered accessible because it can be rendered in many different ways (e.g., as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, as graphical text for individuals who are deaf or do not have a disability). Accessible multimedia alternatives present the same information as is conveyed in the multimedia via accessible text, navigation, forms, etc.. Synchronized alternatives present essential audio information visually (i.e., captions) and essential video information in an auditory manner (i.e., audio descriptions).
freeform drawing
Drawing actions that use the mouse or stylus in a continuous fashion (e.g., a paintbrush feature). This does not cover moving or resizing object-based graphics (including moving or resizing an object that is a previously authored freeform graphic).
general flash or red flash
General flash threshold (Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A sequence of flashes or rapidly changing image sequences where all three of the following occur:
  1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels;
  2. there are more than three flashes within any one-second period; and
  3. the flashing is below 50 Hz.
(Note: For the general flash threshold, a flash is defined as a pair of opposing changes in brightness of 10% or more of full scale white brightness, where brightness is calculated as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R, G, and B are the red, green, and blue RGB values of the color; FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and the "^" character is the exponentiation operator. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. This applies only when the brightness of the darker image is below .80 of full scale white brightness.
Red flash threshold (Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)): A transition to or from a saturated red where both of the following occur:
  1. The combined area of flashes occurring concurrently occupies more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels.
  2. There are more than three flashes within any one-second period.
  3. The flashing is below 50 Hz.
inform
To inform is to make the author aware of an event or situation using methods such as alert, prompt, sound, flash. These methods may be unintrusive (i.e., presented without stopping the author's current activity) or intrusive (i.e., interrupting the author's current activity).
informative
Informative ("non-normative") parts of this document are never required for conformance.
keyboard interface
Interface used by software to obtain keystroke input.
Note 1: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard (e.g., a touch screen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality).
Note 2: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.
markup
Markup is a set of tags from a markup language that specify the characteristics of a document. Markup can be presentational (i.e., markup that encodes information about the visual layout of the content), structural (i.e., markup that encodes information about the structural role of elements of the content) or semantic (i.e., markup that encodes information about the intended meaning of the content).
markup language
A markup language is a syntax and/or set of rules to manage markup (e.g., HTML [HTML4], SVG [SVG], or MathML [MATHML]).
multimedia
Audio or video synchronized with another type of media and/or with time-based interactive components.
non-text objects
Content objects that are not represented by text character(s) when rendered in a user agent (e.g., images, audio, video).
normative
Normative parts of this document are always required for conformance.
platform
The software environment within which the authoring tool operates. For functionality that is not Web-based, this will be an operating system (e.g., Windows, MacOS, Linux), virtual machine (e.g., JVM) or a higher level GUI toolkit (e.g., Eclipse). For Web-based functionality, the term applies more generically to user agents in general, although for purposes of evaluating conformance to ATAG 2.0, a specific user agent(s) will be listed in the conformance profile.
presentation
Presentation is the rendering of the content and structure in a form that can be perceived by the user.
preview
A non-editable view of the content that is intended to show how it will appear and behave in a user agent.
prominence
The prominence of a control in the authoring tool user interface is a heuristic measure of the degree to which authors are likely to notice a control when operating the authoring tool. In this document, prominence refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a control include: control size (large controls or controls surrounded by extra white space may appear to be conferred higher importance), control order (items that occur early in the "localized" reading order (e.g., left to right and top to bottom; right to left and top to bottom) are conferred higher importance), control grouping (grouping controls together can change the reading order and the related judgments of importance), advanced options (when the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance), and highlighting (controls may be distinguished from others using icons, color, styling).
prompt
In this document "prompt" refers to any authoring tool initiated request for a decision or piece of information. Well designed prompting will urge, suggest, and encourage the author.
repairing, accessibility
Accessibility repairing is the process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation: Manual repairing in which the authoring tool only provides instructions for authors to follow in order to make the necessary correction; Semi-Automated repairing, in which the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be completed; and Automated repairing, in which the authoring tool is able to make repairs automatically, with no author input or confirmation from the author. An authoring tool may support any combination of repairing types.
selectable items
Any items that an author may select from within the menus, toolbars, palettes, etc. (e.g., "open", "save", "emphasis", "check spelling")
structured element set
Content organized into lists, maps, hierarchies (e.g., tree views), graphs, etc.
transcript
A transcript is a non-synchronized text alternative for the sounds, narration, and dialogue in an audio clip or the auditory track of a multimedia presentation. For a video, the transcript can also include the description of actions, body language, graphics, and scene changes of the visual track.
transformation
A transformation is a process that takes as input, an object in one content type and produces as output, a different object in the same content type (e.g., a function that transforms tables into lists).
user Agent
A user agent is software that retrieves and renders Web content. This may include Web browsers, media players, plug-ins, and other programs, including assistive technologies, that help in retrieving and rendering Web content.
view
A view is a rendering of Web content by an authoring tool. Authoring tool views are usually either editing views or previews.
Web content (or shortened to "content")
Any material in a content type. If the content type is a markup language, then "content" covers the information both within the tags (i.e., the markup) and between them. In this document, "content" is primarily used in the context of the material that is authored and outputted by authoring tools.
Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)
a method developed at the University of Wisconsin, working in conjunction with Dr. Graham Harding and Cambridge Research Associates, for applying the United Kingdom's "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" to content displayed on a computer screen, such as Web pages and other computer content.
Note: The Ofcom Guidance Document [OFCOM] is based on the assumption that the television screen occupies the central ten degrees of vision. This is not accurate for a screen which is located in front of a person. The Wisconsin algorithm basically carries out the same analysis as the Ofcom Guidelines except that is does it on every possible ten degree window for a prototypical computer display.
workflow
A workflow is a customary sequence of steps or tasks that are followed to produce a deliverable.

4. References

[AMAYA]
Amaya, developed at W3C, is both an authoring tool and browser with a WYSIWYG-style user interface. Amaya serves as a testbed for W3C specifications. Source code, binaries, and further information are available at http://www.w3.org/Amaya/. The techniques in this document are based on Amaya version 2.4.
[AMAYA-HELP-IMG]
"Images and Client-side Image Maps," Amaya's help page for images and image maps.
[AMAYA-SAMPLE]
"Amaya - Authoring Tool Accessibility Guidelines 1.0 sample implementation" Describes how Amaya, W3C's WYSIWYG browser/authoring tool, satisfies version 1.0 of the guidelines.
[API-DESIGN]
"Accessibility requirements for systems design to accommodate users with vision impairments," P. Brunet, B. A. Feigenbaum, K. Harris, C. Laws, R. Schwerdtfeger, and L. Weiss, IBM Systems Journal.
[APPLE-ACCESS]
"Introduction to Accessibility Overview," Apple Computer Inc.
[APROMPT]
The A-prompt tool allows authors to check many accessibility features in HTML pages, and incorporates a mechanism to manage equivalent alternative information for images. The tool is built in such a way that the functions can be incorporated into an authoring tool. A-prompt was developed by the Adaptive Technology Resource Center at the University of Toronto, and the TRACE center at the University of Wisconsin and is freely available at http://aprompt.snow.utoronto.ca.
[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0," J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C reference is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[ATAG10-TECHS]
"Techniques for Authoring Tool Accessibility Guidelines 1.0," J. Treviranus, C. McCathieNevile, J. Richards, and G. Rosmaita, eds., 29 October 2002. This W3C reference is http://www.w3.org/TR/2002/NOTE-ATAG10-TECHS-20021029/.
[ATAG20]
"Authoring Tool Accessibility Guidelines 2.0," J. Treviranus, J. Richards, C. McCathieNevile, and M. May, eds. The latest version is available at http://www.w3.org/TR/ATAG20. The latest version of ATAG 2.0 is available at http://www.w3.org/TR/ATAG20.
[AUTO-TOOL]
"Techniques For Accessibility Evaluation and Repair Tools," C. Ridpath and W. Chisholm, eds., 26 April 2000. This W3C reference is http://www.w3.org/TR/2000/WD-AERT-20000426.
[CARBON-ACCESS]
"Introduction to Accessibility Programming Guidelines for Carbon," Apple Corporation.
[COCOA-ACCESS]
"Introduction to Accessibility Programming Guidelines for Cocoa," Apple Corporation.
[CSS1]
"CSS, level 1 Recommendation," B. Bos and H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. This CSS1 Recommendation is http://www.w3.org/TR/1999/REC-CSS1-19990111. The latest version of CSS1 is available at http://www.w3.org/TR/REC-CSS1. Note: CSS1 has been superseded by CSS2. Tools should implement the CSS2 cascade.
[CSS2]
"CSS, level 2 Recommendation," B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[CSS2-ACCESS]
"Accessibility Features of CSS," I. Jacobs and J. Brewer, eds., 4 August 1999. This W3C Note is http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest version of Accessibility Features of CSS is available at http://www.w3.org/TR/CSS-access.
[EARL]
"EARL - the Evaluation And Report Language," W3C-WAI Evaluation and Repair Tools Working Group.
[ECLIPSE-ACCESS]
"Designing Accessible Plug-ins in Eclipse," T. Creasy, IBM OTI Labs.
[ECLIPSE-API]
"Eclipse Platform API"
[EDU-SOFT-ACCESS]
"Making Educational Software and Web Sites Accessible,". G. Freed, M. Rothberg and T. Wlodkowski, National Center for Accessible Media
[EITAAC]
"EITAAC Desktop Software standards," Electronic Information Technology Access Advisory (EITAAC) Committee.
[GNOME-ACCESS]
"GNOME Accessibility for Developers," C. Benson, B. Cameron, B. Haneman, S. Snider, P. O'Briain, The GNOME Accessibility Project.
[GNOME-API]
"Gnome Accessibility Toolkit API"
[GNOME-KDE-KEYS]
"Gnome/KDE Keyboard Shortcuts," Novell Corporation.
[HTML-XML-VALIDATOR]
The W3C HTML Validation Service validates HTML and XHTML markup.
[HTML4]
"HTML 4.01 Recommendation," D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is available at http://www.w3.org/TR/html4.
[HTML4-ACCESS]
"WAI Resources: HTML 4.0 Accessibility Improvements," I. Jacobs, J. Brewer, and D. Dardailler, eds. This document describes accessibility features in HTML 4.0.
[IBM-ACCESS]
"Software Accessibility," IBM Special Needs Systems.
[ICCCM]
"The Inter-Client communication conventions manual." A protocol for communication between clients in the X Window system.
[ISO-TS-16071]
"Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces". International Organization for Standardization.
[ICE-RAP]
"An ICE Rendezvous Mechanism for X Window System Clients," W. Walker. A description of how to use the ICE and RAP protocols for X Window clients.
[JAVA-ACCESS]
"IBM Guidelines for Writing Accessible Applications Using 100% Pure Java," R. Schwerdtfeger, IBM Special Needs Systems.
[JAVA-API]
" Java Accessibility Package"
[JAVA-CHECKLIST]
"Java Accessibility Guidelines and Checklist," IBM Special Needs Systems.
[JAVA-TUT]
"The Java Tutorial. Trail: Creating a GUI with JFC/Swing." An online tutorial that describes how to use the Swing Java Foundation Class to build an accessible User Interface.
[MACOSX-KEYS]
"Mac OS X keyboard shortcuts," Apple Corporation.
[MATHML]
"Mathematical Markup Language 1.01 (MathML)," P. Ion and R. Miner, eds., 7 April 1998, revised 7 July 1999. This MathML 1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available at http://www.w3.org/TR/REC-MathML.
[MS-ENABLE]
"Accessibility for Applications Designers," Microsoft Corporation.
[MS-KEYS]
"Keyboard shortcuts for Windows," Microsoft Corporation.
 
[MSAA-API]
"Microsoft Active Accessibility," Microsoft Corporation.
[NOTES-ACCESS]
"Lotus Notes application accessibility," IBM Corporation.
[OFCOM]
Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance Note on Flashing Images and Regular Patterns in Television (Re-issued as Ofcom Notes 25 July 2005)" available at http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf)
[PNG]
"Portable Network Graphics (PNG) Specification (Second Edition) Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification. ISO/IEC 15948:2003 (E) ," A. M. Costello, ed. The 10 November 2003 Recommendation is http://www.w3.org/TR/2003/REC-PNG-20031110. The latest version of PNG 1.2 is available at http://www.w3.org/TR/PNG.
[RDF10]
"Resource Description Framework (RDF) Model and Syntax Specification," O. Lassila, R. Swick, eds. The 22 February 1999 Recommendation is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF 1.0 is available at http://www.w3.org/TR/REC-rdf-syntax.
[RUBY]
"Ruby Annotation," M. Sawicki, M. Suignard, M. Ishikawa, and M. Dürst, eds. The 17 December 1999 Working Draft is http://www.w3.org/TR/1999/WD-ruby-19991217. The latest version is available at http://www.w3.org/TR/ruby.
[SMIL]
"SSynchronized Multimedia Integration Language (SMIL) 2.1 Specification)," D. Bulterman, G. Grassel, J. Jansen, A. Koivisto, N. Layaïda, T. Michel, S. Mullender, and D. Zucker, eds. The 13 December 2005 SMIL2 specification is available at http://www.w3.org/TR/2005/REC-SMIL2-20051213/. The latest version of the SMIL specification is available at http://www.w3.org/TR/SMIL2/.
[SMIL-ACCESS]
"Accessibility Features of SMIL," M.-R. Koivunen and I. Jacobs, eds. This W3C Note is http://www.w3.org/TR/1999/NOTE-SMIL-access-19990921. The latest version of Accessibility Features of SMIL is available at available at http://www.w3.org/TR/SMIL-access.
[SUN-DESIGN]
"Designing for Accessibility," Eric Bergman and Earl Johnson. This paper discusses specific disabilities including those related to hearing, vision, and cognitive function.
[SUN-HCI]
"Towards Accessible Human-Computer Interaction," Eric Bergman and Earl Johnson, Sun Microsystems 1995. A substantial paper, with a valuable print bibliography.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)," J. Ferraiolo, ed. The latest version of the SVG specification is available at http://www.w3.org/TR/SVG.
[SVG-ACCESS]
"Accessibility of Scalable Vector Graphics (Working Draft)," C. McCathieNevile, M.-R. Koivunen, eds. The latest version is available at http://www.w3.org/TR/SVG-access.
[TRACE-REF]
"Application Software Design Guidelines," compiled by G. Vanderheiden. A thorough reference work.
[UAAG10]
"User Agent Accessibility Guidelines 1.0 ," I. Jacobs, J. Gunderson, E. Hansen, eds.
[UAAG10-TECHS]
"Techniques for User Agent Accessibility Guidelines 1.0," J. Gunderson and I. Jacobs, eds. The latest version of Techniques for User Agent Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/UAAG10-TECHS/.
[WAI-ER]
The Web Accessibility Initiative Evaluation and Repair Tools Working Group tracks and develops tools that can help repair accessibility errors.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG10-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of Techniques for Web Content Accessibility Guidelines 1.0 is available at http://www.w3.org/TR/WCAG10-TECHS/.
[WCAG20]
"Web Content Accessibility Guidelines 2.0 (Working Draft)", B. Caldwell, W. Chisholm, J. Slatin, and G. Vanderheiden, editors. The latest version of the Web Content Accessibility Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note: This document is still a working draft.
[WHAT-IS]
"What is Accessible Software," James W. Thatcher, Ph.D., IBM, 1997. This paper, available at the IBM Accessibility Center, gives a short example-based introduction to the difference between software that is accessible, and software that can be used by some assistive technologies.
[XHTML10]
"XHTML(TM) 1.0: The Extensible HyperText Markup Language (Working Draft)," S. Pemberton et al. The latest version of XHTML 1.0 is available at http://www.w3.org/TR/xhtml1.
[XML]
"The Extensible Markup Language (XML) 1.0," T. Bray, J. Paoli, C. M. Sperberg-McQueen, eds., 10 February 1998. This XML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-xml-19980210. The latest version of the XML specification is available at http://www.w3.org/TR/REC-xml.
[XMLGL]
"XML Accessibility Guidelines (Draft Note)," D. Dardailler, ed. Draft notes for producing accessible XML document types. The latest version of the XML Accessibility Guidelines is available at http://www.w3.org/WAI/PF/xmlgl.

5. Acknowledgments

The active participants of the Authoring Tool Accessibility Guidelines Working Group who authored this document were: Tim Boland (National Institute for Standards and Technology), Barry A. Feigenbaum (IBM), Matt May, Greg Pisocky (Adobe), Jan Richards (Adaptive Technology Resource Centre, University of Toronto), Roberto Scano (IWA/HWG), and Jutta Treviranus (Chair of the working group, Adaptive Technology Resource Centre, University of Toronto)

Many thanks to the following people who have contributed to the AUWG through review and comment: Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Charles McCathieNevile, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.

This document would not have been possible without the work of those who contributed to ATAG 1.0.

This publication has been funded in part with Federal funds from the U.S. Department of Education under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

Contents | Part A | Part B | References