Copyright ©2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as enabling, supporting, and promoting the production of accessible Web content by all authors.
"Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI).
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/.
This is a Working Draft intended to gather comments on a stabilized version of the Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0) prior to proceeding to a second Last Call Working Draft. The Working Draft includes an Appendix B: Comparison of ATAG 1.0 checkpoints to ATAG 2.0.
The AUWG encourages feedback about this Working Draft. Please send your comments by 11 January 2007 to w3c-wai-au@w3.org. The archives for this list are publicly available.
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 ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; 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) must 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 AUWG are discussed in the Working Group charter. The AUWG is part of the WAI Technical Activity.
You are reading the Authoring Tool Accessibility Guidelines (WCAG) version 2.0. This document includes recommendations for assisting authoring tool developers to make their tools (and the Web content that the tools generate) more accessible to all people, especially people with disabilities, who may potentially be either authors or end users. These guidelines have been written to address the requirements of many different audiences, including, but not limited to: policy makers, technical administrators, and those who develop or manage content. An attempt has been made to make this document as readable and usable as possible for that diverse audience, while still retaining the accuracy and clarity needed in a technical specification.
ATAG 2.0 is part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). The relationship between these documents is explained in "Essential Components of Web Accessibility" [COMPONENTS].
ATAG 2.0 defines an "authoring tool" as: any software, or collection of software components, that authors use to create or modify Web content for publication, where a "collection of software components" are any software products used together (e.g., base tool and plug-in) or separately (e.g., markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products.
The following categories are an informative illustration of the range of tools covered by ATAG 2.0. The categories are used primarily in the Techniques document [ATAG20-TECHS] to mark examples that may be of interest to developers of particular types of tools. Note: Many authoring tools include authoring functions from more than one category (e.g., an HTML editor with both code-level and WYSIWYG editing views):
The guiding principle of ATAG 2.0 is that:
Everyone should have the ability to create and access Web content.
Authoring tools play a crucial role in achieving this principle because the accessibility of the tool's authoring tool user interface determines who can access the tool as a Web content author and the accessibility of the resulting Web content determines who can be an end user of that Web content.
The approach taken to the production of accessible content in these guidelines is one of enabling, supporting, and guiding the author. In general, the Working Group does not believe that enforcing particular author behavior through overly restrictive mechanisms is a workable solution.
As an introduction to accessible authoring tool design, consider that the authors and end users of Web content may be using the tool and its output in contexts that are very different from that which may be regarded as typical. For example, authors and end users may:
For more information, see "How People with Disabilities Use the Web" [PWD-USE-WEB]. In addition, following the guidelines provides benefits for authors and end users beyond those listed in these various disability-related contexts. For example, a person may have average hearing, but still require captions for audio information due to a noisy workplace. Similarly, a person working in an eyes-busy environment may require an audio alternative to information they cannot view.
This section is normative.
At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. Note that the two versions have somewhat different Conformance Models.
ATAG 2.0 refers to WCAG as a benchmark for judging the accessibility of Web content (see the term "Accessible Web Content") and Web-based authoring tool user interfaces (see the term "Accessible Authoring Tool User Interface"). For more information on how WCAG acts as a benchmark, see "Relative Priority" Checkpoints.
Note that the references to WCAG in the guidelines section of ATAG 2.0 are made without an associated version number. This has been done to allow developers to select, and record in the conformance profile, whichever version of WCAG is most appropriate for the circumstances of a given authoring tool. The Working Group does recommend considering the following factors when deciding which WCAG version to use:
This section is normative.
Authoring tools may claim conformance to ATAG 2.0 at one of three conformance levels. The level achieved depends on the priority of those checkpoints for which the authoring tool has satisfied the success criteria. The levels are:
Figure 1: A graphical view of the requirements of the ATAG 2.0 conformance level "ladder".
The graphic is a table with four rows and three columns. The header row labels are "ATAG 2.0 Conformance Levels", "Regular Priority Checkpoints" and "Relative Priority Checkpoints". The data rows are labeled Level 'Triple-A' (highest), Level 'Double-A', and Level 'A' (lowest). Bars superimposed across the rows demonstrate that in order to meet each higher level, additional regular priority checkpoints must be met as well as increasing levels of relative priority checkpoints.
Each checkpoint has been assigned a priority level that indicates its importance and determines whether that checkpoint must be met in order for an authoring tool to achieve a particular conformance level. There are three levels of "regular priority" checkpoints as well as a special class of "relative priority" checkpoints that rely on WCAG to determine their importance.
The importance of each "relative priority" checkpoint depends on the requirements of whichever version of WCAG the evaluator has chosen to specify in the conformance profile. These checkpoints can be met at one of three levels:
If an authoring tool developer intends to claim conformance to ATAG 2.0 at Level-A, they will first identify, in the conformance claim, a published content type-specific WCAG benchmark document that is targeted at WCAG conformance Level-A (i.e., the requirements in the benchmark are those required to conform to Level-A of WCAG).
Then, for each Relative Priority checkpoint in ATAG 2.0, this document will be used as a benchmark for determining whether the success criteria have been met. For instance, Checkpoint B.2.2 ("Check for and inform the author of accessibility problems") is a Relative Priority checkpoint. To conform to ATAG 2.0 at Level-A, this checkpoint must be met at Relative Priority - Level 1. To do this, the authoring tool must satisfy the success criteria of the checkpoint with respect to all of the requirements in the benchmark document. An example of this can be seen in the first success criteria ("An individual check must be associated with each requirement in the content type-specific WCAG benchmark document...").
A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile.
The purpose of the Content Type-Specific WCAG Benchmark document (the "Benchmark" from here on) is to ensure that the authoring tool is consistent with respect to production of accessible content. For example, if the checking function detects a problem, the repair function must be able to help the author fix it. In practical terms, the Benchmark document is just the WCAG Techniques document when one exists for a content type. However, when a WCAG Techniques document does not already exist for a content type, the claimant may publish their own Benchmark document. The Benchmark has the following characteristics:
Each Benchmark document must include the following:
The Working Group suggests the following resources are relevant when creating a Benchmark document:
Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0 conformance level are encouraged to publish a statement on progress towards conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed towards, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.
This section is normative.
The guidelines are divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes guidelines and associated checkpoints related to ensuring accessibility of the authoring tool user interface. Part B contains guidelines and checkpoints related to ensuring support for creation of accessible Web content by the tool. The guidelines in both parts include the following:
Each checkpoint listed under a guideline is intended to be specific enough to be verifiable, while still allowing developers the freedom to meet the checkpoint in a way that is suitable for their own authoring tools. Each checkpoint definition includes the following parts. Some parts are normative (i.e., relate to conformance), while others are informative only:
The checkpoints in Part A are intended to increase the accessibility of the authoring experience for authors with disabilities. For this reason, the requirements are narrowly focused on the accessibility of the user interface that the author uses to operate the tool. The accessibility of the Web content produced is addressed in Part B.
Note for tools with previews: The requirement in this section apply to all parts of the authoring tool user interface except for the content view of any built-in preview features (see Checkpoint A.2.9 for requirements on previews). In general, the configuration of the preview mode is not defined by the configuration of the editing views.
Rationale: Authors must be able to have access to Web-based authoring tool user interface functionality just as they do to other Web content.
Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (e.g., Web-based help features). However, for most Web-based authoring tools the requirement will cover the majority of functionality in the tool and overlap many of the other requirements in Part A of the guidelines. When this is the case, a note entitled "For Web-based authoring tool user interface functionality" will appear below the success criteria to provide more information.
Techniques: Implementation Techniques for Checkpoint A.0.1
Success Criteria:
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to perceive its user interface controls.
Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information, since text is more easily transformed between various display methods (e.g., magnification and enhancement, text-to-speech, Braille output)
Techniques: Implementation Techniques for Checkpoint A.1.1
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 of this checkpoint.
Rationale: People who have difficulty accessing or interpreting multimedia-supported information in the authoring tool user interface can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions, and people who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.
Techniques: Implementation Techniques for Checkpoint A.1.2
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: Some authors require alternative display configurations to use the authoring tool user interface.
Note: The success criteria for this checkpoint are based on the capabilities of platforms (e.g., operating systems, user agents, GUI toolkits) as defined in the conformance profile, however developers are free to provide additional configuration.
Techniques: Implementation Techniques for Checkpoint A.1.3
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: Authors may require settings to render and control the content during editing that differ from the presentation defined for the published content (e.g., providing a high contrast setting to edit content that is not intended to be high contrast).
Techniques: Implementation Techniques for Checkpoint A.1.4
Success Criteria:
Rationale: Separating content and structure from presentation allows the user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors without losing any of the information or structure. For example, information can be presented via speech or Braille (text) that was primarily intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities.
Techniques: Implementation Techniques for Checkpoint A.1.5
Success Criteria:
<p>
") must be available programmatically.For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to operate its user interface controls.
Rationale: Some individuals have difficulty manipulating graphical input devices such as a mouse or trackball. Providing alternate means of navigating the user interface that does not rely on such devices provides an accommodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.
Note 1: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.
Note 2: Also see Checkpoint A.3.1 when choosing keystrokes.
Techniques: Implementation Techniques for Checkpoint A.2.1
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. User agent functionality (e.g., for "cut/copy/paste") or access keys (e.g., for "open new content") may be relied on to achieve success criteria 3 and 4 as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Authors who have limited mobility require quick access to the items that they use frequently.
Techniques: Implementation Techniques for Checkpoint A.2.2
Success Criteria:
Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
Note: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.
Techniques: Implementation Techniques for Checkpoint A.2.3
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
Techniques: Implementation Techniques for Checkpoint A.2.4
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: It is often efficient to make use of the structure that may be inherent within certain content in order to navigate editing views and perform edits. This is particularly important for people who are using a slow interface such as a small Braille device, speech output, or a single switch input device. It is equivalent to the ability provided by a mouse interface to move rapidly around the document.
Techniques: Implementation Techniques for Checkpoint A.2.5
Success Criteria:
Rationale: Search functions within the editing views facilitate author navigation of content as it is being authored by allowing the author to move the focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the efficiency of the search function.
Techniques: Implementation Techniques for Checkpoint A.2.6
Success Criteria:
For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "find" function of the user agent to help perform the searches, as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Authors who have difficulty making fine movements may be prone to making unintended actions. All authors benefit from the ability to easily recover from mistakes.
Note: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single author action.
Techniques: Implementation Techniques for Checkpoint A.2.7
Success Criteria:
For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "undo" function of the user agent to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area), as long as the applicable user agent(s) are specified in the conformance profile.
Rationale: Providing the ability to save and reload sets of keyboard and display preference settings is a benefit to authors using tools intended to be used by multiple authors as well as authors who have keyboard and display preference settings preferences that differ with fatigue, etc..
Techniques: Implementation Techniques for Checkpoint A.2.8
Success Criteria:
Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how content will appear to end users in a user agent. In order to enable authors with disabilities to follow the same workflow as other authors, they must have access to any preview features that exist.
Note 1: Authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this checkpoint.
Note 2: It is understood that the accessibility of the content display of a preview will be negatively affected if the content being rendered is inaccessible or incomplete. For example, a missing image label will result in an inaccessible image, which is useful information to the author.
Techniques: Implementation Techniques for Checkpoint A.2.9
Success Criteria:
In order for an authoring tool to be accessible, authors with a wide range of abilities must be able to understand the user interface controls that they can perceive and operate.
Rationale: Authors are often familiar with accessibility conventions employed by the other applications built on a platform. Departures from those conventions have the tendency to disorient authors by creating an unfamiliar environment.
Techniques: Implementation Techniques for Checkpoint A.3.1
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: Authors who may become disoriented easily will have less difficulty when consistent and predictable responses to author actions are provided. In general, consistent interfaces will benefit all authors to some degree.
Techniques: Implementation Techniques for Checkpoint A.3.2
Success Criteria:
For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: While intuitive user interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.
Techniques: Implementation Techniques for Checkpoint A.3.3
Success Criteria:
Assistive technologies (e.g., screen readers, screen magnifiers) can only provide augmented display and control to their users if the authoring tools support and document the communication protocols upon which they depend.
Rationale: Assistive technologies that are used by many authors with disabilities (e.g., screen readers, screen magnifiers) rely on the authoring tool to provide data and control via prescribed communication protocols.
Techniques: Implementation Techniques for Checkpoint A.4.1
Success Criteria:
For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Rationale: When the use of accessibility architectures is fully documented, assistive technology developers are able to provide enhanced user interface access.
Techniques: Implementation Techniques for Checkpoint A.4.2
Success Criteria:
For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.
The checkpoints in Part B are intended to increase the accessibility of the Web content produced by any author to end users with disabilities. While the requirements in this part do not deal with the accessibility of the authoring tool user interface, it should be noted that any of the features (e.g., checker, tutorial) added to meet Part B must also meet the user interface accessibility requirements of Part A.
The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.
Rationale: Content types with published content type-specific WCAG benchmark documents facilitate the creation of Web content that can be assessed for accessibility with WCAG.
Techniques: Implementation Techniques for Checkpoint B.1.1
Success Criteria:
Rationale: Accessibility information is critical to maintaining comparable levels of accessibility across transformations and conversions.
Techniques: Implementation Techniques for Checkpoint B.1.2
Success Criteria:
Rationale: Automatically removing markup can cause the unintentional loss of structural information. Even unrecognized markup may have accessibility value, since it may include recent technologies that have been added to enhance accessibility.
Techniques: Implementation Techniques for Checkpoint B.1.3
Rationale: Authoring tools that automatically generate content that does not conform to WCAG are a source of accessibility problems.
Note: If accessibility information is required from the author during the automatic generation process, Checkpoint B.2.1 applies.
Techniques: Implementation Techniques for Checkpoint B.1.4
Success Criteria:
Rationale: Pre-authored content, such as templates, images, and videos, is often included with authoring tools for use by the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.
Note: If accessibility information is required from the author during use, Checkpoint B.2.1 applies.
Techniques: Implementation Techniques for Checkpoint B.1.5
This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate features that support accessible authoring that have been added to meet the other requirements in this document.
Note: In addition to the normative requirements of this guideline, implementers should consider one other issue: the integration of features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:
However, whenever new features are introduced into an authoring tool, striking the right design balance between the similarity with existing features and the provision of new functionality is often more of an art than a science.
Rationale: Authors are most likely to use the first and easiest option for a given authoring task.
Techniques: Implementation Techniques for Checkpoint B.3.1
Success Criteria:
Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports the author in considering accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analogous to internationalization, which is much easier when it is considered from the beginning rather than handled last.
Techniques: Implementation Techniques for Checkpoint B.3.2
Success Criteria:
Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used.
Techniques: Implementation Techniques for Checkpoint B.3.3
Success Criteria:
Rationale: The accessible content support features will be more adaptable to the work habits of authors if they can be turned on and off easily as the author needs them.
Techniques: Implementation Techniques for Checkpoint B.3.4
Success Criteria:
Rationale: Without documentation of the features that support the production of accessible content (e.g., prompts for alternatives, accessibility checkers) authors may not find or use them.
Techniques: Implementation Techniques for Checkpoint B.3.5
Success Criteria:
Rationale: If accessible authoring is integrated into instructions and guidance offered by the tool (e.g., documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring techniques if they are demonstrated as common practice. This can also facilitate a better understanding of the reasoning behind and the consequences of authoring accessible content.
Techniques: Implementation Techniques for Checkpoint B.3.6
Success Criteria:
This glossary is normative. Some definitions may differ from those in other WAI documents. The definitions here serve the goals of this Recommendation.
Figure 2: An illustration of the parts of the authoring tool user interface as used in ATAG 2.0.
The graphic is a highly simplified representation of how the user interfaces 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.
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[HTML4]" link to the corresponding entries in this section. These labels are also identified as references through markup. Normative references are highlighted and identified through markup.
There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):
In almost all cases, references (either by name or by link) should be to a specific version of the document. W3C will make every effort to make this document indefinitely available at its original address in its original form. The top of this document includes the relevant catalog metadata for specific references (including title, publication date, "this version" URI, editors' names, and copyright information).
An XHTML 1.0 paragraph including a reference to this specific document might be written:
<p>
<cite><a href="http://www.w3.org/TR/2006/REC-ATAG20-????????/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, M. May, eds.,
W3C Recommendation, ?? ???? ????.
The <a href="http://www.w3.org/TR/ATAG20/">latest
version</a> of this document is available at
http://www.w3.org/TR/ATAG20/.</p>
For very general references to this document (where stability of content and anchors is not required), it may be appropriate to refer to the latest version of this document.
Other sections of this document explain how to build a conformance claim.
A document appears in this section if at least one reference to the document appears in a checkpoint success criteria.
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.