[Contents] [Implementing]
Copyright © 2011 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 both (1) more accessible to authors with disabilities and (2) designed to enable, support, and promote the production of accessible web content by all authors.
The "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 document is the internal working draft used by the AUWG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines (ATAG) 1.0 [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.
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 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.
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.
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 section is informative.
This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting authoring tool developers to make their authoring tools more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others.
Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities:
It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that, in reality, they are deeply inter-connected. For example, when a user participates in an online forum, they frequently author content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the content produced by the other forum users would reduce the overall accessibility of the forum.
The individuals and organizations that may use ATAG 2.0 vary widely and include authoring tool developers, authoring tool users (authors), authoring tool purchasers, and policy makers. In order to meet the varying needs of this audience, several layers of guidance are provided:
In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in the development of authoring tools is as simple as possible, ATAG 2.0 shares WCAG 2.0's three level conformance model: Level A (lowest), AA (middle), AAA (highest). For more information, see Understanding Levels of Conformance.
When implementing ATAG 2.0, authoring tool developers should carefully integrate features that support accessible authoring into the same "look-and-feel" as other features of the authoring tool. Close integration has the potential to:
The success criteria and the conformance applicability notes in this section are normative.
Rationale: When authoring tools (or parts of authoring tools) are web-based, conforming to WCAG 2.0 will facilitate access by all authors, including those using assistive technologies.
Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Rationale: When authoring tools (or parts of authoring tools) are non-web-based, following existing accessibility guidelines and implementing communication with platform accessibility services facilitates access by all authors, including those using assistive technologies.
Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform. (Level A)
Non-web-based authoring tools implement communication with platform accessibility services. (Level A)
Rationale: Some authors require access to alternative content in order to interact with the web content that they are editing.
If an editing-view renders non-text content with programmatically associated text alternatives, then the text alternatives can be programmatically determined. (Level A)
If an editing-view renders time-based media, then at least one of the following is true: (Level A)
Rationale: Some authors need access to details about the editing-view presentation, via their assistive technology, when that presentation is used to convey status information (e.g. underlining misspelled words) or provide information about how the end user will experience the web content being edited.
If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors. (Level A)
If a text property is both rendered and editable and the property can be communicated by the supported platform accessibility service, then the property is programmatically determinable. (Level A)
Rationale: Some authors with limited mobility or visual disabilities are not able to use a mouse, and instead require keyboard access to all of the functionality of the authoring tool.
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Keyboard traps are prevented as follows: (Level A)
The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation. (Level AA)
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
Keyboard access to the authoring tool can be customized. (Level AAA)
Authoring tool user interface components can be presented with any associated keyboard commands. (Level AAA)
Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or that require fast reaction speeds, such as clicking on a moving target.
If the authoring tool includes authoring session time limits, then the authoring tool saves all edits made by authors. (Level A)
If a time limit is set by the authoring tool, then at least one of the following is true: (Level A)
Authoring tool user interface components that accept pointer input are either stationary or authors can pause the movement. (Level A)
The authoring tool can be set to automatically save all content edits made by authors. (Level AAA)
Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.
Editing-views that render visual time-based content can be paused and can be set to not play automatically. (Level A)
Rationale: Some authors who have difficulty typing or operating the mouse benefit when authoring tools make use of the structure present in web content to simplify the tasks of navigation and editing the content.
If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g. source code, content renderings, etc.) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)
If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships. (Level AAA)
Rationale: Some authors who have difficulty typing or operating the mouse benefit from the ability to use text search to navigate to arbitrary points within the web content being authored.
Authors can perform text searches of web content that meet the following: (Level AA)
Rationale: Some authors need to set their own display settings in a way that differs from the presentation that they want to define for the published web content. Providing the ability to save and reload sets of keyboard and display preference settings benefits authors who have needs that differ over time (e.g. due to fatigue).
Authors can set their own display settings for editing-views without affecting the web content to be published. (Level A)
Authoring tool display settings and control settings can be saved between authoring sessions. (Level AA)
The authoring tool applies platform display settings and control settings. (Level AA)
Authors can save and reload multiple sets of any authoring tool display settings and control settings. (Level AAA)
The authoring tool includes a mechanism to help authors configure authoring tool display settings and control settings. (Level AAA)
Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how user agents will display the web content to end users. Authors with disabilities need the same opportunity to check their work.
If a preview is provided, then at least one of the following is true: (Level A)
If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)
Rationale: Some authors with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors.
For authoring actions, one of the following are true: (Level A)
If actions modify authoring tool settings, then one of the following are true: (Level A)
Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)
Rationale: Some authors may not be able to understand or operate the authoring tool user interface without proper accessible documentation.
All features that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)
All features of the authoring tool are documented. (Level AA)
Rationale: If authoring tools automatically specify web content that is not accessible, then additional repair tasks are imposed on authors.
Authors have the default option that, when web content is automatically generated for publishing after the end of an authoring session, it is accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Rationale: Accessibility information is critical to maintaining comparable levels of accessibility between the input and output of web content transformations.
If the authoring tool provides restructuring transformations or re-coding transformations, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
If the authoring tool provides optimizing web content transformations then any accessibility information (WCAG) in the input is preserved in the output. (Level A).
If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).
Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content (WCAG) requirements. To support accessible web content production, at minimum, it must be possible to produce web content that conforms with WCAG 2.0 using the authoring tool.
If the authoring tool places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Rationale: By guiding authors from the outset toward the creation and maintenance of accessible web content (WCAG) , web content accessibility problems (WCAG) are mitigated and less repair effort is required.
If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g. styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A)
Rationale: Improperly generated alternative content can create accessibility problems and interfere with accessibility checking.
See Also: This guideline applies when non-text content is specified by authors (e.g. inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.1.
Authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
During the authoring session, the authoring tool may only automatically suggest programmatically associated text alternatives for non-text content under the following conditions: (Level A)
The authoring tool avoids repairing programmatically associated text alternatives for non-text content using any text value that would also be available to user agents (e.g. do not use the image filename). (Level A)
When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA)
Rationale: Providing accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG) .
If the authoring tool provides templates, then there are accessible template options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
If authors are provided with a template selection mechanism, then both of the following are true: (Level AA)
If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates. (Level AA)
If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. (Level AAA)
Rationale: Providing accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG).
If authors are provided with a selection mechanism for pre-authored content other than templates (e.g. clip art gallery, widget repository, design themes), then both of the following are true: (Level AA)
If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA)
Rationale: Accessibility checking as an integrated function of the authoring tool helps make authors aware of web content accessibility problems during the authoring process, so they can be immediately addressed.
If the authoring tool provides authors with the ability to add or modify web content so that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g. an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. (Level A)
For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A)
Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)
Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA)
Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility problems will be properly addressed.
If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Rationale: The accessible content support features will be more likely to be used if they are turned on and are afforded reasonable prominence within the authoring tool user interface.
All accessible content support features are turned on by default. (Level A)
If authors can turn off an accessible content support feature, then they can turn the feature back on. (Level A)
If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)
Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g. invalid markup, syntax errors, spelling and grammar errors). (Level AA)
Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.
A range of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Instructions for using the accessible content support features appear in the documentation. (Level A)
A tutorial on an accessible authoring process that is specific to the authoring tool is provided. (Level AAA)
The documentation contains an index to the instructions for using the accessible content support features. (Level AAA)
This section is normative.
Conformance means that the authoring tool satisfies the applicable success criteria defined in the guidelines section. This conformance section describes conformance and lists the conformance requirements.
Because WCAG 2.0 [WCAG20] is the most recent W3C Recommendation regarding web content accessibility, ATAG 2.0 frequently refers to WCAG 2.0 in order to set requirements for (1) the accessibility of web-based authoring tool user interfaces (in Part A) and (2) how authors should be enabled, supported, and guided toward producing web content that is accessible to end users with disabilities (in Part B).
Whenever success criteria or defined terms in ATAG 2.0 depend on WCAG 2.0, they are marked with "(WCAG)".
Part of conformance to WCAG 2.0 is the requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported." In broad terms, WCAG 2.0 considers a web content technology to be "accessibility supported" when (1) the way that the web content technology is used is supported by users' assistive technology and (2) the web content technology has accessibility-supported user agents that are available to end users.
This concept is not easily extended to authoring tools because many authoring tools can be installed and used in a variety of environments with differing availabilities for assistive technologies and user agents (e.g. private intranets versus public websites, monolingual sites versus multilingual sites, etc.). Therefore:
ATAG 2.0 does not include the accessibility-supported requirement. As a result, ATAG 2.0 success criteria do not refer to WCAG 2.0 "conformance", but instead refer to "meeting WCAG 2.0 success criteria".
Once an authoring tool has been installed and put into use, it would be possible to assess the WCAG 2.0 conformance of the web content that the authoring tool produces, including whether the WCAG 2.0 accessibility-supported requirement is met. However, this WCAG 2.0 conformance assessment would be completely independent of the authoring tool's conformance with ATAG 2.0.
The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g. a photo editor, a CSS editor, a status update field in a social networking application, etc.), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s) (e.g. Success Criterion B.1.1.1 applies only to authoring tools that automatically generate web content after the end of authoring sessions).
If a conformance claim is made, a declaration that a success criterion is not applicable requires a rationale.
In order for an authoring tool to conform to ATAG 2.0, all of the following conformance requirements must be satisfied:
Authoring tools may conform "fully" or "partially" to ATAG 2.0. In either case, the level of conformance depends on the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance is intended to be used when developers have considered the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible) and the perspective of end users of web content produced by the authoring tools (Part B: Support the production of accessible content):
And the Part A Conformance Applicability Notes and Part B Conformance Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance is intended to be used when developers have initially focused on the accessibility of the authoring tool to authors (Part A: Make the authoring tool user interface accessible):
And the Part A Conformance Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Content Production: This type of conformance is intended to be used when developers have initially focused on the accessibility of the web content produced by the authoring tool to end users (Part B: Support the production of accessible content):
And the Part B Conformance Applicability Notes have been applied.
Note: The Working Group remains committed to the guiding principle that: "Everyone should have the ability to create and access web content". Therefore, it is recommended that "Partial" Conformance be claimed only as a step toward "Full" Conformance.
Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g. Full Level A conformance with respect to the production of XHTML 1.0, Partial Level AA Conformance: Content Production with respect to the production of SVG 1.1).
If an authoring tool is capable of producing multiple web content technologies, then the conformance may include only a subset of these technologies as long as the subset includes any technologies that the developer either sets for automatically-generated content or sets as the default for author-generated content. The subset may include "interim" formats that are not intended for publishing to end users, but this is not required.
When Success Criterion B.2.1.1 refers to web content technologies for which the authoring tool provides support for the production of accessible content, it is referring to this subset.
ATAG 2.0 may be applied to authoring tools with workflows that involve live authoring of web content (e.g. some collaborative tools). Due to the challenges inherent in real-time publishing, conformance to Part B of ATAG 2.0 for these authoring tools may involve some combination of support before (e.g. support in preparing accessible slides), during (e.g. live captioning as WCAG 2.0 requires at Level AA) and after the live authoring session (e.g. the ability to add a transcript to the archive of a presentation that was initially published in real-time). For more information, see the Implementing ATAG 2.0 - Appendix E: Authoring Tools for Live Web Content.
If a conformance claim is made, then the conformance claim must meet the following conditions and include the following information (authoring tools can conform to ATAG 2.0 without making a claim). Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation.
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 toward 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 toward, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Toward 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.
Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim that has not been published under the authority of the W3C, WAI, or AUWG.
This section is normative.
This appendix contains definitions for all of the significant/important/unfamiliar terms used in the normative parts of this specification, including terms used in the Conformance section. Please consult http://www.w3.org/TR/qaframe-spec/ for more information on the role of definitions in specification quality.
This section is informative.
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/WAI/AU/2011/ED-ATAG20-20110613/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Richards, J. Spellman, J. Treviranus, eds.,
W3C Recommendation, http://www.w3.org/TR/ATAG20/.
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.
This section is informative.
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.
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen Mardahl, Matt May, Charles McCathieNevile, Ann McMeekin, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Dana Simberkoff, Reed Shaffner, Michael Squillace, 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, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
[Contents]