[Contents] [Techniques]
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as enabling, supporting, and promoting the production of accessible Web content by all authors.
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 is the W3C Working Draft of 24 November 2008. This draft integrates changes made as a result of comments received on the 10 March 2008 Public Working Draft and also includes changes intended to keep the document harmonized with WCAG 2.0. Substantial changes include:
The Working Group seeks feedback on the following points for this draft:
Comments on this editor's draft are due on or before 6 January 2009. Comments on the draft should be sent to public-atag2-comments@w3.org (Public Archive).
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 1.0 (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, except where noted.
This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting developers to make the 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. However, even authoring tools that conform to ATAG 2.0 may not be able to address the needs of people with all types, degrees and combinations of disabilities.
In order to achieve accessibility, authoring tools must address the needs of two (potentially overlapping) user groups:
The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Creation of authoring tools that address the specialized needs of these communities for is encouraged, but is outside the scope of this document.
These guidelines have been written to address the requirements of many different audiences, including, but not limited to:
This section is normative.
ATAG 2.0 defines an "authoring tool" as any application, part of an application, or collection of applications that authors interact with to create, modify or assemble Web content to be used by other people.
The definition applies to all or part of the following types of applications:
Authoring tools are just one aspect of accessibility. For an overview of the different components of accessibility and how they work together see:
ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes principles and associated guidelines that are related to ensuring accessibility of the authoring tool user interface to authors with disabilities. Part B contains principles and guidelines related to ensuring support by authoring tools for the creation of accessible Web content by any author (not just those with disabilities) to end users with disabilities.
The guidelines and success criteria in Part A are organized around the following four principles, adapted from the four principles in WCAG 2.0:
There are three principles in Part B:
Note: While the requirements in Part B do not deal with the accessibility of the authoring tool user interface per se, it should be noted that any of the features (e.g., checker, tutorial) added to an authoring tool to meet the Part B success criteria must also meet the user interface accessibility requirements of Part A.
Under each guideline there are success criteria that describe specifically what must be achieved in order to conform. They are similar to the "checkpoints" in ATAG 1.0. Each success criterion is written as a statement that will be either true or false when a specific authoring tool is tested against it. While all of the ATAG 2.0 success criteria are written to be testable and some test automation may be possible, human testing will usually be required. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest).
Each of the success criteria has a link to the Techniques document that provides:
Note: Any success criteria that are judged not applicable to a particular authoring tool are treated as satisfied for conformance purposes, as long as a rationale is provided.
Authoring tools may claim full conformance to ATAG 2.0 at one of three "full" conformance levels. The level achieved depends on the level of the success criteria that have been satisfied. The full conformance levels are:
In addition, a "partial conformance" claim option is available in cases where an authoring tool has satisfied all of the success criteria at a specified level in one of the two Parts of the document (i.e., "Part A: Make the authoring tool user interface accessible" and "Part B: Support the production of accessible content"). The partial conformance levels are:
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 as a step towards full conformance.
ATAG 2.0 is intended to be used in conjunction with WCAG 2.0 or similar Web content accessibility guidance (e.g., WCAG 1.0, regulations that include WCAG 2.0, etc.).
The relationship is as follows:
The success criteria and applicability notes in this section are normative.
Scope: The success criteria in Part A apply to all aspects of the authoring tool user interface that are under the control of the developer. This includes functionalities that are independent of the content being edited, such as what is sometimes referred to as the authoring tool's "chrome" (e.g., menus, button bars, status bars, etc.) and also user preferences and documentation, etc. In addition, the developers' responsibility covers certain aspects of other functionalities that reflect the content being edited (e.g., ensuring that an image label present in the content is available programmatically). However, where an accessibility problem in the user interface is caused directly by an accessibility problem in the content it is reflecting (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
Rationale: In addition to generally improving the accessibility of the authoring tool user interface, implementing Web-based functionality (e.g., editing views, documentation) using accessible Web content facilitates communication with assistive technologies via user agents.
A.1.1.1 Web-Based Accessible (Level A): Web-based authoring tool user interfaces conform to WCAG Level A. (Level A)
A.1.1.2 Web-Based Accessible (Level AA): Web-based authoring tool user interfaces conform to WCAG Level AA. (Level AA)
A.1.1.3 Web-Based Accessible (Level AAA): Web-based authoring tool user interfaces conform to WCAG Level AAA. (Level AAA)
This guideline also applies to parts of authoring tools that are Web-based (e.g., help systems).
Rationale: Following existing accessibility standards and/or platform conventions will facilitate access by all authors, including those using assistive technologies.
A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces comply with, and cite in the conformance claim, the "Level A" requirements of standards and/or platform conventions that benefit accessibility. The "Level A" requirements are those that are functionally equivalent to WCAG Level A success criteria. (Level A)
A.1.2.2 Non-Web-Based Accessible (Level AA): Non-Web-based authoring tool user interfaces comply with, and cite in the conformance claim, the "Level AA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AA" requirements are those that are functionally equivalent to WCAG Level AA success criteria. (Level AA)
A.1.2.3 Non-Web-Based Accessible (Level AAA): Non-Web-based authoring tool user interfaces comply with, and cite in the conformance claim, the "Level AAA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AAA" requirements are those that are functionally equivalent to WCAG Level AAA success criteria. (Level AAA)
This guideline also applies to parts of authoring tools that are non-Web-based (e.g., client-side file uploaders).
2.1.1 Accessibility Platform Architecture: Support an accessibility platform architecture relevant to the platform.
2.1.2 Name, Role, State, Value, Description: For all user interface components (including the user interface and the content being edited), the name, role, state, value, description are made available via an accessibility platform architecture.@@more work needed@@ @@techs includes "visited link state"
2.1.3 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. @@techs include CSS DOM
2.1.4 Write Access: If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically.
2.1.5 Properties: If any of the following properties are supported by the accessibility platform architecture, they must be made available via the architecture:
Non-Web-based user agent interfaces only.
Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information because there are a variety of ways to display text (e.g., magnification, enhancement, text-to-speech, Braille output)
A.2.1.1 Alternative equivalents in the content: Editing views that render non-text content (e.g., WYSIWYG) provide authors with access to any equivalent alternatives recognized by the authoring tool. (Level A)
This guideline does not apply to plain text editors as they do not render non-text content.
Rationale: Authors need to have access to and control over both the functional significance of presentation and also, in the context of authoring, the presentation that will be experienced by the end user. This is especially important for user interface components that do not implement an accessibility platform architecture or leverage existing implementations (e.g. custom user interface components built via JavaScript and CSS). Some authors require display settings that differ from the presentation that they intend to define for the published content (e.g., using a high contrast setting during editing content that is not intended to be high contrast).
A.2.2.1 Purpose of Added Presentation: If the authoring tool modifies the presentation of the content being edited, then the functional purpose for the modification is made available via the platform (e.g., if misspelled text is underlined, the fact that it is misspelled is made available). (Level A)
A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties are made available via the platform (Level A):
A.2.2.3 Access to Text Presentation (Enhanced): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG) and are editable by any editing view are available via the platform. (Level AAA)
Rationale: Some authors will require display settings that differ from the presentation that they intend to define for the published content (e.g., an author uses large fonts for themselves, while editing content that is not intended to have a large font in the final content).
A.2.3.1 Independence of Display: Editing views that usually have their display characteristics set by rendering the content being edited (e.g., WYSIWYG) allows the authors' visual and audio display settings to override these characteristics without affecting the content being edited (e.g., markup, style sheets, etc.). (Level A)
Rationale: Providing alternate keyboard accessibility provides access for people with limited mobility and people with visual disabilities, who cannot rely on hand-eye coordination for navigating the user interface.
A.3.1.1 Important Command Functions: If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them (where allowed by the operating environment) (Level A):
A.3.1.2 Importing Content Keyboard Trap: The authoring tool prevents keyboard traps as follows (Level A):
Web-based authoring tools may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria.
Rationale: People who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then authors have the global option to ensure that the content being edited is saved. For Web-based authoring tools, this applies to any content that has already been submitted to the server by the user agent. (Level A)
A.3.2.2 Timing Adjustable: The author is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. "press the space bar"). (Level A)
A.3.2.3 Moving Targets: If the user interface includes any moving targets for authors' actions (e.g.,a selectable component of an animation), then authors can stop that movement. (Level A)
Several of the success criteria in this guideline only apply when there are time limits put on the author.
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
A.3.3.1 Static View: If an editing view renders content (e.g., WYSIWYG) then the author has the global option of a static view in which time-based content appears in a fixed state. (Level A)
Rationale: People who have difficulty typing or operating the mouse benefit when authoring tools use the structure present in the content to simplify navigation and editing.
A.3.4.1 Edit by Structure: If an editing view displays a structured element set, then authors can, with a simple action, select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. (Level A)
A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next identical element. (Level AA)
A.3.4.3 Navigate By Headings: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the heading, regardless of level. (Level AA)
A.3.4.4 Navigate Tree Structures: If an editing view displays a structured element set, authors can, with a simple action, move the editing focus from any element to other elements in the set with any of the following relationships (if they exist) (Level AA):
Rationale: People who have difficulty typing or operating the mouse benefit from the ability to navigate to arbitrary points within editing views.
A.3.5.1 Text Search: A function is provided that allows text search of the content, which meets the following conditions (Level AA):
Web-based authoring tools may rely on the "find" function of the user agent listed in the conformance profile to help perform searches.
Rationale: Providing the ability to save and reload sets of keyboard and display preference settings benefits people using multi-user tools as well as people who have needs that differ over time (e.g., due to fatigue).
A.3.6.1 Save Settings: Preference settings are stored for any of the following that the authoring tool controls (i.e., not controlled by the platform) (Level AA):
A.3.6.2 Multiple Sets: Choosing between multiple sets of preferences (e.g., personal profiles, personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform) (Level AAA):
A.3.6.3 Options Wizard: Authors are provided with an accessibility option-setting "wizard" to configure options related to Part A. (Level AAA)
Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how content will appear to end users in a user agent. Authors with disabilities need to be able to follow the same workflow.
Note: Previews are treated differently than editing views because authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this guideline.
A.3.7.1 Return Mechanism: If a preview is provided, then it is possible to return from the preview using a simple action which is documented in the help system. (Level A)
A.3.7.2 Preview: If a preview is provided, then it meets at least one of the following (Level A):
Rationale: People who have difficulty making fine movements may be prone to making unintended actions.
A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. (Level A)
A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to the author that the setting modification is irreversible. (Level A)
A.4.1.3Redo: Authors can immediately reverse the most recent content "undo(s)" (i.e., a "redo" function). (Level AA)
A.4.1.4Multiple Undos: Authors can reverse at least 5 consecutive reversible authoring actions. (Level AAA)
Rationale: While intuitive user interface design is valuable to many authors, some people may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.
A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of these guidelines (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)
A.4.2.2 Accessibility Feature Tutorials: Tutorials are provided for some of the features that are specifically required to meet Part A of these guidelines. (Level AAA)
The accessibility of the documentation is covered by Guideline A.1.1 and A.1.2.
Rationale: Choosing technologies which support the possibility of accessible authoring is the first step in ensuring that the content produced is accessible.
B.1.1.1 Tool Choice of Technologies (Level A): Any Web content technologies that are automatically selected by the authoring tool can conform to WCAG Level A. (Level A)
B.1.1.2 Author Choice of Technologies (Level A): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level A are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task. (Level A)
B.1.1.3 Tool Choice of Technologies (Level AA): Any Web content technologies that is automatically selected by the authoring tool can conform to WCAG Level AA. (Level AA)
B.1.1.4 Author Choice of Technologies (Level AA): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level AA are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task. (Level AA)
B.1.1.5 Tool Choice of Technologies (Level AAA): Any Web content technologies that is automatically selected by the authoring tool can conform to WCAG Level AAA. (Level AAA)
B.1.1.6 Author Choice of Technologies (Level AAA): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level AAA are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task. (Level AAA)
Rationale: Accessibility information is critical to maintaining comparable levels of accessibility across transformations and conversions.
B.1.2.1 Target Preserves Accessibility Information : If the target technology of the transformation or conversion can preserve *recognized* accessibility information that is required for that content to conform to WCAG Level A, then the accessibility information is preserved and available for end users in the resulting content. (Level A)
B.1.2.x Target Cannot Preserve Accessibility Information: If the target technology of the transformation or conversion cannot preserve *recognized* accessibility information that is required for that content to conform to WCAG Level A, then the authoring tool (Level A):
B.1.2.2 Accessibility Information Preservation (Enhanced): If the authoring tool performs transformations or conversions during an authoring session, then any accessibility information in the pre-transformation/conversion content that is required for content to conform to WCAG Level AA or AAA is preserved and available for end users in the resulting content. (Level AA)
B.1.2.3 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true (Level AA):
If an authoring tool performs transformations or conversions after an authoring session ends (e.g., a batch maintenance process) only option (a) is allowed for both B.1.2.1 and B.1.2.3.
Rationale: Authoring tools that automatically generate content that is not accessible impose additional repair tasks on authors.
See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.
B.1.3.1 Automatic Accessible (Level A): If the authoring tool automatically generates content, then that content meets WCAG Level A prior to publishing.
B.1.3.2 Automatic Accessible (Level AA): If the authoring tool automatically generates content, then that content meets WCAG Level AA prior to publishing. (Level AA)
B.1.3.3 Automatic Accessible (Level AAA): If the authoring tool automatically generates content, then that content meets WCAG Level AAA prior to publishing. (Level AAA)
Principle B.2 applies to authoring tool processes that interact with human authors, and the authoring choices that author is making or the authoring choices under the control of the authoring tool. Authoring choices include choice of style sheets, templates, scripts, etc
Rationale: By guiding authors from the outset towards the creation and maintenance of accessible content, accessibility problems are mitigated and less repair and retrofit effort is required.
See also: For more information on how to prompt, see ATAG 2.0 Techniques - Appendix A: Prompting for Different Types of Accessibility Information. Repair features (see Guidelin B.2.3) are also an important aspect of author guidance.
B.2.1.1 Guide Accessible (Level A): If authors are prompted for any information as content is being added or updated (e.g., by an image modification dialog), then the tool also prominently prompts for any accessibility information required for that content to meet WCAG Level A (Level A).
B.2.1.3 Guide Accessible (Level AA): If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet WCAG Level AA. (Level AA)
B.2.1.5 Guide Accessible (Level AAA): If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet WCAG Level AAA. (Level AAA)
Rationale: Checking as an integrated function of the authoring tool helps make authors aware of accessibility problems during the authoring process, so they can be immediately addressed.
See also: For more information, see ATAG 2.0 Techniques - Appendix A: Levels of Checking Automation.
B.2.2.1 Check Accessibility (Level A): At least one individual check is associated with each WCAG Level A Success Criterion that the tool has the functionality to modify (e.g., a tool that inserts images should check for alt text; a tool that can edit captions should check for them). (Level A)
B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool. (Level A)
B.2.2.3 Help Authors Locate: For any checks that require author judgment to determine whether a potential accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified (e.g., displaying the surrounding text, "Is a sign language interpretation provided?") (Level A)
B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide. (Level A)
B.2.2.5 Check Accessibility (Level AA): At least one individual check is associated with each WCAG Level AA Success Criterion that the tool has the functionality to modify. (Level AA)
B.2.2.6 View Status: If the authoring tool records accessibility problems found during checking, then a list of any accessibility problems is available to authors prior to the end of the authoring session. (Level AA)
B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking , authors have the option to save the list to facilitate interoperability between checking and repair. (Level AA)
B.2.2.8 Metadata for Discovery: If the authoring tool records accessibility status, then authors have the option to associate this status with the content as metadata to facilitate resource discovery by end users. (Level AA)
B.2.2.9 Check Accessibility (Level AAA): At least one individual check is associated with each WCAG Level AAA Success Criterion that the tool has the functionality to modify. (Level AAA)
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.
B.2.3.1 Repair Accessibility (Level A): For each WCAG Level A accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level A)
B.2.3.2 Repair Accessibility (AA): For each WCAG Level AA accessibility problem that is identifiable during checking, repair assistance is provided. (Level AA)
B.2.3.3 Repair Accessibility (AAA): For each WCAG Level AAA accessibility problem that is identifiable during checking, repair assistance is provided. (Level AAA)
Rationale: Improperly generated equivalent alternatives can create accessibility problems and interfere with accessibility checking.
B.2.4.1 Accept, Modify, Reject: Authors have the opportunity to accept, modify, or reject any authoring tool-supplied equivalent alternative, prior to insertion. (Level A)
B.2.4.2 Edit Existing: If the authoring tool is capable of adding equivalent alternatives for a type of non-text objects then authors can edit the equivalent alternatives. (Level A)
B.2.4.3 Acceptable Sources: Authoring tools only supply equivalent alternatives from the following sources (Level AA):
B.2.4.4 Save for Reuse: Authors can store, for future reuse, both of the following author-assigned equivalent alternatives (as applicable) (Level AAA):
Note: Equivalent alternatives should not be automatically generated from unreliable sources (e.g., file names should not be used as text alternatives).
Rationale: Templates and other pre-authored content (e.g., clip art, synchronized media, widgets, etc.) that are not accessible impose additional repair tasks on authors.
B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG Level A when used. (Level A)
B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses. (Level A)
B.2.5.3 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true (Level A):
B.2.5.4 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG Level AA when used. (Level AA)
B.2.5.5 New Templates: 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)
B.2.5.6 Templates in Repository: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. (Level AA)
B.2.5.7 Pre-Authored Content Selection Mechanism: 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):
B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AA)
B.2.5.9 Templates "AAA" Accessible: If the authoring tool automatically select templates or pre-authored content, then the selection meets WCAG Level AAA when used. (Level AAA)
Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of content (in the final technology) created through their proper use.
Note: In addition to the normative requirements of this principle, implementers should also consider close integration of features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:
However, whenever new features are introduced into an authoring tool, striking the right design balance between the similarity with existing features and the provision of new functionality is often more of an art than a science.
Rationale: Some authors are most likely to use the first and easiest authoring action they encounter in the authoring tool user interface that achieves their intended mainstream rendered outcome.
B.3.1.1 Accessible Actions Prominent (Minimum): If authors are provided with a choice of authoring actions to achieve the same mainstream rendered outcome, then actions that implement accessible authoring practices are at least as prominent as the other action(s) (e.g., a "bold" button in a toolbar inserts semantic rather than formatting markup). (Level A)
B.3.1.2 Accessible Actions Prominent (Enhanced): If authors are provided with a choice of authoring actions to achieve the same mainstream rendered outcome, then actions that implement accessible authoring practices are more prominent than the other action(s). (Level AA)
Rationale: When accessibility considerations are a natural part of the workflow, they become a routine part of authoring.
B.3.2.1 Sequencing Features: Function that sequences authoring actions for authors (e.g., wizards) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the function. (Level AA)
B.3.2.2 Sequenced Instructions: Instructions (e.g., tutorials, reference manuals, design guides) that consist of a sequence of steps for authors to follow include the relevant accessibility authoring practices in the sequence before the first opportunity to successfully complete the sequence. (Level AA)
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.
B.3.3.1 Active by Default: All accessible content support features are active by default. (Level A)
B.3.3.2 Reactivate Option: If authors deactivate an accessible content support feature, then they can always reactivate the feature. (Level A)
B.3.3.3 Deactivation Warning: If authors deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)
B.3.3.4 At Least as Prominent: Accessible content support features are at least as prominent to authors 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 alternatives, accessibility checkers), some authors may not be able to find or use them.
B.3.4.1 Instructions: Instructions for using the accessible content support features appear in the documentation. (Level A)
B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible authoring process that is specific to the authoring tool is provided. (Level AAA)
Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.
B.3.5.1 Model Accessible Practice (Minimum): Any examples of authoring practices in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG Level A accessible authoring practices. (Level AA)
B.3.5.2 Model "AA" Accessible Practice (Enhanced): Any examples of authoring practices in the documentation demonstrate WCAG Level AA accessible authoring practices. (Level AAA)
An exception to these success criteria is allowed for examples that are specifically intended to demonstrate inaccessible practices to be avoided.
This section is normative.
Conformance means that the authoring tool satisfies the success criteria defined in the guidelines section. This conformance section describes conformance, and lists the conformance requirements.
A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile.
Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0 conformance level are encouraged to publish a statement on progress towards conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed towards, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.
Neither W3C, WAI, nor WAI-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 WAI-AUWG.
This section is normative.
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/TR/2008/WD-ATAG20-20081016/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, J. Spellman, 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.
Note: In this document, bracketed labels such as "[WCAG20]" link to the corresponding entries in this section. These labels are also identified as references through markup.
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, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, 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 under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
[Contents] [Techniques]