[Contents] [Guidelines]

W3C

Implementing ATAG 2.0

A guide to understanding and implementing Authoring Tool Accessibility Guidelines 2.0

W3C Editors' Draft 20 April 2010

This version:
http://www.w3.org/WAI/AU/2010/ED-IMPLEMENTING-ATAG20-20100420/
Latest version:
http://www.w3.org/TR/IMPLEMENTING-ATAG20/
Previous version:
http://www.w3.org/TR/2009/WD-IMPLEMENTING-ATAG20-20091029/
Editors:
Jutta Treviranus, ATRC, University of Toronto
Jan Richards, ATRC, University of Toronto
Tim Boland, NIST
Jeanne Spellman, W3C
Previous Editors:
Matt May (until June 2005 while at W3C)
 

Editing Styles:@@

Abstract

This document provides non-normative information to authoring tool developers who wish to satisfy the success criteria in the Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20]. This document includes additional information about the intent of the success criteria, examples of how the success criteria might be satisfied, and references to other related resources.

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 Draft of Implementing ATAG 2.0

This is a W3C Public Working Draft of the Implementing ATAG 2.0 document. This document was previously named "Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0". The structure of the document was modified in order to bring it into line with the approach taken by WCAG 2.0. The name was changed to more accurately reflect the purpose of the document.

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

The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publish "Implementing ATAG 2.0" as a W3C Note. The Working Group expects to update this document in response to queries raised by implementers of the Guidelines, for example to cover new technologies. Suggestions for additional examples or related resources are welcome.

Comments on the draft are welcome at public-atag2-comments@w3.org (Public Archive). Comments on this working draft are due on or before DD MMM YYYY.

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

Implementing ATAG 2.0 is an essential guide to understanding and using Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20]. Although the normative definitions and requirements for ATAG 2.0 can all be found in the ATAG 2.0 document itself, the concepts and provisions may be new to some people. Implementing ATAG 2.0 provides a non-normative extended commentary on each guideline and each success criterion to help readers better understand the intent and how the guidelines and success criteria work together. It also provides examples that the Working Group has identified for each success criterion.

This is not an introductory document. It is a detailed technical description of the guidelines and their success criteria. See Authoring Tool Accessibility Guidelines (ATAG) Overview for an introduction to ATAG 2.0, supporting technical documents, and educational material.

Implementing ATAG 2.0 is organized by guideline. There is an Implementing Guideline X.X.X section for each guideline. The rationale for the guideline is listed there.

The Implementing Guideline X.X.X section is then followed by an Implementing Success Criterion X.X.X.X section for each success criterion of that guideline. These sections each contain:

Links are provided from each Guideline in ATAG 2.0 directly to each Implementing Guideline X.X.X in this document. Similarly, there is a link from each success criterion in ATAG 2.0 to the Implementing Success Criterion X.X.X.X section in this document.

Notes:

  1. The Working Group encourages authoring tool developers to carefully consider the examples provided, where appropriate. However, these examples do not provide a final definition of ATAG 2.0 conformance and is possible to meet the guideline requirements without implementing these examples. The Working Group encourages implementers to submit example implementations. These examples will be considered for inclusion in future versions of this document.
  2. Some "Examples" include "mockups". These are for informative purposes only and do not imply endorsement of similar tools or suggest that the mockups represent the best or only implementations.
  3. "Related Resources" are for information purposes only, no endorsement is implied.
  4. For links to information on different disabilities and assistive technologies see Disabilities on Wikipedia.

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

  1. 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.
  2. 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.
  3. 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:


Implementing ATAG 2.0 Guidelines

The success criteria and applicability notes are included here for informative purposes. See Authoring Tool Accessibility Guidelines 2.0 [ATAG20] for the normative version of this information.

Implementing 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 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 display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that a text alternative 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., 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. If a conformance claim is made, the claim cites the user agent.
  4. 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., documentation, search functions, etc.). The only exemption is for preview features, as long as they meet Guideline A.3.7. Previews are treated differently than editing views because all authors, including those with disabilities, benefit when preview features accurately reflect the actual functionality of user agents.

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

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

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.

Implementing Success Criterion 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)

Intent of Success Criterion A.1.1.1:

The intent of this success criterion is to ensure that authoring tool user interfaces that are web-based are accessible to authors with disabilities. Since WCAG 2.0 already provides requirements for the accessibility of web content, including web applications, those guidelines are referenced to avoid replication of requirements.

Some success criteria in Part A that are based on WCAG 2.0 may in some cases be more stringent than WCAG 2.0. In most cases, this is because authors need to be able to edit all web content, while certain types of content (e.g., decoration, invisible content) are not as important to an end user's experience.

Examples of Success Criterion A.1.1.1:
  • Web-based authoring tool: A web-based wiki application is designed to conform to WCAG 2.0 Level A. During development, all parts of the user interface (including editing views rendering test content) are tested by the developer using an accessibility evaluation harness for web applications. Periodically, the application is also tested by authors using assistive technologies.
  • Web-based help system: A non-web-based authoring tool makes use of a web-based help system. Each page in the help system is based on a template that was designed to conform to WCAG 2.0 Level A (when used) and the developer ensures that each help page passes an accessibility checker before being published. The developer confirms the accessibility of the final help system by spot-checking sample pages.
Related Resources for Success Criterion A.1.1.1:

Implementing Success Criterion 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)

See Implementing Success Criterion A.1.1.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion 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)

See Implementing Success Criterion A.1.1.1, substituting WCAG 2.0 Level AAA.

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

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.

Implementing Success Criterion A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow accessibility standards and/or platform conventions that support accessibility. (Level A) Note: If a conformance claim is made, the claim cites the accessibility standards and/or platform conventions that were followed.

Intent of Success Criterion A.1.2.1:

The intent of this success criterion is to ensure that authoring tool user interfaces that are not web applications are accessible to authors with disabilities. In formulating a requirement that would best fulfill this intent, the Working Group decided upon a requirement to follow and cite the accessibility standards and platform conventions that already exist for many platforms. It was decided that this was the best approach because:

  1. the "accessibility standards" wording allows developers the scope to harmonize with accessibility legislation in their markets.
  2. "platform conventions", by their nature, include platform-specific details such as API calls and look-and-feel examples that generic software guidance cannot.
  3. "accessibility standards" and "platform conventions" will continue to progress even after the publication of these guidelines.
  4. the note to cite, in any conformance claims, the accessibility standards and/or platform conventions that were followed, should mean that reputable developers will refrain from implementing obscure or weak requirements.

Note: Developers should take note of the documents listed in the "Related Resources for Success Criterion A.1.2.1" section, below. Unless extenuating circumstances exist (e.g., a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed.

Examples of Success Criterion A.1.2.1:
  • WYSIWYG on Mac OS: A WYSIWYG text editor is designed in Cocoa following the Mac OS X accessibility framework including using Accessibility Objects setting attributes for Role, Role Description, Description, Title, Relationship and Value. No custom actions are defined and all actions can be performed through the keyboard. Hit-testing has been implemented to pass current focus to assistive technologies. The recommended and reserved keyboard shortcuts for Apple Human Interface Guidelines and for Mac OS X accessibility are included in the application and not overwritten. The conformance claim includes links to the Accessibility Programming Guidelines for Cocoa and the Accessibility Keyboard Shortcuts as applicable.
  • Content management system on Windows: A content management system is written to operate on the Windows XP and Vista operating systems following Microsoft's Active Accessibility. The programs uses IAccessible proxies and only implements IAccessible for controls that are not proxied by OLEACC. The conformance claim includes links to the applicable Microsoft Developer Network documents.
Related Resources for Success Criterion A.1.2.1:

Implementing PRINCIPLE A.2: Editing views must be perceivable

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

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

Implementing Success Criterion A.2.1.1 Recognized Alternative Content: If recognized alternative content is available for editing view content renderings, then the alternative content is provided to authors. (Level A)

Intent of Success Criterion A.2.1.1:

The intent of this success criterion is to ensure that authors with disabilities have access to alternative content in the web content that they are editing, because this information can help authors orient and navigate as they edit.

The intent of the "recognized" condition is to acknowledge that "alternative content" may appear in web content in ways that software is not able to detect (e.g., when captions are added directly to the main video track). As per the definition of "recognized", the forms of alternative content that the authoring tool recognizes are to be listed in any conformance claim.

Web-based authoring tools will already be required to meet this success criterion as part of Success Criterion A.1.1.1.

Examples of Success Criterion A.2.1.1:
  • WYSIWYG editing view: A WYSIWYG editing view is implemented using a browser component that meets the requirements in the User Agent Accessibility Guidelines (UAAG) 1.0 that are relevant to the processing of alternative content (e.g., displaying captions, ensuring alternative text can be programmatically determined).
  • Source content editing view: A source content editing view displays plain text alternative content, providing authors with direct access to any alternative content and the ability to edit it directly.
Related Resources for Success Criterion A.2.1.1:

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

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.

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

Intent of Success Criterion A.2.2.1:

The intent of this success criterion is to ensure that if the authoring tool makes changes to the display of the web content being edited in order to communicate with authors (e.g., to highlight spelling errors, identify the location of markup tags, etc.), then authors with disabilities will have the same access to that information as other authors.

Examples of Success Criterion A.2.2.1:
  • Change tracking feature: A web-based authoring tool includes a change tracking feature that displays inserted text in green and deleted text in red with a strike-through style. Instead of implementing this using simple CSS selectors, the authoring tool uses the XHTML elements ins and del, since these have semantic meaning.
Related Resources for Success Criterion A.2.2.1:

Implementing Success Criterion 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.

Intent of Success Criterion A.2.2.2:

The intent of this success criterion is to ensure that authors with disabilities have access to text presentation information that is made available to other authors by editing views. This is important because authors who cannot see still need to understand how their web content will appear to end users who can, once it is published.

This success criterion pertains to the rendered properties of text on the screen, even if the properties differ from the web content being edited. For example, when authors have chosen custom display settings (as per Success Criterion A.2.3.1).

Examples of Success Criterion A.2.2.2:
  • Non-web-based authoring tool:
    A non-web-based authoring tool includes a WYSIWYG editing view that implements the appropriate platform accessibility architecture. Included in the information passed to the platform accessibility architecture is information on the size, font, foreground and background color, font weight, and position of any rendered text.
  • Web-based authoring tool:
    A web-based WYSIWYG authoring tool uses style sheets to control text presentation, enabling the presentation information to be programmatically determined by the user agent, which passes it on to the appropriate platform accessibility architecture (the user agent is cited in any conformance claim).
Related Resources for Success Criterion A.2.2.2:

Implementing Success Criterion 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)

See Implementing Success Criterion A.2.2.2, substituting all text presentation properties that are both rendered and editable by the authoring tool for the four presentation properties listed in A.2.2.2.

Implementing Guideline A.2.3: [For the authoring tool user interface] Ensure the independence of authors' display preferences. [Return to Guideline]

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.

Implementing Success Criterion A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views) without affecting the web content to be published. (Level A)

Intent of Success Criterion A.2.3.1:

The intent of this success criterion is to ensure that the preference display settings that authors set for their own use while they are editing web content are independent of the display settings that are encoded (and eventually published) in the content being editing.

Examples of Success Criterion A.2.3.1:
  • Editing view preferences: A non-web-based WYSIWYG authoring tool has preference settings that enable authors to override the default rendering styles used in the WYSIWYG editing view with the display settings that they have already set in the operating system (e.g., large fonts, high contrast mode, etc.). The preference settings have absolutely no effect on the web content being edited.
  • Setting an authoring style sheet: A WYSIWYG authoring tool has preference settings that enable authors to set an "authoring" style sheet. This style sheet is only used to control the rendering of the web content in the author's editing view. The stylesheet does not make changes to the content markup being edited and is not published to end users.
  • Web-based authoring tool: A web-based authoring tool lets authors customize the appearance of editing views using the preference display settings of the user agent (the user agent is cited in any conformance claim).
Related Resources for Success Criterion A.2.3.1:
  • N/A

Implementing PRINCIPLE A.3: Editing views must be operable

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

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

Implementing Success Criterion A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input. (Level A) Note 1: This exception relates to the nature of web content, not the usual input technique. For example, setting the path of a freehand curve is exempt, while setting the endpoints of a straight line is not. Note 2: This should not be interpreted as discouraging mouse input or other input methods in addition to the keyboard interface.

Intent of Success Criterion A.3.1.1:

The intent of this success criterion is to ensure that almost all authoring tool functionality can be operated using a keyboard or an assistive technology that makes use of a keyboard interface, such as onscreen scanning keyboards and voice recognition systems.

The only exemption at Level A to this requirement involves the editing of web content properties that encode continuous input. This is a very narrow exception related to web content properties containing hundreds or thousands of numerical values. The exception exists because it is not reasonable to expect that authors using only a keyboard would be prepared to hand-code so many data points. The exception does not apply simply because the developers of an authoring tool have decided to use mouse input to control functionality in the past (e.g., setting the endpoints for straight lines, rectangles and circles). The exception also does not apply simply because a functionality is related to graphics. Also, the exception applies to the editing of particular properties. While editing the path of a freehand curve may be exempt, setting the line color and thickness likely is not exempt. Finally, this is a Level A exception only. There is no exception for the Level AAA requirement (Success Criterion A.3.1.4).

The intent of Note 1 is to clarify when the exception applies.

The intent of Note 2 is to clarify that rather than replacing other types of interaction, the keyboard access requirement is to provide an alternative.

Examples of Success Criterion A.3.1.1:
  • Drag-and-drop feature: An authoring tool allows authors to open documents by dragging them into the authoring tool window. The same operation can be performed from the menus using the keyboard.
  • Keyboard manipulation of drawing objects: A multimedia authoring tool allows authors to navigate the selection focus between all of the drawing objects on the canvas. Once an object is selected, it can be manipulated with keyboard-driven menu commands, some of which have keyboard shortcuts (e.g., arrow keys to move the object, etc.). New drawing objects can also be added from the keyboard-driven menus.
  • Keyboard manipulation of drawing object properties: A multimedia authoring tool does not include keyboard access to the drawing canvas directly, but instead provides a keyboard accessible list of drawing objects that allows a keyboard editable property page to be brought up. The property page includes properties such as "top", "left", "width", "height", "rotation", and "label". When these properties are adjusted, the objects on the canvas are updated accordingly. New drawing objects can be added from the keyboard-driven menus.
Related Resources for Success Criterion A.3.1.1:

Implementing Success Criterion A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented 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 Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).

Intent of Success Criterion A.3.1.2:

The intent of this success criterion is to ensure that neither the authoring tool's own user interface nor any rendered web content within editing views "traps" keyboard focus. This is a problem may occur when an interactive object is embedded in content. Authors might be able to move focus to the object (e.g., by using the "tab" key) within a WYSIWYG editing view, but they are unable to move the focus out using the keyboard, because keyboard control has passed to the embedded object.

The first requirement (a) applies only to the authoring tool user interface, which is the part of the authoring tool that developers have the most control over. In this case, there should not be any keyboard traps. If authors can move focus to a component using standard keyboard navigation commands (e.g., using the tab key), then they must be able to move focus out of the component in the same way.

The second requirement (b) applies to renderings of web content. Because the content may contain keyboard handlers, the authoring tool may not be able to prevent keyboard traps entirely. Therefore, the requirement is only that the authoring tool be able to restore the keyboard focus to some known location. This known location could be outside of the rendered area (e.g., the menus) or it might be the next rendered element.

Examples of Success Criterion A.3.1.2:
  • Non-web-based authoring tool: A non-web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open web content containing keyboard traps in the WYSIWYG editing view, the authoring tool allows authors to restore keyboard focus to the authoring tool's menus at any time using the "alt" keystroke, which the authoring tool never passes to the content being edited.
  • Web-based authoring tool: A web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open web content containing keyboard traps, the authoring tool relies on a feature in the authors' user agent that always restores keyboard focus to the address bar (the user agent is cited in any conformance claim).
Related Resources for Success Criterion A.3.1.2:

Implementing Success Criterion A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)

Intent of Success Criterion A.3.1.3:

The intent of this success criterion is to ensure that authors using a keyboard interface can more easily access commonly used functions of the authoring tool. The wording is intentionally general because the features that require keyboard shortcuts and the number and nature of keyboard shortcuts that are available in various operating environments varies greatly (i.e., desktop systems generally have more keystrokes available to be assigned as shortcuts than mobile devices).

Examples of Success Criterion A.3.1.3:
  • Non-web-based authoring tool: A non-web-based authoring tool provides keyboard shortcuts for its menu functions as well as access keys in the design of its menus and dialog boxes. The choice of shortcut keys follows platform conventions.
  • Social networking application on a mobile device: A social networking application on a mobile device has only a very few keyboard shortcuts available on its targeted devices. These few keyboard shortcuts are used for the most commonly accessed functions of the application (e.g., home, list of friends).
Related Resources for Success Criterion A.3.1.3:

Implementing Success Criterion A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is operable through a keyboard interface. (Level AAA)

Intent of Success Criterion A.3.1.4:

The intent of this success criterion is to establish an enhanced requirement for keyboard access, without any exceptions. While some "high-end" drawing features, such as a "watercolor painting" tool that continuously sampled the path, pressure and angle of a stylus would be very challenging to make fully keyboard accessible, other less complex functions might be practical.

Web-based authoring tools will already be required to meet this success criterion as part of Success Criterion A.1.1.1.

Examples of Success Criterion A.3.1.4:
  • Keyboard-driven "freehand" drawing: A multimedia authoring tool has a mode that allows "freehand" lines to be drawn in increments, letting authors use the keyboard to choose the angle and length of the next increment, after which the shape is smoothed.
Related Resources for Success Criterion A.3.1.4:
  • N/A

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

Intent of Success Criterion A.3.1.5:

The intent of this success criterion is to ensure that authors using a keyboard interface have the ability to remap the authoring tool's keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g., for one handed use).

Examples of Success Criterion A.3.1.5:
  • Non-web-based authoring tool: A non-web-based authoring tool has a keyboard setup utility that lists all of the available keyboard shortcuts and allows authors to associate each with any of the authoring tool's commands (e.g., all of the menu commands).
  • Web-based content management system: A web-based content management system has a keyboard setup utility that allows authors to change the access keys that are available during authoring. These access key rebindings are for the authors' use only and do not affect the web content being edited.
  • Social networking application on a mobile device: A social networking application has a keyboard setup utility that allows authors to change their keyboard shortcuts for the site. The remapping is saved in site cookies.
Related Resources for Success Criterion A.3.1.5:
  • N/A

Implementing Success Criterion A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls can be presented with their associated keyboard commands. (Level AAA)

Intent of Success Criterion A.3.1.6:

The intent of this success criterion is to ensure that authors using a keyboard interface have the ability to both discover and be reminded of keyboard shortcuts, while they are using the authoring tool.

Examples of Success Criterion A.3.1.6:
  • Non-web-based authoring tool: When authors press a modifier key in a non-web-based authoring tool (e.g., the "Ctrl" key), all of the keyboard shortcuts in the authoring tool user interface are displayed along with any existing text labels or icons.
Related Resources for Success Criterion A.3.1.6:
  • N/A

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

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.

Implementing Success Criterion A.3.2.1 Data 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)

Intent of Success Criterion A.3.2.1:

The intent of this success criterion is to ensure that the work of authors is saved in the event that an authoring session is ended due to a time limit (e.g., the timeout of an authenticated authoring session). For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent. Reducing the likelihood of lost content edits will benefit all authors, but especially authors with disabilities who may take longer to accomplish authoring tasks.

Examples of Success Criterion A.3.2.1:
  • Save and continue: A web-based content management system has a "Save and Continue" button that allows authors to continually submit their content edits without requiring them to re-enter the editing view afterwards.
  • Wiki: A wiki has an auto-save feature that can be turned on by authors. The auto-save feature always saves before a system timeout.
Related Resources for Success Criterion A.3.2.1:
  • N/A

Implementing Success Criterion 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) (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., "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., 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.

Intent of Success Criterion A.3.2.2:

The intent of this success criterion is to ensure that authoring tools provide authors with disabilities adequate time to perform their tasks. Any process that happens without author initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of the screen (for example, page refresh), or the expiration of a window of opportunity for authors to react to a request for input. It also includes user interface functionality that is advancing or updating at a rate beyond the ability of authors to read and/or understand it. In other words, animated, moving or scrolling information introduces a time limit.

Generally, turning off time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs. In some cases, however, it is not possible to change the time limit (e.g., a collaborative authoring session) and exceptions are therefore provided for those cases.

Web-based authoring tools will already be required to meet this success criterion as part of a Success Criterion A.1.1.1.

Examples of Success Criterion A.3.2.2:
  • Web-based content management system: A web-based content management system has a login timeout function that automatically logs authors out after 20 minutes of inactivity. One minute before the automatic log out, the system notifies authors that they will be logged out unless they cancel the notification (meeting (c)). The system also includes a preference setting that lets authors set the timing of the notification up to 10 minutes before the automatic logout (meeting (b)).
  • Real-time collaborative editing system: A real-time collaborative editing system allows multiple authors to edit the same web content simultaneously. An integral part of the real-time collaborative activity is that any author may edit or delete what others have just authored (meeting (d)).
Related Resources for Success Criterion A.3.2.2:

Implementing Success Criterion A.3.2.3 Moving Targets: If a user interface component is moving (e.g., animated vector graphic), then authors can pause the movement. (Level A)

Intent of Success Criterion A.3.2.3:

The intent of this success criterion is to ensure that authors are not prevented from using the authoring tool by a requirement for fast reactions.

Examples of Success Criterion A.3.2.3:
  • Timeline-based authoring tool: A timeline-based interactive web content editor has an indicator of the current position on the timeline that authors can click and drag. When the interactive content is being previewed, the indicator moves along the timeline, which can make it difficult to target with the mouse. Authors can stop the indicator from moving by selecting the "Stop" or "Pause" buttons.
Related Resources for Success Criterion A.3.2.3:

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

Intent of Success Criterion A.3.2.4:

The intent of this success criterion is to ensure that the work of authors is saved in the event that an authoring session is ended due to a time limit. Reducing the likelihood of lost content edits will benefit all authors, but especially authors with disabilities who may take longer to accomplish authoring tasks.

Examples of Success Criterion A.3.2.4:
  • Web-based content management system: The system includes an option to turn on asynchronous server communication to constantly save authoring actions into a backup file. If the authoring session ends unexpectedly, authors can retrieve backups during their next authoring session.
Related Resources for Success Criterion A.3.2.4:
  • N/A

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

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

Implementing Success Criterion A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off. (Level A)

Intent of Success Criterion A.3.3.1:

The intent of this success criterion is to ensure that authors with photosensitive seizure disorder can use the authoring tool to open time-based web content without risk. Some people with seizure disorders can have a seizure triggered by flashing visual content.

Examples of Success Criterion A.3.3.1:
  • Blog: A blogging tool allows authors to import video files. Authors have the option to turn off an auto-play feature, so that the video files are not played until a "Play" button is activated.
  • WYSIWYG web page editor: A WYSIWYG editing view is capable of rendering JavaScript in real-time. Authors have the option to turn off the real-time rendering feature, so that the JavaScript is not rendered until a "Play" button is activated.
Related Resources for Success Criterion A.3.3.1:

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

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.

Implementing Success Criterion A.3.4.1 Edit by Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure. (Level A)

Intent of Success Criterion A.3.4.1:

The intent of this success criterion is to let authors make use of the structure that may be present in the web content that they are editing to more efficiently edit that content. This is particularly important when authors are editing large amounts of content. Of course, the editing mechanisms are contingent on the content containing the appropriate structure. For example, editing by structure would not be very effective in an HTML document composed of plain text in a pre element.

Examples of Success Criterion A.3.4.1:
  • WYSIWYG web page editor: A WYSIWYG editing view allows authors to select and manipulate elements as objects. When an element is selected, any content (including sub-elements) of the element are also selected. When authors perform a function a selected element, the scope of the function and the resulting outcome depends on the nature of the function.
    • Some functions target the entire selection (i.e., the element, content and sub-elements). For example, when a <table> element is selected and the "delete" operation is performed, the entire table is deleted, including sub-elements (tr and td) and any text content etc. within the table.
    • Some functions only target the top level element of the selection. For example, the "strip element tag" function deletes the markup of the top level element without affecting its sub-elements or content.
    • Some functions only target the content, including sub-elements of the top level element of the selection without having any affect on the markup of that top level element. For example, the “replace contents” function is a variant of "paste" in which the sub-elements and content of the selected element are replaced.
Related Resources for Success Criterion A.3.4.1:
  • N/A

Implementing Success Criterion A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure. (Level A)

Intent of Success Criterion A.3.4.2:

The intent of this success criterion is to help authors using a keyboard interface to navigate more efficiently within structured web content. Because web content technologies differ in the types of structure that they include, developers have flexibility to decide what types of navigation mechanisms to include. The following list contains some possibilities:

  1. tree navigation: the ability to move focus to the elements up, down and across tree structures.
  2. navigation by headers: the ability to move focus between elements identified as headers in the markup (e.g., h1, h2, etc in HTML4).
  3. navigation by element: the ability to move focus between element of the same type or sharing particular attributes.
  4. navigation by role: the ability to move focus between elements identified by their roles.
  5. navigation by accessibility relationships: the ability to move focus between elements bound by accessibility relationships (for attribute of label in HTML4, aria-describedby, etc.).

Of course, the navigation mechanisms are contingent on the content containing the appropriate structure. For example, navigation by headers would not be very effective in an HTML document that did not contain headers.

Examples of Success Criterion A.3.4.2:
  • Source content editing view: A source content editing view supports authors by providing the ability to use keyboard shortcuts to move the focus from any element (e.g., table row) to:
    • the element immediately above (e.g., table),
    • the first element immediately below (e.g., table data cell),
    • the element immediately preceding it at the same level (e.g., previous table row), and
    • the element immediately following it at the same level (e.g., next table row).
  • Search by any header element: An authoring tool includes a search function mode that enables authors to search forwards or backwards by "any header element". For example, in HTML4 this would be h1, h2, h3, h4, h5, and h6. When a searched-for header element exists, it is selected in the editing view, enabling authors to immediately edit the element.
  • Search by element: An authoring tool includes a search function mode that enables authors to search forwards or backwards by the names of elements. When a searched-for element exists, it is selected in the editing view, enabling authors to immediately edit the element. In addition, the search can be customized to search by attributes, etc.
    Figure: A "Find and Replace" dialog box is shown configured to find the "element" with the name "img", "with attribute" "height" "=" "100" ( where each value in quotation marks is editable). The replacement action is to "set attribute" "height" to "50". The following checkbox options are available "match case", "ignore white space" and "search text alternatives". The dialog box also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)
    See the example caption above for description.
  • Outline view: An "outline" or "structure" editing view is provided that organizes structured element sets being edited into a document tree. In this editing view, only the arrow keys are required for navigation between the parent, child and sibling elements.
  • Customizing widgets: An authoring tool enables authors to add and customize JavaScript widgets in its WYSIWYG editing view. Authors can use the keyboard to navigate through the elements that make up the widget in order to set the properties or appearance of the widget. For example, in a slider widget, the keyboard can be used to select the background, the line, the line ticks or the thumb marker of the slider.
Related Resources for Success Criterion A.3.4.2:
  • N/A

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

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.

Implementing Success Criterion A.3.5.1 Text Search: Authors can perform text searches of web content as follows: (Level AA) (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 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 to display the results. (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.

Intent of Success Criterion A.3.5.1:

The intent of this success criterion is to ensure that authors can efficiently find the web content that they wish to edit.

The intent of the note under (a) is to acknowledge that not every editing view is capable of editing every type of content that can be searched (e.g., a WYSIWYG editing view may not be able to display search results within markup tags).

Examples of Success Criterion A.3.5.1:
  • Basic text search: An authoring tool provides both WYSIWYG and source content editing views. The authoring tool provides bi-directional, case sensitive searching for plain text sequences within both editing views. The default search option is to search only within the editing view that the author is currently working within. However, there is an option to search both editing views simultaneously. When this option is selected, the search results are all displayed in a selectable list that labels each as "Text" or "Source Code", reflecting which editing view will become active when the author selects the search result.
  • Advanced text search: An authoring tool's basic text search feature is augmented by more advanced search options, such as:
    • replacement,
    • wildcard characters,
    • whole word matching,
    • search repetition, and
    • highlighting of all occurrences.
  • Metadata editor: A metadata editor provides bi-directional, case sensitive searching for plain text sequences within textual metadata fields (e.g., title, description, author, etc.).
Related Resources for Success Criterion A.3.5.1:
  • N/A

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

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

Implementing Success Criterion A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between authoring sessions. (Level AA)

Intent of Success Criterion A.3.6.1:

The intent of this success criterion is to ensure that authors' preference settings for keyboard and display settings do not need to be reset for each authoring session.

Examples of Success Criterion A.3.6.1:
  • Storing preferences with author account: A web-based authoring tool requires that authors log in to their accounts before authoring sessions can begin. Because preference settings are associated with author accounts, the settings are applied as soon as authors log in.
Related Resources for Success Criterion A.3.6.1:
  • N/A

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

Intent of Success Criterion A.3.6.2:

The intent of this success criterion is to encourage authoring tools to respect the display and control settings that authors have already specified at the platform level. This reduces the need for authors to repeatedly specify the same preferences. It also means that when authors first open the authoring tool, they can more easily use the tool.

The intent of the note is to remind implementers of Success Criterion A.2.3.1, which requires that there be independence between the settings that authors choose for their own work environment and the characteristics they set for the web content that they are editing.

Examples of Success Criterion A.3.6.2:
  • Desktop high contrast mode: A non-web-based authoring tool defaults to high contrast mode when it detects that the platform is set to high contrast mode.
  • Web-based authoring tool: A web-based authoring tool respects the display and control settings of the user agent on which it is running.
Related Resources for Success Criterion A.3.6.2:
  • N/A

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

Intent of Success Criterion A.3.6.3:

The intent of this success criterion is to ensure that authors whose personal preferences vary over time (e.g., due to fatigue) can easily select from a series of pre-set preferences for display and control settings.

Examples of Success Criterion A.3.6.3:
  • Basic multiple profiles: An authoring tool allows the various configurations of preference settings to be stored as different profiles that authors can switch between at any time. The stored preference settings include all display and control settings that are specific to the authoring tool (i.e., are not controlled by the platform).
  • Portable profiles: An authoring tool's basic multiple profiles feature is augmented by the ability for authors to save the profiles as separate files. This allows authors to move configurations between instances of the authoring tool on different systems or to share the configuration files with other authors with similar requirements.
Related Resources for Success Criterion A.3.6.3:
  • N/A

Implementing Success Criterion A.3.6.4 Preferences Assistance: The authoring tool includes a mechanism to help authors configure any preference settings related to Part A of this document. (Level AAA)

Intent of Success Criterion A.3.6.4:

The intent of this success criterion is to ensure that authoring tools provide assistance to authors in configuring any options related to the accessibility of the user interface. This assistance should include extra assistance resolving any incompatibilities between options (e.g., prevent the same color being used for both the foreground and background).

Examples of Success Criterion A.3.6.4:
  • Options setting wizard: An authoring tool includes a wizard that takes authors step-by-step through the accessibility options, providing explanations and previews of how the options will change the display. The wizard follows an interview format, first asking authors about general areas (e.g., seeing the screen, using the keyboard) and then becoming more detailed (e.g., text size, text color, etc.).
Related Resources for Success Criterion A.3.6.4:
  • N/A

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

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.

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

Intent of Success Criterion A.3.7.1:

The intent of this success criterion is to ensure that even if the preview feature makes use of an existing user agent with accessibility problems to meet Success Criterion A.3.7.2, authors will at least be able to exit the preview feature in an accessible way.

Examples of Success Criterion A.3.7.1:
  • Preview in a user agent tab: A web-based authoring tool performs previews by opening the web content in a new user agent tab. The user agent includes keyboard shortcuts for returning to the tab that contains the web-based authoring tool (the user agent is cited in any conformance claim).
  • Preview in an external user agent: A non-web-based authoring tool performs previews by opening a user agent for the web content to be previewed in. Authors can use standard operating system keyboard shortcuts for returning to the authoring tool application (the operating system is cited in any conformance claim).
  • Preview in a pane: A web-based authoring tool performs previews by opening the web content in a new frame. The user agent includes keyboard shortcuts for returning focus to the editing view, located in a different frame (the user agent is cited in any conformance claim).
Related Resources for Success Criterion A.3.7.1:
  • N/A

Implementing Success Criterion A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A) (a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].

Intent of Success Criterion A.3.7.2:

The intent of this success criterion is to ensure that preview features strike a balance between giving authors with disabilities an accessible means of previewing the web content that they are editing and not giving those authors an unrealistic impression of how end users with similar disabilities will actually experience that content in their own user agents (e.g., browser, video player, etc.). In other words, it is not necessarily useful to present a user experience with content as a "preview" when it is much more accessible than the actual user experience of the content would be in an existing user agent.

The most straightforward way to meet this success criterion is for authoring tools to implement preview features using user agents that are already in use by end users - see (a). This might be done in several ways, including by opening the content in the author's default user agent or by making use of a user agent widget nested within the authoring tool's own user interface (the user agent is cited in any conformance claim).

On the other hand, if a preview is being developed that is already a departure from existing user agents, then the W3C User Agent Accessibility Guidelines (UAAG) must be followed - see (b). At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development. Note: Developers may develop a preview from scratch that does not meet (b) as long as authors retain the option to preview using their own user agent, since this meets (a).

Examples of Success Criterion A.3.7.2:
  • Preview in a user agent: A web-based authoring tool performs previews by opening the web content in a new user agent tab or window.
  • Preview in an external user agent: A non-web-based authoring tool performs previews by opening the web content to be previewed in the user's default browser.
  • Preview options: Authors have the option of choosing from any of the user agents installed on their computer to perform the preview.
  • Preview in a user agent component: A non-web-based authoring tool performs previews using a user agent component that is built directly into the authoring tool.
  • Custom built preview: An authoring tool makes use of a custom built preview feature. The preview feature conforms to User Agent Accessibility Guidelines (UAAG) 1.0 at Level "A".
Related Resources for Success Criterion A.3.7.2:

Implementing PRINCIPLE A.4: Editing views must be understandable

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

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

Implementing Success Criterion 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.

Intent of Success Criterion A.4.1.1:

The intent of this success criterion is to help authors with disabilities avoid serious consequences in the web content that they are editing as the result of a mistake while performing authoring actions. Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

The intent of Note 1 is to acknowledge that some implementations of undo may group text entry actions.

The intent of Note 2 is to acknowledge that undo is not always technically possible.

Examples of Success Criterion A.4.1.1:
  • Non-web-based authoring tool: An authoring tool has an "Undo" action under the "Edit" menu. Activating the undo action reverses the previous authoring action. Activating "undo" again undoes the previous authoring action and so on.
  • Web-based content management system: A web-based content management system supports two types of undo. In the first type of undo, text entry actions into text fields can be undone using the undo feature of the user agent (user agent is cited in the conformance claim). In the second type of undo, "Cancel" buttons are available that allow authors to undo changes that have already been committed. However, to avoid the "Cancel" button being pressed accidentally, authors have the option of having confirmation dialogs displayed when "Cancel" is activated (see Success Criterion A.4.1.3).
Related Resources for Success Criterion A.4.1.1:

Implementing Success Criterion 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)

Intent of Success Criterion A.4.1.2:

The intent of this success criterion is to help authors with disabilities avoid making the authoring tool unusable to them as the result of making a mistake while installing the program or modifying preference settings. Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

Examples of Success Criterion A.4.1.2:
  • All reversible: All of the preference setting changes in an authoring tool can be reversed by revisiting the preference setting utility and adjusting the settings.
  • Restore defaults: In a preference setting utility, a "restore default settings" button is always available.
Related Resources for Success Criterion A.4.1.2:

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

Intent of Success Criterion A.4.1.3:

The intent of this success criterion is to ensure that an inadvertent "undo" can be reversed, which is sometimes called "re-do". Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

Examples of Success Criterion A.4.1.3:
  • Web-based content management system: In the "Web-based content management system" example in Success Criterion A.4.1.1, the content management system supports two ways of reversing undo actions. In the first, the redo feature of the user agent (user agent is cited in the conformance claim) can be used to redo text entry that has been reversed with the user agent's undo feature. In the second, confirmation dialogs let the user reverse "Cancel" actions that would discard content changes.
Related Resources for Success Criterion A.4.1.3:
  • N/A

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

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

Implementing Success Criterion 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)

Intent of Success Criterion A.4.2.1:

The intent of this success criterion is to ensure that authors with disabilities that need to use the accessibility features of the authoring tool user interface can easily find specific instruction in the documentation. The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

Examples of Success Criterion A.4.2.1:
  • Accessibility features documented: An authoring tool includes a help system that is always available to authors, is searchable by keyword and is also linked in context from the various features within the authoring tool. The documentation conforms to WCAG 2.0 Level A and includes the following topics grouped together into an "Accessibility Features" chapter in the help system:
    • how to customize display settings
    • what keyboard shortcuts are available, including navigation keys
    • how to customize keyboard shortcuts
    • how to avoid keyboard traps
    • how to extend time limits
    • how to use the search features
    • how to undo/redo
    • how to set accessibility-related options, such as turning off auto-play
Related Resources for Success Criterion A.4.2.1:
  • N/A

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

Intent of Success Criterion A.4.2.2:

The intent of this success criterion is to ensure that authors who need additional support to learn to operate an authoring tool can easily access instructions. The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

Examples of Success Criterion A.4.2.2:
  • All features documented: An authoring tool includes documentation for all of its features.
Related Resources for Success Criterion A.4.2.2:

Implementing 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. Applicability after the end of an authoring session: For author-generated content, the requirements of Part B only apply during authoring sessions. For example, if the author includes a third-party feed in their web content, the authoring tool is not required to provide checking for web content accessibility problems in that feed after the end of the authoring session. In contrast, for automatically-generated content, Part B continues to apply after the end of the authoring session. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for automatically-generated content.
  3. 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., an authoring tool could make use of a third-party software accessibility checking and repair tool).
  4. 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 to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation, etc.).
  5. Multiple author roles: Some authoring tool include multiple author roles, each with different views and content editing permissions (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.

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

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

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 conforms with WCAG 2.0 using the authoring tool.

Implementing Success Criterion B.1.1.1 Accessible Content Production (WCAG Level A): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level A. (Level A)

Intent of Success Criterion B.1.1.1:

The intent of this success criterion is to ensure that authors who have the motivation and knowledge to create accessible web content using an authoring tool are not prevented from doing so. The subsequent success criteria in Part B will build on this minimal requirement.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.1.1:
  • Accessible workflow exists: An authoring tool is designed such that accessible web content (conforming to WCAG 2.0 Level A) will result if authors do all of the following:
    • turn on all features that support the production of accessible content; and
    • correctly follow all prompts by features that support the production of accessible content; and
    • use the accessibility checker, including a final check prior to publishing; and
    • correctly perform any manual checks suggested by the accessibility checker; and
    • correctly repair all of the automatically, semi-automatically or manually identified web content accessibility problems using the automated, semi-automated and manual repair assistance that the authoring tool provides.
  • Source content editing view: An authoring tool is designed around a source content editing view, allowing motivated and knowledgeable authors to control every detail of the content produced, including following accessible authoring practices.
Related Resources for Success Criterion B.1.1.1:

Implementing Success Criterion B.1.1.2 Accessible Content Production (WCAG Level AA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AA. (Level AA)

See Implementing Success Criterion B.1.1.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion B.1.1.3 Accessible Content Production (WCAG Level AAA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AAA. (Level AAA)

See Implementing Success Criterion B.1.1.1, substituting WCAG 2.0 Level AAA.

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

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

Implementing Success Criterion B.1.2.1 Preserve Accessibility Information (Minimum): Any accessibility information (WCAG 2.0 Level A) recognized in the input to any web content transformation is preserved as accessibility information in the output, if allowed by the web content technology of the output. (Level A)

Intent of Success Criterion B.1.2.1:

The intent of this success criterion is to ensure that, whenever technically possible, any accessibility information that authors have made the effort to include in web content is still available to end users after a web content transformation.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.2.1:
  • Similar data structures: A conversion tool preserves accessibility information in similar data structures, whenever possible. For example:
    • when converting between HTML and SVG, the contents of alt attributes are stored in desc attributes
    • when saving a word-processor format to markup, headings and list items are transformed into appropriate structural markup
  • Dissimilar but accessible: A conversion tool preserves accessibility information in a dissimilar, but accessible way, when similar data structures are not available. For example:
    • when transforming a SMIL presentation with a closed-caption text track into a video-only format, authors have the option of converting the closed captions into open-captions encoded in the video file
    • when transforming a table to a list, table headings are transformed into headings and summary or caption information is retained as rendered text content
    • when saving a word-processing format to markup, specialized document features (i.e., footnotes, endnotes, call-outs, annotations, references, etc.) are retained as rendered text content with two-way linking.
  • Authors control: A conversion tool allows authors to augment the accessibility of their web content by setting conversion rules to specify how patterns of presentation markup can be converted into structural markup and stylesheet information.
Related Resources for Success Criterion B.1.2.1:

Implementing Success Criterion B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a web content transformation cannot preserve recognized accessibility information (WCAG 2.0 Level A) (e.g., saving a structured graphic to a raster image format), then at least one of the following are true: (Level A) (a) Option to Save: authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input); or (b) Warning: authors are warned that this will result in web content accessibility problems in the output.

Intent of Success Criterion B.1.2.2:

The intent of this success criterion is to address situations in which, for technical reasons, accessibility information cannot be preserved in the end product of web content transformations such that it can be accessed by end users. In these case, the accessibility information (which represents effort by some author) should still be preserved (as a backup, etc.) to allow the accessibility information to be retrieved in the future by authors or possibly by end users (if technologies progress).

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.2.2:
  • Make backup of accessibility info: An authoring tool automatically archives a backup copy of the original web content, if accessibility information will be lost (e.g., when a structured SVG graphic is saved as an unstructured JPG graphic), and notifies authors of both the location of the backup copy and the fact that the new content will not be available to any end users who need the accessibility information.
  • Warning when text is converted to graphics: A conversion tool includes the ability to convert textual formats into graphics. However, if this option is selected by authors, they are warned that the output will have web content accessibility problems. They are also advised that style sheets are preferable for presentation control. If authors continue, the conversion tool suggests retaining the original text as alternative content for the graphical output.
  • Auto-check after transformation: If authors choose to proceed with a transformation that includes an accessibility warning (see (b)), then an accessibility check is immediately run on the output.
  • Transformation undo: If authors choose to proceed with a transformation that includes an accessibility warning (see (b)), then an option to undo the transformation is available.
Related Resources for Success Criterion B.1.2.2:

Implementing Success Criterion B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output. (Level AA)

Intent of Success Criterion B.1.2.3:

The intent of this success criterion is to set out an enhanced preservation requirement (at Level AA) in which authoring tools only offer authors web content transformations that preserve accessibility information that will be needed to make the end product accessible.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.2.3:
  • Preserving secondary audio tracks: A multimedia authoring tool is capable of converting video formats that include secondary audio tracks, which may contain audio descriptions, into video formats that support only one audio track. In these cases, authors are provided with options to preserve the information in the secondary audio track by either (1) combining the two audio tracks into the one remaining audio track or (2) moving the secondary audio track into a separate audio file that is associated with the resulting video file using SMIL.
Related Resources for Success Criterion B.1.2.3:

Implementing Success Criterion 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) (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: Authors have the option to prevent automatic deletion by the authoring tool.

Intent of Success Criterion B.1.2.4:

The intent of this success criterion is to ensure that accessibility information, such as structural or alternative content, is not inadvertently lost. The approach taken is that unless the authoring tool can detect that web content is not accessibility information, it must provide authors with options to receive notification prior to deleting the content or to not delete the content.

Examples of Success Criterion B.1.2.4:
  • Avoid deleting content: An authoring tool does not automatically delete any author-generated content.
  • Avoid deleting accessibility information: An authoring tool detects and then avoids deleting author-generated content that is accessibility information.
  • Conform or override removal: An authoring tool that may delete author-generated content provides authors with the option to confirm or override removal of content either on a change-by-change basis or as a batch process.
  • Option to cancel: A markup editor has a feature that that automatically removes any attributes or elements that do not appear in the defined DTD when content is opened for editing. Upon activation, the feature notifies authors that content will be deleted with unknown effects for end users. The authors have the option to cancel the operation, in which case the content will not be opened for editing.
Related Resources for Success Criterion B.1.2.4:
  • N/A

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

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.

Implementing Success Criterion B.1.3.1 Accessible Auto-Generated Content (WCAG Level A): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level A prior to publishing. (Level A) Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of 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.).

Intent of Success Criterion B.1.3.1:

The intent of this success criterion is to ensure that when authoring tools have been designed to take over responsibility from authors in determining aspects of web content that are important for accessibility, that the content that is actually produced meets WCAG 2.0 Level A by default. If this was not the case, authoring tools could continually introduce web content accessibility problems that authors would then need to check for and repair.

The intent of the note is to make it clear that this success criterion applies to "good faith" efforts by authoring tool developers. These guidelines do not contain any requirement that authors be forced to provide accessibility information, although some constrained use cases (e.g., government or corporate settings) may take that approach.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.3.1:
  • Markup behind WYSIWYG: A WYSIWYG web page authoring tool provides authors with a toolbar of options for formatting text. Following the WYSIWYG (what-you-see-is-what-you-get) paradigm, the options are labeled with the visual result (e.g., a bold "B" to represent bold, an italicized "I" to represent italics, etc.) of performing the action however, the content that is automatically generated from those actions actually conforms to WCAG 2.0 (e.g., using strong for bold and em for emphasis).
  • Automatic generation with author input: An online photo album allows authors to upload images and then automatically generates content to display the images. Since the album application is not able to automatically generate alternative content for the images that meets WCAG 2.0, authors are prompted for this information.
  • Documentation: An authoring tool that employs automatic content generation documents the accessibility of this functionality with reference to particular WCAG 2.0 techniques.
Related Resources for Success Criterion B.1.3.1:

Implementing Success Criterion B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AA prior to publishing. (Level AA) Note: This 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.).

See Implementing Success Criterion B.1.3.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion B.1.3.3 Accessible Auto-Generated Content (Level AAA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AAA prior to publishing. (Level AAA) Note: This 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.).

See Implementing Success Criterion B.1.3.1, substituting WCAG 2.0 Level AAA.

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

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

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.

Implementing Success Criterion B.2.1.1 Decision Support: 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) (a) Warning: 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 a list of technologies for which the authoring tool does provide support for the production of accessible content.

Intent of Success Criterion B.2.1.1:

The intent of this success criterion is to inform authors as early as possible about the degree to which the authoring tool will be able to provide accessible web content production support for the web content technologies that it is capable of producing. If accessibility is part of early decision-making, it will reduce the likelihood that retrofits for accessibility will be required later on.

The success criterion makes no judgment or assumption about the accessibility of web content technologies. Instead, it is assumed that any technology can be made accessible if used properly. For example, a technology with no intrinsic accessibility features can be made accessible in conjunction with another technology (e.g., bitmap images may be made more accessible via HTML text labels).

Instead, the success criterion depends on whether the authoring tool in question actually supports the production of accessible content in the technology through features such as checking and repair or does not. The choice of which technologies to provide accessible content production support for is left completely to the developer (e.g., a developer might decide to begin by adding support to a less-popular technology because a major customer has requested it).

The wording "provides the option of producing" is intended to rule out situations in which authors make technology choices without guidance by the authoring tool (e.g., by hand coding, by specifying a DTD).

The wording "for publishing" is intended to rule out situations in which incomplete content is created in interim formats that are not intended for publishing.

The intent of (a) is that there be a warning before authors have progressed too far with a technology option lacking support for the production of accessible content in the authoring tool. The warning may appear before authors make a selection or after.

The intent of (b) is simply to inform the user, who has now just received a warning that the authoring tool lacks accessibility support for a given technology, that one or more other web content technologies produced by the authoring tool are supported by such accessibility support features. The list may be a partial or complete list of the technologies for which support for the production of accessible content is provided. In either case, it is left to authors, to decide whether any of the listed technologies might be appropriate for the task or whether they will continue on with their original selection.

Examples of Success Criterion B.2.1.1:
  • Choosing video formats: A video authoring tool allows authors to save into several video file formats. However, the authoring tool includes a built-in closed-caption editor that only works with one of the file formats. While there is nothing intrinsically "inaccessible" about any of these three video formats, when the option to save is presented, the formats that are not supported by the authoring tool's own closed-caption editor include warnings that caption support is not provided. In the warning's explanation, the video format that is supported by the closed-caption editor is identified.
Related Resources for Success Criterion B.2.1.1:
  • N/A

Implementing Success Criterion 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)

Intent of Success Criterion B.2.1.2:

The intent of this success criterion is to ensure that if authoring tools only allow authors the ability to modify a subset of the properties of a content element, then the properties required for conformance to WCAG 2.0 are included in that subset.

Examples of Success Criterion B.2.1.2:
  • Context sensitive properties: A markup authoring tool includes a context sensitive properties pane that displays property fields for the most common subset of attributes associated with the markup element that currently has focus in the editing view. The attributes that are required for WCAG 2.0 are included in the subset.
    Figure: An "Image Properties" dialog box in which the input fields are ordered (from top to bottom, left to right): source ("src"), short label ("alt"), long description ("longdesc"), height, and width. The buttons at the bottom are "More...", "OK" and "Cancel". (Source: mockup by AUWG)
    See the example caption above for description.

Implementing Success Criterion B.2.1.3 Other Technologies: If the authoring tool can insert web content that it cannot subsequently edit, then authors can associate accessibility information with that web content. (Level A)

Intent of Success Criterion:

The intent of this success criterion is to ensure that when web content technologies can only be imported or integrated (but not edited), authoring tools still provide a mechanism for associating the necessary accessibility information. Many authoring tools make a distinction between technologies that the authoring tool actually uses to edit content and other technologies that can only be imported or integrated. For example, most HTML editors can insert images into web pages without the ability to edit the images.

The association of accessibility information can take many forms, depending on the nature of the inserted web content technology and the web content technology that can be edited. In the HTML example, it is straightforward to associate accessibility information for images via the HTML markup (i.e., alt, longdesc). However, if the inserted web content technology can introduce extensive, inaccessible content, then support for linking to conforming alternate versions might be appropriate.

Examples of Success Criterion B.2.1.3:
  • Time-based media alternatives: A SMIL authoring tool lets authors create multimedia presentations by pulling together video, audio and timed text objects on to a timeline, even though the tool has no built-in ability to edit these objects. When authors specify information about video to be inserted, they are also provided with the opportunity to associate a timed text object (for captions), an audio object (for audio description) and a secondary video (for sign language interpretation). When authors specify information about audio to be inserted, they are also provided with the opportunity to associate a timed text object (for captions) and a video (for sign language interpretation).
  • Data table for a bar graph: A learning content management system has a feature that lets authors insert figures. The feature accepts images, even though the authoring tool has no built-in ability to edit images, but as part of the "figure properties" the authors can identify the figure as a graph. If they choose this option, then the system assists them in creating an accompanying data table using the values used to create the graph.
Related Resources for Success Criterion B.2.1.3:

Implementing Guideline B.2.2: Assist authors in checking for accessibility problems. [Return to Guideline]

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.

Implementing Success Criterion 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 alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A) Note: Automated 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 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.

Intent of Success Criterion B.2.2.1:

The intent of this success criterion is to ensure that authors are supported in discovering web content accessibility problems in the content that they are editing. This is critical if these issues are to be addressed prior to publishing. The requirement to individually check WCAG 2.0 success criteria is intended to prevent manual checks from being worded in excessively general ways (e.g., "does the page meet all of the requirements?").

The success criterion does not specify how multiple instances of the same problem should be handled, because this will usually depend on the nature of the problem and the degree of automation in the checking and repair features of the authoring tool. Some problems are limited to one or just a few elements and lend themselves to automated or semi-automated reporting of each instance (e.g., missing labels), while other problems extend across many elements and are sometimes best checked globally (e.g., reading level, etc.).

The intent of the note about manual checking is to recognize that the current state of technology does not allow every web content accessibility problem to be identified automatically.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.2.1:
  • Markup processing checker: An accessibility checking tool includes automated checking for web content accessibility problems that can be detected from markup alone. The tool includes semi-automated checking where potential instances can be detected from the markup, but where the author's assessment of the content is required to make a final decision. In cases where markup processing is of little or no use in detecting problems, manual instructions are included for authors to follow in identifying whether the relevant WCAG 2.0 success criterion has been met.
  • Content processing checker: An accessibility checking tool goes beyond markup processing by applying content processing heuristics, such as:
    • Image processing to detect whether foreground and background contrast levels are sufficient or whether images are blank.
    • Text processing to calculate reading levels and detect changes in human language.
Related Resources for Success Criterion B.2.2.1:

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

Intent of Success Criterion B.2.2.2:

The intent of this success criterion is to ensure that accessibility checking is an integral part of the normal workflow of authoring tools, similar to checking for other content issues (e.g., spelling, syntax, validation, security). If authors are made aware of the web content accessibility problems in their web content as a normal part of their workflow, the issues are more likely to be repaired before the content is published. Through this process, authors will become more aware of accessible authoring practices.

Examples of Success Criterion B.2.2.2:
  • Check-as-you-type: An authoring tool continuously checks the web content being edited and highlights problems as the authors work.
    Figure: A WYSIWY authoring tool is shown with check-as-you-type accessibility checking activated. Two elements on the page have been highlighted as having problems: an image is surrounded by a blue squiggly line and a line of text is underlined by the same style of blue squiggly line. (Source: mockup by AUWG)
    See the example caption above for description.

  • Checking on demand: An authoring tool provides accessibility checking from a menu item that is always available.
  • Prompt to check before publishing: An authoring tool automatically performs an accessibility check if authors choose a publishing option and informs authors of the results.
Related Resources for Success Criterion B.2.2.2:

Implementing Success Criterion 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 decide whether it is correctly identified. (Level A)

Intent of Success Criterion B.2.2.3:

The intent of this success criterion is to ensure that authors, who in many cases will lack accessibility knowledge, will be able to make adequate judgments. If this is not the case, authors may miss web content accessibility problems that do exist and/or mistakenly identify problems that do not exist.

Examples of Success Criterion B.2.2.3:
  • Questions answered: Instructions are formulated to answer the questions: "What part of the content should be examined?" and "What is present or absent that is causing the problem?".
  • Variety of views: When author judgment would be enhanced by modified views of the web content being edited, an accessibility browser toolbar is used to provide various previews, such as:
    • an alternative content view (with images and other multimedia replaced by any alternative content)
    • a monochrome view (to test contrast)
    • a text to speech view (to test the availability of text alternatives)
    • no scripts view
    • no frames view
    • no style sheet view
  • Judgments saved: An authoring tool saves author judgments for manual checks and only prompts for new judgments after authors have made substantial changes.
Related Resources for Success Criterion B.2.2.3:

Implementing Success Criterion 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 content is identified (e.g., highlighting the affected content, displaying line numbers, etc.) (Level A)

Intent of Success Criterion B.2.2.4:

The intent of this success criterion is to increase the accuracy of author judgments by identifying the location of suspected web content accessibility problems as precisely as possible.

Examples of Success Criterion B.2.2.4:
  • By line number: An authoring tool displays potential problems in a separate list by the line number of the first element involved.
  • Underlining: A source content editing view displays potential problems in-line by underlining all of the markup for the affected span of elements.
  • Outlining: A WYSIWYG editing view displays potential problems in-line with the rendered content as blue outlining around the affected span of elements.
  • Site-wide checking: A web site management software is designed to identify issues on a site-wide scale (e.g., broken links, outdated information). The software also includes a feature to detect site-wide accessibility problems. The feature is able to identify faulty templates, widgets, etc. that can cause systematic problems.
Related Resources for Success Criterion B.2.2.4:

Implementing Success Criterion 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) Note: Automated 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 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.

See Implementing Success Criterion B.2.2.1, substituting WCAG 2.0 level AA.

Implementing Success Criterion B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) 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.

Intent of Success Criterion B.2.2.6:

The intent of this success criterion is to ensure that authors are able to obtain an overview of the accessibility status of their web content. This information has many uses, including the assessment of repair options, progress monitoring and performance reporting.

The intent of the note is to be clear that no particular format is required, since this will depend on the nature of the authoring tool and its checking feature.

Examples of Success Criterion B.2.2.6:
  • List of accessibility problems: A step-by-step checking feature provides a single consolidated list of all of the web content accessibility problems that were detected. Direct links are provided to additional help and repair assistance for each type of accessibility problem.
  • Conformance level report: A check-as-you-type checking feature highlights accessibility problems that can be automatically detected directly within a WYSIWYG editing view. The author controls the strictness of the automatic checking from a preferences screen, where they select the target WCAG 2.0 level. The overall status of of accessibility checking is available on the application status bar, which lists the target WCAG 2.0 level and the number of outstanding problems that can be automatically detected. A link to the remaining manual checks is also provided.
Related Resources for Success Criterion B.2.2.6:
  • N/A

Implementing Success Criterion B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., specific check results, summary conformance claims, etc.)

Intent of Success Criterion B.2.2.7:

The intent of this success criterion is to facilitate the creation of accessibility metadata, which can have multiple uses, benefiting both authors (e.g., by enabling interoperability between various checking and repair tools) and end users (e.g., by enabling accessible resource discovery).

The intent of the note is to be clear that no particular format is required. Various metadata options exist and they differ in the nature of the information they encode. The metadata choice will depend on the intended use of the metadata. While this success criterion does not require the use of a particular accessibility metadata format, accessible resource discovery is facilitated by formats that include specific checking results as opposed to formats that only include summary conformance information. The reason for this is that individual end users who are seeking accessible content, may have preferences for certain types of accessibility information (e.g., captions), but not for others (e.g., audio descriptions). This level of detail can be extracted from specific checking results, but not from summary conformance claims.

Examples of Success Criterion B.2.2.7:
  • Saving EARL: An authoring tool includes an automated/semi-automated accessibility checker, but only manual repair guidance. In order to give authors additional repair options, the checker includes the option of storing the listing of web content accessibility problems using the Evaluation and Repair Language (EARL). This allows the author to use an external automated/semi-automated repair service.
  • Saving AccessForAll: A learning content management system (LCMS) is implemented with a personalized approach to accessibility. Instead of every version of every web content resource being fully conformant (e.g., every video including captions), several versions of each web content resource are produced (e.g., one with captions and one without) and AccessForAll metadata is associated with each. Then when an end user attempts to access a web content resource, their personal preferences are used by the LCMS to locate and serve out the version of the web content resource that is appropriate to that end user's preferences.
  • Accessibility of legacy web content: A content management system includes the ability to inventory issues within legacy web content. Running automated checking on legacy web content and storing the results in metadata, provides decision-makers with potentially useful information.
Related Resources for Success Criterion B.2.2.7:

Implementing Success Criterion B.2.2.8 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) Note: Automated 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 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.

See Implementing Success Criterion B.2.2.1, substituting WCAG 2.0 level AAA.

Implementing Guideline B.2.3: Assist authors in repairing accessibility problems. [Return to Guideline]

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.

Implementing Success Criterion 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: 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.

Intent of Success Criterion B.2.3.1:

The intent of this success criterion is to ensure that authors are given a method to repair identifiable web content accessibility problems.

The intent of the note allowing manual repair assistance to meet this success criterion is to take into account the difficulty of automatically or semi-automatically repairing certain types of accessibility problems.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.3.1:
  • Check-as-you-type: An authoring tool includes a check-as-you-type feature (see also Example for Success Criterion B.2.2.2) that provides context sensitive repair.
    Figure: A WYSIWYG editing view is shown, in which a table is being edited. The first row of the table is highlighted in blue "squiggly" lines because a checking heuristic has detected that it might actually be a header row. The author has right clicked on the outlined area and a pop-up menu gives them several repair options: "Repair: Set as header row", "Skip", "Ignore", "Check Accessibility..." and "Help...".
    See the example caption above for description.
  • Combined check-repair feature: A WYSIWYG web page authoring tool includes an accessibility check and repair feature that presents web content accessibility problems and repair options in a sequential manner analogous to a typical spelling or grammar checking "wizard". Each screen provides input field(s) for the information required to address the issue as well as additional information and tips that authors may require in order to properly provide the requested information.
    Figure: A correction interface is shown for repairing missing alternate text label for an image. The interface includes (1) a short description of the problem (here: "Missing Alternate Text Label for an Image"), (2) a preview (here: the "earthrise" image that is missing a label), (3) tips for performing the repair (here: "Alternate text should be 10 words or less and should include any text in the image."; "Image buttons should have alternate text that describes the button function."; and "Image bullets should have "bullet" as alternate text."), and (4) an offered semi-automated repair in an editable drop-down box (here: "An earth rise as seen from the moon"). The global checker controls include a progress indicator ("5 of 25") and navigation buttons to move backwards ("back") and forwards ("skip") through the list of repair tasks. Buttons to "repair", get "help" and "cancel" are also provided. (Source: mockup by AUWG)
    See the example caption above for description.
  • Manual repair instructions: For each potential accessibility problem identified by the checking function (required for Success Criterion B.2.2.1), documentation with repair instructions is provided that authors (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem.

Implementing Success Criterion 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) 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.

See Implementing Success Criterion B.2.3.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion 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.8), repair assistance is provided. (Level AAA) 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.

See Implementing Success Criterion B.2.3.1, substituting WCAG 2.0 Level AAA.

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

Rationale: Improperly generated alternative content can create accessibility problems and interfere with accessibility checking.

See Also: This guideline applies when non-text content is specified by authors (e.g., inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.3.

Implementing Success Criterion 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)

Intent of Success Criterion B.2.4.1:

The intent of this success criterion is to ensure that authors can add alternative content for non-text content and modify that alternative content in the future. If the type of alternative content (e.g., alternative text) is not typically displayed on screen by user agents, then WYSIWYG editing views may not display it. This is acceptable as long as another mechanism is provided for modifying that content.

Examples of Success Criterion B.2.4.1:
  • Source content editing view: In a source content editing view, alternative content within the source is always available, regardless of what user agents might render. If alternative content is referenced from an external location (e.g., HTML4 longdesc), then that resource can be opened for editing.
  • Properties dialog: In a WYSIWYG editing view, alternative content is not displayed, since the editing view is designed to mimic typical user agents. However, the alternative content can be accessed and edited via a properties editor that displays the properties for the content that currently has focus.
Related Resources for Success Criterion B.2.4.1:

Implementing Success Criterion 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).

Intent of Success Criterion B.2.4.2:

The intent of this success criterion is to prevent the production of alternative content that is not useful to an end user because it has not been approved by an author and/or it is derived from unreliable sources.

The requirement of author control (a) enables knowledgeable authors to have the final say on alternative content suggested by authoring tools.

The limitation to relevant sources (b) is intended to reduce the possibility that authors who are unfamiliar with accessibility may approve alternative content suggestions without realizing the problems these can cause for end users.

Examples of Success Criterion B.2.4.2:
  • Metadata on an archive: A content management system includes a feature that allows authors to make use of images from an extensive photographic archive. The photographic archive includes metadata for each photograph with title and description fields. The title field is always filled, but the description field is sometimes lacking. When authors select an image for insertion, the metadata title is suggested as the alternative text label and the metadata description (if any) is suggested as the long description. In both cases, some basic guidance on what constitutes correct alternative content is provided to help authors judge the appropriateness of the suggestions.
  • Alternative content registry: A web page authoring tool implements an alternative content registry (see also Success Criterion B.2.4.4). Since the alternative content was gathered from authors' previous entries into the same fields for the same objects, these are acceptable as relevant sources. The authors are still given the opportunity to accept, modify, or reject the suggested alternative content prior to insertion, in case the non-text content is being used in a different context.
  • Accepting patterns: An authoring tool allows authors to accept patterns of future uses of an alternative content under certain conditions (e.g., whenever the same non-text content is marked with the same semantic role).
Related Resources for Success Criterion B.2.4.2:

Implementing Success Criterion 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)

Intent of Success Criterion B.2.4.3:

The intent of this success criterion is to address situations in which authors have either not noticed or ignored opportunities for adding alternative content and have ended their authoring sessions. ATAG 2.0 does not require authoring tools to attempt automated repairs in this situation because doing so risks misleading accessibility checking tools and end users into the assumption that the alternative content was either provided or approved by an author. However, if developers do want to provide automated assistance to end users, then this success criterion specifies what types of repairs may be provided. Essentially:

  1. Basic "text" processing repairs using information that is equally available to user agents (e.g., file name, text metadata within non-text objects, the title of a linked resource, etc.) are not allowed, because they are best performed by user agents and assistive technologies.
  2. Repairs are allowed when authoring tools have contextual information (e.g., the image is the author's profile picture) that user agents do not have equal access to.
  3. Repairs are also allowed that go beyond simple text processing to directly processing images, audio or video. The intent here is to encourage progress in these rapidly advancing fields.
Examples of Success Criterion B.2.4.3:
  • Contextual information is known: A social networking authoring tool allows authors to add a description of their profile picture. If an author chooses not to provide a description, the authoring tool labels the image as the author's profile picture.
  • Contextual information is not known: A web page authoring tool allows authors to insert images. If an author ignores opportunities to add alternative content and then ends the authoring session, the authoring tool has access to information such as the file name of the image, but since this is text information that is equally available to user agents, it is not suggested.
  • Auto-generated transcript: An on-line video editing and hosting authoring tool has a feature that allows authors to create transcripts or captions for their videos. Authors can begin by copying in a transcript if one is available or the authoring tool can use voice recognition technology to generate a transcript for the authors to correct. While this is preferred, the authoring tool also has a setting in which it will automatically add the auto-generated transcript to the published presentation if the end user requests this and the author has not made an attempt to add their own captions or transcript.
Related Resources for Success Criterion B.2.4.3:

Implementing Success Criterion 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)

Intent of Success Criterion B.2.4.4:

The intent of this success criterion is to ensure that when authors spend effort providing alternative content, this content is retained by the authoring tool in a form that allows it to be easily reused.

Examples of Success Criterion B.2.4.4:
  • Alternative content registry: An authoring tool includes a registry that associates object identity information with alternative content (i.e., text, URIs). Whenever an object is used and any alternative content is collected, the object's identifying information and the alternative content is added to the registry. The stored alternative content is suggested as alternative content for author approval whenever the associated object is inserted. The alternative content registry allows several different versions of alternative content to be associated with a single object (e.g., various translations, various contexts).
    Figure: The interface of a sample alternative content registry viewer is shown. The design takes into account multiple non-text content objects of the same name, multiple types of text equivalents for each non-text content object, and multiple versions of each text equivalent type. In the viewer shown here, the author has selected "image" as the "media type" and then selected pic123.gif as the "content" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the content has three text labels. The author has selected one ("An earth rise as seen from the moon") in order to edit it. In addition some authoring tips are included ("Alternate text should be 10 words or less and should include any text in the image", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have "bullet" as alternate text."(Source: mockup by AUWG)
    See the example caption above for description.
  • Interoperability with pre-authored content: An enterprise authoring tool's clip art system is integrated with an alternative content registry so that new alternative content created by any author on the enterprise system is stored along with the pre-authored alternative content for the images in the system. The keyword search feature of the clip art system makes use of any alternative content to retrieve matches.
Related Resources for Success Criterion B.2.4.4:

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

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.

Implementing Success Criterion 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) 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.

Intent of Success Criterion B.2.5.1:

The intent of this success criterion is to ensure that when authoring tools select templates or pre-authored content for authors or automatically generate web content from a template, then the web content conforms to WCAG 2.0 Level A by default. If this was not the case, authoring tools could continually introduce accessibility problems that authors would likely not be able to repair.

The intent of the note is to make it clear that this success criterion takes into account that templates are, by their nature, incomplete. In addition, templates are often stored in forms quite different than the final web content that they are used to produce.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.5.1:
  • Content management system: A content management system offers a variety of templates to authors for different purposes (e.g., information page, interactive form page, registration page, etc.). All of the templates have passed WCAG 2.0 Level A accessibility evaluations when filled in with sample content by authors who follow all of the instructions provided.
Related Resources for Success Criterion B.2.5.1:

Implementing Success Criterion 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)

Intent of Success Criterion B.2.5.2:

The intent of this success criterion is to reduce the possibility that authors will be forced to use inaccessible templates to create web content because accessible templates do not exist.

Examples of Success Criterion B.2.5.2:
  • Variety of accessible templates: A web page authoring tool provides several template choices for home pages, guest books and on-line albums. For each type of functionality, the basic template option is accessible.
Related Resources for Success Criterion B.2.5.2:
  • N/A

Implementing Success Criterion 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) 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.

See Implementing Success Criterion B.2.5.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion 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) (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.

Intent of Success Criterion B.2.5.4:

The intent of this success criterion is to ensure that authors can easily determine the accessibility status of templates prior to selecting them and that authors are more likely to notice the accessible template options.

Examples of Success Criterion B.2.5.4:
  • Template names include accessibility status: In a wiki system, creating a new page brings up a list of available templates. Each template has its WCAG 2.0 conformance level included in its name (e.g., "slide show template - wcagA").
  • Sort by accessibility status: A template repository lists the available templates and provides the templates' accessibility status as a sortable field.
Related Resources for Success Criterion B.2.5.4:
  • N/A

Implementing Success Criterion 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)

Intent of Success Criterion B.2.5.5:

The intent of this success criterion is to ensure that new templates that authors create and which might be used by subsequent authors interoperate with the relevant template selection mechanism (See Success Criterion B.2.5.4).

Examples of Success Criterion B.2.5.5:
  • Save as template: An authoring tool provides a "save as template" feature. When authors activate this feature, the authoring tool automatically runs an accessibility checker on the template with sample data. Once the checker returns a resulting accessibility status, authors have the option of labeling the template with this status. If the template fails to conform to WCAG 2.0 with sample data, then authors are advised that templates should be held to a high accessibility standard, since they will be repeatedly reused.
Related Resources for Success Criterion B.2.5.5:

Implementing Success Criterion 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.

See Implementing Success Criterion B.2.5.4, substituting "pre-authored content" for "templates".

Implementing Success Criterion 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)

Intent of Success Criterion B.2.5.7:

The intent of this success criterion is to ensure that all templates that the authoring tool provides include an accessibility status, which might be used by a template selection mechanism (See Success Criterion B.2.5.4). This is not a requirement that all templates meet any particular accessibility level.

Examples of Success Criterion B.2.5.7:
  • Template repository: A web page authoring tool provides several template choices for home pages, guest books and on-line albums. All of the templates are labeled with an accessibility level (i.e., conforming to WCAG 2.0 Level A, Level AA or Level AAA when used as directed).
Related Resources for Success Criterion B.2.5.7:
  • N/A

Implementing Success Criterion 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)

Intent of Success Criterion B.2.5.8:

The intent of this success criterion is to ensure that all pre-authored content that the authoring tool provides include an accessibility status, which might be used by a pre-authored content selection mechanism (See Success Criterion B.2.5.6). This is not a requirement that all pre-authored content meet any particular accessibility level.

Examples of Success Criterion B.2.5.8:
  • Clip art collection: An authoring tool is shipped with a clip art collection. Each image in the collection has a short text label and long text description and the system is interoperable with the alternative content registry, so that whenever authors insert an image from the clip art collection, its alternative content is automatically retrieved.
Related Resources for Success Criterion B.2.5.8:

Implementing Success Criterion B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AAA when used. (Level AAA) 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.

See Implementing Success Criterion B.2.5.1, substituting WCAG 2.0 Level AAA.

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

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

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.

Implementing Success Criterion B.3.1.1 Accessible Options Prominent (WCAG Level A): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not. (Level A)

Intent of Success Criterion B.3.1.1:

The intent of this success criterion is to help ensure that accessible authoring practices are part of the default workflow of authoring tools.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.3.1.1:
  • Only accessible options: A WYSIWYG editing view does not include any options for authors that will necessarily result in web content that will not conform to WCAG 2.0 Level A.
  • De-emphasizing problematic options: A WYSIWYG editing view emphasizes more accessible choices with a higher position in the menus and a position in user interface shortcuts such as toolbars. Choices that always lead to less accessible web content are de-emphasized with lower menu position.
    Figure: An authoring tool that supports two methods for setting text color: using CSS and using font. Since using CSS is the more accessible option, it is given a higher prominence within the authoring interface by: (1) the "CSS Styling" option appearing above the "FONT Styling" option in the drop down Text menu, and (2) the CSS styling option being used to implement the one-click text color formatting button in the tool bar. The association is made clear because the toolbar button has the same icon (an "A" beside a color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu option.). (Source: mockup by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.3.1.1:

Implementing Success Criterion B.3.1.2 Accessible Options Prominent (WCAG Level AA): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not. (Level AA)

See Implementing Success Criterion B.3.1.1, substituting WCAG 2.0 Level AA.

Implementing Success Criterion B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If authors If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not. (Level AAA)

See Implementing Success Criterion B.3.1.1, substituting WCAG 2.0 Level AAA.

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

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.

Implementing Success Criterion B.3.2.1 Active by Default: All accessible content support features are turned on by default. (Level A)

Intent of Success Criterion B.3.2.1:

The intent of this success criterion is to help ensure that the accessible content support features are perceived by authors (and developers) as a natural and expected part of the authoring tool workflow, just as features for addressing spelling, grammar and syntax errors already are.

Examples of Success Criterion B.3.2.1:
  • On by default: A web page authoring tool has all accessible content support features turned on by default within the "Accessibility" tab of its preferences area.
    Figure: The preference setting area of an authoring tool, open to an "Accessibility" section, shows the default settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the following options: "Check accessibility as you type", "Check accessibility after saving", "Auto-correct when possible", "Highlight accessibility related fields", "Prompt when highlighted fields are left blank", and "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.3.2.1:
  • N/A

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

Intent of Success Criterion B.3.2.2:

The intent of this success criterion is to ensure that if authors turn off accessible content support features for any reason, they can easily turn them back on.

Examples of Success Criterion B.3.2.2:
  • Toggle in preferences area: A web page authoring tool provides an "Accessibility" tab in its preferences area (See Figure for Success Criterion B.3.2.1, above) where any deactivated features can be reactivated.
  • Reminders: An authoring tool has a "wizard"-style accessibility checker and a "check-as-you-type"-style accessibility checker. If the "check-as-you-type"-style checker has been turned off, then authors are reminded about the feature and provided with an option to turn it back on whenever they run the "wizard"-style checker.
Related Resources for Success Criterion B.3.2.2:
  • N/A

Implementing Success Criterion B.3.2.3 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)

Intent of Success Criterion B.3.2.3:

The intent of this success criterion is to ensure that if authors attempt to turn off an accessible content support feature for any reason, they will have the opportunity to understand the effect this will have on the accessibility of the web content that they produce.

Examples of Success Criterion B.3.2.3:
  • Warning: An authoring tool provides authors with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.
    Figure: In an authoring tool, the author has unchecked a "highlighting accessibility related fields" feature the tool. As a result the tool displays a warning that reads "You have just turned off the highlighting accessibility related fields feature. This feature is designed to inform you when information must be provided in order for your documents to comply with your target accessibility setting. Turning this feature off could cause your documents to be less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you sure you want to proceed?". The author has the option to answer "Yes", "No" or "Cancel". (Source: mockup by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.3.2.3:
  • N/A

Implementing Success Criterion 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)

Intent of Success Criterion B.3.2.4:

The intent of this success criterion is to help ensure that authors are as likely to notice and use functions for addressing accessibility problems as functions for addressing other web content issues (e.g., invalid markup, syntax errors, spelling and grammar errors).

Examples of Success Criterion B.3.2.4:
  • Prominence of checking and repair: An authoring tool includes a pane dedicated to content "Evaluation and Repair". The pane lists accessibility, grammar, link checking, spelling, and syntax validation. When the various utilities are run, their results are displayed in similar ways within the pane.
  • Prominence of documentation: An authoring tool includes documentation of its accessibility checker as part of the main documentation of an authoring tool, with very similar prominence to that of the spelling-related features.
    Figure: A help system is shown. In the right pane is the documentation table of contents, where "Accessibility Features" appears as a top level topic just below "Spelling Features". In the left panel is the help text, demonstrating a style typical of the rest of the help system: "Checking for Accessibility: A variety of accessibility checking options are available: Accessibility verifier, Check accessibility as you type, Manual test support materials. These are suitable for use at different times during the authoring process and all have options that can be changed with the accessibility preferences. To get more information on accessible web content, see the References.". (Source: mockup by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.3.2.4:
  • N/A

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

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.

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

Intent of Success Criterion B.3.3.1:

The intent of this success criterion is to help ensure that authors are able to find help on how to use the accessible content support features effectively.

Examples of Success Criterion B.3.3.1:
  • Documentation of accessible content support features: An authoring tool's help system documents the accessible content support features as it would other features of the authoring tool. Since the authoring tool includes context-sensitive help, this is also provided for the accessible content support features.
  • Short and long versions of help: During prompting and repairs, an authoring tool provides authors with immediate access to some basic accessibility documentation and one-step access to more comprehensive documentation.
    Figure: An accessibility checker includes some limited tips for authoring short text labels listed beneath the text entry area as well as a "Help" button linking to the full documentation. The tips are: "Alternate text should be 10 words or less and should include any text in the image.", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have 'bullet' as alternate text.". The screen shot also includes the name of the problem ("Missing Alternate Text Label for an Image"), a field for adding the short text label and a preview rendering of the image ("earthrise"). At the bottom are five buttons: "Help", "< Back", "Repair", "Skip", and "Cancel". (Source: mockup by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.3.3.1:
  • N/A

Implementing Success Criterion 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)

Intent of Success Criterion B.3.3.2:

The intent of this success criterion is to ensure that authors that learn best through tutorials are exposed to accessibility best practices specific to the authoring tool.

Examples of Success Criterion B.3.3.2:
  • Accessibility tutorial: A web page authoring tool includes built-in tutorials demonstrating several multi-step tasks (e.g., setting up the folders and files for the local version of a website, formatting with CSS, etc.). One of the tutorials describes how to use the accessible content support features of the authoring tool to increase the accessibility of the web content produced. The tutorial begins at the typical starting point for the tool (e.g., empty document). The tutorial also covers when and how checking and repair should be performed. The tutorial includes some basic rationales for accessible content production. These rationales emphasize the importance of accessibility for a wide range of content consumers, from those with disabilities to those with alternative viewers (see "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource).
Related Resources for Success Criterion B.3.3.2:

Implementing Guideline B.3.4: Ensure that any authoring practices demonstrated in documentation are accessible. [Return to Guideline]

Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.

Implementing Success Criterion B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)

Intent of Success Criterion B.3.4.1:

The intent of this success criterion is to introduce accessible authoring practices as a naturally integrated common practice. The range of examples might include markup fragments, screen shots of WYSIWYG editing views, sample code or sample applications.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.3.4.1:
  • Reference examples are accessible: An HTML authoring tool includes an on-line HTML reference guide. Most of the examples provided in the reference guide conform to WCAG 2.0 Level A.
  • Screen shots show accessibility features in use: A content management system has a help system that includes screen shots of various screens. When screen shots show examples of the user interfaces while content being produced, the user interface is always such that the content produced would conforms WCAG 2.0 Level A (e.g., prompts filled in, optional accessibility features turned on, etc.).
Related Resources for Success Criterion B.3.4.1:

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

See Implementing Success Criterion B.3.4.1, substituting WCAG 2.0 Level AA.

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

See Implementing Success Criterion B.3.4.1, substituting WCAG 2.0 Level AAA.


Implementing ATAG 2.0 Conformance

This section is included here for informative purposes. The normative version appears in the Authoring Tool Accessibility Guidelines 2.0 [ATAG20].

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

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 producing accessible web content (in Part B).

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] success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported." In broad terms, WCAG 2.0 considers a web content technology to be accessibility supported when (1) the way that the web content technology is used is supported by users' assistive technology and (2) the web content technology has accessibility-supported user agents that are available to end users.

This concept is not easily extended to authoring tools because many authoring tools can be installed and used in a variety of environments with differing availabilities for assistive technologies and user agents (e.g., private intranets versus public websites, monolingual sites versus multilingual sites, etc.). Therefore:

For the purposes of ATAG 2.0 conformance, the accessibility-supported requirement is waived.

Once an authoring tool has been installed and put into use, it is 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.

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 Level A success criteria.
  2. Full ATAG 2.0 Conformance at Level AA
    The authoring tool satisfies all of the Level A and Level AA success criteria.
  3. Full ATAG 2.0 Conformance at Level AAA
    The authoring tool satisfies all of the success criteria.

And the Part A Applicability Notes and Part B 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 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 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 success criteria in Part A. Nothing is implied about Part B.

And the Part A 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 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 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 success criteria in Part B. Nothing is implied about Part A.

And the Part B 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 "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., 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.

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

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., 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).
  5. 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.
  6. 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., 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.
  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., 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 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: Gathering Accessibility Information from Authors:

This section is informative.

In order to produce accessible web content, authoring tools often need authors to provide accessibility information such as text alternatives for images, role and state information for widgets, relationships within complex tables, captions for audio. As for any information to be gathered from authors, there are a range of approaches that a developer might take for gathering accessibility information, from voluntary unintrusive reminders to intrusive mandatory prompts. While ATAG 2.0 does not require any particular approach, author cooperation and goodwill are important considerations in ensuring that the accessibility information that is gathered is correct and complete.

The following are some techniques that may assist in gathering different types of accessibility information, along with some example implementations.

1. Short text labels (e.g., alternate text, titles, short text metadata fields, rubies for ideograms):

Example A-1a: A dialog box offers short text labels for reuse. It shows an "Insert Image" dialog box a thumbnail image of the "earthrise" graphic along with entry fields for "src", "alt", "longdesc", "height" and "width". The "alt" entry field is drop-down list that is shown with several short labels for the same image. The first is a visual description in English ("An earth rise as seen from the moon"), the second is a visual description in French ("Une vue do la terre de la lune") and the third is an English functional label used if the image serves as a link ("Go to pictures of the earth"). (Source: mockup by AUWG)
See the example caption above for description.

Example A-1b: A source content editing view offers short text labels for reuse. It shows the author midway through adding markup for an image. After adding the src attribute value the author has pressed the spacebar, causing the tool to prompt them with the alt attribute along with several attribute values, including a visual description in English (alt="An earth rise as seen from the moon"), a visual description in French (alt="Une vue de la terre de la lune") and an English functional label used if the image serves as a link (alt="Go to pictures of the earth"). (Source: mockup by AUWG)
See the example caption above for description.

2. Multiple text labels (e.g., image map area labels):

Example A-2: An interface for image map area text labels. It is comprised of a list with two columns. In the right-hand column is the URL for each image map area. This can be used as a hint by the author as they fill in the text labels (left-hand column). A checkbox at the bottom provides the option of using the text labels to create a set of text links below the image map. (Source: mockup by AUWG)
See the example caption above for description.

(3): Long text descriptions (e.g., longdesc text, table summaries, site information, long text metadata fields):

Example A-3: An interface for long text descriptions. A "description required" checkbox controls whether the rest of the interface is available. If a description is required, the author then has the choice of opening an existing description file or writing (and saving) a new one. If they choose to use an existing file, there is a text entry area for the name along with a button to browse the file system. If they choose to compose a new description, there is a text entry area for the description followed by a text field for the file name and a button to save it to that location. In the situation shown, the author chooses to use an existing description of "earthrise" so the file name containing the description is shown. In addition, the text of the description from the file is loaded into the compose area ("The earth hangs in the pitch black sky above the gray horizon of the moon. The dazzling blue sphere is covered with creamy white streamers of cloud.") in case the author would like to use this text as a basis for a new description. (Source: mockup by AUWG)
See the example caption above for description.

(4): Form control labels:

Example A-4: A form properties list with five columns that allows the author to simultaneously decide the following for each field: the tab order, form name, field label, control type, and accesskey. In this example, two form field labels are missing, causing yellow highlighting of the cells and red icons to be displayed. "Move up" and "move down" buttons are provided. (Source: mockup by AUWG)
See the example caption above for description.

(5): Form field place-holders:

(6): Tab orders:

(7): Navigational shortcuts (e.g., keyboard shortcuts, bypass blocks, etc.):

Example A-7: A source content editing view that suggests access key values. The following markup can be seen: "<body><p>Here is one of the most famous photographs taken from the <a href="moon.html" > moon.</a></p><It was taken with a special <a href="camera.html" accesskey="c">camera.</p>". A pop-up menu, centered on the word "moon" suggest accesskey="m", because "moon" begins with "m", followed by the rest of the alphabet in order. Accesskey="c" is missing, however, since it is already used as an accesskey later in the document (for the "camera" link). (Source: mockup by AUWG)
See the example caption above for description.

(8): Contrasting colors:

Example A-8: A dialog box for choosing sufficiently contrasting color combinations. The dialog box has two tabs: one for text color and one for background color. A "hide low contrast choices" checkbox has been selected, so the palette of colors has been pre-screened so that sufficient contrast between the text and the current background color is assured. All other colors have been grayed out. (Source: mockup by AUWG)
See the example caption above for description.

(9): Alternative content for multimedia (transcripts, captions, video transcripts, audio descriptions, signed translations, still images, etc.):

(10): Metadata:

(11): Document structure:

Example A-11: A WYSIWYG editing view that detects opportunities for enhancing structure and alerts the author. On the left side is the WYSIWYG editing view with the title of the page ("Mars") displayed with a blue underline. The author has brought up a pop-up menu for the title and sees the following options: "Repair: Mark as heading (a sub-menu displays the different levels of header (i.e., h1, h2, etc.)) for the author to choose", "Skip", "Ignore", "Check Accessibility...", and "Help...". On the right, an element inspector makes clear that the title is currently marked up as a paragraph. (Source: mockup by AUWG)
See the example caption above for description.

(12): Tabular structure:

Example A-12: A WYSIWYG editing view that prompts the author to decide whether the top row of a table contains the table header cells. The top row of the rendered table is outlined in blue to indicate an accessibility problem. The author has brought up a pop-up menu for one of the cells in the top row and sees the following options: "Repair: Set as header row", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

(13): Style sheets:

(14): Clearly written text:

Example A-14a: A source content editing view that indicates the reading level of a page and whether it exceeds a limit determined by the author's preference settings. The editing view includes the following markup: <body><h1>Mars</h1><p>Mars is the fourth planet in the solar system, orbiting at a distance of 1.5 AU, with a period of 687 days.</p></body></html>. Then in a status bar below the text entry area, is a reading level display: "Reading Level: 11.2 (target<8)". The 11.2 is highlighted with a yellow background and bold text to indicate that the target is exceeded. (Source: mockup by AUWG)
See the example caption above for description.

Example A-14b: An authoring interface that prompts the author to enter an acronym expansion. The rendered text reads: "The 'habitable zone' around a star is the region of that star’s solar system in which liquid water is possible. The continuous habitable zone (CHZ) is the region of the solar system which has remained in the zone, even during changes in the star’s radiation pattern." The acronym "CHZ" is identified with a blue underline as an accessibility problem. The author has brought up a pop-up menu for the acronym and sees the following options: "Repair: Enter acronym expansion…", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

(15): Device-independent events:

(16): Non-text supplements to text:

Example A-16: An authoring interface for prompting the author about whether a paragraph that contains many numbers might be made more clear with the addition of a chart or graph. On the left side of the interface is the rendered text: " Planet Orbits: The inner planets orbit the sun relatively quickly with Mercury orbiting the sun in 88 days, Venus in 224 days, Earth in 365 days, and Mars in 687 days. Compare this to Jupiter’s, 4332 day orbit." This text is marked with a yellow exclamation mark icon. On the right side is the following explanation of the error icon: "This paragraph contains 5 numbers. Would readers benefit if a chart or graph of this information was added?". "Yes" and "no" buttons are provided. (Source: mockup by AUWG)
See the example caption above for description.


Appendix B: Levels of Checking Automation

This section is informative.

This list is representative, but not necessarily complete.

(a) Automated Checking:

In automated checking, the tool is able to check for accessibility problems automatically, with no human intervention required. This type of check is usually appropriate for checks of a syntactic nature, such as the use of deprecated elements or a missing attribute, in which the meaning of text or images does not play a role.

Example B-1: A summary interface for a code-based authoring tool that displays the results of an automated check. The display is a tree-view where the leftmost nodes are the names of problems ("Image missing alternate text" and "Text boxes missing labels) with number of problems appended (e.g., "[6]") and the sub-items are the problem instances with line numbers appended (e.g., "(Line:45)"). (Source: mockup by AUWG)
See the example caption above for description.

Example B-2: A WYSIWYG interface that displays the results of an automated check in a WYSIWYG authoring view using blue highlighting around or under rendered elements (in this case, the "earthrise" image and some "blinking text"), identifying accessibility problems for the author to correct. (Source: mockup by AUWG)
See the example caption above for description.

Example B-3: An authoring interface of an automated check in an instruction-level authoring view. The text is: "<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>".In this view, the text of elements with accessibility problems (img and blink) is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
See the example caption above for description.

(b) Semi-Automated Checking:

In semi-automated checking, the tool is able to identify potential problems, but still requires human judgment by authors to make a final decision on whether an actual problem exists. Semi-automated checks are usually most appropriate for problems that are semantic in nature, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, that lend themselves more readily to full automation.

Example B-4: A dialog box that appears once the tool has detected an image without a description attribute. However, since not all images require description, the author is prompted to make the final decision ("Does this image require descriptive text?"). The author can confirm that this is indeed an accessibility problem by choosing and move on to the repair stage by choosing "Yes" or press "No" to mark the potential problem, as not a problem at all. Additional help is available in the form of a tip: "An image requires descriptive text when the information it contains cannot be conveyed in 10 words or less using an alternate text label." (Source: mockup by AUWG)
See the example caption above for description.

(c) Manual Checking:

In manual checking, the tool provides authors with instructions for detecting a problem, but does not automate the task of detecting the problem in any other way. As a result, authors must decide on their own whether or not a problem exists. Manual checks are discouraged because they are prone to human error, especially when the type of problem in question may be easily detected by a more automated utility, such as an element missing a particular attribute.

Example B-5: A dialog box that reminds the author to check if there are any words in other languages in the document with the message: "Does this document contain any words or phrases in a different language than the main content?". The author can move on to the repair stage by pressing "Yes" or press "No" to mark the potential problem, as not a problem at all. (Source: mockup by AUWG)
See the example caption above for description.


Appendix C: Levels of Repair Automation

This section is informative.

This list is representative, but not necessarily complete.

(a) Repair Instructions:

In manual repairing, the tool provides authors with instructions for making the necessary correction, but does not automate the task in any other way. For example, the tool may move the cursor to start of the problem, but since this is not a substantial automation, the repair would still be considered "manual". Manual correction tools leave it up to authors to follow the instructions and make the repair by themselves. This is the most time consuming option for authors and allows the most opportunity for human error.

Example C-1: Repair instructions in a code level editing view. In this case, the following markup is being edited: <body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>. Since the problems have already been detected in the checking step and the selected offending elements in a code view (<img href="pic123.gif"/> and <blink>Blinking text</blink>) have been highlighted in blue text. When the author puts focus on the highlighted text, a short repair instruction ("Repair: Add 'alt' attribute") appears in a status bar with a button than will open a longer explanation in the help system. (Source: mockup by AUWG)
See the example caption above for description.

(b) Semi-Automated:

In semi-automated repairing, the tool can provide some automated assistance to authors in performing corrections, but author input is still required before the repair can be complete. For example, the tool may prompt authors for a plain text string, but then be capable of handling all of the markup required to add the text string to the content. In other cases, the tool may be able to narrow the choice of repair options, but still rely on authors to make the final selection. This type of repair is usually appropriate for corrections of a semantic nature.

Example C-2: A semi-automated repair in a WYSIWYG editing view. The author has right-clicked on an image of the "earthrise" that has been highlighted with a blue outline by the automated checker system. This has brought up a pop-up menu with the following choices: "Repair: Set Alt -Text: 'An earth rise as seen from the moon'", "Enter different alt-text…", " Skip", "Ignore", "Check Accessibility...", "Help...". The author must decide whether the label text that the tool suggests is appropriate. Whichever option the author chooses, the tool will handle the details of updating the content. (Source: mockup by AUWG)
See the example caption above for description.

(c) Automated:

In automated repairing, the tool is able to make repairs automatically, with no author input required. For example, a tool may be capable of automatically adding a document type to the header of a file that lacks this information. In these cases, very little, if any, author notification is required. This type of repair is usually appropriate for corrections of a syntactic or repetitive nature.

Example C-3: An announcement that an automated repair has been completed ("All instances of <blink> have been replaced with CSS styling according to your preferences."). The author selects an "ok" to proceed. An "undo" button is provided in case the author wishes to reverse the operation. In some cases, automated repairs might be completed with no author notification at all. (Source: mockup by AUWG)
See the example caption above for description.


Appendix D: Author Interruption Timing Options

This section is informative.

This list is representative, but not necessarily complete.

(a) Negotiated Interruption: A negotiated interruption is caused by interface mechanisms (e.g., icons or highlighting of the element, audio feedback) that alert the author to a problem, but remain flexible enough to allow the author to decide whether to take immediate action or address the issue at a later time. Since negotiated interruptions are less intrusive than immediate or scheduled interruptions, they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of problems within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems as they occur. Instead, it is recommended that negotiated interruption be supplemented by scheduled interruptions at major editing events (e.g., when publishing), when the tool should alert the author to the outstanding accessibility problems.

Applicable to content-rendering authoring functionsExample D-1: A WYSIWYG editing view makes the author of problems detected automatically by means of a blue line under text or around rendered objects with accessibility problems. Here, red lines are also visible, highlighting spelling errors in the text. The author can decide to address the problems at a later time. (Source: mockup by AUWG)
See the example caption above for description.

(b) Scheduled Interruption: A scheduled interruption is one in which the author has set the tool to alert them of accessibility issues on a configurable schedule. One option for the schedule might be to have prompts associated with the interface mechanisms for significant authoring events, such as opening, saving, closing, committing, or publishing files. At the significant authoring event, the author would be informed of the problem, while at the same time they would not be prevented from saving, publishing, printing, etc. A potential downside of postponing corrective actions is that by the time the prompt is displayed, the author may not have sufficient time or inclination to make the required changes, especially if they are extensive.

Example D-2: A "Publish" dialog box allows the author to publish multiple files at once, however in the case shown here, two of the files have uncorrected accessibility problems which causes them not to meet a "standard of publishing" the author has set for themselves in the options. As a result the files are selected, a message is displayed ("The selected files do not meet your specified standard for publishing.") and the "publishing" button is grayed out. This standard is referred to generally since it is assumed that it might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)
See the example caption above for description.

(c) Immediate Interruption: An immediate interruption is the most intrusive timing option because the attention of the author is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog. This type of alert presents multiple usability problems and should be used sparingly because it interferes with the normal design workflow. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close, such as when an author decides to publish the content in question. In general, negotiated and scheduled interruptions are preferred.

Example D-3: A modal dialog box contains the message: "This image is missing alternate text". The author must press the "OK" button to continue. (Source: mockup by AUWG)
See the example caption above for description.

 

Appendix E: Real-Time Content Production

This section is informative.

When authoring tools produce content in real time, it is usually no longer possible to delay addressing accessibility problems until an arbitrary point in the future. At the same time, due to the time pressure, authors in real-time environments tend to be less receptive to intrusive prompts. Nevertheless, tools that allow this kind of authoring should still take accessibility issues into account by supporting the following:

(a) Determination of Participant Requirements: If real-time authoring is consumed by individuals with no special communicative needs, there may be no need for real-time prompting. However, as with any other web content it is often impossible for authors to know all of the needs of the actual or potential participants. Therefore, the best practice is to create real-time content that conforms with WCAG to the greatest extent possible. However, when this is not possible, a real-time authoring tool might be able to facilitate graceful degradation of accessibility by polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or in some cases checking the profiles of participants (e.g., using CCPP, ACCLIP) to determine which types of accessibility practices would offer the greatest advantage in the short time available. Once this information is compiled, the tool can prompt authors (or see Assistant/Peer Author) to correct problems appropriately (preferably during Preparation Time). When it is not possible to know, with certainty, the needs of all participants, the tool should still assume that accessible content is required. This is especially true if the results of the session will be archived.

(b) Assistant/Peer Author: In some cases, it may be possible to designate one or more secondary authors in the live community, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author might be an unrelated specialist, analogous to Sign language interpreter, a co-author (helpful for describing technical drawings, etc.), or in some situations any member of the session audience (i.e., a peer).

(c) Preparation Time: If the authoring tool allows authors time to pre-assemble materials for a live presentation (e.g., a professor preparing for an online class), this authoring is not considered real-time authoring. The authoring tool has the opportunity and the obligation to support accessible authoring as described elsewhere in this document.

(d) Archiving: If the session will be archived, there may be other opportunities to increase the accessibility of the content of the archive by guiding authors through a process to check for and repair accessibility problems after the real-time session has ended, but prior to archiving.

If it has been determined that authors must provide real-time supplements, but no preparation time or assistant author are available, then in addition to allowing the author control of the nature and timing of prompting, the authoring tool can facilitate the inclusion of supplements by:

Example E-1: A real-time presentation in a whiteboard/chat client environment that has been enhanced to provide real-time descriptions. The example has five panes. On the far left is a list of participants ("Presenter", "John (You)", "Jane", and "Alice"). In the upper-middle is the chat "Presenter> I suggest a space theme for the slide presentation.", "Image File Inserted (by Presenter) Description: An earthrise as seen from the surface of the moon.", "Presenter> The white text would go...", "Marker (by Presenter) Description> Draws a red box..., and "Presenter> in this area." Notice that descriptions are appearing here. The lower-middle is the message composition area for this user and is blank. The upper-right is the whiteboard. So far there is an image of "earthrise" and a red hand-drawn rectangle on the "canvas". The whiteboard tools are "select box", "text tool", "marker", "eraser", "insert image", "line tool", "rectangle tool", and an "ellipse tool". In the lower-right is an area for describing a drawing action - in this case the "Presenter' use of the Marker". Notice that any participant can describe the events on the whiteboard even as the dialog continues. (Source: mockup by AUWG).
See the example caption above for description.


Appendix F: Glossary

This section is included here for informative purposes. The normative version appears in the Authoring Tool Accessibility Guidelines 2.0 [ATAG20].

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 of ATAG 2.0.
  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 a particular level of 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: Authors must be supported in the production of accessible content).
alternative content
Web 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
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:
  • 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 sounds, or both.
authors
People who use 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 (see also Part B Applicability Note 5). A person only qualifies as 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 author permission for that content.
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.
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 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 web 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
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
    • software for creating mobile web applications
  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.).
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):
  1. 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.
  2. 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 accessible authoring tool user interface is one that meets the success criteria of a level in Part A.
checking (accessibility)
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 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 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.
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. Accessible web content is web content that conforms to a particular level of WCAG 2.0 (see Relationship to WCAG 2.0 section). Structured web content is content that includes machine-readable internal structure (e.g., markup elements), as opposed to unstructured content, such as raster image formats or plain human language text. Web content properties are the individual pieces of information that make up the web content (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 includes properties that can be said to encode continuous input 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 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 to graphically mimic the diffusion effects that occur when a real paint brush is moved in a similar manner.
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. For example, 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 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 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).
control settings
Settings that relate to how authors control the authoring tool, for example using the keyboard or 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., 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., 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
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., 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 keyboard may be used to move focus to, but not from, a control or group of controls.
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.
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
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
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
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.
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
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 web content being 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 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 web 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
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 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 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 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
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).
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, 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.
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. ATAG 2.0 categorizes views according to whether they support editing and the way in which they present content:
  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 transformation
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, 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).
workflow
A customary sequence of steps or tasks 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 G: 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/.
[ATAG20]
"Authoring Tool Accessibility Guidelines 2.0," J. Treviranus, J. Richards, C. McCathieNevile, and M. May, eds. The latest version is available at http://www.w3.org/TR/ATAG20. The latest version of ATAG 2.0 is available at http://www.w3.org/TR/ATAG20.
[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 H: Acknowledgments

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.


[Contents] [Guidelines]