[Contents]
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Editing Styles:
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 by 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 document is the internal working draft used by the ATAG WG 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 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.
The Introduction includes both normative and informative sections, as noted.
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 the authoring tools that they develop 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 (potentially overlapping) user groups with disabilities:
This section is normative.
ATAG 2.0 defines an "authoring tool" as "any software 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".
This section is informative.
The individuals and organizations that 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 including two parts, overall principles, general guidelines, testable success criteria and a collection of sufficient techniques and advisory techniques with examples and resource links.
This section is normative.
ATAG 2.0 is intended to be used in conjunction with WCAG 2.0 [WCAG20] (or similar Web content accessibility guidance, such as regulations based on WCAG 2.0, etc.).
The relationship is as follows:
This section is informative.
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).
As with WCAG 2.0, there are a number of conditions that must be met for a Success Criterion to be included in ATAG 2.0. These include:
The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level in Part A included:
Some of the common factors evaluated when setting the level in Part B included:
This section is informative.
When implementing ATAG 2.0, it is recommended that authoring tool developers closely integrate 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:
The success criteria and applicability notes in this section are normative.
Rationale: When authoring tools or parts of authoring tools (e.g., Web-based help systems) are Web-based, conforming to WCAG 2.0 will facilitate access by all people, including those using assistive technologies along with their user agents.
A.1.1.1 Web-Based Accessible (Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)
A.1.1.2 Web-Based Accessible (Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA)
A.1.1.3 Web-Based Accessible (Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)
This guideline also applies to any parts of authoring tools that are Web-based (e.g., help systems).@@Moved to defn of authoring tool@@
Rationale: When authoring tools or parts of authoring tools (e.g., a client side file uploader for a Web-based content management system) are not Web-based (i.e., they run directly on platforms such as Windows and MacOS), following existing accessibility standards and/or platform conventions will facilitate access by all people, including those using assistive technologies.
A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) standards and/or platform conventions that benefit accessibility. (Level A)
A.1.2.2 Non-Web-Based Accessible (Level AA): Non-Web-based authoring tool user interfaces follow (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 2.0 Level AA success criteria. (Level AA)
A.1.2.3 Non-Web-Based Accessible (Level AAA): Non-Web-based authoring tool user interfaces follow (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 2.0 Level AAA success criteria. (Level AAA)
This guideline also applies to any parts of authoring tools that are non-Web-based (e.g., client-side file uploaders).@@Moved to defn of authoring tool@@
Rationale: People who have difficulty perceiving non-text content 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).
A.2.1.1 Recognized Alternative Content: If an editing view includes renderings of non-text content (e.g., WYSIWYG view), then authors have access to any alternative content for the rendered non-text content that are recognized by the authoring tool. (Level A)
This guideline does not apply to editing views, such as plain text editors, that do not render non-text content.@@is this really necessary??@@
Rationale: Authors need access to the information signified by presentation added by the authoring tool. Within editing views that render content, authors need access to the presentation that will be experienced by end users, since the ability to constantly monitor the end user experience is an important part of the workflow when using these editing views.
A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of Web content to provide authors with additional information (e.g., underlining misspelled words), then that additional information is made available via the platform. (Level A)
A.2.2.2 Access to Text Presentation (Minimum): If any of the following text presentation properties are editable by the authoring tool (even via a different editing view), then if the property is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform (Level A):
A.2.2.3 Access to Text Presentation (Enhanced): If any text presentation property (text size, text positioning, etc.) can be modified by the authoring tool (even via a different editing view), then if the property is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform. (Level AAA)
Rationale: Some authors need display settings that differ from the presentation that they define for the published Web content (e.g., an author may zoom an editing view in order to modify text that will appear small by default to end users).
A.2.3.1 Independence of Display: Editing views that render content (e.g., WYSIWYG) allow the authors' visual display settings and audio display settings to take precedence in the editing view without affecting the Web content being edited (i.e., no effect on markup, style sheets, etc.). (Level A)
Rationale: Keyboard accessibility provides access to people with limited mobility or visual disabilities, who are not able to use a mouse to navigate.
A.3.1.1 Important Commands: If the authoring tool includes any of the following features, 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 Avoiding Content Keyboard Traps: The authoring tool prevents keyboard traps by both of the following (Level A):
Web-based authoring tools may rely on the keyboard navigation features of the user agent listed in the conformance profile to help satisfy some of these success criteria.@@suggest move up to Part A??@@
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., an authenticated session expires), then authors have the global option to ensure that the Web content being edited is saved. For Web-based authoring tools, this applies to any Web content that has already been submitted to the server by the user agent. (Level A)
A.3.2.2 Timing Adjustable: If the authoring tool includes time limits, then authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. pressing the enter key to accept more time). (Level A)
A.3.2.3 Moving Targets: If a user interface component that accepts mouse input is capable of movement (e.g., animated vector graphic), provide authors with the option to stop the movement. (Level A)
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
A.3.3.1 Static View: If an editing view renders time-based content (e.g., animations), provide authors with the global option of rendering only the initial state of time-based content. (Level A)
Rationale: 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.
A.3.4.1 Edit by Structure: If an editing view displays a structured element set, then authors can select any element in the structured element 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 instance of the same 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 to the heading before or the heading after the element. (Level AA)
A.3.4.4 Navigate Tree Structures: If an editing view displays a structured element set, authors can move the editing focus from any element to the following other elements in the structured element set (if they exist) (Level AA):
Rationale: Authors 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: Authors can perform text searches of Web content in which all of the following are true (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.@@suggest move up to Part A??@@
Rationale: Providing the ability to save and reload sets of keyboard and display preference settings benefits 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 Assistance: An interactive mechanism helps authors 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 user agent will display the Web content to end users. 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 user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A, if they meet this guideline.@@moved to Part A applic notes@@
A.3.7.1 Return Mechanism: If a preview is provided, then it is possible for authors to return from the preview using only keyboard commands. (Level A)
A.3.7.2 Preview: If a preview is provided, then at least one of the following is true (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 authors that the action is irreversible. (Level A)
A.4.1.3 Redo: Authors can immediately reverse the most recent "undo" action(s) (i.e., a "redo" function). (Level AA)
A.4.1.4 Multiple 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 may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.
See Also: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.
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)
Rationale: Choosing Web content technologies which support the possibility of accessible Web content is a critical first step.
B.1.1.1 Tool Choice of Technologies: Only accessible technologies are ever automatically selected by the authoring tool. (Level A)
B.1.1.2 Author Choice of Technologies: If the authoring tool provides authors with Web content technology options, then any accessible technology options that are suitable for the task are at least as prominent as any other technology options. (Level A)
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 Web content technology of the output of a transformation or conversion can preserve recognized accessibility information that is required for that Web content to conform to WCAG 2.0 Level A, then the accessibility information is preserved and available for end users in the outputted Web content. (Level A)
B.1.2.2 Target Cannot Preserve Accessibility Information: If the Web content technology of the output of a transformation or conversion cannot preserve recognized accessibility information that is required for that Web content to conform to WCAG 2.0 Level A, then both of the following are true:
B.1.2.3 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 the Web content to conform to WCAG 2.0 Level AA or AAA is preserved and available for end users in the outputted Web content. (Level AA)
B.1.2.4 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):
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 Web content meets WCAG 2.0 Level A prior to publishing. (Level A)
B.1.3.2 Automatic Accessible (Level AA): If the authoring tool automatically generates content, then that Web content meets WCAG 2.0 Level AA prior to publishing. (Level AA)
B.1.3.3 Automatic Accessible (Level AAA): If the authoring tool automatically generates content, then that Web content meets WCAG 2.0 Level AAA prior to publishing. (Level AAA)
Rationale: By guiding authors from the outset towards the creation and maintenance of accessible Web content, Web content accessibility problems are mitigated and less repair 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 Guideline B.2.3) are also an important aspect of guiding authors.
B.2.1.1 Guide Accessible (Level A): If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level A (Level A).
B.2.1.2 Guide Accessible (Level AA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AA (Level AA).
B.2.1.3 Guide Accessible (Level AAA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AAA (Level AAA).
Rationale: 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.
See also: For more information on checking, see ATAG 2.0 Techniques - Appendix B: Levels of Checking Automation.
B.2.2.1 Check Accessibility (Level A): At least one individual check is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (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 Web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant Web content is identified (e.g., displaying the content, displaying line numbers, etc.) (Level A)
B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential Web content 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 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify. (Level AA)
B.2.2.6 View Status: If the authoring tool records Web content accessibility problems found during checking, then a list of any 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 a list of Web content accessibility problems 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 Web 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 2.0 Level AAA Success Criterion that the authoring 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.
See also: For more information on repair , see ATAG 2.0 Techniques - Appendix C: Levels of Repair Automation.
B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A Web content 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 2.0 Level AA Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AA)
B.2.3.3 Repair Accessibility (AAA): For each WCAG 2.0 Level AAA Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AAA)
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., an author inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.3.
B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)
B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)
B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text values that is equally available to user agents (e.g., the filename is not used). (Level A)
B.2.4.4 Special Values: The authoring tool follows recommendations on special values for alternative content (e.g., in HTML4, alt="" denotes images that should be ignored by assistive technology). (Level A)
B.2.4.5 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)
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 2.0 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 2.0 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 2.0 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 Web content (in the final Web content technology) created through their proper use.
Rationale: When authors are learning a new authoring tool, they may find and learn to use the first authoring action they encounter that achieves their intended outcome. Since they may be unaware of the issue of accessibility, it is preferable that accessible Web content be an additional unintended outcome, rather than inaccessible content.
B.3.1.1 Accessible Options Prominent (Level A): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not.
B.3.1.2 Accessible Options Prominent (Level AA): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not.
B.3.1.3 Accessible Options Prominent (Level AAA): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not.
Rationale: When accessibility considerations are a natural part of the workflow, they become a routine part of authoring.
B.3.2.1 Sequencing Features: Features that sequences authoring actions for authors (e.g., "wizard"-type mechanisms) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the sequence. (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 accessible 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 turned on by default. (Level A)
B.3.3.2 Reactivate Option: If authors turn off an accessible content support feature, then they can always turn on 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 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 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 2.0 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 2.0 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.
Authoring tools may claim "full" or "partial" conformance to ATAG 2.0. In either case, a level is also claimed which depends on the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance claim 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 content produced by the authoring tools (Part B: Support the production of accessible content):"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance claim 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):
"Partial" ATAG 2.0 Conformance: Content Production:This type of conformance claim 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):
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 towards "Full" Conformance.
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 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. Except where indicated by "[ ]", the source of these definitions is the AUWG, developed with a goal of clarity, detail, understanding, and completeness. Every attempt has been made to find appropriate definitions for these terms from other sources before such development by the AUWG. All these terms are linked at least from their first usage in the specification. Terms that have designations of "[ ]" beside them are taken from the indicated W3C specifications. Where a definition so referenced is not suitable or adequate for the ATAG2.0, it may be modified as described herein. 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/TR/2009/WD-ATAG20-20090521/">
"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.
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, National Institute on Disability and Rehabilitation Research (NIDRR) 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]