[ Contents ] [ Implementing ]

W3C

Authoring Tool Accessibility Guidelines (ATAG) 2.0

W3C Working Draft 08 July 2010 26 April 2011

This version:
http://www.w3.org/TR/2010/WD-ATAG20-20100708/ http://www.w3.org/WAI/AU/2011/WD-ATAG20-20110426/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2009/WD-ATAG20-20091029/ http://www.w3.org/TR/2010/WD-ATAG20-20100708/
Editors:
Jan Richards, Adaptive Technology Resource Centre, Inclusive Design Institute, OCAD University of Toronto
Jeanne Spellman, W3C
Jutta Treviranus, Adaptive Technology Resource Centre, Inclusive Design Institute, OCAD University of Toronto
Previous Editors:
Matt May (until June 2005 while at W3C )

Abstract

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 ).

Status of This Document

W3C Public Working Draft of ATAG 2.0

This is the W3C Last Call Working Draft of 8 July 2010. 26 April 2011. This draft integrates changes made as a result of comments received on the 29 October 2009 Public Working Draft. Publication as a 8 July 2010 Last Call Working Draft indicates that the Draft. The Authoring Tool Accessibility Guidelines Working Group (AUWG) believes it has addressed all substantive issues and that the document is stable. The first public Working Draft of refined ATAG 2.0 was published 14 March 2003. Since then, with the AUWG has published nine Working Drafts and one previous Last Call Working Draft, addressed hundreds contributions of public commenters. A summary of issues and developed implementation support information for the guidelines. See How WAI Develops Accessibility Guidelines through the W3C Process for more background on document maturity levels. Substantial substantive changes from the 29 October 2009 draft include: follows:

  1. The ATAG Working Group (AUWG) has approved a number of requests for changes to improve A more specific requirement that the clarity editing view of the document. authoring tool also render the alternatives to time-based media ( A.2.1.2 Alternatives for Rendered Time-Based Media );
  2. The conformance section now specifically waives "accessibility-supported ways An enhanced requirement to make rendered text properties available to assistive technologies ( A.2.2.2 Access to Rendered Text Properties );
  3. A new level-AAA requirement to allow navigation by programmatic relationships as in a programming iIntegrated development environment (IDE) ( A.3.4.2 Navigate by Programmatic Relationships ); and
  4. A modified approach to automatic generation of using technologies" from WCAG 2.0 for evaluating ATAG 2.0 conformance, because WCAG 2.0 accessibility support is typically not evaluated until the web content ( B.1.1.1 ; B.1.1.2 ) and content transformations ( B.1.2.1 ; B.1.2.2 ; and B.1.2.3 ) that is created. more nuanced and in some cases enables accessibility checking to be employed;
  5. The success criteria "B.2.1.1 Decision Support" has been changed to clarify the responsibilities of the developer A re-organization of all the authoring tool as success criteria related to which technologies require warnings, checking and repair to link to consolidate them under one guideline ("Authors must be supported in improving the conformance claim for more information. accessibility of existing content"); and
  6. The success criteria "B.2.2.1 Check Accessibility (WCAG Level A)" has been changed Clarifications to make it more flexible. The the definitions of " authoring tool will now require " and " authors " regarding when a check for success criteria that the author has the ability to violate, instead of being required to test every success criteria. web application should be treated as an authoring tool.

The Working Group seeks feedback on the following points for this draft:

  1. Does ATAG 2.0 address the shortcomings definition of ATAG 1.0? Since authoring tool developers will need to use ATAG 2.0 in conjunction with WCAG 2.0, are the documents sufficiently similar in style and approach to clearly delineate which kinds of authoring tools can potentially be effective? considered conforming toATAG 2.0?
  2. Do users with disabilities think that their needs have been addressed with regard Is it clear where ATAG 2.0 applies to Section A? integrated or stand-alone accessibility checkers?
  3. Is Does ATAG Part A address the conformance claim process usable by developers needs of authoring tool software? people with different types of disabilities? We encourage people with disabilities to review and provide feedback.

Comments on this working draft are due on or before 2 September 2010 24 May 2011 . 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 (ATAG) 1.0 [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.

May be Superseded

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/.

Web Accessibility Initiative

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 .

No Endorsement

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.

Patents

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 .


Table of Contents


Introduction

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 their 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) 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.

Notes:

  1. The term " authoring tools " has a specific definition in ATAG 2.0. The definition, which includes several normative notes, appears in the Glossary .
  2. ATAG 2.0 recommends that authoring tools be capable of producing web content that conforms with WCAG 2.0 . However, WCAG 2.0 notes that even content that conforms to the highest level of WCAG 2.0 (i.e., (i.e. Level AAA) may not be "accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas". Development of authoring tools that address more specialized needs is encouraged, but is beyond the scope of this document.
  3. ATAG 2.0 does not include standard usability recommendations, except where they have a significantly greater impact on people with disabilities than on other people.
  4. Authoring tools are just one aspect of web accessibility. For an overview of the different components of accessibility and how they work together see:

ATAG 2.0 Layers of Guidance

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 including two parts , overall principles , general guidelines , testable success criteria and an Implementing ATAG 2.0 document. provided:

All of these layers of guidance (parts, principles, guidelines, success criteria, and the Implementing ATAG 2.0 document) work together to provide guidance on how to make authoring tools more accessible. Authoring tool developers are encouraged to review all of the layers.

Understanding Levels of Conformance

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: For Part A , all success criteria must present authoring tool user interface-related accessibility issues . In other words, the user interface issue must cause a proportionately greater problem for authors with disabilities than it causes authors without disabilities and must be specific to authoring tool software, as opposed to software in general. For Part B , all success criteria must present accessible web content production issues . In other words, the issue must be specific to the production of accessible web content by authoring tools, as opposed to the production of web content in general. All success criteria must also be testable . This is important since otherwise it would not be possible to determine whether an authoring tool met or failed to meet the success criteria. The success criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a success criterion has been satisfied with a high level of confidence. 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: whether the success criterion is essential (in other words, if the success criterion is not met, then even assistive technology cannot make the authoring tool user interface accessible) whether it is possible to satisfy the success criterion for all types of authoring tools that the success criteria would apply to (e.g., text editors, WYSIWYG editors, content management systems, etc.) whether the success criterion would impose limits on the "look-and-feel" and/or function of authoring tools (e.g., limits on the function, design, aesthetic or freedom of expression of authoring tool developers ) whether there are workarounds for authors with disabilities if the success criterion is not met Some more information, see Understanding Levels of the common factors evaluated when setting the level in Part B included: Conformance .

whether the success criterion is essential (in other words, if the success criterion is not met, then even authors with a high degree of accessibility expertise would be unlikely to produce accessible web content using an authoring tool) whether it is possible to satisfy the success criterion for the production of all web content technologies that the success criteria would apply to. whether the success criterion requires features that would reasonably be used by authors . whether the success criterion would impose limits on the "look-and-feel" and/or function of authoring tools (e.g., limits on the function, design, aesthetic or freedom of expression of authoring tool developers )

Integration of Accessibility Features

When implementing ATAG 2.0, it is recommended that authoring tool developers closely should carefully integrate features that support accessible authoring with into the same "look-and-feel" of as other features of the authoring tool . Close integration has the potential to:


Guidelines

The success criteria and the conformance applicability notes in this section are normative .

PART A: Make the authoring tool user interface accessible

Part A Conformance Applicability Notes:

  1. Scope of authoring "authoring tool user interface: interface": The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of concerned with producing the authoring tool developer "included" web content technologies . This includes views of the web content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation , etc.
  2. Reflected web content accessibility problems: The authoring tool is responsible for ensuring that editing views editing-views display the web content being edited in a way that is accessible to authors with disabilities (e.g., (e.g. ensuring that a text alternative alternatives in the content can be programmatically determined ). However, where an authoring tool user interface accessibility problem is caused directly by a web content accessibility problem in the content being edited (e.g., (e.g. if an image in the content lacks a label), text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface .
  3. Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer .It does not apply to any subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user modifications, etc.).
  4. User agent features: Web-based authoring tools may rely on user agent features (e.g., (e.g. keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made, the claim cites must cite the user agent.
  5. Features for meeting Part A must be accessible: The Part A success criteria apply to the entire authoring tool user interface , including any features added to meet the success criteria in Part A (e.g., (e.g. documentation, search functions, etc.). The only exemption is for preview features, as long as they meet the relevant success criteria in Guideline A.3.7 . Previews are treated differently than editing views editing-views because all authors, including those with disabilities, benefit when preview features accurately reflect the actual functionality of user agents. agents that are actually in use by end users .

PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility guidelines

Guideline A.1.1: [For (For the authoring tool user interface] interface) Ensure that web-based functionality is accessible. [ Implementing A.1.1 ]

Rationale: When authoring tools or (or parts of authoring tools (e.g., an online help system) tools) are web-based , conforming to WCAG 2.0 will facilitate access by all authors , including those using assistive technologies .

A.1.1.1 Web-Based Accessible (WCAG Level A): (WCAG): Web-based authoring tool user interfaces conform to meet the WCAG 2.0 Level A. (Level A) success criteria. [ Implementing A.1.1.1 ] A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user interfaces conform to
The WCAG 2.0 Level AA. A success criteria are met (Level AA) [ Implementing A.1.1.2 ] A.1.1.3 Web-Based Accessible (WCAG A); or
The WCAG 2.0 Level AAA): Web-based authoring tool user interfaces conform to A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level AAA. A, Level AA, and Level AAA success criteria are met (Level AAA) [ Implementing A.1.1.3 ] AAA).

Guideline A.1.2: [For (For the authoring tool user interface] interface) Ensure that non-web-based functionality is accessible. [ Implementing A.1.2 ]

Rationale: When authoring tools or (or parts of authoring tools tools) are non-web-based (e.g., a client-side file uploader for a web-based content management system), , following existing accessibility standards and/or guidelines and implementing communication with platform conventions that support accessibility will facilitate services facilitates access by all authors , including those using assistive technologies .

A.1.2.1 Non-Web-Based Accessible: Accessibility Guidelines: Non-web-based authoring tool user interfaces follow user interface accessibility standards and/or guidelines for the platform conventions that support accessibility. . (Level A) [ Implementing A.1.2.1 ]
Note:
If a conformance claim is made, then the claim cites must cite the accessibility standards and/or platform conventions that were guidelines followed.

A.1.2.2 Platform Accessibility Services: Non-web-based authoring tools implement communication with platform accessibility services .(Level A) [ Implementing A.1.2.2 ]
Note:
If a conformance claim is made, then the claim must cite the platform accessibility service(s) implemented.

PRINCIPLE A.2: Editing views Editing-views must be perceivable

Guideline A.2.1: [For (For the authoring tool user interface] interface) Make alternative content available to authors. [ Implementing A.2.1 ]

Rationale: Some authors require access to alternative content in order to interact with the web content that they are editing.

A.2.1.1 Recognized Alternative Text Alternatives for Rendered Non-Text Content: If recognized an editing-view alternative renders non-text content is available with programmatically associated text alternatives ,then the text alternatives can be programmatically determined .(Level A) [ Implementing A.2.1.1 ]

A.2.1.2 Alternatives for Rendered Time-Based Media: If an editing view editing-view content renderings , renders time-based media, then at least one of the alternative content following is provided to authors . true: (Level A) [ Implementing A.2.1.1 A.2.1.2 ] (a) Alternatives Rendered: alternatives for the time-based content are also rendered; or (b) User Agent Option: authors have the option to preview the time-based content in a user agents that is able to render the alternatives.

Guideline A.2.2: [For (For the authoring tool user interface] Editing view interface) Editing-view presentation can be programmatically determined. [ Implementing A.2.2 ]

Rationale: Some authors need access to details about the editing view editing-view presentation because this may be , via their assistive technology, when that presentation is used to convey both status information added by the authoring tool (e.g., (e.g. underlining misspelled words) and, within content renderings , or provide information about how the end user will experience of the web content being edited. edited .

A.2.2.1 Purpose of Added Presentation: Editing-View Status Information: If an editing view editing-view modifies the presentation of web content to provide additional information to authors , convey status information, then that additional 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) [ Implementing A.2.2.1 ]

A.2.2.2 Access to Rendered Text Presentation (Minimum): Properties: If an editing view (e.g., WYSIWYG a text property view) is both renders any of the following presentation properties for text, then those properties can be programmatically determined : (Level A) [ Implementing A.2.2.2 rendered ] (a) Text Font ; and (b) Text Style (e.g., italic, bold); and (c) Text Color ; editable and (d) Text Size . A.2.2.3 Access to Text Presentation (Enhanced): If an editing view (e.g., WYSIWYG view) renders any presentation properties for text, then those properties the property can be programmatically determined . (Level AAA) [ Implementing A.2.2.3 ] Guideline A.2.3: [For the authoring tool user interface] Ensure the independence of authors' display preferences. [ Implementing A.2.3 ] Rationale: Some authors need to set their own display settings in a way that differs from the presentation that they want to define for communicated by the published web content . A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views ) without affecting supported platform accessibility service ,then the web content to be published property is programmatically determinable . (Level A) [ Implementing A.2.3.1 A.2.2.2 ]

PRINCIPLE A.3: Editing views Editing-views must be operable

Guideline A.3.1: [For (For the authoring tool user interface] interface) Provide keyboard access to authoring features. [ Implementing A.3.1 ]

Rationale: Some authors with limited mobility or visual disabilities are not able to use a mouse, and instead require full keyboard access. access to all of the functionality of the authoring tool .

A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface , without requiring specific timings for individual keystrokes, except where editing web content properties that encode continuous the underlying function requires input . that depends on the path of the user's movement and not just the endpoints. (Level A) [ Implementing A.3.1.1 ]
Note 1: This
The path exception relates to the nature of web content, underlying function, not the usual input technique. For example, setting if using handwriting to enter text, the path of a freehand curve is exempt, while setting input technique (handwriting) requires path-dependent input, but the endpoints of a straight line is underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
Note 2:
This success criterion does not forbid and should not be interpreted as discouraging discourage providing mouse input or other input methods in addition to the keyboard interface. operation.

A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented as follows: (Level A) [ Implementing A.3.1.2 ] (a) In the Authoring Tool User Interface : If keyboard focus can be moved to a component using the keyboard, a keyboard interface , then focus can be moved away from that component using standard only a keyboard navigation commands (e.g., TAB key); interface and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away; and (b) In Editing Views Editing-Views that Render Web Content : If an editing view editing-view renders web content (e.g., (e.g. WYSIWYG view), then a documented keyboard command is provided that will always restore moves the editing-view keyboard focus to a known location (e.g., (e.g. the menus). start of the editing-view).

A.3.1.3 Efficient Keyboard Shortcuts: Access: Keyboard shortcuts are provided. The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard navigation . (Level AA) [ Implementing A.3.1.3 ]

A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is operable through a keyboard interface . without requiring specific timings for individual keystrokes. (Level AAA) [ Implementing A.3.1.4 ]

A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be customized. (Level AAA) [ Implementing A.3.1.5 ]

A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls components can be presented with any associated keyboard commands. (Level AAA) [ Implementing A.3.1.6 ]

Guideline A.3.2: [For (For the authoring tool user interface] interface) Provide authors with enough time. [ Implementing A.3.2 ]

Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a that require fast reaction speed, speeds, such as clicking on a moving target.

A.3.2.1 Data Content Edits Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool saves all submitted content edits made by authors . (Level A) [ Implementing A.3.2.1 ]

A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool , then at least one of the following is true: (Level A) [ Implementing A.3.2.2 ] (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., (e.g. "press the space bar"), and authors are allowed to extend the time limit at least ten times; or (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., (e.g. a collaborative authoring system), and no alternative to the time limit is possible; or (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or (f) 20 Hour Exception: The time limit is longer than 20 hours.

A.3.2.3 Static Pointer Targets: User Authoring tool user interface components that accept pointer input are either stationary or authors can pause the movement. (Level A) [ Implementing A.3.2.3 ]

A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to automatically save all content edits made by authors . (Level AAA) [ Implementing A.3.2.4 ]

Guideline A.3.3: [For (For the authoring tool user interface] interface) Help authors avoid flashing that could cause seizures. [ Implementing A.3.3 ]

Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.

A.3.3.1 Static View Option: Editing-views that Rendering render of visual time-based content (e.g., animations) in editing views can be turned off. paused and can be set to not play automatically. (Level A) [ Implementing A.3.3.1 ]

Guideline A.3.4: [For (For the authoring tool user interface] interface) Enhance navigation and editing via content structure. [ Implementing A.3.4 ]

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.

A.3.4.1 Edit Navigate By Structure: If Editing views editing-views for structured expose the markup elements in the web content include editing mechanism(s) that can make use of being edited ,then the structure. markup elements (e.g. source code, content renderings, etc.) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level A) AA) [ Implementing A.3.4.1 ]

A.3.4.2 Navigate By Structure: by Programmatic Relationships: If Editing views editing-views for structured allow editing of programmatic relationships within web content include navigation mechanism(s) , then mechanisms are provided that can make use support navigation between the related content. Depending on the web content technology and the nature of the structure. authoring tool ,relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships. (Level A) AAA) [ Implementing A.3.4.2 ]

Guideline A.3.5: [For (For the authoring tool user interface] interface) Provide text search of the content. [ Implementing A.3.5 ]

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.

A.3.5.1 Text Search: Authors can perform text searches of web content as follows: that meet the following: (Level AA) [ Implementing A.3.5.1 ] (a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content , metadata, markup elements and attributes; and
Note: If the current editing view editing-view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view editing-view to display the results; and results.
(b) Bi-Directional: Two-way: The search can be made forwards or backwards; and (c) Case Sensitive: The search can be in both case sensitive and case insensitive modes. modes; and (d) No Match: Authors are informed when no results are found.

Guideline A.3.6: [For (For the authoring tool user interface] interface) Manage preference settings. [ Implementing A.3.6 ]

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., (e.g. due to fatigue).

A.3.6.1 Independence of Display: Authors can set their own display settings for editing-views without affecting the web content to be published .(Level A) [ Implementing A.3.6.1 ]

A.3.6.1 A.3.6.2 Save Settings: Any authoring Authoring tool display settings and control settings are can be saved between authoring sessions . (Level AA) [ Implementing A.3.6.1 A.3.6.2 ]

A.3.6.2 Respect A.3.6.3 Apply Platform Settings: The authoring tool respects applies platform display settings and control settings . (Level AA) [ Implementing A.3.6.2 A.3.6.3 ] Note: As per Success Criterion A.2.3.1 , authors' display settings must still be independent of the web content being edited.

A.3.6.3 A.3.6.4 Multiple Sets: Authors can save and reload multiple sets of any authoring tool display settings and control settings . (Level AAA) [ Implementing A.3.6.3 A.3.6.4 ]

A.3.6.4 Preferences Assistance: A.3.6.5 Assistance with Preferences: The authoring tool includes a mechanism to help authors configure any preference authoring tool display settings related to Part A of this document. and control settings . (Level AAA) [ Implementing A.3.6.4 A.3.6.5 ]

Guideline A.3.7: [For (For the authoring tool user interface] interface) Ensure that previews are as accessible as existing user agents. [ Implementing A.3.7 ]

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 to be able to follow the same workflow. opportunity to check their work.

A.3.7.1 Return Mechanism: If a preview is provided, then authors can return from the preview using only keyboard commands. (Level A) [ Implementing A.3.7.1 ] A.3.7.2 Preview: Preview (Minimum): If a preview is provided, then at least one of the following is true: (Level A) [ Implementing A.3.7.2 A.3.7.1 ] (a) Third-Party Pre-existing User Agent: The preview makes use of an existing third-party a pre-existing user agent ; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [ UAAG ] .

A.3.7.2 Preview (Enhanced): If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA) [ Implementing A.3.7.2 ]

PRINCIPLE A.4: Editing views Editing-views must be understandable

Guideline A.4.1: [For (For the authoring tool user interface] interface) Help authors avoid and correct mistakes. [ Implementing A.4.1 ]

Rationale: Some authors who have difficulty making fine movements with disabilities may be prone more susceptible to input errors due to factors such as difficulty making unintended actions. fine movements and speech recognition system errors.

A.4.1.1 Undo Content Changes: Changes Reversible (Minimum): For Authoring authoring actions are either reversible by an "undo" function or include a warning to authors that , one of the action is irreversible . following are true: (Level A) [ Implementing A.4.1.1 ]
Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g. a "redo" function).
Note 2: It is acceptable to collect a series of text entry actions (e.g., (e.g. typed words, a series of backspaces) into a single reversible authoring action.
Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions .(a) Reversible: The authoring action can be immediately reversed; or Note 2: (b) Warn and Confirm: It The authoring tool includes a warning to authors that the action is acceptable for certain committing actions (e.g., "save", "publish") irreversible and requires authors to make all previous authoring actions irreversible. confirm the action before proceeding.

A.4.1.2 Undo Setting Changes: Changes Reversible: Actions that If actions modify authoring tool settings settings, then one of the following are either reversible true: (Level A) [ Implementing A.4.1.2 ] (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or include (b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible . (Level A) [ Implementing A.4.1.2 ] and requires authors to confirm the action or save the current settings before proceeding.

A.4.1.3 Undo is Reversible: Content Changes Reversible (Enhanced): Authors can immediately sequentially reverse the most recent "undo" action(s). a series of reversible authoring actions . (Level AA) AAA) [ Implementing A.4.1.3 ]
Note: The notes for A.4.1.1 still apply.

Guideline A.4.2: [For (For the authoring tool user interface] interface) Document the user interface including all accessibility features. [ Implementing A.4.2 ]

Rationale: Some authors may not be able to understand or operate the authoring tool user interface without proper accessible documentation .

A.4.2.1 Document Accessibility Features: All features that are specifically required must be present to meet Part A of this document ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented . (Level A) [ Implementing A.4.2.1 ]
Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2 .

A.4.2.2 Document All Features: All features of the authoring tool are documented . (Level AA) [ Implementing A.4.2.2 ]
Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2 .

PART B: Support the production of accessible content

Part B Conformance Applicability Notes:

  1. Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions .
  2. Applicability after the end of an authoring session: Developer control: For author-generated content , the requirements of The Part B success criteria only apply during authoring sessions. For example, if the author includes a third-party feed in their web content , to the authoring tool as it is provided by the developer .This does not required to provide checking for web content accessibility problems include subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user-defined templates, user modifications of default settings, etc.).
  3. in that feed Applicability after the end of the an authoring session . In contrast, session: Authoring tools are responsible for automatically-generated the accessibility of web content , Part B continues to apply that they automatically generate after the end of the an author's authoring session. session (see Success Criterion B.1.1.1 ). For example, if the developer changes the site-wide templates of a content management system are updated, system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).
  4. Authoring systems: As per the ATAG 2.0 definition of authoring tool , several software tools (identified in any conformance claim ) can be used in conjunction to meet the requirements of Part B (e.g., (e.g. an authoring tool could make use of a third-party software accessibility checking and repair tool).
  5. Features for meeting Part B must be accessible: The Part A success criteria apply to the entire authoring tool user interface , including any features added that must be present to meet the success criteria in Part B (e.g., (e.g. checking tools, repair tools, tutorials, documentation, etc.).
  6. Multiple author roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., (e.g. a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role. Accessible content support features should be made available to any author role where it would be useful.

PRINCIPLE B.1: Production of Fully automatic processes must produce accessible content must be enabled

Guideline B.1.1: Support web content technologies that enable the creation of Ensure automatically specified content that is accessible. [ Implementing B.1.1 ]

Rationale: For the purposes of this document, WCAG 2.0 If authoring tools defines the accessible web content automatically requirements. To support accessible web content production, at minimum, it must be possible to produce specify web content that conforms with WCAG 2.0 is not accessible, then additional repair using the authoring tool tasks are imposed on authors .

B.1.1.1 Accessible Content Production (WCAG Level A): Auto-Generation After Authoring Sessions (WCAG): Authors can use have the authoring tool default option to produce that, when web content that conforms to WCAG 2.0 is automatically generated Level A. (Level A) for publishing after the end of an authoring session ,it is accessible web content (WCAG) . [ Implementing B.1.1.1 ]
Note: This success criterion applies only to automatic processes specified by the authoring tool developer .It does not apply when author actions prevent generation of accessible web content .
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

B.1.1.2 Accessible Content Production (WCAG Level AA): Auto-Generation During Authoring Sessions (WCAG): Authors can use have the authoring tool default option to produce that, when web content that conforms to WCAG 2.0 is automatically generated Level AA. (Level AA) during an authoring session ,then one of the following is true: [ Implementing B.1.1.2 ]
Note 1: Automatic generation includes automatically selecting templates for authors.
Note 2:
This success criterion applies only to automatic processes specified by the authoring tool developer .It does not apply when author actions prevent generation of accessible web content .
(a) Accessible: The content is accessible web content (WCAG) B.1.1.3 Accessible Content Production (WCAG Level AAA): without author input; or (b) Prompting: Authors During the automatic generation process, authors are prompted for any required accessibility information (WCAG) can use ; or (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or (d) Checking Suggested: After the automatic generation process, the authoring tool to produce web content that conforms prompts authors to perform accessibility checking. The WCAG 2.0 Level AAA. A success criteria are met (Level AAA) [ Implementing B.1.1.3 ] A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

Guideline B.1.2: Ensure that the authoring tool preserves accessibility information. information is preserved. [ Implementing B.1.2 ]

Rationale: Accessibility information is critical to maintaining comparable levels of accessibility between the input and output of web content transformations .

B.1.2.1 Preserve Accessibility Information (Minimum): Restructuring and Recoding Transformations (WCAG): Any accessibility information ( WCAG 2.0 Level A) recognized in If the input to any web content transformation authoring tool is preserved as accessibility information in the output, if allowed by the web content technology provides restructuring transformations or re-coding transformations ,then at least one of the output. (Level A) following is true: [ Implementing B.1.2.1 ]
Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance. B.1.2.2 End Product Cannot Preserve Accessibility Information: (a) Preserve: If the web content technology of the output of a web content transformation cannot preserve recognized accessibility Accessibility information (WCAG) ( WCAG 2.0 Level A) (e.g., saving a structured graphic to a raster image format), then at least one of is preserved in the following are true: (Level A) [ Implementing B.1.2.2 ] output; or (a) Option to Save: (b) Warning: author s Authors have the default option to save the be warned that accessibility information in another way (e.g., as may be lost (e.g. when saving a "comment", as vector graphic into a backup copy of raster image format); or (c) Automatic Checking: After the input); transformation, accessibility checking is automatically performed; or (b) Warning: (d) Checking Suggested: After the transformation, the authoring tool prompts authors are warned that this will result in web content to perform accessibility problems in the output. checking. The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

B.1.2.3 B.1.2.2 Optimizations Preserve Accessibility Information (Enhanced): Accessibility: Any If the authoring tool provides optimizing web content transformations then any accessibility information (up to WCAG 2.0 Level AAA) recognized (WCAG) in the input to any web content transformation is preserved as accessibility information in the output. (Level AA) A). [ Implementing B.1.2.3 B.1.2.2 ]

B.1.2.4 Notification Prior to Deletion: B.1.2.3 Text Alternatives for Non-Text Content are Preserved: If the authoring tool automatically deletes any author-generated provides web content transformations for any reason, that preserve non-text content in the output, then at least one any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the following is true: output. (Level AA) A). [ Implementing B.1.2.4 B.1.2.3 ] (a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information ; or

(b) Notification Option: Authors have the option to receive notification before deletion; or (c) No Deletion Option: PRINCIPLE B.2: Authors have the option to prevent automatic deletion by the authoring tool. must be supported in producing accessible content

Guideline B.1.3: B.2.1: Ensure that automatically generated accessible content production is accessible. possible. [ Implementing B.1.3 B.2.1 ]

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 Accessible Auto-Generated Content (WCAG Level A): If Rationale: For the authoring tool automatically generates content , then that web content conforms to purposes of this document, WCAG 2.0 Level A prior to publishing . (Level A) [ Implementing B.1.3.1 ] Note: This success criterion only applies to the automated behavior specified by defines the authoring tool developer . It does not apply when actions of authors prevent generation of accessible web content (WCAG) (e.g., authors might set less strict preferences, ignore prompts for accessibility information , provide faulty accessibility information, write their own automated scripts, etc.). B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool automatically generates requirements. To support accessible web content , then that production, at minimum, it must be possible to produce web content that conforms to with WCAG 2.0 Level AA prior to publishing . (Level AA) [ Implementing B.1.3.2 ] Note: This success criterion only applies to the automated behavior specified by using the authoring tool developer . It does not apply when actions of the authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information , provide faulty accessibility information, write their own automated scripts, etc.).

B.1.3.3 B.2.1.1 Accessible Auto-Generated Content (Level AAA): Possible (WCAG): If the authoring tool automatically generates content , then that places restrictions on the web content conforms to that authors can specify, then those restrictions do not prevent WCAG 2.0 Level AAA prior to publishing . (Level AAA) success criteria from being met: [ Implementing B.1.3.3 B.2.1.1 ] Note: This The WCAG 2.0 Level A success criterion only applies to the automated behavior specified by the authoring tool developer . It does not apply when actions of the authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information , provide faulty accessibility information, write their own automated scripts, etc.). criteria can be met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria can be met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria can be met (Level AAA).

PRINCIPLE B.2: Authors must be supported in the production of accessible content

Guideline B.2.1: B.2.2: Guide authors to create produce accessible content. [ Implementing B.2.1 B.2.2 ]

Rationale: By guiding authors from the outset towards toward the creation and maintenance of accessible web content (WCAG) , web content accessibility problems (WCAG) are mitigated and less repair effort is required.

B.2.1.1 Decision Support: B.2.2.1 Accessible Option Prominence (WCAG): 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) [ Implementing B.2.1.1 ] (a) Warning: Authors authors are warned that the authoring tool does not provide support for the production of accessible content for that technology; and (b) List: From the warning, authors can access provided with a list choice of technologies for which the authoring tool does provide support for the production of accessible content . B.2.1.2 Set Accessible Properties: Mechanisms that set web content properties (e.g., attribute values, etc.) also can be used to set the accessibility-related properties. (Level A) [ Implementing B.2.1.2 ] actions B.2.1.3 Other Technologies: If for achieving the same authoring tool outcome can insert (e.g. styling text), then options that will result in accessible web content (WCAG) that it cannot subsequently edit, then authors can associate accessibility information are at least as prominent with as options that web content. will not. (Level A) [ Implementing B.2.1.3 B.2.2.1 ] Guideline B.2.2: Assist authors in checking for accessibility problems. [ Implementing B.2.2 ] 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. B.2.2.1 Check Accessibility (WCAG The WCAG 2.0 Level A): If the authoring tool provides authors with the ability to add A success criteria are met (Level A); or modify web content so that any
The WCAG 2.0 Level A Success Criterion can be violated, then accessibility checking for those and Level AA success criteria 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 ). are met (Level A) [ Implementing B.2.2.1 ] Note: Automated AA); or
The WCAG 2.0 Level A, Level AA, and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems . However, manual checking is the minimum requirement to meet this Level AAA success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation . criteria are met (Level AAA).

B.2.2.2 Availability: Setting Accessibility Properties (WCAG): Checking is available prior to publishing in a manner appropriate to the workflow of If the authoring tool . (Level A) [ Implementing B.2.2.2 ] B.2.2.3 Help Authors Decide: For any checks that require author judgment provides mechanisms to determine whether a potential set web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking properties ), instructions (e.g. attribute values, etc.), then mechanisms are also provided to help authors decide whether it is correctly identified. (Level A) [ Implementing B.2.2.3 ] B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential set web content properties related to accessibility problem is correctly identified (i.e., manual checking and semi-automated checking ), the relevant content is identified (e.g., highlighting the affected content, displaying line numbers, etc.) (Level A) information (WCAG) : [ Implementing B.2.2.4 B.2.2.2 ]
Note: Success Criterion B.4.1.4 B.2.2.5 Check Accessibility (WCAG Level AA): If addresses the authoring tool provides authors with prominence of the ability to add or modify web content so that any mechanisms. The WCAG 2.0 Level AA Success Criterion can be violated, then accessibility checking for those A success criteria is provided. are met (Level AA) [ Implementing B.2.2.5 ] Note: Automated A); or
The WCAG 2.0 Level A and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems . However, manual checking is the minimum requirement to meet this Level AA success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation . B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks . criteria are met (Level AA) [ Implementing B.2.2.6 ] Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected AA); or a
The WCAG 2.0 conformance level, etc. B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. Level A, Level AA, and Level AAA success criteria are met (Level AA) [ Implementing B.2.2.7 ] Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., specific check results, summary conformance claims, etc.) AAA).

B.2.2.8 Check Accessibility (WCAG Level AAA): B.2.2.3 Technology Decision Support: If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level AAA Success Criterion can be violated, then accessibility checking for those success criteria is provided. (Level AAA) [ Implementing B.2.2.8 ] Note: Automated and semi-automated checking option is possible (and encouraged) for many types of producing a web content accessibility problems . However, manual checking technology is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors for publishing with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation . Guideline B.2.3: Assist authors in repairing accessibility problems. [ Implementing B.2.3 ] Rationale: Repair as an integral part of the authoring process greatly enhances tool does not provide support for the utility production of checking and increases the likelihood that accessibility problems will be properly addressed. B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web accessible content accessibility problem that is identifiable during checking (as required by Guideline B.2.2 ), repair assistance is provided. , then both of the following are true: (Level A) [ Implementing B.2.3.1 B.2.2.3 ]
Note: (a) Warning: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair Authors is the minimum requirement to meet this success criterion. In manual repair, are warned that the authoring tool provides authors with instructions does not provide support for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels the production of Repair Automation . B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web accessible content accessibility problem for that is identifiable during checking (as required by Success Criterion B.2.2.5 ), repair assistance is provided. (Level AA) [ Implementing B.2.3.2 ] technology; and
Note: (b) List: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, From the authoring tool provides authors with instructions for repairing problems, which warning, authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels can access a list of Repair Automation . B.2.3.3 Repair Accessibility (WCAG Level AAA): For each WCAG 2.0 Level AAA web content accessibility problem that is identifiable during checking (as required by Success Criterion B.2.2.8 ), repair assistance is provided. (Level AAA) [ Implementing B.2.3.3 ] Note: Automated and semi-automated repair is possible (and encouraged) technologies for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, which the authoring tool provides authors with instructions does provide support for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels the production of Repair Automation accessible content .

Guideline B.2.4: B.2.3: Assist authors with managing alternative content for non-text content. [ Implementing B.2.4 B.2.3 ]

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., (e.g. inserts an image). When non-text content is automatically added by the authoring tool , see Guideline B.1.3 B.1.1 .

B.2.4.1 Editable: B.2.3.1 Alternative Content is Editable (WCAG): Authors are able to modify alternative content programmatically associated text alternatives for non-text content . This includes types of alternative content that may not typically be displayed on screen by user agents . content. (Level A) . [ Implementing B.2.4.1 B.2.3.1 ]
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

B.2.4.2 B.2.3.2 Conditions on Automated Suggestions: During the authoring session , the authoring tool can may only automatically suggest alternative content programmatically associated text alternatives for non-text content only under the following conditions: (Level A) [ Implementing B.2.4.2 B.2.3.2 ] (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested alternative content text alternatives prior to insertion; and (b) Relevant Sources: The suggested alternative content is text alternatives are only derived from sources designed to fulfill the same purpose (e.g., (e.g. suggesting the value of an image's "description" metadata field as a long description).

B.2.4.3 B.2.3.3 Let User Agents Repair: After the end of an authoring session , the The authoring tool does not attempt to avoids repair repairing alternative content programmatically associated text alternatives for non-text content using any text value that is equally would also be available to user agents (e.g., the filename is (e.g. do not used). use the image filename). (Level A) [ Implementing B.2.4.3 B.2.3.3 ]

B.2.4.4 B.2.3.4 Save for Reuse: When Authors have the option of having any recognized plain text alternative content authors that they enter (e.g., short programmatically associated text labels, long descriptions) stored alternatives for future reuse. non-text content ,both of the following are true: (Level AA) AAA) [ Implementing B.2.4.4 B.2.3.4 ] (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool ,if the same non-text content is reused; and (b) Edit Option: the author has the option to edit or delete the saved text alternatives.

Guideline B.2.5: B.2.4: Assist authors with accessible templates and other pre-authored content. templates. [ Implementing B.2.5 B.2.4 ]

Rationale: Providing accessible templates and other pre-authored content (e.g., (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, edited , reducing the effort required of authors , and demonstrating the importance of accessible web content. content (WCAG) .

B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level A when used. (Level A) [ Implementing B.2.5.1 ] Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology ) created when the template is used properly.

B.2.5.2 Provide B.2.4.1 Accessible Templates: Template Options (WCAG): If the authoring tool provides templates , then there are accessible template options for a range of template uses. (Level A) [ Implementing B.2.5.2 B.2.4.1 ]

B.2.5.3 Templates Accessible (WCAG Level AA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AA when used. (Level AA) [ Implementing B.2.5.3 ] Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology ) created when the template is used properly. B.2.5.4 B.2.4.2 Template Selection Mechanism: If authors are provided with a template selection mechanism , then both of the following are true: (Level AA) [ Implementing B.2.5.4 B.2.4.2 ] (a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and (b) Prominence: Any accessible template options are at least as prominent as other template options.

B.2.5.5 B.2.4.3 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) [ Implementing B.2.5.5 B.2.4.3 ]

B.2.5.6 B.2.4.4 Template Accessibility Status: If the authoring tool provides a repository of templates ,then each of the templates has a recorded accessibility status. (Level AAA) [ Implementing B.2.4.4 ]

Guideline B.2.5: Assist authors with accessible pre-authored content. [ Implementing B.2.5 ]

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) .

B.2.5.1 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., (e.g. clip art gallery, widget repository, design themes), then both of the following are true: (Level AA) [ Implementing B.2.5.6 B.2.5.1 ] (a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and (b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.

B.2.5.7 Templates in Repository: B.2.5.2 Pre-Authored Content Accessibility Status: If the authoring tool provides a repository of templates , pre-authored content, then each of the templates content objects has a recorded accessibility status. (Level AAA) [ Implementing B.2.5.7 B.2.5.2 ]

B.2.5.8 Pre-Authored Content PRINCIPLE B.3: Authors must be supported in Repository: If improving the authoring tool provides a repository of pre-authored content, then each accessibility of the existing content objects has a recorded

Guideline B.3.1: Assist authors in checking for accessibility status. (Level AAA) problems. [ Implementing B.2.5.8 B.3.1 ]

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.

B.2.5.9 Templates Accessible (WCAG Level AAA): B.3.1.1 Checking Assistance (WCAG): If the authoring tool automatically selects templates provides authors or pre-authored content, then with the selections conform ability to add or modify web content so that a WCAG 2.0 Level AAA when used. (Level AAA) 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). [ Implementing B.2.5.9 B.3.1.1 ]
Note: Templates may not pass accessibility checks Automated due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility and semi-automated checking is possible (and encouraged) for many types of completed web content accessibility problems .However, manual checking (in is the final web content technology ) created when minimum requirement to meet this success criterion. In manual checking, the template is used properly. authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation .The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

PRINCIPLE B.3: Accessibility solutions must be promoted and integrated B.3.1.2 Help Authors Decide: For checks Guideline B.3.1: Ensure that accessible authoring actions require authors to decide whether a potential web content accessibility problem is correctly identified (i.e. manual checking and semi-automated checking ), instructions are given prominence. provided from the check that describe how to make the decision. (Level A) [ Implementing B.3.1 B.3.1.2 ] Rationale: When

B.3.1.3 Help Authors Locate: For checks that require authors are learning to decide whether a new authoring tool , they may find potential web content accessibility problem is correctly identified (i.e. manual checking and learn semi-automated checking ), the relevant content is identified to use the first authoring action authors. (Level A) [ Implementing B.3.1.3 they encounter that achieves their intended outcome. Since they may be unaware ]
Note: Depending on the nature of the issue editing-view and the scope of accessibility, it is preferable that accessible the potential web content be an additional unintended outcome, rather than inaccessible content. accessibility problem, identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.

B.3.1.1 Accessible Options Prominent (WCAG Level A) : If B.3.1.4 Status Report: authors Authors are provided with a choice can receive an accessibility status report based on the results of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not. accessibility checks . (Level A) AA) [ Implementing B.3.1.1 B.3.1.4 ]
Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.

B.3.1.2 Accessible Options Prominent (WCAG Level AA) : If B.3.1.5 Metadata Production: authors are provided with a choice of authoring actions Authors for achieving have the same authoring outcome (e.g., styling text), then options option that will result in of associating accessibility checking results with the web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not. metadata. (Level AA) [ Implementing B.3.1.2 B.3.1.5 ]
Note: The metadata format that is implemented will dictate the nature of the associated results (e.g. specific check results, summary conformance claims, etc.)

B.3.1.3 Accessible Options Prominent (WCAG Level AAA) : If Guideline B.3.2: Assist authors in repairing accessibility problems. [ Implementing B.2.3 are provided with a choice of authoring actions ]

Rationale: Repair for achieving as an integral part of the same authoring outcome (e.g., styling text), then options process greatly enhances the utility of checking and increases the likelihood that accessibility problems will result in web content be properly addressed.

conforming to B.3.2.1 Repair Assistance (WCAG): If checking (see Success Criterion B.3.1.1 ) can detect that a WCAG 2.0 Level AAA are at least as prominent success criterion is not met, then repair as options that will not. (Level AAA) suggestion(s) are provided: [ Implementing B.3.1.3 B.3.2.1 ]
Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation .The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

PRINCIPLE B.4: Authoring tools must promote and integrate their accessibility features

Guideline B.3.2: B.4.1: Ensure that features of the authoring tool supporting availability of features that support the production of accessible content are available. content. [ Implementing B.3.2 B.4.1 ]

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.2.1 B.4.1.1 Features Active by Default: All accessible content support features are turned on by default. (Level A) [ Implementing B.3.2.1 B.4.1.1 ]

B.3.2.2 B.4.1.2 Option to Reactivate Option: Features: If authors can turn off an accessible content support feature , then they can always turn the feature back on. (Level A) [ Implementing B.3.2.2 B.4.1.2 ]

B.3.2.3 B.4.1.3 Feature Deactivation Warning: 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) [ Implementing B.3.2.3 B.4.1.3 ]

B.3.2.4 At Least as Prominent: B.4.1.4 Feature Prominence: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., (e.g. invalid markup, markup , syntax errors, spelling and grammar errors). (Level AA) [ Implementing B.3.2.4 B.4.1.4 ]

Guideline B.3.3: B.4.2: Ensure that features of the authoring tool supporting documentation promotes the production of accessible content are documented. content. [ Implementing B.3.3 B.4.2 ]

Rationale: Without documentation of the features that support the production of accessible content (e.g., (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. B.3.3.1 Instructions: Instructions for using the accessible content support features appear in the documentation . (Level A) [ Implementing B.3.3.1 ] B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible authoring process that is specific to the authoring tool is provided. (Level AAA) [ Implementing B.3.3.2 ] Guideline B.3.4: Ensure that any authoring practices demonstrated in documentation are accessible. [ Implementing B.3.4 ] Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors .

B.3.4.1 B.4.2.1 Model Accessible Practice (WCAG Level A): (WCAG): A range of examples in the documentation (e.g., (e.g. markup , screen shots of WYSIWYG editing views editing-views ) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria: [ Implementing B.4.2.1 ] The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

B.4.2.2 Feature Instructions: Instructions for using the accessible authoring practices content support features appear in the documentation . (Level A) [ Implementing B.3.4.1 B.4.2.2 ]

B.3.4.2 Model Accessible Practice (WCAG Level AA): B.4.2.3 Tutorial: A range of examples in the documentation (e.g., markup , screen shots of WYSIWYG editing views ) demonstrate WCAG 2.0 tutorial Level AA on an accessible authoring practices . process that is specific to the authoring tool is provided. (Level AA) AAA) [ Implementing B.3.4.2 B.4.2.3 ]

B.3.4.3 Model Accessible Practice (WCAG Level AAA): B.4.2.4 Instruction Index: A range of examples in the The documentation (e.g., markup , screen shots of WYSIWYG editing views ) demonstrate WCAG 2.0 Level AAA contains an index to the instructions for using the accessible authoring practices content support features . (Level AAA) [ Implementing B.3.4.3 B.4.2.4 ]

 


Conformance

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.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

Because WCAG 2.0 [ WCAG20 ] is the most recent W3C Recommendation regarding web content accessibility, ATAG 2.0 frequently refers to WCAG 2.0 conformance 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 towards toward producing accessible 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)".

Note on "accessibility-supported ways of using technologies":

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] 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." supported ." In broad terms, WCAG 2.0 considers a web content technology to be accessibility supported "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., (e.g. private intranets versus public websites, monolingual sites versus multilingual sites, etc.). Therefore:

For the purposes of ATAG 2.0 conformance, does not include the accessibility-supported requirement is waived. 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 is 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.

Applicability of Success Criteria

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.

Conformance Requirements

In order for an authoring tool to conform to ATAG 2.0, all of the following conformance requirements must be satisfied:

Conformance Levels:

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 ):

  1. Full ATAG 2.0 Conformance at Level A
    The authoring tool satisfies all of the applicable Level A success criteria.
  2. Full ATAG 2.0 Conformance at Level AA
    The authoring tool satisfies all of the applicable Level A and Level AA success criteria.
  3. Full ATAG 2.0 Conformance at Level AAA
    The authoring tool satisfies all of the applicable success criteria.

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):

  1. Partial ATAG 2.0 Conformance Level A: Authoring Tool User Interface
    The authoring tool satisfies all of the applicable Level A success criteria in Part A. Nothing is implied about Part B.
  2. Partial ATAG 2.0 Conformance Level AA: Authoring Tool User Interface
    The authoring tool satisfies all of the applicable Level A and Level AA success criteria in Part A. Nothing is implied about Part B.
  3. Partial ATAG 2.0 Conformance Level AAA: Authoring Tool User Interface
    The authoring tool satisfies all of the applicable success criteria in Part A. Nothing is implied about Part B.

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):

  1. Partial ATAG 2.0 Conformance Level A: Content Production
    The authoring tool satisfies all of the applicable Level A success criteria in Part B. Nothing is implied about Part A.
  2. Partial ATAG 2.0 Conformance Level AA: Content Production
    The authoring tool satisfies all of the applicable Level A and Level AA success criteria in Part B. Nothing is implied about Part A.
  3. Partial ATAG 2.0 Conformance Level AAA: Content Production
    The authoring tool satisfies all of the applicable success criteria in Part B. Nothing is implied about Part A.

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 towards toward "Full" Conformance.

Web Content Technologies Produced:

Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g., (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.

Live publishing authoring tools:

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 .

Conformance Claims (Optional)

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): claim). Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation.

Conditions on Conformance Claims

  1. At least one version of the conformance claim must be published on the web as a document meeting Level A of WCAG 2.0. A suggested metadata description for this document is "ATAG 2.0 Conformance Claim".
  2. Whenever the claimed conformance level is published (e.g., (e.g. product information web site), the URI for the on-line published version of the conformance claim must be included.
  3. The existence of a conformance claim does not imply that the W3C has reviewed the claim or assured its validity.
  4. Claimants may be anyone (e.g., authoring tool developers , journalists, other third parties). Claimants are solely responsible for the accuracy of their claims (including claims that include products for which they are not responsible) and keeping claims up to date.Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation.

Required Components of an ATAG 2.0 Conformance Claim

  1. Claimant name and affiliation .
  2. Date of the claim.
  3. Guidelines title , version and URI
  4. Conformance level satisfied.
  5. Authoring tool information: The name of the authoring tool and sufficient additional information to specify the version (e.g., (e.g. vendor name, version number (or version range), required patches or updates, human language of the user interface or documentation ).
    • Note: If the authoring tool is a collection of software components (e.g., (e.g. a markup editor, an image editor, and a validation tool), then information must be provided separately for each component, although the conformance claim will treat them as a whole. As stated above, the Claimant has sole responsibility for the conformance claim, not the developer of any of the software components.
  6. Web content technologies produced .
    • A list of the web content technologies produced by the authoring tool that the Claimant is including in the conformance claim. For each web content technology, provide information on how the web content technology might be used to create accessible web content (e.g., (e.g. provide links to technology-specific techniques).
    • A list of any web content technologies produced by the authoring tool that the Claimant is not including in the conformance claim.
  7. Declarations: For each success criterion:
    • A declaration of whether or not the success criterion has been satisfied; or
    • A declaration that the success criterion is not applicable and a rationale for why not.
  8. Platform(s): The platform(s) upon which the authoring tool was evaluated:

Optional Components of an ATAG 2.0 Conformance Claim

  1. A description of the authoring tool that identifies the types of editing views editing-views that it includes.
  2. A description of how the ATAG 2.0 success criteria were met where this may not be obvious.

"Progress Towards Toward Conformance" Statement

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 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 towards, toward, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards 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.

Disclaimer

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.


Appendix A : Glossary

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.

accessibility problem problems
ATAG 2.0 refers to recognizes two types of accessibility problems:
  • authoring tool user interface accessibility problem : An aspect problems: Aspects of an authoring tool user interface that does not meet a success criterion in Part A of ATAG 2.0.
  • web content accessibility problem : An aspect problems (WCAG): Aspects of web content that does not meet a WCAG 2.0 success criterion. criterion (Level A, AA or AAA).
accessibility information (WCAG)
Any information that web content is required to must contain in order to conform with meet a particular level of WCAG 2.0 (e.g., success criterion (Level A, AA or AAA). Examples include: programmatically associated alternative content (e.g. text alternatives for images, images), role and state information for widgets, relationships within complex tables, captions for audio ). tables).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the accessibility of the content web content being edited (i.e., . These are features added that must be present to meet any of the success criteria in Principle B.2: Authors must be supported in the production of accessible content Part B ). of ATAG 2.0.
alternative content
Web content that is used in place of other content that a person may some people are not be able to access. Alternative content fulfills essentially the same function or purpose as the original content. Examples include WCAG 2.0 recognizes several general types of alternative content (for more information see WCAG 2.0 ):
  • text alternatives for non-text content: Text that is programmatically associated with non-text content , captions or referred to from text that is programmatically associated with non-text content. For example, an image of a chart might have two text alternatives: a description in the paragraph after the chart and a short text alternative for audio , the chart indicating in words that a description follows.
  • audio descriptions alternatives for video , time-based media: Web content that serves the same function or purpose as one or more tracks in a time based media presentation. This includes: captions, audio descriptions, extended audio descriptions, sign language for audio, interpretation as well as correctly sequenced text descriptions of time-based visual and auditory information that also is capable of achieving the outcomes of any interactivity in the time-based presentation.
  • media alternative for text: Media that presents no more information than is already presented in text (directly or via text alternatives). A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for time-based media. See WCAG 2.0 text may be audio-only, video-only (including sign-language video), or audio-video.
Importantly, from the perspective of authoring tools, alternative content may or may not be:
  • programmatically associated: Alternative content whose location and purpose can be programmatically determined from the original content for more information. which it is serving as an alternative. For example, a paragraph might serve as a text alternative for an image, but it is only programmatically associated if this relationship is properly encoded (e.g. by "aria-labeledby").
Note: ATAG 2.0 typically refers to programmatically associated alternative content.
ASCII art
A picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
assistive technology
Software (or hardware), separate from the authoring tool , that provides functionality to meet the requirements of users with disabilities. Some authoring tools may also provide direct accessibility features . Examples of assistive technologies include, but are not limited to, the following: include:
  • screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order improve the visual readability of rendered text and images;
  • screen readers, which are used by people who are blind to read textual information through synthesized speech or Braille;
  • text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
  • speech recognition software, which may be used by people who have some physical disabilities;
  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices);
  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
audio
The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real world real-world sounds, or both.
author actions preventing generation of accessible web content
When the actions of authors prevents authoring tools from generating accessible web content (WCAG) .Examples include: turning off accessibility options, ignoring prompts for accessibility information (WCAG) ,providing faulty accessibility information (WCAG) at prompts, modifying the authoring tool (e.g. via scripting, macros, etc.), and installing plug-ins .
authors
People who use an authoring tool tools to create or modify web content for use by other people. This . The term may include cover roles such as content authors, designers, programmers, publishers, testers, etc. working either alone or collaboratively (see also Part B Conformance Applicability Note 5 6: Multiple author roles ). A person only qualifies as Some authoring tools control who may be an author of some given content if (1) the authoring tool supports the relevant web content technology used to implement that content and (2) the person has by managing author permission for that content. permissions .
author permission
Whether a person has a right to modify Authorization that allows modification of given web content . In other words, whether they qualify as an author of the content. Some authoring tools are capable of managing authoring permissions in order to prevent unauthorized modifications.
authoring action
Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., (e.g. typing text, deleting, inserting an element , applying a template ). Most authoring tool user interfaces also enable actions that do not edit content (e.g., (e.g. saving, publishing , setting preferences, viewing documentation ).
authoring outcome
The content or content modifications that result from authoring actions . Authoring outcomes are cumulative (e.g., (e.g. text is entered, then styled, then made into a link, then given a title).
authoring practice
An approach that authors follow to achieve a given authoring outcome . (e.g., (e.g. controlling presentation with style sheets). Depending on the design of an authoring tool , authoring practices may be chosen by the authors or by the authoring tool. An Authoring practices may or may not be:
authoring session
A state of the authoring tool in which web content can be edited by an author . The
  • end of an authoring session session: is the The point at which the author has no further opportunity to make changes without starting another session. The end of an authoring session may be determined by authors (e.g., (e.g. closing a document, publishing ) or by the authoring tool (e.g., (e.g. when the authoring tool transfers editing permission to another author on a collaborative system). Note system). Note that the end of the authoring session is distinct from publishing. Automatic content generation may continue after the end of both the authoring session and initial publishing (e.g., (e.g. content management system updates).
authoring tool
Any software, or software (or collection of software components , ) that can be used by authors can use (alone or collaboratively) to create or modify web content for use by other people. Examples people (other authors or end user s).
Note 1: "collection of authoring tools: software components": Multiple applications, plug-ins, etc. can be used together to meet ATAG 2.0 applies (see also note in the "Required Components of an ATAG 2.0 Conformance Claim").
Note 2: "alone or collaboratively":
Multiple authors may contribute to a wide variety the creation of web content generating applications, including, but not limited to: and, depending on the authoring tool, each author may work with different views of the content and different author permissions .
Note 3: "to create or modify web content":
This clause rules out software that collects data from a person for other purposes (e.g. online grocery order form) and then creates web content from that data (e.g. a web-based warehouse order) without informing the person (however, WCAG 2.0 would still apply). This clause also rules out software used to create content exclusively in non-web content technologies.
Note 4: "for use by other people":
This clause rules out the many web applications that allow people to modify web content that only they themselves experience (e.g. web-based email display settings) or that only provide input to automated processes (e.g. library catalog search page).
Examples of software that are generally considered authoring tools under ATAG 2.0:
  • web page authoring tools (e.g., (e.g. WYSIWYG HTML editors)
  • software for directly editing source code (see note below )
  • software for converting to web content technologies (e.g., (e.g. "Save as HTML" features in office suites) document applications)
  • integrated development environments (e.g., (e.g. for web application development)
  • software that generates web content on the basis of templates , scripts, command-line input or "wizard"-type processes
  • software for rapidly updating portions of web pages (e.g., (e.g. blogging, wikis, online forums)
  • software for generating/managing entire web sites (e.g., (e.g. content management systems, courseware tools, content aggregators)
  • email clients that send messages in web content technologies
  • multimedia authoring tools
  • debugging tools for web content software for creating mobile web applications
Web-based and non-web-based: ATAG 2.0 applies equally to authoring tools Examples of web content software that are web-based , non-web-based or a combination (e.g., a non-web-based markup editor with a web-based help system, a web-based content management system with a non-web-based file uploader client). Real-time publishing: not considered authoring tools under ATAG 2.0 (in all cases, WCAG 2.0 still applies to authoring tools with workflows that involve real-time publishing of if the software is web-based):
  • customizable personal portals: ATAG 2.0 does not apply because the web content (e.g., some collaborative tools). For these authoring tools, conformance being edited is only available to Part B the owner of the portal
  • e-commerce order forms: ATAG 2.0 may involve some combination does not apply because the purpose of real-time accessibility supports and additional accessibility supports available after an e-commerce order form is to order a product, not communicate with other people via web content, even if the real-time authoring session (e.g., data collected by the ability to add captions for audio that was initially published form actually does result in real-time). For more information, see the Implementing ATAG 2.0 - Appendix E: Real-time web content production . (e.g. online tracking pages, etc.)
  • Text Editors: stand-alone accessibility checkers: ATAG 2.0 is does not intended to apply to simple text editors that can be used to edit source content , but that include because a stand-alone accessibility checker with no support for the production of any particular automated or semi-automated repair functionality does not actually modify web content technology. In contrast, ATAG 2.0 can apply to more sophisticated source content editors content. An accessibility checker with repair functionality or that support the production is considered as part of specific web content technologies (e.g., with syntax checking, markup prediction, etc.). a larger authoring process would be considered an authoring tool.
authoring tool user interface
The display and control mechanism that authors use to operate the authoring tool software. User interfaces may be non-web-based or web-based or a combination (e.g., (e.g. a non-web-based authoring tool might have web-based help pages):
  • authoring tool user interface (non-web-based): Any parts of an authoring tool user interface that are not implemented as web content and instead run directly on a platform that is not a user agent , such as Windows, Mac OS, Java Virtual Machine, etc.
  • authoring tool user interface (web-based): Any parts of an authoring tool user interface that are implemented using web content technologies and are accessed by authors via a user agent .
  • An
Authoring tool user interfaces may or may not be:
  • accessible authoring tool user interface interfaces: is one Authoring tool user interfaces that meets meet the success criteria of a level in Part A . of ATAG 2.0.
checking (accessibility) checking, accessibility
The process by which web content is evaluated for web content accessibility problems (WCAG) . ATAG 2.0 identifies recognizes three types of checking, based on increasing levels of automation of the tests:
  • manual checking : where checking: Checking in which the tests are carried out by authors . This includes the case where authors are aided by instructions or guidance provided by the authoring tool, tool , but where authors must carry out the actual test procedure; procedure.
  • semi-automated checking : where checking: Checking in which the tests are partially carried out by the authoring tool, but where authors ' authors' input or judgment is still required to decide or help decide the outcome of the tests; and tests.
  • automated checking : where checking: Checking in which the tests are carried out automatically by the authoring tool without any intervention by authors . authors. An authoring tool may support any combination of checking types.
collection of software components
Any software programs that are used either together (e.g., (e.g. base tool and plug-in ) or separately (e.g., (e.g. markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the software components.
content (web content)
Information and sensory experience to be communicated to the end user by means of a user agent , including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, the term is primarily used to refer to the output that is produced by the authoring tool . Content produced by authoring tools may include web applications, including those that act as web-based authoring tools. Content may or may not be:
  • Accessible web accessible content (WCAG): is web Web content that conforms to a particular level of WCAG 2.0 (see meets the Relationship to WCAG 2.0 section). success criteria (Level A, AA, or AAA).
  • Structured web content being edited: is The web content that includes machine-readable internal structure (e.g., markup elements an author ), as opposed to unstructured content, such as raster image formats can modify during an authoring session .The content being edited may be a complete piece of content (e.g. image, style sheet) or plain human language only part of a larger piece of content (e.g. a status update). The content being edited only includes content in web content technologies text. that the authoring tool supports (e.g. a WYSIWYG HTML editor allows editing of the HTML content of a webpage editable, but not the images).
content (web content)) properties
The individual pieces of information that make up the web content (e.g., (e.g. the attributes and contents of elements, stylesheet information, etc.). While many web content properties have discrete values (e.g., a single value for size, color, font, etc.), some types of web content (especially graphics) may include properties that can be said to
encode continuous input content (structured) because they incorporate frequent data samples (e.g., the location, speed, pressure, angle, etc. of a pointing device) . For example, a freehand line graphic object might have a "continuous" path property
Web content that encodes thousands of individual x-y location values, but "discrete" properties for setting the color and thickness of the line. A "watercolor stroke" graphic object might have multiple "continuous" properties (e.g., path, speed, pressure) in order includes machine-readable internal structure (e.g. markup elements ), as opposed to graphically mimic the diffusion effects that occur when a real paint brush is moved in a similar manner. unstructured content, such as raster image formats or plain human language text.
content generation (content authoring, content editing)
The act of specifying the web content to be rendered, played or executed by user agents . (also may be referred to as "content authoring" or "content editing"). This may refer to information perceived by end users or to instructions for the user agents. Content may be author generated or automatically generated: In some cases, responsibility for content generation is shared. For example, an author requests an interactive object be placed on their page (e.g., (e.g. a photo album), the authoring tool applies a template , but the template requires input from the author to be complete.
content rendering
User interface functionality that authoring tools present if they render, play or execute the web content being edited. In edited . ATAG 2.0 the term covers recognizes several types of content renderings:
  • conventional renderings (e.g., WYSIWYG (or "WYSIWYG"): When content is rendered in a way that is similar to the default rendering a user agent would create from the same content. While "WYSIWYG", standing for "What-you-see-is-what-you-get" is the common term, differences between user agents and end user settings mean that in reality there is no single typical end user experience; or
  • ), unconventional renderings (e.g., renderings: When content is rendered differently than it would be in a typical user agent (e.g. rendering an audio file as a graphical wavefront) and wavefront); or
  • partial renderings , in which renderings: When some aspects of the content are rendered, played, or executed, but not others (e.g., (e.g. a frame-by-frame video editor renders the graphical, but not the timing aspects, of a video).
content transformations
Processes that take content in one web content technology or non-web content technology (e.g. a word processing format) as input and produce content that has been either:
  • optimized: e.g. removing whitespace, re-compressing images; or
  • restructured: e.g. linearizing tables, splitting a document into pages; or
  • re-coded: e.g. HTML to XHTML, a word processing format to HTML.
control settings
Settings that relate to how authors control operate the authoring tool , for example using the keyboard or mouse mouse.
developer
Any entities or individuals responsible for programming the authoring tool . This includes the programmers of any additional software components included by the Claimant in the conformance claim . In some cases, development of the authoring tool is complete before authors can use it to publish web content . However, in other cases (e.g., (e.g. some web-based authoring tools ), the developer may continue to modify the authoring tool even after content has been published, such that the content experienced by the end user is modified.
direct accessibility features
Features of an authoring tool that provide functionality to meet the requirements of authors with disabilities (e.g., (e.g. keyboard navigation, zoom features, text-to-speech). Additional or specialized functionality may still be provided by external assistive technology .
display settings
Display settings Settings that relate to how authors perceive the authoring tool. These include:
documentation
Any information that supports the use of an authoring tool . This information may be provided electronically or otherwise and includes help, manuals, installation instructions, sample work flows , tutorials , etc.
document object
The internal representation of data in the source content by a non-web based authoring tool or user agent . The document object may form part of a platform accessibility architecture service that enables communication with assistive technologies . Web-based authoring tools are considered to make use of the document object that is maintained by the user agent .
element
A pair of markup tags and its content, or an "empty tag" (one that requires no closing tag or content).
end user
A person who interacts with web content once it has been authored. This includes people using assistive technologies .
human language
Language that is spoken, written or signed (through visual or tactile means) to communicate with humans.
informative
For information purposes and not required for conformance.
keyboard interface
An interface used by software to obtain keystroke input. A keyboard interface can allows keystroke input even if particular devices do not contain a conventional keyboard (e.g., (e.g. a touchscreen PDA can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected). Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.
keyboard trap
A user interface situation in which the a keyboard interface may be used to move focus to, but not from, a control user interface component or group of controls. components.
label
Text or other component with a text alternative that is presented to users to identify a component. A label is presented to all users whereas the name may be hidden and only exposed by assistive technology . In many (but not all) cases the name and the label are the same.
live
Information captured from a real-world event that is published with no more than a broadcast delay.
Note: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.
markup language
A system of text annotations (e.g., (e.g. elements in HTML) and processing rules that may be used to specify the structure, presentation or semantics of content. content . Examples of markup languages include HTML and SVG. The
  • markup of some content is the set of annotations that appear in the content.
name
Text by which software can identify a user interface component to the user. author or end user . The name may be hidden and only exposed by assistive technology, technology , whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.
non-text content
Any content that is not a sequence of characters that can be recognized programmatically determined or where the sequence is not expressing something in human language . This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text.
normative
Required for conformance. One may conform in a variety of well-defined ways to this document. ATAG 2.0. Content identified as " informative " or "non-normative" is never required for conformance.
option
When an author is presented with choices.
  • default option: A setting or value for an option that is assigned automatically by the authoring tool and remains in effect unless canceled or changed by the author .
platform
The software environment within which the authoring tool operates. In the case of web-based authoring user interfaces , this will be user agents . In the case of non-web-based user interfaces this will be operating systems (e.g., (e.g. Windows, Mac OS, Linux), virtual machines (e.g., (e.g. JVM ), etc.
platform accessibility architecture service
A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g., MSAA (e.g. MSAA, IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OSX applications, Gnome Accessibility Toolkit API for Gnome applications, Java Access for Java applications, etc.). On some platforms , it may be conventional to enhance communication further by implementing a document object .
plug-in
A program that runs as part of the authoring tool (e.g., (e.g. a third-party checking and repair tool) and that is not part of web content being edited. edited . Authors generally choose to include or exclude plug-ins from their authoring tool.
presentation
Rendering of the content in a form to be perceived by authors or end users .
programmatically determined (programmatically determinable)
When information Information that is encoded in a way that allows different software, including assistive technologies , to extract and present the information in different modalities. ATAG 2.0 uses this term in two contexts:
prominence
A heuristic measure of how likely users are to notice items (e.g., single controls, groups of controls, text messages) a user interface component in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g., (e.g. size, spacing, color), and even the modality of use (e.g., (e.g. mouse vs. keyboard use).
  • at least as prominent: For purposes of conformance to ATAG 2.0, item a user interface component A is considered to be at "at least as prominent prominent" as item another component B if: both items occur in when, from a default state, component A becomes displayed (and enabled) with the same item number or less "opening" actions than are required for component B to become displayed (and enabled).
    Note 1: When a container (e.g., is open, all of the enabled components in the container (e.g. items in a menu for menu items, list, items in a list for list items, menu, buttons in a toolbar, all components on a dialog box for text boxes); box, etc.) are considered to be displayed (and therefore are at least as prominent as each other), even if item B is emphasized, then so is item A; the container must be scrolled for them to become visible. This takes into account that different screen sizes and item A occurs higher in author settings will affect which components are visible at a given time.
    Note 2: "Opening actions" are actions made by authors on components within the reading order user interface that result in new components becoming displayed or immediately follows enabled. For example: (a) keyboard shortcut to a top-level menu item B. to display a sub-menu, (b) keyboard selection on a button to display a dialog box, (c) mouse click on a checkbox to enable previously disabled sub-items, etc. Actions that do not cause new components to become actionable (e.g., moving focus, scrolling a list), are not counted as "opening actions".
    Note 3: Keyboard shortcuts to components in closed containers are not counted as "opening actions" because the components have no prominence when they are not displayed. The same is true when authors must use "search" to reveal components in closed containers.
    Note 4: The "default state" is the state of the authoring tool at the beginning of an authoring session as set by the developer. The default state of many document authoring tools is an editing-view .
prompt
Any authoring tool initiated request for a decision or piece of information from authors . Well designed prompting will urge, suggest, and encourage authors.
publishing
The Any point at which the authors or authoring tool make web content available to end users (e.g., (e.g. uploading a web page, committing a change in a wiki). recognized (by the authoring tool) When an authoring tool is able to process encoded information, such as labels , names , roles or relationships , with certainty. For example, an authoring tool would only be able to recognize a particular text string as a text label for non-text content , if this relationship was appropriately encoded (e.g., in an alt attribute, by a labeledby property). If success criteria apply to recognized types of content (e.g., tool-recognized alternative content ), the conformance claim must list the recognized types. wiki, live streaming).
relationships
Meaningful associations between distinct pieces of content .
repairing (accessibility)
The process by which web content accessibility problems that have been identified within web content are resolved. ATAG 2.0 identifies recognizes three types of repairing, based on increasing levels of automation:
  • manual : where repairing: Where the repairs are carried out by authors . This includes the case where authors are aided by instructions or guidance provided by the authoring tool , but where authors carry out the actual repair procedure;
  • semi-automated : where repairing: Where the repairs are partially carried out by the authoring tool , but where authors ' input or judgment is still required to complete the repair; and
  • automated : where repairing: Where the repairs are carried out automatically by the authoring tool without any intervention by authors .
restrictions, restricted web content authoring
When the web content that authors can specify with an authoring tool either must include or must not include certain content (e.g. elements, attributes, widgets, etc). Many authoring tools restrict authoring in some way, which can either benefit accessibility (e.g., if text alternatives for non-text content are required) or detract from accessibility (e.g. if attributes for defining text alternatives are not available). In contrast, authoring tools that allow unrestricted web content authoring do not require any particular content to be included or not included (e.g. many source editing-views ).
reversible actions
Authoring actions that, by their nature, can be completely undone so that the system returns to the state it was in before the action. The opposite of reversible actions are:
  • Irreversible actions irreversible actions: are actions Actions that cannot be reversed and may include certain save and delete actions as well as actions made in a collaborative environment that another author has begun to work with.
role
Text or a number by which software can identify the function of a component within web content (e.g., (e.g. a string that indicates whether an image functions as a hyperlink, command button, or check box).
sequential keyboard navigation
Using a keyboard interface to navigate one-by-one through all of the items in an ordered set (e.g. menu items, form fields, etc.). This is in contrast to direct navigation methods such as keyboard shortcuts and bypass links.
technology (web content)
A mechanism for encoding instructions to be rendered, played or executed by user agents . Web content technologies may include markup languages , data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static web pages to multimedia presentations to dynamic web applications. Some common examples of web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, Silverlight, Flex and JavaScript.
template s
A content pattern Content patterns that is are filled in by authors or the authoring tool to produce content for end users (e.g., (e.g. document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.
  • accessible templates (WCAG): Templates that the author or authoring tool can use to create web content that meets the WCAG 2.0 success criteria at a particular level (Level A, AA or AAA) under both of the following conditions:
    1. Authors correctly follow the minimum instructions associated with the template, including providing complete and correct information when requested (e.g. by responding to prompts, replacing highlighted placeholders, etc.); and
    2. No further authoring occurs (e.g. a "blank" document template would be assessed only on the basis of the resulting blank web content).
template selection mechanism
A function beyond standard file selection that allows authors to select templates to use as the basis for new content or to apply to existing content.
tutorial
A type of documentation that provides step-by-step instructions for performing multi-part tasks.
user agent
Any software that retrieves, renders and facilitates end user interaction with web content . Examples include web browsers, browser plug-ins, and media players.
user interface component
A part of the user interface or content display (including content renderings ) that is perceived by authors as a single control for a distinct function.
video
The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.
view
A user interface function that authors use to interact with the web content being edited. edited . ATAG 2.0 categorizes views according to whether they support editing and the way in which they present content: editing:
  • editing views editing-views: are editable. View in which some or all of the content is editable; or
  • previews previews: are not editable and Views in which none of the content is editable. Often the purpose is to present content as it would appear in a user agent .
  • There are three
ATAG 2.0 also recognizes several approaches to presenting the content in a view:
  • as source content views in which the unrendered : The content is presented (e.g., in unrendered form (e.g. plain text editors), editors); or
  • as content rendering , and rendered views: Content renderings (conventional, unconventional or partial) are presented; or
  • as pre-built content property views: in which authors set only high-level options that Only properties of the content are presented. The authoring tool then interprets uses these properties to automatically generate the resulting content (e.g., a calendar module in a content management system). web content transformation to be published A process (e.g. CMS calendar widget that takes as input, content in one web content technology or non-web content technology (e.g., generates a word processing format) calendar from the numeric month and produces as output, web content that has been restructured (linearizing tables, splitting a document into pages), re-coded (e.g., HTML to XHTML, a word processing format to HTML) or optimized (e.g., removing whitespace, re-compressing images). year).
workflow
A customary sequence of steps or tasks that authors follow to produce a content deliverable. If an authoring tool is composed of a collection of software components , then its workflows may include use of one or more of the components.
WYSIWYG This is an acronym for "What You See Is What You Get". A WYSIWYG view displays (to authors ) the content being edited in a way that is very similar to how it will appear to end users .

Appendix B: How to refer to ATAG 2.0 from other documents

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):

  1. References to a specific version of "Authoring Tool Accessibility Guidelines 2.0." For example, use the "this version" URI to refer to the current document:
    http://www.w3.org/TR/2010/WD-ATAG20-20100708/ http://www.w3.org/WAI/AU/2011/WD-ATAG20-20110426/
  2. References to the latest version of "Authoring Tool Accessibility Guidelines 2.0." Use the "latest version" URI to refer to the most recently published document in the series:
    http://www.w3.org/TR/ATAG20/ .

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/2010/WD-ATAG20-20100708/"> href="http://www.w3.org/WAI/AU/2011/WD-ATAG20-20110426/">
"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 .


Appendix C : References

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.

[ATAG10]
" Authoring Tool Accessibility Guidelines 1.0 ", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is available at http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[UAAG]
" User Agent Accessibility Guidelines 1.0 ," I. Jacobs, J. Gunderson, E. Hansen, eds.17 December 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
[WCAG20]
" Web Content Accessibility Guidelines 2.0 ", B. Caldwell, M. Cooper, L. Guarino Reid, and G. Vanderheiden.

Appendix D : Acknowledgments

Appendix Editors:

Participants active in the AUWG at the time of publication:

Other previously active AUWG participants and other contributors to ATAG 2.0:

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 Loughbor 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.


Appendix E: Checklist