Authoring Tool Accessibility Guidelines Working Group
This "Frequently Asked Questions" (FAQ) page provides background on the Authoring Tool Accessibilty Guidelines Working Group (AUWG), and on the World Wide Web Consortium's (W3C) Authoring Tool Accessibility Guidelines 1.0 Recommendation, released on February 3, 2000, which were developed by the Working Group.
This is currently a draft for a Working Group FAQ list. It may contain errors, and has not yet been reviewed by the Working Group as a single document. This document is based in part on the document Fact Sheet for "Authoring Tool Accessibility Guidelines 1.0".
Comments on this FAQ are welcome, and should be sent to the Working Group's mailing list w3c-wai-au@w3.org - you may also like to read the archives of that list.
An authoring tool is software that people use to create Web pages and Web sites. Authoring tools include text editors, WYSIWYG ("what you see is what you get") editors, save-as-HTML conversion tools (word processors, spreadsheets, presentation software, etc.), tools that generate content from databases, multimedia editors, formating tools, and site management tools.
The Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) include seven general guidelines, or principles, each of which has several checkpoints, or requirements -- twenty-eight all together. Checkpoints are assigned one of three priority levels. A companion Checklist of Checkpoints sorts all checkpoints by priority, including a set of relative-priority checkpoints, which address authoring tool support for checkpoints in the Web Content Accessibility Guidelines 1.0. The guidelines also include an introduction, information about how to indicate conformance to the document, and references.
Authoring tools can support the production of accessible Web content by generating valid markup automatically; by checking the accessibility of content created; by prompting the author for necessary changes; and by informing the author how to create accessible content.
Many of today's authoring tools create markup that is difficult for people with disabilities to access. Since the Web has become such a key information resource, it is important to ensure that people with disabilities can use the Web. The Authoring Tool Accessibility Guidelines 1.0 will make it much easier for Web site developers to create sites that meet accessibility goals established by the W3C's Web Content Accessibility Guidelines 1.0, and will make it possible for more people with disabilities to create content themselves.
There is an increasing number of public and private-sector organizations that are interested in ensuring accessibility of their Web sites, and in some cases, governmental policies that require accessibility of certain kinds of Web sites. These organizations are already requesting information on tools that produce accessible content, and we expect the demand to increase.
The Web Content Accessibility Guidelines explain how to design Web pages that are accessible. The User Agent Accessibility Guidelines explain how to develop browsers and multimedia players that can be used by people regardless of disability. The Authoring Tool Accessibility Guidelines explain how to develop authoring tools that make it easier to produce accessible Web pages that conform to the Web Content Accessibility Guidelines.
The Authoring Tool Accessibility Guidelines Working Group (AUWG) includes representatives of industry, the disability community, and research organizations. Active members of the group at various times have included the Adaptive Technology Resource Centre Centre at the University of Toronto, Allaire Corporation, the HTML Writers Guild, IBM, Lotus Corporation, Microsoft Corporation, Smith-Kettlewell Eye Research Institute, Texas School for the Blind and Visually Impaired, TRACE Research and Development Center, the University of Melbourne, UsableNet, the Visually Impaired Computers Users' Group of New York. In addition, the guidelines received review and comment during their development by members of the Web Accessibility Initiative (WAI) Interest Group, by W3C Member organization representatives, and by other software developers, and all feedback was reviewed and incorporated where relevant.
The Web Accessibility Initiative home page includes a variety of information about WAI: resources, events, Working Group activities, involvement opportunities, and sponsorship opportunities.
W3C hosts the Web Accessibility Initiative, bringing expertise in accessibility to the W3C Member organizations and to the Web community at large. New W3C specifications are reviewed to ensure that they do not compromise and where possible that they enhance the accessibility of the Web, ensuring that the Web is developed to its full potential for all its users.
At the time of the release of ATAG 1.0, every requirement of the Guidelines has been implemented by one or more existing tools, though no tool yet satisfies all checkpoints. In addition, authoring tool developers are planning ATAG 1.0 support in upcoming products, indicated among the wide range of testimonials.
Since no tool yet conforms to any ATAG 1.0 conformance level at the time of ATAG 1.0 release, the most appropriate tool for a given author may depend upon the needs and skills of the author in consideration with various available tools. Does the authoring tool produce valid markup? Tool output can be tested against W3C validators. Does a tool make it easy or difficult to add accessibility information into pages, and does it check accessibility semi-automatically? If not, existing evaluation tools can be used in conjunction with existing authoring tools to facilitate checking. Check the WAI home page for links to updated information on implementation status of ATAG 1.0 in different authoring tools.
The Web site developer could review the Checklist of Checkpoints for Authoring Tool Accessibility Guidelines 1.0 and accompanying Techniques for Authoring Tool Accessibility, and compare the authoring tool against these. This would require some familiarity with ATAG 1.0 as well as the Web Content Accessibility Guidelines. Alternatively, the Web site developer could ask the developer of the authoring tool how soon that product will support ATAG 1.0.
W3C has a testbed authoring tool/browser known as Amaya. The Amaya development team has developed a workplan to implement ATAG 1.0, and has begun development on the implementations.
ATAG 1.0 has three priority levels, which relate to the goals of the document. Priority one checkpoints are essential to meeting the goals of the document; priority two checkpoints are important to meeting the goals; and priority three checkpoints are beneficial to meeting the goals. The goals of the document are that the authoring tool be accessible; that it generate accessible content by default; and that it encourage the creation of accessible content. In addition, some checkpoints have relative priority, in that they reference the priority levels of checkpoints from the Web Content Accessibility Guidelines 1.0 for which they provide implementation guidance in authoring tools.
The Checklist of Checkpoints for Authoring Tool Accessibility Guidelines 1.0 that accompanies these guidelines provides a reference listing, by priority, of all ATAG 1.0 checkpoints, for assessing current product features with regard to ATAG 1.0. A W3C Note Techniques for Authoring Tool Accessibility 1.0 describes strategies for implementing the checkpoints and provides references to material relevant for specific topics such as the accessibility of multimedia content.
Techniques for Authoring Tool Accessibility 1.0 includes references to tools, including open-source tools, that demonstrate different strategies for meeting the checkpoints. In addition, W3C's continuing development of its open-source test-bed authoring tool/browser Amaya has started to implement ATAG 1.0.
The Web Accessibility Initiative publishes a wide range of resources to support accessibility of the Web. Many of these are linked from the "resources" section of the WAI home page, such as other guidelines and techniquesdocuments; easy introductions to Web accessibility (Quick Tips, Curricula, WAI Overview, etc.); technical references (on HTML, CSS, SMIL, and other W3C technical reports); and a collection of pages with relevant reference links (policies, alternate browsers, evaluation tools, etc.).
ATAG 1.0 has three levels of conformance, which correspond to its three priority levels. Authoring tools that satisfy all priority one checkpoints conform at "Level-A"; authoring tools that satisfy all priority one and two checkpoints conform at level "Double-A"; and authoring tools that implement all three priority levels conform at level "Triple-A". All conformance levels include relative priority checkpoints.
An authoring tool that supports these guidelines will most likely claim conformance at the appropriate conformance level. Further information on claims of conformance for ATAG 1.0 is available on the Web. The Authoring Tool Guidelines Working Group will continue to compile implementation information, available at the time of this release in a preliminary report only, and list authoring tools that conform to different ATAG 1.0 conformance levels as those tools become available and as information about new tools becomes available to the Web Accessibility Initiative.
It is possible to create accessible Web pages with non-conformant tools, by using either a text editor, WYSIWYG, or other editor, and directly applying the Web Content Accessibility Guidelines 1.0 while creating the page. This may involve more steps than if using a conformant tool, for instance going into the source code to ensure that the tool is generating valid code, or performing steps manually to check the accessibility of a page. For authors who are less familiar with the Web Content Accessibility Guidelines 1.0, authoring tools that conform to ATAG 1.0 may significantly facilitate production of accessible Web sites.
It depends - authoring tools are easy or difficult to use according to the level of user experience they presume. The fact that a tool supports ATAG 1.0 should not directly affect its ease of use, with the exception that when authoring accessible pages, an ATAG-conformant tool would be easier to use than a similar tool that was not ATAG-conformant since the first tool would automate some steps involved in making a Web page accessible.
Yes. An ATAG-conformant tool should be usable by people with disabilities since accessibility of the tool itself is covered by the guidelines.
Yes. Conformant tools will allow people to create interesting Web pages. The degree of "interest" in a Web page can be related to the design skills of the author, the nature of the content on the page, and the capabilities of the authoring tool with regard to support for different markup languages (HTML, SMIL, SVG, etc.) and presentation formats (CSS1, CSS2, etc.). Whatever the capabilities of the tool, ATAG 1.0 provides guidance on how to ensure that those capabilities support accessibility.
No. While ATAG-conformant tools can automate some accessibility requirements, such as production of valid markup, they cannot automate all accessibility requirements. For instance, they cannot automate reliable production of alternative text for a complex image used in a specific context -- however, they may be able to automate re-use of that alternative text the next time that the image appears on a Web site.
Yes. One of W3C's primary goals is to promote the interoperability of the Web. ATAG 1.0 emphasizes production of content that is consistent with established Web standards, and which therefore has the greatest chance of working across current browsers as well as the browsers of the future, as Web technologies converge.
Yes. ATAG-conformant tools include help files which explain how to perform potentially unfamiliar steps such as captioning audio or describing video for the first time, where relevant to the type of tool. In addition, sample or tutorial files accompanying conformant tools would include some examples of how to author accessibility information.
Yes. ATAG-conformant tools are required to provide functions for validating accessibility of the Web pages they produce.
Yes, some tools will. The extent of configurability depends on the type of tool. In many tools, functions such as prompting, alerts, and validation could be adjusted or turned off by the user; while other tools might always have accessibility features "turned on."
Not necessarily. This depends on the type of tool. Some tools assume no knowledge of HTML or other markup language, and others either require some knowledge, or allow the user to edit source code directly when needed. With tools that do not conform to ATAG 1.0, the user often must know some HTML to be able to fix accessibility problems that the tool creates.
This depends primarily on the type of tool used to produce existing source code. A page already using valid code should not require conversion for the purpose of accessibility, although it might require the addition of information such as providing a summary for a table. A page containing large amounts of inaccessible markup from a previous authoring tool could require conversion or "repair" of the source code. Some conformant tools may make conversions automatically; while others might reject code that is invalid.
Because ATAG 1.0 went to Recommendation before the phase of Candidate Recommendation was part of the W3C Process, only a fairly rudimentary assessment of existing implementations was done at that time. As more implementation experience with ATAG 1.0 is accumulated, it has become clear that there are several issues in need of clarification. Since some of these issues, require changes that go beyond the level of errata, the group decided that a new version of ATAG was desirable. Further impetus for a new version is the ongoing development of a new version of WCAG, on which ATAG normatively depends.
ATAG 1.0 refers normatively to WCAG 1.0 for its requirements on content. Ideally, in keeping with this model, the group would like to release, the new version of the ATAG Recommendation as ATAG 2.0 as soon as possible after the release of WCAG 2.0. However, in order to complete the Candidate Recommendation Process, it is important to have the draft and supporting materials ("Techniques" Note, etc.) prepared as far in advance as possible. This opens up the possibility that a new version of ATAG will be ready before WCAG 2.0 has been released. In this event, the group wanted to keep open the possibility of publishing the new version as a 1.X update, in order to keep the major ATAG version number parallel with the WCAG version number on which it depends
More detailed analysis is available in the changes history
Authoring tool developers wishing to make a conformance claim to a W3C Recommendation should use ATAG 1.0, since that is the current Recommendation. However, now that a draft of the "Wombat" version is available, tool developers should read that version, especially for planning of development which is not expected to be complete before 2003. During a Candidate Recommendation phase, the Working Group will be actively seeking to show that the requirements have been implemented, in an interoperable way.
Please note that the current "Wombat" draft is only a work in progress, and may be changed. In particular, W3C Process requires that the working group is not constrained in its development of the draft by implementation in products, although relevant implementation experience will always be considered by the Working Group. Although the Working Group cannot predict a final date for a release of the "Wombat" draft as a Recommendation, it is not expected to happen during the first half of 2002.
A Wombat is an Australian animal. It is a marsupial (keeps its young in a pouch) that live underground, and it is a powerful tunnel builder. More information about wombats can be found on the web - for example information provided by the Tasmanian Parks and Wildlife Service, or a "Wombat fan page".