[Contents]

W3C

Authoring Tool Accessibility Guidelines (ATAG) 2.0

W3C Working Draft 29 October 2009

This version:
http://www.w3.org/TR/2009/WD-ATAG20-20091029/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2009/WD-ATAG20-20090521/
Editors:
Jan Richards, Adaptive Technology Resource Centre, University of Toronto
Jeanne Spellman, W3C
Jutta Treviranus, Adaptive Technology Resource Centre, 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 for 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 Working Draft of 29 October 2009. This draft integrates changes made as a result of comments received on the 21 May 2009 Public Working Draft.

Substantial changes include:

  1. The ATAG Working Group (AUWG) has revised and renamed the support document for ATAG 2.0, formerly Techniques for ATAG 2.0, to Implementing ATAG 2.0.
  2. The Working Group has revised section B.2 advising how authoring tools should support authors in making choices that improve accessibility
  3. Part A (Make the authoring tool user interface accessible) has improvements to the clarity of the success criteria.
  4. The Working Group has addressed editorial comments received on the 21 May 2009 Working Draft and completed a general editorial review for clarity.

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

  1. Does the new Implementing document explain and ease implementation of ATAG?
  2. Should there be an exception for level A keyboard accessibility in section A.3.1.1 for certain free-hand drawing or other software tools requiring timing or pressure information from a pointing device? Is the exception properly phrased to allow those drawing programs to meet ATAG at A level while still encouraging developers to provide full keyboard access for AAA compliance?
  3. Is the lack of specific Techniques a barrier to implementing ATAG?
  4. Are there any areas in which the guidelines may be lacking?

Comments on this working draft are due on or before 30 November 2009. Comments on the draft should be sent to public-atag2-comments@w3.org (Public Archive).

The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.

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 authoring tools that they develop more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others.

Accessibility, from an authoring tool perspective, includes addressing the needs of two (potentially overlapping) user groups with disabilities:

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 web content that conforms to the highest level of WCAG 2.0 (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.

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 view and apply all layers that they are able to.

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:

  1. All success criteria must:
    • present authoring tool user interface-related accessibility issues (in Part A). In other words, the access 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, or
    • present accessible web content production issues (in Part B). In other words, the issue must be specific to authoring accessible web content software, as opposed to authoring web content in general.
  2. 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:

Some of the common factors evaluated when setting the level in Part B included:

Integration of Accessibility Features

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


Guidelines

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

PART A: Make the authoring tool user interface accessible

Applicability Notes:

  1. Scope of Authoring Tool User Interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited, and features that are independent of the web content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.
  2. Reflected Content Accessibility Problems: The authoring tool is responsible for ensuring that editing views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that an image label in the web 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 web content being edited (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
  3. User Agent Features: Web-based authoring tools may rely on user agent features (e.g., keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria as long as the user agent is listed in the conformance claim.
  4. Applies to Features for Part B: The Part A success criteria apply to the entire authoring tool user interface, including any of the features (e.g., checking tool , tutorials) added to meet the Part B success criteria.
  5. Previews: Preview features are exempt from having to meet the other requirements in Part A, if they meet Guideline A.3.7. Previews are treated differently than editing views because authors, including those with disabilities, are not well-served if preview features diverge too much from the actual functionality of user agents.

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

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

Rationale: When authoring tools or parts of authoring tools (e.g., an online help system) 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): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)

A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA)

A.1.1.3 Web-Based Accessible (WCAG Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)

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

Rationale: When authoring tools or parts of authoring 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 platform conventions that support accessibility will facilitate access by all authors, including those using assistive technologies.

A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A)

PRINCIPLE A.2: Editing views must be perceivable

Guideline A.2.1 [For the authoring tool user interface] Make alternative content available to the author. [Implementing A.2.1]

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

A.2.1.1 Recognized Alternative Content: When recognized alternative content is available for web content being edited, the authoring tool makes the alternative content accessible to the author(s). (Level A)

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

Rationale: Some authors need access to the editing view presentation because this may be used to convey both status information added by the authoring tool (e.g., underlining misspelled words) and, within content renderings, information about the end user experience of the web content being edited.

A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of web content to provide additional information to the author(s), then that additional information can be programmatically determined. (Level A)

A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then those properties can be programmatically determined: (Level A)

  • (a) Text font; and
  • (b) Text style (e.g., italic, bold); and
  • (c) Text color; 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 can be programmatically determined. (Level AAA)

Guideline A.2.3: Ensure the independence of the 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 the published web content.

A.2.3.1 Independence of Display: The author(s) can set a global option to specify display settings for editing views that take precedence over web content renderings without affecting the web content to be published. (Level A)

PRINCIPLE A.3: Editing views must be operable

Guideline A.3.1 [For the authoring tool user interface] Enhance 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.

A.3.1.1 Keyboard (Minimum): : All functionality of the authoring tool is operable through a keyboard interface and does not require specific timings for individual keystrokes. An exception to keyboard operability is allowed where the underlying function requires input that depends on the path of the author's movement and not just the endpoints. (Level A)

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the author's movement and not just the endpoints. (Level A)
Note 1: The movement path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

A.3.1.2 Avoiding Content Keyboard Traps: The authoring tool prevents keyboard traps as follows: (Level A)

  • (a) In the authoring tool user interface: If keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key); and
  • (b) In editing views that render content: If an editing view (e.g., WYSIWYG view) renders web content, then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).

A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts. (Level AA)

A.3.1.4 Customize Keyboard Access: The author(s) can customize keyboard access to the authoring tool. (Level AAA)

Guideline A.3.2 [For the authoring tool user 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 fast reaction speed, such as clicking on a moving target.

A.3.2.1 Data Saved: If the authoring tool may end authoring sessions due to time limits (e.g., an authenticated session expires), then the author(s) can set a global option to ensure that the web content being edited is saved. (Level A)
Note: For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.

A.3.2.2 Timing Adjustable: For each time limit that is set by the authoring tool, at least one of the following is true: (Level A)

  • (a) Turn off: The author(s) are allowed to turn off the time limit before encountering it; or
  • (b) Adjust: The author(s) 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: The author(s) are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and the author(s) 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., 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 Moving Targets: If a user interface component is moving (e.g., animated vector graphic), then the author(s) can stop the movement. (Level A)

Guideline A.3.3 [For the authoring tool user 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: If an editing view renders time-based content (e.g., animations), the author(s) can set a global option to render only the initial state of time-based web content. (Level A)

Guideline A.3.4 [For the authoring tool user 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 by Structure: If an editing view displays a structured element set, then the author(s) can select any element in the structured element set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. (Level A)

A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, then the author(s) can move the editing focus forward or backward to the next instance of the same element. (Level AA)

A.3.4.3 Navigate By Headings: If an editing view displays a structured element set, then the author(s) can move the editing focus to the heading before or the heading after the element. (Level AA)

A.3.4.4 Navigate Tree Structures: If an editing view displays a structured element set, then the author(s) can move the editing focus from any element to the following other elements in the structured element set (if they exist): (Level AA)

  • (a) Parent: The element immediately above; and
  • (b) Child: The first element immediately below; and
  • (c) Previous Sibling: The element immediately preceding at the same level; and
  • (d) Next Sibling: The element immediately following at the same level.

Guideline A.3.5 [For the authoring tool user 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: The author(s) can perform text searches of web content in which all of the following are true: (Level AA)

  • (a) Search All Editable: The search can be within any information that is text and that the authoring tool can modify (e.g., text content, text alternatives for non-text content, metadata, markup elements and attributes, etc.); and
    Note: If the current editing view is not able to display the results of a search then the authoring tool may switch to a different editing view to display the results (e.g., to a source content editing view to display search results within markup tags).
  • (b) Bi-Directional: The search can be made forwards or backwards; and
  • (c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

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

Rationale: Providing the ability to save and reload sets of keyboard and display preference settings benefits authors who have needs that differ over time (e.g., due to fatigue).

A.3.6.1 Save Settings: Preference settings are stored for any of the following that the authoring tool controls (i.e., that are not controlled by the platform): (Level AA)

A.3.6.2 Multiple Sets: The author(s) can save and reload multiple sets of preferences (e.g., personal profiles, personal settings) for any of the following that the authoring tool controls (i.e., that are not controlled by the platform): (Level AAA)

A.3.6.3 Options Assistance: The authoring tool includes a mechanism to help the author(s) configure options related to Part A. (Level AAA)

Guideline A.3.7 [For the authoring tool user 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.

A.3.7.1 Return Mechanism: If a preview is provided, then the author(s) can return from the preview using only keyboard commands. (Level A)

A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A)

  • (a) Existing User Agent: the preview makes use of an existing user agent that is specified in the conformance claim (e.g., opening the content in a third-party browser, browser component, video player, etc.); or
  • (b) Part A.1: the preview meets all of the Level A guidelines in Principle A.1 of this document; or
  • (c) UAAG (level A): the preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].

PRINCIPLE A.4: Editing views must be understandable

Guideline A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. [Implementing A.4.1]

Rationale: Some authors who have difficulty making fine movements may be prone to making unintended actions.

A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. (Level A)
Note 1: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.

Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to make all previous authoring actions irreversible.

A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)

A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s). (Level AA)

Guideline A.4.2 [For the authoring tool user 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 documentation.

See Also: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of this document (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)

A.4.2.2 Document All Features: All features of the authoring tool are documented. (Level AA)

PART B: Support the production of accessible content

Applicability Notes:

  1. Author Availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
  2. Responsibility After Authoring Sessions: Authoring tools are not responsible for web content accessibility problems that result from carrying out instructions made by authors during authoring sessions (e.g., the content of a third-party feed specified by the author). Authoring tools are responsible if the web content accessibility problems are automatically generated (e.g., when the developer of a content management system updates its site-wide templates).
  3. Existing Technologies: The Part B success criteria in only apply to support for production of web content using the web content technologies that are included in the conformance claim.
  4. Authoring Systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in the conformance claim) can be used in conjunction to meet the requirements of Part B. (e.g., an authoring tool could make use of a third-party software accessibility checking and repair tool).

PRINCIPLE B.1: Production of accessible content must be enabled

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

Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content requirements. To support accessible web content production, at minimum, it must be possible to produce web content that complies with WCAG 2.0 using the authoring tool.

B.1.1.1 Accessible Content Production (WCAG Level A): The author(s) can use the authoring tool to produce web content that conforms to WCAG 2.0 Level A.

B.1.1.2 Accessible Content Production (WCAG Level AA): The author(s) can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AA.

B.1.1.3 Accessible Content Production (WCAG Level AAA): The author(s) can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AAA.

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

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

B.1.2.1 End Product Preserves Accessibility Information: If the web content technology of the output of a transformation or conversion can preserve recognized accessibility information that is required for that web content to conform to WCAG 2.0 Level A, then the accessibility information is preserved and available for end users in the end product of the transformation or conversion. (Level A)

B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a transformation or conversion cannot preserve recognized accessibility information that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level A, then at least one of the following are true: (Level A)

B.1.2.3 Accessibility Information Preservation (Enhanced): If the authoring tool performs transformations or conversions during an authoring session, then any accessibility information in the pre-transformation/conversion content that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level AA or AAA is preserved and available for end users. (Level AA)

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true: (Level AA)

Guideline B.1.3 Ensure that automatically generated content is accessible. [Implementing B.1.3]

Rationale: Authoring tools that automatically generate content that is not accessible impose additional repair tasks on authors.

See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.

B.1.3.1 Automatic Accessible (WCAG Level A): If the authoring tool automatically generates content, then that web content meets WCAG 2.0 Level A prior to publishing. (Level A)
Note 1: This success criterion (as well as B.1.3.2 and B.1.3.3) applies to the automated behavior specified by the authoring tool developer only when author(s) respond properly to any prompts.
Note 2: This success criterion (as well as B.1.3.2 and B.1.3.3) does not apply when actions of the author(s) prevent generation of accessible web content (e.g., the author(s) might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).

B.1.3.2 Automatic Accessible (Level AA): If the authoring tool automatically generates content, then that web content meets WCAG 2.0 Level AA prior to publishing. (Level AA)

B.1.3.3 Automatic Accessible (Level AAA): If the authoring tool automatically generates content, then that web content meets WCAG 2.0 Level AAA prior to publishing. (Level AAA)

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

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

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

B.2.1.1 Decision Support: If the authoring tool provides authors with a choice between web content technology options, then the following information is provided for each option: (Level A)

B.2.1.2 Set Accessible Properties: Mechanisms that set the properties of web content (e.g., attribute values, etc.) include the ability to set the accessibility-related properties. (Level A)

B.2.1.3 Other Technologies: If the authoring tool enables web content to be inserted that the authoring tool cannot be used to edit, then provide the author(s) with the option to insert or associate accessibility information. (Level A)


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.

See also: For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.

B.2.2.1 Check Accessibility (WCAG Level A): At least one individual check is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify web content to meet (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A)
Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, manual checking is the minimum requirement to meet this success criterion (as well as B.2.2.4 and B.2.2.10).

B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool. (Level A)

B.2.2.3 Help Authors Decide: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide whether it is correctly identified. (Level A)

B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant web content is identified (e.g., displaying the web content, displaying line numbers, etc.) (Level AA)

B.2.2.5 Check Accessibility (WCAG Level AA): At least one individual check is associated with each WCAG 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AA)

B.2.2.6 View Status: If the authoring tool records web content accessibility problems found during checking, then a list of any problems is available to authors prior to the end of the authoring session. (Level AA)

B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking, then authors have the option to save a list of web content accessibility problems to facilitate interoperability between checking and repair. (Level AA)

B.2.2.8 Metadata for Discovery: If the authoring tool records the accessibility status of web content, then authors have the option to associate this status with the web content as metadata to facilitate resource discovery by end users. (Level AA)

B.2.2.9 Metadata for Repair: If repair assistance is not provided during checking, then authors have the option to save a metadata listing of the web content accessibility problems to facilitate interoperability between checking and repair. (Level AAA)

B.2.2.10 Check Accessibility (WCAG Level AAA): At least one individual check is associated with each WCAG 2.0 Level AAA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AAA)

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 the utility of checking and increases the likelihood that accessibility problems will be properly addressed.

See also: For more information on repair , see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.

B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level A)
Note: While automated repair assistance or more advanced implementations of semi-automated repair assistance may improve the authoring experience, manual repair assistance is the minimum requirement to meet this success criterion (as well as success criteria B.2.3.2 and B.2.3.3).

B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web content accessibility problem that is identifiable during checking (required in Success Criterion B.2.2.5), repair assistance is provided. (Level AA)

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 (required in Success Criterion B.2.2.10), repair assistance is provided. (Level AAA)

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

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

B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)

B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)

  • (a) Author control: authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion; and
  • (b) Relevant sources: the suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description).

B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text value that is equally available to user agents (e.g., the filename is not used). (Level A)

B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)

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

Rationale: Templates and other pre-authored content (e.g., clip art, synchronized media, widgets, etc.) that are not accessible impose additional repair tasks on authors.

B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level A when used. (Level A)
Note: Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of web content (in the final web content technology) created when authors use them properly.

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

B.2.5.3 Templates Accessible (WCAG Level AA): If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level AA when used. (Level AA)

B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true (Level AA):

B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates. (Level AA)

B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true (Level AA):

  • (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: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. (Level AAA)

B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA)

B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically select templates or pre-authored content, then the selection meets WCAG 2.0 Level AAA when used. (Level AAA)

PRINCIPLE B.3: Accessibility solutions must be promoted and integrated

Guideline B.3.1 Ensure that accessible authoring actions are given prominence. [Implementing B.3.1]

Rationale: When authors are learning a new authoring tool, they may find and learn to use the first authoring action they encounter that achieves their intended outcome. Since they may be unaware of the issue of accessibility, it is preferable that accessible web content be an additional unintended outcome, rather than inaccessible content.

B.3.1.1 Accessible Options Prominent (WCAG Level A): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not. (Level A)

B.3.1.2 Accessible Options Prominent (WCAG Level AA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not. (Level AA)

B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not. (Level AAA)

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

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 Active by Default: All accessible content support features are turned on by default. (Level A)

B.3.2.2 Reactivate Option: If the author(s) turn off an accessible content support feature, then they can always turn on the feature. (Level A)

B.3.2.3 Deactivation Warning: If the author(s) deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)

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

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

Rationale: Without documentation of the features that support the production of accessible content (e.g., prompts for text alternatives, accessibility checking tools), some authors may not be able to use them.

B.3.3.1 Instructions: Instructions for using the accessible content support features appear in the documentation. (Level A)

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)

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 Model Accessible Practice (WCAG Level A): A range of examples of documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)

B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples of documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AA)

B.3.4.3 Model Accessible Practice (WCAG Level AAA): A range of examples of documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AAA accessible authoring practices. (Level AAA)


Conformance

This section is normative.

Conformance means that the authoring tool satisfies the success criteria defined in the guidelines section. This conformance section describes conformance and lists the conformance requirements.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

ATAG 2.0 is intended to be used in conjunction with WCAG 2.0 [WCAG20] (or similar web content accessibility guidance, such as regulations based on WCAG 2.0, etc.).

The relationship is as follows:

Levels of Conformance

Conformance Levels in Conformance Claims

Authoring tools may claim "full" or "partial" conformance to ATAG 2.0. In either case, a level is also claimed which depends on the level of the success criteria that have been satisfied.

"Full" ATAG 2.0 Conformance: This type of conformance claim is intended to be used when developers have considered the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible) and the perspective of end users of content produced by the authoring tools (Part B: Support the production of accessible content):
  1. Full ATAG 2.0 Conformance at Level "A"
    The authoring tool satisfies all of the Level A success criteria.
  2. Full ATAG 2.0 Conformance at Level "Double-A"
    The authoring tool satisfies all of the Level A and Level AA success criteria.
  3. Full ATAG 2.0 Conformance at Level "Triple-A"
    The authoring tool satisfies all of the success criteria.

"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance claim is intended to be used when developers have initially focused on the accessibility of the authoring tool to authors (Part A: Make the authoring tool user interface accessible):

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

"Partial" ATAG 2.0 Conformance: Content Production:This type of conformance claim is intended to be used when developers have initially focused on the accessibility of the web content produced by the authoring tool to end users (Part B: Support the production of accessible content):

  1. Partial ATAG 2.0 Conformance Level "A": Content Production
    The authoring tool satisfies all of the Level A success criteria in Part B. Nothing is claimed about Part A.
  2. Partial ATAG 2.0 Conformance Level "Double-A": Content Production
    The authoring tool satisfies all of the Level A and Level AA success criteria in Part B. Nothing is claimed about Part A.
  3. Partial ATAG 2.0 Conformance Level "Triple-A": Content Production
    The authoring tool satisfies all of the success criteria in Part B. Nothing is claimed about Part A.

Note: The Working Group remains committed to the guiding principle that: "Everyone should have the ability to create and access web content". Therefore, it is recommended that "Partial" Conformance be claimed only as a step towards "Full" Conformance.

Conformance Claims

A conformance claim is an assertion by a Claimant that an authoring tool has satisfied the requirements of ATAG 2.0 under the conditions described.

Conditions on Conformance Claims

Required Components of an ATAG 2.0 Conformance Claim

  1. Claimant name and affiliation.
  2. Date of the claim.
  3. Conformance level satisfied.
  4. Authoring tool information: The name of the authoring tool and sufficient additional information to specify the version (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., 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.
  5. Included Technologies: A list of the web content technologies (including version numbers) produced by the authoring tool that the Claimant is including in the conformance claim. By including a web content technology, the Claimant is claiming that the authoring tool meets the requirements of ATAG 2.0 during the production of web content using that web content technology.
  6. Excluded Technologies: A list of any web content technologies produced by the the authoring tool that the Claimant is excluding from the conformance claim. The authoring tool is not required to meet the requirements of ATAG 2.0 during the production of the web content technologies on this list.
  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 that it includes.
  2. A description of how the ATAG 2.0 success criteria were met where this may not be obvious.

"Progress Towards 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 conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed towards, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Towards Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.

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. Except where indicated by "[ ]", the source of these definitions is the AUWG, developed with a goal of clarity, detail, understanding, and completeness. Every attempt has been made to find appropriate definitions for these terms from other sources before such development by the AUWG. All these terms are linked at least from their first usage in the specification. Terms that have designations of "[ ]" beside them are taken from the indicated W3C specifications. Where a definition so referenced is not suitable or adequate for the ATAG2.0, it may be modified as described herein. Please consult http://www.w3.org/TR/qaframe-spec/ for more information on the role of definitions in specification quality.

abbreviation [adapted from WCAG 2.0]
Shortened form of a word, phrase, or name where the abbreviation has not become part of the language. Includes:
  1. initialism: shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase (e.g., ESP is an initialism for extrasensory perception).
  2. acronym: abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word (e.g., WAI is an acronym made from the initial letters of the Web Accessibility Initiative).
accessibility problem
ATAG 2.0 refers to two types of accessibility problems:
  1. authoring tool user interface accessibility problem: An aspect of an authoring tool user interface that does not meet a success criterion in Part A.
  2. web content accessibility problem: An aspect of web content that does not meet a WCAG 2.0 success criterion.
accessibility information
Any information that web content is required to contain in order to conform with WCAG 2.0 (e.g., text alternatives for images, role and state information for widgets, relationships within complex tables, captions for audio).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the accessibility of the content being edited (i.e., features added to meet any of the success criteria in Principle B.2).
alternative content
Content that is used in place of other content that a person may not be able to access. Alternative content fulfills essentially the same function or purpose as the original content. Examples include text alternatives for non-text content, captions for audio, audio descriptions for video, sign language for audio, media alternatives for time-based media. See WCAG 2.0 for more information.
ASCII art [WCAG 2.0]
A picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
assistive technology [adapted from WCAG 2.0]
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:
  • 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 [adapted from WCAG 2.0]
The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real world sounds, or both.
authoring action
Any action that authors can take using the authoring tool user interface that results in creating or editing web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit web content (e.g., setting preferences, viewing documentation).
authoring outcome
The content or content modifications that result from authoring actions. Authoring outcomes are cumulative (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., 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 accessible authoring practice is one in which the authoring outcome conforms to WCAG 2.0 . Some accessible authoring practices require accessibility information.
authoring session
A state of the authoring tool in which content can be edited by an author. The end of an authoring session is 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., closing a document, publishing) or by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative 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., content management system updates).
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., a non-web-based authoring tool might have web-based help pages). An accessible authoring tool user interface is one that meets the success criteria of a level in Part A.
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, MacOS, 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.
authoring tool
Any software, or collection of software components, that authors can use to create or modify web content for use by other people.
  1. Examples of authoring tools: ATAG 2.0 applies to a wide variety of web content generating applications, including, but not limited to:
    • web page authoring tools (e.g., WYSIWYG HTML editors)
    • software for directly editing source code (see note below)
    • software for converting to web content technologies (e.g., "Save as HTML" features in office suites)
    • integrated development environments (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., blogging, wikis, online forums)
    • software for generating/managing entire web sites (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
  2. Web-based and non-web-based: ATAG 2.0 applies equally to authoring tools of web content 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).
  3. Real-time publishing: ATAG 2.0 applies to authoring tools with workflows that involve real-time publishing of web content (e.g., some collaborative tools). For these authoring tools, conformance to Part B of ATAG 2.0 may involve some combination of real-time accessibility supports and additional accessibility supports available after the real-time authoring session (e.g., the ability to add captions for audio that was initially published in real-time). For more information, see the Implementing ATAG 2.0 - Appendix E: Real-time content production.
  4. Text Editors: ATAG 2.0 is not intended to apply to simple text editors that can be used to edit source content, but that include no support for the production of any particular web content technology. In contrast, ATAG 2.0 can apply to more sophisticated source content editors that support the production of specific web content technologies (e.g., with syntax checking, markup prediction, etc.).
author permission
Whether a person has a right to modify 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.
authors
One or more people using an authoring tool to create or modify web content for use by other people. This may include content authors, designers, programmers, publishers, testers, etc. working either alone or collaboratively. A person only qualifies as an author of some given web content if (1) the authoring tool supports the relevant web content technology used to implement that web content and (2) the person has author permission for that web content.
checking (accessibility) [harmonized with EARL 1.0]
The process by which web content is evaluated for web content accessibility problems. ATAG 2.0 identifies three types of checking, based on increasing levels of automation of the tests:
  1. manual checking: where the tests are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure;
  2. semi-automated checking: where the tests are partially carried out by the authoring tool, but where authors' input or judgment is still required to decide or help decide the outcome of the tests; and
  3. automated checking: where the tests are carried out automatically by the authoring tool without any intervention by the 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., base tool and plug-in) or separately (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.
conforming alternate version [adapted from WCAG 2.0]
A version of web content that:
  1. conforms at the designated level, and
  2. provides all of the same information and functionality in the same human language, and
  3. is as up to date as the non-conforming content, and
  4. for which at least one of the following is true:
    1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
    2. the non-conforming version can only be reached from the conforming version, or
    3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version
  • Note 1: In this definition, "can only be reached" means that there is some mechanism, such as a conditional redirect, that prevents a user from "reaching" (loading) the non-conforming page unless the user had just come from the conforming version.
  • Note 2: The alternate version does not need to be matched page for page with the original (e.g., the conforming alternate version may consist of multiple pages).
  • Note 3: If multiple language versions are available, then conforming alternate versions are required for each language offered.
  • Note 4: Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1.
  • Note 5: The conforming alternative version does not need to reside within the scope of conformance, or even on the same web site, as long as it is as freely available as the non-conforming version.
  • Note 6: Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension.
  • Note 7: Setting user preferences within the content to produce a conforming version is an acceptable mechanism for reaching another version as long as the method used to set the preferences is accessibility supported.
content generation
The act of specifying the web content to be rendered, played or executed by user agents. This may refer to information perceived by end users or to instructions for the user agents. Content may be author-generated when authors are fully responsible for the web content (e.g., typing markup into a source content editing view, writing captions for audio, etc.) or automatically-generated when programming by the authoring tool developer is responsible for the web content (e.g., applying a template, automatically correcting markup errors, etc.). In some cases, responsibility for content generation is shared, as when an author requests an interactive object be placed on their page (e.g., a photo album), the authoring tool applies a template, but the template requires input from the authors to be complete.
content rendering
User interface functionality that authoring tools present if they render, play or execute the web content being edited. In ATAG 2.0 the term covers conventional renderings (e.g., WYSIWYG), unconventional renderings (e.g., rendering an audio file as a graphical wavefront) and partial renderings, in which some aspects of the content are rendered, played, or executed, but not others (e.g., a frame-by-frame video editor renders the graphical, but not the timing aspects, of a video).
conversion
A process that takes as input, content in one web content technology or non-web content technology (e.g., a word processing format) and produces as output, content in a different web content technology (e.g., "Save as HTML" features).
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., some web-based authoring tools), the developer may continue to modify the authoring tool even after web content has been published, such that the web 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., keyboard navigation, zoom features, text-to-speech). Additional or specialized functionality may still be provided by external assistive technology.
display settings
Display settings includes:
  1. display settings (audio): the characteristics of audio output of music, sounds and speech. Examples include volume, speech voices, voice speed, and voice emphasis.
  2. display settings (visual): the characteristics of the on-screen rendering of text and graphics. Examples include fonts, sizes, colors, spacing, positioning, and contrast.
  3. display settings (tactile): the characteristics of haptic output. Examples include the magnitude of the haptic forces and the types of vibration.
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 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 [adapted from WCAG 2.0]
Language that is spoken, written or signed (through visual or tactile means ) to communicate with humans.
informative [adapted from WCAG 2.0]
For information purposes and not required for conformance.
keyboard trap
A user interface situation in which the keyboard may be used to move focus to, but not from, a control or group of controls.
label [adapted from WCAG 2.0]
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.
markup language
A system of text annotations (e.g., elements in HTML) and processing rules that may be used to specify the structure, presentation or semantics of 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 [WCAG 2.0]
Text by which software can identify a component to the user. The name may be hidden and only exposed by assistive 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 [WCAG 2.0]
Any content that is not a sequence of characters that can be recognized 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 [WCAG 2.0, UAAG 2.0]
Required for conformance. One may conform in a variety of well-defined ways to this document. Content identified as "informative" or "non-normative" is never required for conformance.
option
When an author is presented with choices. An option may be local (e.g., prompting whether to save before ending an authoring session) or global (e.g., preference settings).
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., Windows, Mac OS, Linux), virtual machines (e.g., JVM), etc.
platform accessibility architecture
A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g., MSAA and UI Automation for Windows applications, AXAPI for MacOSX 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 [UAAG 2.0]
A program that runs as part of the authoring tool (e.g., a third-party checking and repair tool) and that is not part of content being edited. Authors generally choose to include or exclude plug-ins from their authoring tool.
presentation [WCAG 2.0]
Rendering of the content in a form to be perceived by authors.
programmatically determined (programmatically determinable) [adapted from WCAG 2.0]
When information is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. For non-web-based user interfaces, this means making use of a platform accessibility architecture. For web-based user interfaces , this means following WCAG 2.0 so that the user agent can pass on the information.
prominence
A heuristic measure of how likely users are to notice items (e.g., single controls, groups of controls, text messages) 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., size, spacing, color), and even the modality of use (e.g., mouse vs. keyboard use). For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if:
  1. both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes);
  2. if item B is emphasized, then so is item A; and
  3. item A occurs higher in the reading order or immediately follows item B.
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 point at which the authors or authoring tool make content available to end users (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.
relationships [adapted from WCAG 2.0]
Meaningful associations between distinct pieces of content.
repairing (accessibility) [harmonized with EARL 1.0]
The process by which web content accessibility problems that have been identified within content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation:
  1. manual: where the repairs are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
  2. semi-automated: 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
  3. automated: where the repairs are carried out automatically by the authoring tool without any intervention by the authors.
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. Irreversible actions are 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 [adapted from WCAG 2.0]
Text or a number by which software can identify the function of a component within web content (e.g., a string that indicates whether an image functions as a hyperlink, command button, or check box).
structured element set
Content that consists of organized elements (e.g., lists, maps, hierarchies, graphs).
technology (web content) [harmonized with WCAG 2.0]
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, and JavaScript.
template
A content pattern that is filled in by authors or the authoring tool to produce content for end users (e.g., document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.
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.
transformation
A process that takes content in one web content technology as input and outputs different content in the same technology (e.g., a function that transforms tables into lists).
tutorial
A type of documentation that provides step-by-step instructions for performing multi-part tasks.
user agent [adapted from WCAG 2.0]
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 [adapted from WCAG 2.0]
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 [WCAG 2.0]
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 content being edited. ATAG 2.0 categorizes views according to whether they support editing and the way in which they present content. There are two options for supporting editing in a view:
  1. editing views are editable.
  2. previews are not editable and present content as it would appear in a user agent.
There are three approaches to presenting the content in a view:
  1. as source content in which the unrendered content is presented (e.g., plain text editors),
  2. as content rendering, and
  3. as pre-built content in which authors set only high-level options that the authoring tool then interprets to generate the resulting content (e.g., a calendar module in a content management system).
web content [adapted from WCAG 2.0]
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, "web content" is primarily used to refer to the output that is produced by the authoring tool. "Web content" may include web applications, including those that act as web-based authoring tools. Accessible web content is web content that conforms to a particular level of WCAG 2.0 .
workflow
A customary sequence of steps or tasks authors follow to produce a content deliverable. If an authoring tool is composed of multiple 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 user interface 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/2009/WD-ATAG20-20091029/
  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/2009/WD-ATAG20-20090521/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Richards, J. Spellman, J. Treviranus, eds.,
W3C Recommendation, http://www.w3.org/TR/ATAG20/.
The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> of this document is available at http://www.w3.org/TR/ATAG20/.</p>

For very general references to this document (where stability of content and anchors is not required), it may be appropriate to refer to the latest version of this document. Other sections of this document explain how to build a conformance claim.


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.

Note: In this document, bracketed labels such as "[WCAG20]" link to the corresponding entries in this section. These labels are also identified as references through markup.

[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/.
[CSS2-ACCESS]
"Accessibility Features of CSS," I. Jacobs and J. Brewer, eds., 4 August 1999. This W3C Note is available at http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest version of Accessibility Features of CSS is available at http://www.w3.org/TR/CSS-access.
[IEC-4WD]
IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.
[SMIL-ACCESS]
"Accessibility Features of SMIL," M.-R. Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Note is available at available at http://www.w3.org/TR/SMIL-access.
[sRGB]
"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at http://www.w3.org/Graphics/Color/sRGB.html.
[SVG-ACCESS]
"Accessibility of Scalable Vector Graphics," C. McCathieNevile, M.-R. Koivunen, eds., 7 August 2000. This W3C Note is available at http://www.w3.org/TR/SVG-access.
[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/.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG10-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 6 November 2000. This W3C Note is available at http://www.w3.org/TR/WCAG10-TECHS/.
[WCAG20]
"Web Content Accessibility Guidelines 2.0 ", B. Caldwell, M. Cooper, L. Guarino Reid, and G. Vanderheiden.
[WCAG20-TECHS]
"Techniques for WCAG 2.0," B. Caldwell, M. Cooper, L. Guarino Reid, G. Vanderheiden, eds.
[WCAG20-UNDERSTANDING]
"Understanding (WCAG 2.0)," B. Caldwell, M. Cooper, L. Guarino Reid, G. Vanderheiden, eds.
[XAG]
"XML Accessibility Guidelines", D. Dardailler, S. B. Palmer, C. McCathieNevile, eds. 3 October 2002. This is a Working Group Draft.

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 Loughborough, Karen Mardahl, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Michael Squillace, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.

This document would not have been possible without the work of those who contributed to ATAG 1.0.

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.


Appendix E: Checklist @@to be generated once wording is finalized@@


Appendix F: Comparison of ATAG 1.0 guidelines to ATAG 2.0 @@to be generated once wording is finalized@@


[Contents]