Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This specification provides guidelines for Web authoring tool developers. Its purpose is two-fold: to assist developers in designing authoring tools that produce accessible Web content and to assist developers in creating an accessible authoring interface.
Authoring tools can enable, encourage, and assist users ("authors") in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. It is as important that all people be able to author content as it is for all people to have access to it. The tools used to create this information, therefore, must also be accessible. Implementation of these guidelines will contribute to the proliferation of Web content that can be read by a broader range of readers and authoring tools that can be used by a broader range of authors in a wider range of contexts with more devices.
This document is part of a series of accessibility documents published by the W3C Web Accessibility Initiative (WAI).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a Public Working Draft of a document which will supersede the W3C Recommendation Authoring Tool Accessibility Guidelines 1.0 [ATAG10]. It has been made available for review by W3C Members and other interested parties, in accordance with W3C Process. It is not endorsed by the W3C or its Members. It is inappropriate to refer to this document other than as a "work in progress".
This document has been produced by the Authoring Tool Accessibility Guidelines Working Group (AUWG) as part of the Web Accessibility Initiative (WAI). The goals of the Working Group are discussed in the AUWG charter.
The Working Group maintains a list of patent disclosures and issues related to ATAG 2.0.
A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR/. The AUWG is part of the WAI Technical Activity.
This draft refers to the Web Content Accessibility Guidelines (WCAG) for specification of accessible content and refers non-normatively to the Techniques for Authoring Tool Accessibility [ATAG20-TECHS]. The working group has provided a reference called ATAG 2.0 References to WCAG [WCAG-REFS] mapping the ATAG checkpoints to WCAG 1.0 and the January 2003 draft of WCAG 2.0, currently a W3C Working Draft.
The AUWG expects the ATAG 2.0 to be backwards-compatible with ATAG 1.0, or at most to make only minor changes in requirements. Before this document reaches last call, the Working Group will publish a detailed analysis of the differences in requirements.
The working group maintains an ATAG 2.0 Issues List.
Please send comments about this document to the public mailing list: w3c-wai-au@w3.org (public archives). Please note that this document may contain typographical errors. It was published as soon as possible since review of the content itself is important, although noting typographical errors is also helpful.
For information about the current activities of the working group, please refer to the AUWG home page. This page includes an explanation of the inter-relation of each document as well as minutes and previous drafts.
Everyone should have the ability to create and access Web content.
Authoring tools are pivotal in achieving this principle. The accessibility of authoring tools determines who can create Web content and the output of authoring tools determines who can access Web content.
The guidelines set forth in this document will benefit people regardless of disability. This includes people who need to use their eyes for another task and are unable to view a screen, people in environments where the use of sound is not practical, and people who use small mobile devices with small screens, no keyboard, or no mouse.
The guidelines promote the following goals:
The accessibility of authoring tools is defined primarily by existing specifications for accessible software. The accessibility of authoring tool output is defined by the Web Content Accessibility Guidelines (WCAG).
This document contains four guidelines that reflect the goals of accessible authoring tool design:
Each guideline includes:
Each checkpoint is intended to be sufficiently specific to be verifiable, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to satisfy it. The checkpoints specify requirements for meeting the guidelines. Each checkpoint includes:
A separate document, entitled "Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS], provides suggestions and examples of how to achieve the recommendations in this document. Another document [ATAG20-CHECKLIST] lists all checkpoints, ordered by priority, for convenient reference.
Each checkpoint in the specification has been assigned one of the following priority levels to indicate the importance of the checkpoint in satisfying the guidelines:
Note: The choice of priority level for each checkpoint is based on the assumption that the author is a competent, but not necessarily expert, user of the authoring tool, and that the author has little or no knowledge of accessibility. For example, the author is not expected to have read all of the documentation, but is expected to know how to turn to the documentation for assistance.
An ATAG conformance claim for an authoring tool must indicate which of the following conformance levels has been met:
In the above, "meeting the checkpoints" means satisfying all of the success criteria associated with that particular checkpoint.
For the purposes of ATAG 2.0 conformance claims, tools may be bundled together (e.g. a markup editor and a evaluation and repair tool or a multimedia editor with a custom plug-in), however, this has two important consequences:
Satisfying certain success criteria may involve usability issues and as such may require integrating aspects of usability testing.
Conformance Icons: There are currently no conformance icons available for this draft specification. If it becomes a Recommendation, it is expected that there will be conformance icons like those available for ATAG 1.0.
From the standpoint of accessibility, Web authoring is a process that may involve one or more tools in parallel or in sequence. In order to ensure that the Web content produced as a result of a Web authoring process is accessible, developers and purchasers should choose tools that are either ATAG 2.0 conformant or ATAG 2.0-"Friendly". ATAG-"Friendly" tools are tools which, although they do not conform with ATAG, are also very unlikely to degrade the accessibility of Web content. For example, an ATAG-friendly tool is one that converts the URI locations in a Web page from absolute to relative prior to publishing.
In some cases, strategic ordering of the tools in a Web authoring process may increase the likelihood of producing accessible content. For example, a markup editor that does not conform to ATAG might be used before an ATAG conformant evaluation and repair tool. While this is, of course, preferable to not addressing accessibility at all, the original markup tool is still considered ATAG non-conformant. Considering the markup editor and evaluation and repair tool together is possible, but due to the low likelihood of proper integration between the tools, the result is unlikely to be a high level of ATAG conformance.
An authoring tool is a software program with standard user interface elements and as such must be designed according to relevant user interface accessibility guidelines. When custom interface components are created, it is essential that they be accessible through the standard access mechanisms for the relevant platform so that assistive technologies can be used with them.
Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document.
Authoring tools must also ensure that the author can navigate a document efficiently while editing. Authors who use screen readers, refreshable Braille displays, or screen magnifiers can make limited use (if any) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (especially people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation.
Note: Documentation, help files, and installation are part of the software and need to be available in an accessible form.
Rationale: If the authoring tool interface does not follow these conventions, the author who depends upon the techniques associated with the conventions is not likely to be able to use the tool.
Techniques: Implementation Techniques for Checkpoint 1.1, Evaluation Techniques for Checkpoint 1.1
Success Criteria:
Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays or screen enhancers. The explicit property value should be accessible to those technologies which read text and support authors editing text.
Techniques: Implementation Techniques for Checkpoint 1.2, Evaluation Techniques for Checkpoint 1.2
Success Criteria:
Rationale: Authors may require a set of display
preferences to view and control the document that is different from
the desired default
display style for the published document (e.g. a particular
text-background combination that differs from the published
version).
Techniques: Implementation Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint 1.3
Success Criteria:
Rationale:
Efficient authoring requires that the author be able to move
quickly to arbitrary locations in the content and, once there, make
modifications beyond character-by-character edits. This is usually best
accomplished by making use of any explicit structure that may have been
encoded with hierarchy-based markup. When explicit structure is
unavailable, the implicit structure in the visual look and layout of
content may sometimes be used.
Techniques: Implementation Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint 1.4
Success Criteria:
Rationale: Search functions facilitate author navigation of content as it is being authored by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the accessibility of the search function.
Techniques: Implementation Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint 1.5
Success Criteria:
The most basic determinant of the accessibility of Web content is the degree to which the authoring tool that produced it gives priority to markup validity and accessibility. Tools that generate and preserve high quality markup are well prepared to meet the other guidelines.
Conformance with standards promotes interoperability and accessibility by making it easier to create specialized user agents that address the needs of users with disabilities. In particular, many assistive technologies used with browsers and multimedia players are only able to provide access to Web documents that use valid markup. Therefore, valid markup is an essential aspect of the accessibility compliance of an authoring tool.
Where applicable use W3C Recommendations, which have been reviewed to ensure accessibility and interoperability and which are relied upon by assistive technology developers. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.
Rationale: Following language specifications is the most basic requirement for accessible content production. When content is valid, it is easier to check and correct accessibility errors and user agents are better able to render the content properly and personalize the content to the needs of individual users' devices.
Techniques: Implementation Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint 2.2
Success Criteria:
Rationale: The W3C has implemented an accessibility review process for language recommendations that has resulted in addition of supports for accessibility within many of these languages as well as published Notes describing best use practices for some of the most popular languages. Because this process is ongoing, more recent versions of W3C language recommendations are likely to include better supports for accessibility than older ones.
Techniques: Implementation Techniques for Checkpoint 2.1, Evaluation Techniques for Checkpoint 2.1
Success Criteria:
If the tool automatically generates markup, many authors will be unaware of the accessibility status of the final content unless they expend extra effort to review it and make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, authoring tools are responsible for automatically generating accessible markup, and where appropriate, for guiding the author in producing accessible content.
Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format specifically intended for the Web such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. It is essential that these processes do not introduce inaccessible markup or remove other content intended to increase accessibility, particularly when a tool hides the markup changes from the author's view.
Rationale: If it is at least possible for the author to produce accessible content, then well-informed authors may be able to work around any accessibility short-comings in the rest of the authoring tool.
Techniques: Implementation Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3
Success Criteria:
Rationale: Authors will be discouraged from adding accessibility information if it is discarded during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language).
Techniques: Implementation Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint 2.4
Success Criteria:
Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.
Techniques: Implementation Techniques for Checkpoint 2.5, Evaluation Techniques for Checkpoint 2.5
Success Criteria:
Rationale: Pre-authored content (e.g. templates, images, videos, etc.) is often included with authoring tools for the convenience of the author. Ensuring that pre-authored content is WCAG conformant increases that convenience by ensuring that authors can use any of the content without concern for the accessibility implications and relieving subsequent authors from having to compose their own version of alternative content.
Techniques: Implementation Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6
Success Criteria:
Rationale: Markup that is not recognized by an authoring tool may have been added to enhance accessibility. Also, newer XML-based languages, such as XHTML 1.1, allow authors to include multiple languages in a single document, via namespaces. In the future, documents may contain metadata, including accessibility information, in another namespace. Authoring tools must not strip this information when it is encountered.
Techniques: Implementation Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint 2.7
Success Criteria:
Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to effect the accessibility of content, either positively, if the author is purposefully following accessibility guidelines, or negatively, if the author is not. In order to manage these effects, authoring tools should support the author by guiding them to follow accessibility authoring practices as they produce that content that involves an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility-related documentation.
Conformance with accessibility authoring practices is an authoring constraint that is little different, in principle, from the constraint to produce valid code or grammatical text. Since the role of authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. For example, tools may assist authors to follow specific practices by suggesting accessible authoring practices or prompting for information that cannot be generated automatically, such as equivalent alternatives (alternate text, descriptions, captions, etc.).
Many authoring tools already allow authors to create documents with little or no need for knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction when either the markup is hidden from the author or the author does not know how to correct it.
Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can choose how to configure the tool's accessibility features to support their regular work patterns are more likely to feel comfortable with their use of the tool and be receptive to interventions from the tool. (see guideline 4). For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session. This choice is analogous to that offered in programming environments that allow authors to decide whether to check syntax during editing or at compilation.
Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes and authors.
Techniques: Implementation Techniques for Checkpoint 3.1, Evaluation Techniques for Checkpoint 3.1
Success Criteria:
Rationale: Authors may not notice or be able to identify accessibility problems.
Techniques: Techniques for checkpoint 3.2, Evaluation Techniques for Checkpoint 3.2.
Success Criteria:
Rationale: Assistance may expedite the task of correcting some authors' accessibility problems, while other authors may be unable to correct accessibility problems without this help.
Techniques: Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3
Success Criteria:
Rationale: Improperly generated alternatives can create accessibility problems and interfere with accessibility checking.
Techniques: Implementation Techniques for Checkpoint 3.4, Evaluation Techniques for Checkpoint 3.4
Success Criteria:
Rationale: Simplifying the initial production and later reuse of alternative equivalents will encourage authors to use them more frequently. In addition, such an alternative equivalent management system will facilitate meeting the requirements of Checkpoint 3.4.
Techniques: Implementation Techniques for Checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5
Success Criteria:
Rationale: This summary will prompt the author to: improve the accessibility status; keep track of problems; and monitor progress.
Techniques: Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6.
Success Criteria:
Some Web authors may not be familiar with accessibility issues that arise when creating Web content, while others may be authors familiar with these issues, but may not know how the tool can help to address them. Therefore, help and other supplied documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.
Rationale: Without documention of the features that promote accessibility (e.g. prompts for alternates, code validators, accessibility checkers, etc.) authors may not find or use them.
Techniques: Techniques for checkpoint 3.7, Evaluation Techniques for Checkpoint 3.7.
Success Criteria:
Rationale: If authors must look somewhere special for information on accessible authoring practices, they may be unlikely to make the effort. Familiarity with these practices will be promoted by their integration.
Techniques: Implementation Techniques for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8
Success Criteria:
Rationale: Authors will be more likely to use features that promote accessibility if they understand when and how to use them.
Techniques: Techniques for checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9
Success Criteria:
When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool.
Rationale: If the features that support accessible authoring are difficult to find, activate or use, they are less likely to be used. Ideally, these features should be turned on by default.
Techniques: Implementation Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint 4.1
See Also: ATAG Checkpoints 3.1, 3.2, and 3.3.
Success Criteria:
Rationale: Authors are most likely to use the first and easiest options.
Techniques: Implementation Techniques for Checkpoint 4.2, Evaluation Techniques for Checkpoint 4.2
Success Criteria:
Rationale: Most authors are reluctant to use features that depart from the conventions of a tool.
Techniques: Implementation Techniques for Checkpoint 4.3, Evaluation Techniques for Checkpoint 4.3
Success Criteria:
"alt"
, "title"
, and
"longdesc"
attributes in HTML).IMG
or DL
), the values of its attributes,
and information associated by means of a style sheet. In a
database, properties of a particular element may include values of
the entry, and acceptable data types for that entry.BLOCKQUOTE
element in HTML
[HTML4]to
achieve an indentation visual layout effect. Structural markup
should be used correctly to communicate the roles of the elements
of the content and presentation
markup should be used separately to control the
presentation and layout.Many thanks to the following people who have contributed through review and comment: Giorgio Brajnik, Daniel Dardailler, Katie Haritos-Shea, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Matthias Müller-Prove, Graham Oliver, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Carlos Velasco.
This document would not have been possible without the work of those who contributed to The Authoring Tool Accessibility Guidelines 1.0
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR.