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. 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 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 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.
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.
Please send comments about this document to the public mailing list: email@example.com (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.
Any software or service that authors may use to create or modify Web content for publication.
Within a single authoring tool, different parts of the authoring interface will fall under one or more of the following types of authoring functionality or functionality that falls outside this classification scheme. The types of authoring functions used will help determine which of the ATAG 2.0 implementation techniques are applicable to a particular tool:
Author has full control over all aspects of the resulting Web content that
have bearing on the final outcome. This covers, but is not limited to plain
text editing, as this category also covers the manipulation of symbolic
representations that are sufficiently fine-grained to allow the author the
same freedom of control as plain text editing (e.g. graphical tag placeholders).
Examples: Text editors, text editors enhanced with graphical tags, etc.
Techniques symbol: TBA
Author has control over entities that closely resemble the final appearance
and behaviour of the resulting Web content.
Examples: Rendered Web page editors, bitmap graphics editors, etc.
Techniques symbol: TBA
Author has control over non-WYSIWYG entities that represent a functional
abstraction from the low level aspects of the resulting Web content.
Examples: timelines, waveforms, vector-based graphic editors, etc.
Techniques symbol: TBA
Authors have control of only high-level parameters related to the automated
production of the resulting Web content.This may include interfaces that
assist the author to create and organize Web content without the author
having control over the markup or programming implementation.
Examples: Content managment systems, site building wizards, site management tools, courseware, weblogging tools, content aggregators and conversion tools, etc
Techniques symbol: TBA
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.
To understand the accessibility issues relevant to authoring tool design, consider that many authors may be creating content in contexts very different from your own (see "How People with Disabilities Use the Web [PWD-USE-WEB]):
Accessible design will benefit people in these different authoring scenarios and also many people who do not have a physical disability but who have similar needs. For example, someone may be working in a noisy environment and thus require an alternative representation of audio information. Similarly, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs as some users with disabilities.
The guidelines set forth in this document 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:
The first guideline addresses the accessibility of the authoring tool, itself. Guidelines 2, 3, and 4, on the other hand address the accessibility of the content produced by the tool. These three guidelines build upon each other, with guideline 2 establishing core requirements, guideline 3 establishing key user support functionality and guideline 4 specifying general considerations for how any functionality related to accessibility should be integrated with the rest of the tool.
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.
ATAG 2.0 builds upon the Web Content Accessibility Guidelines (WCAG). Authoring tools developed using these guidelines will commonly produce content that conforms to WCAG by default. This also means that authors using ATAG conforming tools will more easily produce quality content that can be accessed by larger audiences.
The Web Content Accessibility Guidelines are the global standard for Web accessibility. Many countries and organizations have adopted WCAG for their Web content. An ATAG-conformant tool indicates that the requirements set for authors in these environments can be met more easily.
Additionally, this draft refers to an ISO document titled "Ergonomics of human-system interaction - Guidance on accessibility for human-computer interfaces" [ISO16071]. The ISO document contains guidelines relevant to software and operating system accessibility.
A conformance claim (with or without an accompanying conformance icon) is an assertion that an authoring tool has satisfied the requirements of a chosen conformance level. Claimants (or relevant assuring parties) are solely responsible for the validity of their claims, keeping claims up to date, and proper use of the conformance icons.
The existence of a conformance claim (with or without an accompanying conformance icon) does not imply that W3C has reviewed the claim or assured its validity. As of the publication of this document, W3C does not act as an assuring party, but it may do so in the future, or it may establish recommendations for assuring parties.
Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to claim conformance to the most recent Authoring Tool Accessibility Guidelines Recommendation available.
This specification imposes no restrictions about:
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.
Authoring tools claiming conformance to ATAG 2.0 must also state a version of WCAG to which its output conforms. For example, a tool may claim ATAG 2.0 conformance with WCAG 1.0, because its accessibility checking tools test for WCAG 1.0 conformance, and the tool's output conforms to WCAG 1.0. Another tool may claim ATAG 2.0 conformance with WCAG 2.0 because its native file format has a WCAG 2.0 Techniques document, and/or could not claim conformance to WCAG 1.0. A third tool may claim ATAG 2.0 conformance with both versions of WCAG.
For information on ATAG 2.0 conformance regarding individual versions of WCAG, see Resolving ATAG 2.0 References to WCAG [WCAG-REFS].
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.
This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces.
The special nature of authoring interfaces dictates that special consideration be paid to several specific functions of the user interface design. These include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5).
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
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
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
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
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
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.
The first responsibility is to create valid, standards-based Web content, this can be rendered reliably by more user agents, including assistive technologies (Checkpoint 2.1). The next responsibility is to support formats that enable accessible content (Checkpoint 2.2).
Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that support this include ensuring that it is possible to author accessible content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).
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.1, Evaluation Techniques for Checkpoint 2.1
Rationale: Some formats are WCAG-capable, enabling the creation of web content that conforms to WCAG, while other formats may intrinsically preclude this possibility.
Techniques: Implementation Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint 2.2
Rationale: The ability to produce accessible Web content is the most basic requirement of this document.
Techniques: Implementation Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3
Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved 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). Accessibility information should also be preserved.
Techniques: Implementation Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint 2.4
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
Rationale: Pre-authored content (e.g. templates, images, videos) is often included with authoring tools for the convenience of the author. When this content is WCAG-conformant, it is more convenient for users and more easily reused.
Techniques: Implementation Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6
Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.
This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).
Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7), and ensuring that documentation demonstrates authoring practices and workflow processes that result in accessible content (Checkpoint 3.8).
All functions that support accessible authoring practices should allow author preferences to be configurable to allow for different authoring styles. Custom configurations should improve use of the tool and make authors more receptive to assistive interventions from the authoring tool.
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
Rationale: Authors may not notice or be able to identify accessibility problems. The tool can assist in their identification.
Techniques: Techniques for checkpoint 3.2, Evaluation Techniques for Checkpoint 3.2.
Rationale: Assistance by the tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.
Techniques: Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3
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
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
Rationale: This summary will help the author to improve the accessibility status of their work, keep track of problems and monitor progress.
Techniques: Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6.
Rationale: Without documentation 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.
Techniques: Implementation Techniques for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8
This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring the priority for accessible means of completing an authoring tasks (Checkpoint 4.1), ensuring the availibility of accessibility-related functions (Checkpoint 4.2), and ensuring that accessibility-related functions fit into the appearance and interactive style of the tool (Checkpoint 4.4).
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 a workflow in which the author considers accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analagous to internationalization, which is much easier when it is considered from the beginning rather than handled last.
Techniques: Implementation Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint 4.1
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
Rationale: If the features that support accessible authoring are difficult to find and activate, 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
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
"longdesc"attributes in HTML).
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.
BLOCKQUOTEelement 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 to the AUWG through review and comment: Giorgio Brajnik, Daniel Dardailler, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Liddy Nevile, 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 and Wombat.
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR.