[Contents] [Guidelines]

W3C

Implementing ATAG 2.0

A guide to understanding and implementing Authoring Tool Accessibility Guidelines 2.0

W3C Editors' Draft 30 September 2011

This version:
http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110930/
Latest version:
http://www.w3.org/TR/IMPLEMENTING-ATAG20/
Previous version:
http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110902/
Editors:
Jutta Treviranus, Inclusive Design Institute, OCAD University
Jan Richards, Inclusive Design Institute, OCAD University
Jeanne Spellman, W3C
Previous Editors:
Tim Boland, NIST
Matt May (until June 2005 while at W3C)
 

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

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. The group does not expect this document to become a W3C Recommendation. 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 illustrative examples 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.

Each 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. Each of these sections contains:

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 it 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 "mock ups". These are for informative purposes only and do not imply any endorsement of similar tools and they do not imply that the mock ups 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:

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 (WCAG) 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, authoring tool developers should carefully integrate features that support accessible authoring into the same "look-and-feel" as other features of the authoring tool. Close integration has the potential to:


Implementing ATAG 2.0 Guidelines

The success criteria and the conformance 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

Part A Conformance 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 concerned with producing the "included" web content technologies. This includes views of the web content being edited and features that are independent of the content being edited (e.g., menus, button bars, status bars, user preferences, documentation).
  2. Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an accessibility problem is caused directly by the content being edited (e.g., if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
  3. Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. They do not apply to any subsequent modifications by parties other than the authoring tool developer (e.g., user modifications of default settings, third-party plug-ins).
  4. User agent features: Web-based authoring tools may rely on user agent features (e.g., keyboard navigation, find functions, display preferences, undo features) to satisfy success criteria. Conformance claims are optional, but any claim that is made must record the user agent employed during evaluation.
  5. Features provided to meet 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). The only exemption is for preview features, as long as they meet the relevant success criteria in Guideline A.3.7. Previews are treated differently than editing-views because all authors, including those with disabilities, benefit when preview features accurately reflect the functionality of user agents that are actually in use by end users.

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

Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion A.1.1.1:

The intent of this success criterion is to ensure that authoring tool user interfaces that are fully or partially 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 duplication of requirements.

Examples of Success Criterion A.1.1.1:
  • Wiki: 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 includes 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 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, following existing accessibility guidelines and implementing communication with platform accessibility services facilitates access by all authors, including those using assistive technologies.

Implementing Success Criterion A.1.2.1 Accessibility Guidelines:

Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform. (Level A)

  • Note: Conformance claims are optional, but any claim that is made must record the accessibility guideline(s) 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. Existing accessibility guidelines are referenced because:

  1. accessibility guidelines already exist for many platforms,
  2. this wording allows developers the flexibility to conform with accessibility legislation in their markets.
  3. the note that conformance claims must cite the accessibility guidelines that were followed should encourage developers to refrain from implementing obscure or weak requirements.

Note: Developers should see the documents listed in the "Related Resources for Success Criterion A.1.2.1" section. 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:
  • Mobile authoring tool: The developer of an authoring tool on the iPhone platform follows the guidance in the "Accessibility Programming Guide for iPhone OS".
Related Resources for Success Criterion A.1.2.1:

Implementing Success Criterion A.1.2.2 Platform Accessibility Services:

Non-web-based authoring tools implement communication with platform accessibility services. (Level A)

  • Note: Conformance claims are optional, but any claim that is made must record the platform accessibility service(s) implemented.
Intent of Success Criterion A.1.2.2:

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 who use assistive technologies that communicate with software via platform accessibility services. The requirement is stated generally because the specifics of what constitutes a platform accessibility service will differ on each platform.

The note that conformance claims must cite the platform accessibility service(s) implemented should encourage developers to refrain from implementing services that are not supported by assistive technologies.

Examples of Success Criterion A.1.2.2:
  • WYSIWYG editor 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. The conformance claim includes links to the Accessibility Programming Guidelines for Cocoa.
  • Content management system on Windows: Content management system on Windows: A content management system is written to operate on the Windows operating systems following Microsoft Windows' accessibility API, UI Automation, Microsoft Active Accessibility, or IAccessible 2. The conformance claim includes links to the applicable Microsoft Developer Network documents.
Related Resources for Success Criterion A.1.2.2:

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 Text Alternatives for Rendered Non-Text Content:

If an editing-view renders non-text content with programmatically associated text alternatives, then the text alternatives can be programmatically determined. (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 text alternatives for non-text content within the web content that they are editing, because this information can help authors orient and navigate as they edit.

The term "programmatically associated" is simply a reminder that text alternatives may appear within web content in ways that authoring tools are not able to detect (e.g., when the information conveyed by an image is described in an adjacent paragraph).

Examples of Success Criterion A.2.1.1:
  • WYSIWYG editing-view: A WYSIWYG editing-view renders images in the content being edited. If an image includes alternative text, this information is exposed to assistive technologies via the platform accessibility service.
Related Resources for Success Criterion A.2.1.1:

Implementing Success Criterion A.2.1.2 Alternatives for Rendered Time-Based Media:

If an editing-view renders time-based media, then at least one of the following is true: (Level A)

Intent of Success Criterion A.2.1.2:

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

There are two ways to meet this success criterion.

Option (a) is to render the alternatives in conjunction with the rendered time-based content. For example, a captioned video would have its captions displayed when it played. This approach is preferable, since it does not require authors to switch applications.

Option (b) is to instead provide authors with the option of rendering their content in a user agent that is able to render the alternatives. While this is not ideal from a usability perspective, it is necessary because alternatives are sometimes provided in different modalities that authoring tools are not equipped to render. For example, an audio editor might allow authors to edit the waveform of the audio file and render (i.e., play) the resulting audio files. However, the audio editor might not be equipped to render video, so if an audio file includes an alternative that is a sign language file in video format, the audio editor will need assistance in rendering the file.

Examples of Success Criterion A.2.1.2:
  • Web-based WYSIWYG: A web-based WYSIWYG editing-view is implemented so that videos placed into the content are rendered. If the videos include captions these are displayed, meeting (a).
  • Audio editor: An audio editor allows authors to edit audio tracks using the audio waveform. At any time, authors can play the audio file. Sometimes the audio files include a link to a video file that contains an alternative version (e.g., sign language). Although the audio editor does not include the functionality to natively render the video it provides the option to launch the video in a user agent specified by the author, meeting (b).
Related Resources for Success Criterion A.2.1.2:

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 details about the editing-view presentation, via their assistive technology, when that presentation is used to convey status information (e.g., underlining misspelled words) or provide information about how the end user will experience the web content being edited.

Implementing Success Criterion A.2.2.1 Editing-View Status Information:

If an editing-view highlights parts of the content being edited to indicate information about the content (e.g. an underline indicating a spelling error), then the information being indicated can be programmatically determined. PROPOSAL-REF modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors. (Level A)

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 status information with authors (e.g., to highlight spelling errors, identify the location of markup tags), 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 Rendered Text Properties:

If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. PROPOSAL-REF If a text property is both rendered and editable and the text property is supported by the implemented platform accessibility service, then the property is programmatically determinable. (Level A)

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 when this information is already made available to other authors by editing-views. This is important because this type of rendering acts as a type of preview to help authors understand how their content may appear to end users, once it is published. Authors who cannot see also need to understand how their web content will be experienced by end users who can see.

Note: This success criterion pertains to the rendered properties of text on the screen, even if the properties differ from the content being edited (e.g., when authors chose custom display settings as per Success Criterion A.3.6.1). In this way, the views provided on screen and via any assistive technologies can remain synchronized.

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 service. Included in the information passed to the platform accessibility service 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 then passes it on to the appropriate platform accessibility service. The user agent is cited in any conformance claim.
Related Resources for Success Criterion A.2.2.2:
  • 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 keyboard access to all of the functionality of the authoring tool.

Implementing Success Criterion A.3.1.1 Keyboard Access (Minimum):

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

  • Note 1: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
  • Note 2: This success criterion does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
Intent of Success Criterion A.3.1.1 (Based on WCAG 2.0, Success Criterion 2.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 functions that require input that depends on the path of the user's movement and not just the endpoints. This is a very narrow exception that relates to authoring web content properties that contain 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 would not be exempt. Finally, this is a Level A exception only. There is no exception for the Level AAA requirement (Success Criterion A.3.1.4).

Note 1 clarifies that the exception applies to the underlying function and that pointing device input variables, such as pressure, speed and angle, are also covered.

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

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.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). 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 pages include 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.
  • Select and operate: An authoring tool provides editing functionality in which authors can select content in the editing-view (e.g., select text) and then perform an operation (i.e., authoring action) on that selection (e.g., formatting, deletion). Keyboard access to this functionality is enabled by the fact that the selection can be made using the keyboard and that the selection is maintained while the author uses the keyboard to navigate the authoring tool user interface to arrive at the operation they want to perform.
Related Resources for Success Criterion A.3.1.1:

Implementing Success Criterion A.3.1.2 No 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 a keyboard interface, then focus can be moved away from that component using only a keyboard interface and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away; and
  • (b) In Editing-Views that Render Content: If an editing-view renders content (e.g., WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known documented PROPOSAL-REF location (e.g., the start of the editing-view).
Intent of Success Criterion A.3.1.2 (Modified from WCAG 2.0, Success Criterion 2.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 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 must 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 or be advised of the method.

The second requirement (b) applies to renderings of 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.

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, meeting (a). If authors open web content containing keyboard traps in the WYSIWYG editing-view, the authoring tool allows authors to restore keyboard focus to the top of the editing-view at any time by pressing the "Home" key, which the authoring tool never passes to the content being edited, meeting (b).
  • 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, meeting (a). If authors open 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, meeting (b). 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 Efficient Keyboard Access:

The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)

Intent of Success Criterion A.3.1.3:

The intent of this success criterion is to introduce a Level AA requirement to strengthen the requirement of Success Criterion A.3.1.1. That success criterion would be met even by a keyboard access mechanism in which users had to sequentially navigate through every available user interface component in order to reach their intended destination. This success criterion (A.3.1.3) introduces the additional requirement that keyboard access must include mechanisms to make it more efficient that this type of purely sequential keyboard access.

The wording is intentionally general because the appropriate mechanisms available for increasing the efficiency of keyboard access vary according to the operating environment and the design of the authoring tool:

  1. In desktop environments with a full keyboard, there is generally some set of keys available for developers to use as shortcut keys that directly link to particular functionality (e.g., the "ctrl" + "S" key combination can be directly mapped to the "Save" function).
  2. In web-based environments very few direct shortcut keys are available, once the potential keys used by the various operating systems, user agents and assistive technologies are taken into account. In this case, bypass links are useful mechanisms for making keyboard access more efficient.
  3. In mobile environments, the situation is variable. Some mobile environments include full, physical keyboards and support keyboard shortcuts. Other mobile environments do not enable keyboard shortcuts, but often increase keyboard navigation efficiency via recommending the use of tabs and other organizational mechanisms.
Examples of Success Criterion A.3.1.3:
  • In a desktop environment: 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 where applicable (e.g., for open document, save document, cut, copy, paste).
  • In a mobile environment: 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).
  • In a web-based environment: A web-based CMS uses links to allow authors to skip between the toolbars and directly to the content editing area.
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 without requiring specific timings for individual keystrokes. (Level AAA)

Intent of Success Criterion A.3.1.4 (Based on WCAG 2.0, Success Criterion 2.1.3):

The intent of this success criterion is to establish an enhanced requirement for keyboard access at Level AAA, 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 shortcut 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 components can be presented with any 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: An authoring tool on Windows includes a feature that allows authors to press a modifier key (e.g., the "Alt" key) to display all of the keyboard shortcuts in the current authoring tool user interface on top of the components to which they relate.
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 that require fast reaction speeds, such as clicking on a moving target.

Implementing Success Criterion A.3.2.1 Auto-Save (Minimum):

If the authoring tool includes authoring session time limits, then the authoring tool can be set to automatically save web content edits made using the authoring tool before the session time limits are reached. (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). Reducing the likelihood of lost content edits will benefit all authors, but especially authors with disabilities who may take longer to accomplish authoring tasks.

For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.

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 (Based on WCAG 2.0, Success Criterion 2.2.1):

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 Static Pointing Device Targets:

Authoring tool user interface components that accept pointing device input are either stationary or 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 automatically save web content edits made using the authoring tool. (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. Increasing the frequency with which content edits are saved also helps authors recover more easily from inadvertent actions.

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:

Editing-views that render visual time-based content can be paused and can be set to not play automatically. (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 visual time-based web content (e.g., animations) 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 Navigate By Structure:

If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g., source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)

Intent of Success Criterion A.3.4.1:

The intent of this success criterion is to help authors using keyboard interfaces to navigate more efficiently using the structure of the web content being edited.

Examples of Success Criterion A.3.4.1:
  • Source editing-view: A source editing-view supports authors by providing the ability to use keyboard shortcuts to select the current element (e.g., table row) and other keyboard shortcuts to move the focus 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 headings: 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...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.
    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: mock up 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.
  • 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 on 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 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 Programmatic Relationships:

If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships. (Level AAA)

Intent of Success Criterion A.3.4.2:

The intent of this success criterion is to help authors using keyboard interfaces to navigate more efficiently using the programmatic relationships that may exist in many types of web content.

Examples of Success Criterion A.3.4.2:
  • JavaScript editor: When a method is used, authors can navigate directly to where that method is defined.
  • HTML/CSS editor: When a style is used in content being edited, authors can navigate directly to where that style is defined, even if an external style sheet must be opened.
  • HTML editor: When an ID is used in content being edited, authors can navigate directly to where that ID is defined.
  • ARIA editor: Authors can navigate directly via ARIA relationships, such as "aria-labeledby" and "aria-describedby".
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 edited.

Implementing Success Criterion A.3.5.1 Text Search:

Editing-views enable text search, such that all of the following are true: (Level AA)

  • (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
  • (b) Match: Matching results can be made visible to authors and given focus; and
  • (c) No Match: Authors are informed when no results are found; and
  • (d) Two-way: The search can be made forwards or backwards.
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.

Examples of Success Criterion A.3.5.1:
  • Basic text search: An authoring tool provides both WYSIWYG and source editing-views. The authoring tool provides two-way 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 two-way searching for plain text sequences within textual metadata fields (e.g., title, description, author).
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: Some authors need to set their own display settings in a way that differs from the presentation that they want to define for the published web content. Providing the ability to save and reload sets of keyboard and display preference settings benefits authors who have needs that differ over time (e.g., due to fatigue).

Implementing Success Criterion A.3.6.1 Independence of Display:

If the authoring tool includes display settings for editing-views, then the authoring tool allows authors to adjust these settings without modifying the web content being edited. (Level A)

Intent of Success Criterion A.3.6.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 edited.

When "WYSIWYG authoring tools" are referred to in the examples, it is with the understanding that browsers will differ in rendering of the same content and that end users are often free to override the default presentation of web content.

Examples of Success Criterion A.3.6.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). 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.3.6.1:
  • N/A

Implementing Success Criterion A.3.6.2 Save Settings:

If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)

Intent of Success Criterion A.3.6.2:

The intent of this success criterion is to ensure that authors' preference settings for keyboard and display settings do not need to be re-entered at the beginning of each authoring session.

Examples of Success Criterion A.3.6.2:
  • 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.2:
  • N/A

Implementing Success Criterion A.3.6.3 Apply Platform Settings:

The authoring tool respects changes in platform display and control settings made by authors, unless they conflict with display and control settings of the authoring tool PROPOSAL-REF. (Level AA)

Intent of Success Criterion A.3.6.3:

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.

Examples of Success Criterion A.3.6.3:
  • 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.3:

Implementing Success Criterion A.3.6.4 Multiple Sets:

If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings then authors can save and reload multiple sets of these settings. PROPOSAL-REF (Level AAA)

Intent of Success Criterion A.3.6.4:

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.4:
  • 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.4:
  • N/A

Implementing Success Criterion A.3.6.5 Assistance with Preferences:

If the authoring tool includes display and/or control settings, then the authoring tool includes a mechanism to help authors configure these settings. (Level AAA)

PROPOSAL-REF

Intent of Success Criterion A.3.6.5:

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.5:
  • 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).
Related Resources for Success Criterion A.3.6.5:
  • 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 the same opportunity to check their work.

Implementing Success Criterion A.3.7.1 Preview (Minimum):

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

  • (a) Pre-existing User Agent: The preview renders content using a makes use of a pre-existing user agent PROPOSAL-REF that is in use by end-users; or
  • (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG].
Intent of Success Criterion A.3.7.1:

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). 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 end user experience of the content would be in a pre-existing user agent.

There are two ways to meet this success criterion:

Option (a) is to implement preview features using user agents that are already in use by end users, which is the most straightforward way to meet this success criterion. 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.

Option (b) requires that 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. At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development.

Note: Developers may create a preview feature 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.1:
  • 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, meeting (a).
  • 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, meeting (a).
  • 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, meeting (a).
  • 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", meeting (b).
Related Resources for Success Criterion A.3.7.1:

Implementing Success Criterion A.3.7.2 Preview (Enhanced):

If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)

Intent of Success Criterion A.3.7.2:

The intent of this success criterion is to provide an enhanced Level AAA requirement for preview features, in which authors have the flexibility to choose their preferred user agent for performing previews.

Examples of Success Criterion A.3.7.2:
  • Non-web-based authoring tool: A non-web-based authoring tool gives authors the option of choosing from any of the user agents installed on their computer to perform the preview.
  • Web-based authoring tool: A web-based authoring tool provides authors with a URI that can be entered into another user agent to perform the preview.
Related Resources for Success Criterion A.3.7.2:
  • N/A

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 with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors.

Implementing Success Criterion A.4.1.1 Content Changes Reversible (Minimum):

If an authoring action is not immediately reversible, then the authoring tool requires author confirmation to proceed. (Level A)

  • Note 1: Reversing actions (e.g., an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g., a "redo" function).
  • Note 2: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.
  • Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions.
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, but people with some disabilities have more difficulty creating error-free input.

Note 1 makes it clear that "undo" functions, themselves, are authoring actions that authors may need to undo.

Note 2 acknowledges that some implementations of "undo" may group text entry actions.

Note 3 makes it clear that this success criterion does not require authoring actions made in one authoring session to be reversible in subsequent authoring sessions.

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, meeting (a). 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 reversible actions. Firstly, text entry actions into text fields can be reversed using the "Undo" feature of the user agent. Secondly, "Cancel" buttons are available within the web-based authoring tool user interface that allow authors to reverse 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), meeting (a). The user agent is cited in any conformance claim.
Related Resources for Success Criterion A.4.1.1:

Implementing Success Criterion A.4.1.2 Setting Changes Reversible:

If an authoring tool setting change is not reversible, then the authoring tool requires author confirmation to proceed.PROPOSAL-REFIf actions modify authoring tool settings, then one of the following is true: (Level A)

  • (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or
  • (b) Warn and Confirm: The authoring tool provides a warning to authors that the setting change is irreversible and requires authors to confirm or save the current settings before proceeding.
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, but people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for some people with disabilities to detect that they have made an error.

Examples of Success Criterion A.4.1.2:
  • Cancel: On each preference settings page are two options, OK and Cancel. Canceling prevents the setting changes from being applied, meeting (a).
  • 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, meeting (a).
  • Restore defaults: In a preference setting utility, a "restore default settings" button is always available, meeting (a).
Related Resources for Success Criterion A.4.1.2:

Implementing Success Criterion A.4.1.3 Content Changes Reversible (Enhanced):

Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)

  • Note: The notes for A.4.1.1 still apply.
Intent of Success Criterion A.4.1.3:

The intent of this success criterion is to establish an enhanced Level AAA requirement for reversing inadvertent actions that modify the content being edited. Everyone makes mistakes, but some people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for some people with disabilities to detect and rectify errors, so it is more likely that they will benefit from the ability to reverse a series of actions once an error is discovered.

The note is a reminder that the three notes from Success Criterion A.4.1.1 also apply.

Examples of Success Criterion A.4.1.3:
  • Undo queue: An authoring tool saves author actions in a "last-in-last-out" queue.
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 of the authoring tool that must be present to meet Part A of ATAG 2.0 (e.g., keyboard shortcuts, text search) 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 note is a reminder that 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 in content
    • 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:

The authoring tool includes documentation for its author-level user interface features. (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 note is a reminder that 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 available features. The documentation conforms to WCAG 2.0 Level A.
Related Resources for Success Criterion A.4.2.2:

Implementing PART B: Support the production of accessible content

Part B Conformance Applicability Notes:

  1. Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
  2. Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g., third-party plug-ins, user-defined templates, user modifications of default settings).
  3. Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes has specifiedPROPOSAL-REF, whether it is author-generated or automatically-generated by another system that the author has specified (e.g., a third-party feed).
  4. Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any conformance claim) can be used in conjunction to meet the requirements of Part B (e.g., an authoring tool could make use of a third-party software accessibility checking tool).
  5. Features provided to meet Part B must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation).
  6. Multiple authoring roles: Some authoring tools 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 authoring role. Accessible content support features should be made available to any authoring role where it would be useful.

Implementing PRINCIPLE B.1: Fully automatic processes must produce accessible content

Implementing Guideline B.1.1: Ensure automatically specified content is accessible. [Return to Guideline]

Rationale: If authoring tools automatically specify web content that is not accessible, then additional repair tasks are imposed on authors.

Implementing Success Criterion B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):

Authors have the default option that, when web content is automatically generated for publishing after the end of an authoring session, it is accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.1.1.1:

The intent of this success criterion is to ensure that when authoring tools have been designed to generate web content that is published directly to end users without an opportunity for author action, the default option should be for that web content to be accessible.

The note acknowledges that there are automatic behaviors that may be specified by other parties, and that author actions may purposefully or inadvertently affect the accessibility of the content generated later.

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

Examples of Success Criterion B.1.1.1:
  • Email archive: An automatic email archiving system automatically creates web pages from each email message that it receives. It has been designed to generate accessible markup, but if email messages contain accessibility problems, the archiving system is not able to rectify them.
  • Social networking application: A social networking application collects some limited information from authors (e.g., name, gender, status updates), which the application uses to personalize an automatically generated web application that meets the requirements of WCAG.
Related Resources for Success Criterion B.1.1.1:

Implementing Success Criterion B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG):

Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • (a) Accessible: The content is accessible web content (WCAG) without author input; or
  • (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
  • (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking.
Intent of Success Criterion B.1.1.2:

The intent of this success criterion is to provide more flexible guidance when authors are available to assist in ensuring the accessibility of content, while also recognizing that authors often will not be able to assist if they are not made aware that web content accessibility problems do or may exist.

Note 1 highlights the fact that when an authoring tool automatically selects a template for the author to use, the authoring tool is considered to be auto-generating the content in the template.

Note 2 acknowledges that there are many ways in which the automatic behavior of authoring tools can be modified that are not under the control of the developer.

There are four ways to meet this success criterion:

Option (a) is the most straightforward. It requires the authoring tool to generate only accessible content.

Option (b) takes into account that even more access-aware authoring tools may need to query the author regarding issues that require human judgment, such as whether alternative text is suited to the context.

Option (c) takes into account that prompting during the generation process may be contrary to the workflow. Instead, the authoring tool can run a checker on the output.

Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the option of manual checking.

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

Examples of Success Criterion B.1.1.2:
  • 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) 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), meeting (a).
  • 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, meeting (b).
  • Automatic accessibility checking: An authoring tool allows images, videos and other multimedia files to be dragged into documents. When this happens, markup is automatically generated that contains accessibility problems. However, the authoring tool includes an "as-you-type" accessibility checker that unobtrusively highlights the problems for author attention, meeting (c).
  • Manual accessibility checking: An authoring tool allows images, videos and other multimedia files to be dragged into documents. When this happens, markup is automatically generated that contains accessibility problems. Since the authoring tool includes a manual checking wizard instead of an automatic checker, a message appears in a status area of the user interface stating that the author should use the wizard before publishing, meeting (d).
  • 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.1.2:

Implementing Guideline B.1.2: Ensure accessibility information is preserved. [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 Restructuring and Recoding Transformations (WCAG):

If the authoring tool provides restructuring transformations or re-coding transformations, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
  • (b) Warning: Authors have the default option to be warned that accessibility information may be lost (e.g., when saving a vector graphic into a raster image format); or
  • (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.
  • Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance.
Intent of Success Criterion B.1.2.1:

The intent of this success criterion is to encourage authoring tools to preserve accessibility information during restructuring or recoding transformations and to ensure authors are made aware when the authoring tool is unable to preserve accessibility information. This may occur when the output format does not support the same accessibility features as the input format (i.e., the example of a vector graphic being saved as a raster image format) or when an authoring tool has not implemented the necessary data mapping. There is no negative connotation intended here. In some cases, the number of source technology possibilities is simply too large to ensure complete mappings are in place for all of them.

The options available partially mirror the options for Success Criterion B.1.1.2, reflecting the similarities between automatic generation and restructuring/re-coding web content transformations:

Option (a) is the most straightforward. It requires the authoring tool to preserve accessibility information during transformations.

Option (b) is to warn the author directly that accessibility information may be lost, allowing them to decide whether or not to proceed.

Option (c) takes into account that prompting during the transformation process may be contrary to the workflow. Instead, the authoring tool can run a checker on the output.

Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the option of manual checking.

See Also: ATAG 2.0 identifies other types of transformations in which the expectation for preserving accessibility information is higher. These are optimizing transformations (Success Criterion B.1.2.2) and transformations in which non-text content is preserved (Success Criterion B.1.2.3).

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 "Save As" feature preserves accessibility information in similar data structures, meeting (a). 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 "Save As" feature preserves accessibility information in a dissimilar, but accessible way, when similar data structures are not available, meeting (a). 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) are retained as rendered text content with two-way linking.
  • Warning when text is converted to graphics): A "Save As" feature 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, there is a suggestion to retain the original text as alternative content for the graphical output, meeting (b).
  • Option to cancel: A markup editor has a feature 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 author has the option to cancel the operation, in which case the content will not be opened for editing, meeting (b).
  • Automatic accessibility checking: An authoring tool allows content to be copy-and-pasted from other applications (e.g., office applications, user agents). When this happens, the source content is recoded into the technology of the current document. While accessibility was considered in the design of the feature, web content accessibility problems may still occur. However, the authoring tool includes an "as-you-type" accessibility checker, meeting (c).
  • Manual accessibility checking: An authoring tool allows content to be copy-and-pasted from other applications (e.g., office applications, user agents). When this happens, the source content is recoded into the technology of the current document. While accessibility was considered in the design of the feature, web content accessibility problems may still occur. Since the authoring tool includes a manual checking wizard instead of an automatic checker, a message appears in a status area of the user interface stating that the author should use the wizard before publishing, meeting (d).
Related Resources for Success Criterion B.1.2.1:

Implementing Success Criterion B.1.2.2 Optimizations Preserve Accessibility:

If the authoring tool provides optimizing web content transformations then any accessibility information (WCAG) in the input is preserved in the output. (Level A).

Intent of Success Criterion B.1.2.2:

The intent of this success criterion is to ensure that web content transformations intended only to optimize content do not result in the introduction of web content accessibility problems.

Examples of Success Criterion B.1.2.2:
  • Pretty-print: A "pretty-print" tool reformats markup code to make it easier to read by programmers. The tool never makes changes to the markup tags.
  • Video compression: A tool that compresses video does not automatically delete text tracks or secondary audio tracks, since these may contain accessibility information.
Related Resources for Success Criterion B.1.2.2:

Implementing Success Criterion B.1.2.3 Text Alternatives for Non-Text Content are Preserved:

If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).

Intent of Success Criterion B.1.2.3:

The intent of this success criterion is to increase the likelihood that text alternatives will be preserved by web content transformations. This is especially important because text alternatives, such as labels and long descriptions, can represent substantial investments of author effort.

Examples of Success Criterion B.1.2.3:
  • Save as HTML: A word processor includes a "Save as Simple HTML" feature that re-codes word processor files into HTML where there is a one-to-one correspondence between elements. As a result, some word processor-specific content is lost (e.g., change tracking, footnotes). However, because of the existence of the <img> tag in HTML, images are preserved and, in order to meet this success criterion, the text alternatives associated with the image are also preserved in HTML.
Related Resources for Success Criterion B.1.2.3:

Implementing PRINCIPLE B.2: Authors must be supported in producing accessible content

Implementing Guideline B.2.1: Ensure accessible content production is possible. [Return to Guideline]

Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content (WCAG) 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.2.1.1 Accessible Content Possible (WCAG):

If the authoring tool places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.2.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 by restrictions in the actions that the authoring tool allows them to perform. The subsequent success criteria in Part B will build on this minimal requirement.

Note that the term "restricted" is not intended to have any negative connotation. Authoring tools usually restrict web content authoring in order to simplify the production of content that is in fact complex and technical. The accessibility implications of the restrictions may be positive or negative and need to be considered case by case:

Examples of unrestricted authoring:

  1. source code editor: authors can type whatever they like (e.g., <img src="..." alt="..." longdesc="..." />)
  2. WYSIWYG editor for HTML4: the "Insert Image" dialog includes all of the HTML4 attributes for <img>

Examples of restricted authoring that does not prevent WCAG 2.0 success criteria from being met:

  1. WYSIWYG editor for HTML4: the "Insert Image" dialog includes just some of the HTML4 attributes for <img>, but "alt" and "longdesc" are included in the subset.
  2. CMS: authors can only add images that they have previously uploaded to their "Asset Manager". While alt-text and long description do not appear as options when they choose images from the "Asset Manager" to include on a page, they can add/edit these values at any time within the "Asset Manager".

Examples of restricted authoring that prevents WCAG 2.0 success criteria from being met:

  1. WYSIWYG editor for HTML4: the "Insert Image" dialog has only one field "src". There is no possible way to add other attribute values, including for the "alt" and "longdesc" attributes.
  2. CMS: to be saved, each page of content must have a main title, but when the author provides text for the title it is marked up with presentation markup rather than appropriate header markup.

See Also: Unrestricted authoring tools entail less author guidance and therefore may allow the introduction of more accessibility problems than authoring tools with restrictions that encourage accessibility. ATAG 2.0 addresses this issue with other success criteria, including B.3.1.1 Checking Assistance (WCAG), which requires an accessibility checking feature.

See Also: Restrictions on authors may also be related to automatically generated content. ATAG 2.0 addresses the accessibility of automatically generated content in Guideline B.1.1: Ensure automatically specified content is accessible.

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

Examples of Success Criterion B.2.1.1:
  • Accessible workflow exists: An authoring tool is designed such that accessible web content (in this case 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
    • uses 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 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.2.1.1:

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

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

Implementing Success Criterion B.2.2.1 Accessible Option Prominence (WCAG):

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 accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.2.2.1:

The intent of this success criterion is to help ensure that accessible authoring practices are part of the default workflow of authoring tools. This requirement applies when the authoring outcome is predictable by the authoring tool. For example, a generic "insert table" command would not be applicable, despite the fact that an author might misuse it for layout, because the author might be seeking the outcome of adding tabular information. In contrast, a page layout editor is covered by the requirement because the purpose of the feature is to edit the page layout.

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

Examples of Success Criterion B.2.2.1:
  • Structural Markup: A WYSIWYG HTML editor does not include any authoring action options that will necessarily result in web content that will not meet the WCAG 2.0 Level A success criteria. For example:
    • a toolbar button that allows text to be marked as bold does so by adding a <strong> element rather than a <span> element with a bold style.
    • a the toolbar button for placing text into a bulleted list does so with list markup (<ul> and <li> elements) rather than a <span> element-based implementation.
    • a page layout view makes use of CSS positioning rather than table markup.
  • 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 positions.
    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: mock up by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.2.2.1:

Implementing Success Criterion B.2.2.2 Setting Accessibility Properties (WCAG):

If the authoring tool provides mechanisms to set web content properties (e.g., attribute values), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.2.2.2:

The intent of this success criterion is to ensure that if authoring tools provide authors with content authoring support that goes beyond source editing (e.g., property dialogs) then accessibility information that is required for the content are similarly supported. In many cases, authoring tools support a subset of all of the possible properties that technologies might offer. This success criterion requires that the subset of supported properties must include properties required for conformance to WCAG 2.0.

The note is a reminder that the mechanisms for adding accessibility information properties must have prominence that is at least comparable with the other mechanisms for other properties.

Examples of Success Criterion B.2.2.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: mock up by AUWG)
    See the example caption above for description.
  • 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.

Implementing Success Criterion B.2.2.3 Technology Decision Support:

B.4.1.X Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible content, then the authoring tool provides the authors with the option of being informed when support for the production of accessible content is not available. [Level AA] Note: This requirement concerns the presence or absence of support features such as accessibility checkers. It does not concern any intrinsic property of web content technologies. PROPOSAL-REF

 

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)

Intent of Success Criterion B.2.2.3:

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.

Requirement (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.

Requirement (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.2.3:
  • 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.2.3:
  • N/A

Implementing Guideline B.2.3: 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., inserting an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.1.

Implementing Success Criterion B.2.3.1 Alternative Content is Editable (WCAG):

Authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.2.3.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 alternative content (e.g., an "Image Properties" dialog).

Examples of Success Criterion B.2.3.1:
  • Source content editing-view: In a source 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.3.1:

Implementing Success Criterion B.2.3.2 Conditions on Automated Suggestions:

During the authoring session, the authoring tool may only automatically suggest programmatically associated text alternatives for non-text content under the following conditions: (Level A)

  • (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and
  • (b) Relevant Sources: The suggested text alternatives are 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.3.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.3.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. 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.
  • Alternative content registry: A web page authoring tool implements an alternative content registry (see also Success Criterion B.2.3.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.3.2:

Implementing Success Criterion B.2.3.3 Let User Agents Repair:

The authoring tool avoids repairing programmatically associated text alternatives for non-text content using any text value that would also be available to user agents (e.g., do not use the image filename). (Level A)

Intent of Success Criterion B.2.3.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) 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.3.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.3.3:

Implementing Success Criterion B.2.3.4 Save for Reuse:

When authors enter programmatically associated text alternatives for non-text content, both of the following are true: (Level AAA)

  • (a) Save and Suggest: the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and
  • (b) Edit Option: the author has the option to edit or delete the saved text alternatives.
Intent of Success Criterion B.2.3.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.

The editing requirement (b) allows authors to correct or remove alternatives in case of content inaccuracies (e.g., out of date, spelling errors).

Examples of Success Criterion B.2.3.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: mock up 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.3.4:

Implementing Guideline B.2.4: Assist authors with accessible templates. [Return to Guideline]

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

Implementing Success Criterion B.2.4.1 Accessible Template Options (WCAG):

If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: It is recommended that the accessible options be identified, but this is not required.
Intent of Success Criterion B.2.4.1:

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.4.1:
  • 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 (see definition of "accessible template (WCAG)").
  • 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). All of the templates are accessible.
Related Resources for Success Criterion B.2.4.1:
  • N/A

Implementing Success Criterion B.2.4.2 Identify Template Accessibility (Minimum):

If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
Intent of Success Criterion B.2.4.2:

The intent of this success criterion is to ensure that when faced with template options that differ in terms of accessibility, authors can more easily determine the accessibility status of templates prior to selecting them.

The note makes it clear that developers have flexibility with respect to implementation. If only a few inaccessible templates exist, it may be preferable to mark the inaccessible ones. If only a few accessible options exist, it may be preferable to mark those. In other cases, the accessibility of every template might be indicated.

The mechanism is not specified and might include data in dedicated metadata fields (e.g., a WCAG conformance level), plain text in a description field (e.g., "5-day week calendar template. Meets WCAG Level A"), or on-the-fly checkers, once the technology exists.

Examples of Success Criterion B.2.4.2:
  • Accessibility status as metadata: An HTML editor includes a template selection mechanism that consists of selecting templates from a list. The template list has several sortable fields that are populated from the templates' metadata: the template name, date, popularity and accessibility status. The accessibility status values are: "Level A", "Level AA", "Level AAA", "None" and "Not Available". By default, the list of templates is sorted alphabetically, but the author has the option to sort by accessibility status instead. The accessibility status values of the developer-provided templates are based on the degree to which WCAG 2.0 success criteria are met when the template is used (see definition of "accessible template (WCAG)"). This may have been assessed manually or semi-automatically with an accessibility checker.
  • Accessibility status included in template names/descriptions: In a wiki system, creating a new page brings up a list of available templates. Each template is only displayed as a name and a short description. When the developer has ensured the accessibility of a template, this is indicated by the template name (e.g., "slide show template (accessible)") and/or information in the description ("This template meets WCAG 2.0 Level A as provided and should result in an accessible page, if accessible authoring practices are followed.").
Related Resources for Success Criterion B.2.4.2:
  • N/A

Implementing Success Criterion B.2.4.3 Author-Created Templates:

If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
Intent of Success Criterion B.2.4.3:

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 identification mechanism (See Success Criterion B.2.4.2).

Examples of Success Criterion B.2.4.3:
  • 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.
  • Edit template name/description: When saving templates, an authoring tool provides authors with the ability to add their own name and description, which could potentially include accessibility status information.
Related Resources for Success Criterion B.2.4.3:

Implementing Success Criterion B.2.4.4 Identify Template Accessibility (Enhanced):

If the authoring tool provides any non-accessible templates (WCAG) options and does not include a template selection mechanism, then the non-accessible templates include accessibility warnings within the templates. (Level AAA)

Intent of Success Criterion B.2.4.4:

The intent of this success criterion is to ensure that authors using authoring tools that do not include template selection mechanisms are made aware when non-accessible template options are provided.

Examples of Success Criterion B.2.4.4:
  • Warning messages in non-accessible templates : A web page authoring tool allows templates to be opened using the standard file open mechanism of the operating system. Most of the templates are accessible, but several are not. In these cases, cautionary messages are present at the top of the non-accessible templates informing authors of the issue.
Related Resources for Success Criterion B.2.4.4:
  • N/A

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

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

Implementing Success Criterion B.2.5.1 Pre-Authored Content Selection Mechanism:

If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., 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.
Intent of Success Criterion B.2.5.1:

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

Examples of Success Criterion B.2.5.1:
  • Sort by accessibility status: A clip-art repository lists the available images and provides the alternative text associated with the images in a sortable field.
Related Resources for Success Criterion B.2.5.1:
  • N/A

Implementing Success Criterion B.2.5.2 Pre-Authored Content Accessibility Status:

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

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.4.2). This is not a requirement that all pre-authored content meet any particular accessibility level.

Examples of Success Criterion B.2.5.2:
  • 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.2:

Implementing PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content

Implementing Guideline B.3.1: 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.3.1.1 Checking Assistance (WCAG):

If the authoring tool provides authors with the ability to add or modify web content so that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.3.1.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).

The note about manual checking acknowledges 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.3.1.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.3.1.1:

Implementing Success Criterion B.3.1.2 Help Authors Decide:

For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided from the check that describe how to decide. (Level A)

Intent of Success Criterion B.3.1.2:

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.3.1.2:
  • 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.3.1.2:

Implementing Success Criterion B.3.1.3 Help Authors Locate:

For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A)

  • Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem, identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.
Intent of Success Criterion B.3.1.3:

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.

The note acknowledges that there are many ways that this success criterion may be met.

Examples of Success Criterion B.3.1.3:
  • 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 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, and other content that can cause systematic problems.
Related Resources for Success Criterion B.3.1.3:

Implementing Success Criterion B.3.1.4 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 report is not specified and they might include a listing of problems detected or a WCAG 2.0 conformance level, etc..
Intent of Success Criterion B.3.1.4:

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 note highlights 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.3.1.4:
  • 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 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.3.1.4:
  • N/A

Implementing Success Criterion B.3.1.5 Programmatic Association of Results:

Authoring tools can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

Intent of Success Criterion B.3.1.5:

The intent of this success criterion is to facilitate automated use of accessibility checking results, which can benefit both authors and end-users. This can benefit authors and end-users in at least two ways: (a) increasing the interoperability of separated checking and repair tools and (b) supporting accessible resource discovery.

Increasing the interoperability of separated checking and repair tools allows authors to choose different checking and repair tools to suit their needs and also allows separation of checking and repair within the same authoring tool. For instance, a CMS with a continuously running web site accessibility checker might automatically queue up issues to be repaired later from within a quality assurance view.

Systems that support accessible resource discovery take the accessibility preferences of end-users into account when fetching content. This allows authors to offer multiple versions of content with differing accessibility levels while still enabling end-users to receive versions that are accessible to them.

The success criterion does not specify the format of the programmatic association, which may be specific (e.g., individual check results) or more general (e.g., WCAG 2.0 conformance level). However, formats that include specific checking results are typically more useful for accessible resource discovery because individual end-users may have preferences for certain types of accessibility information (e.g., captions), but not for others (e.g., audio descriptions).

Examples of Success Criterion B.3.1.5:
  • 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 provides decision-makers with potentially useful information.
Related Resources for Success Criterion B.3.1.5:

Implementing Guideline B.3.2: 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.3.2.1 Repair Assistance (WCAG):

If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.3.2.1:

The intent of this success criterion is to ensure that authors are aided in repairing content accessibility problems that are detectable via the authoring tools own checking system.

The note allows manual repair assistance to meet this success criterion in order to acknowledge 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.3.2.1:
  • Check-as-you-type: An authoring tool includes a check-as-you-type feature 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: mock up by AUWG)
    See the example caption above for description.
  • Manual repair instructions: For each potential accessibility problem identified by the checking function (as required by Success Criterion B.3.1.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 PRINCIPLE B.4: Authoring tools must promote and integrate their accessibility features

Implementing Guideline B.4.1: Ensure the availability of features that support the production of accessible content. [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.4.1.1 Features Active by Default:

All accessible content support features are turned on by default. (Level A)

Intent of Success Criterion B.4.1.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.4.1.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: mock up by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.4.1.1:
  • N/A

Implementing Success Criterion B.4.1.2 Option to Reactivate Features:

If authors can turn off an accessible content support feature, then they can turn the feature back on. (Level A)

Intent of Success Criterion B.4.1.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.4.1.2:
  • Toggle in preferences area: A web page authoring tool provides an "Accessibility" tab in its preferences area 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.4.1.2:
  • N/A

Implementing Success Criterion B.4.1.3 Feature Deactivation Warning:

If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)

Intent of Success Criterion B.4.1.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.4.1.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: mock up by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.4.1.3:
  • N/A

Implementing Success Criterion B.4.1.4 Feature Prominence:

Accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA)

Intent of Success Criterion B.4.1.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.4.1.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: mock up by AUWG)
    See the example caption above for description.
  • Check-as-you-type: An authoring tool continuously checks the web content being edited and highlights problems as the authors work.
    Figure: A WYSIWYG 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: mock up 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.4.1.4:

Implementing Guideline B.4.2: Ensure that documentation promotes the production of accessible content. [Return to Guideline]

Rationale: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use the accessibility checking tool). Demonstrating accessible authoring as routine practice or at least not demonstrating inaccessible practices will help to encourage acceptance of accessibility by some authors. PROPOSAL-REFWithout 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. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.

Implementing Success Criterion B.4.2.1 Model Practice (WCAG):

A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Intent of Success Criterion B.4.2.1:

The intent of this success criterion is to have accessible authoring practices introduced to authors as naturally integrated common practice. The success criterion is also intended to reduce the chance that authors will copy inaccessible authoring practices from examples in the documentation. Essentially, modelling inaccessible authoring practices in the documentation should be viewed in the same way as modelling invalid markup or spelling/grammar errors.

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

Examples of Success Criterion B.4.2.1:
  • Reference examples are accessible: An HTML authoring tool includes an on-line HTML reference guide. Markup examples within the reference guide are all valid code and they all meet the WCAG 2.0 Level A success criteria.
  • Screen shots show accessibility features in use: A content management system has a help system that includes screen shots of various aspects of the system's user interface. When screen shots show examples of the user interfaces as content is being produced, the user interface is always shown such that the content produced would meet the WCAG 2.0 Level A success criteria (e.g., prompts filled in, optional accessibility features turned on).
Related Resources for Success Criterion B.4.2.1:

Implementing Success Criterion B.4.2.2 Feature Instructions:

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

Intent of Success Criterion B.4.2.2:

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.4.2.2:
  • 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: mock up by AUWG)
    See the example caption above for description.
Related Resources for Success Criterion B.4.2.2:
  • N/A

Implementing Success Criterion B.4.2.3 Tutorial:

A tutorial on an accessible authoring process that is specific to the authoring tool is provided. (Level AAA)

Intent of Success Criterion B.4.2.3:

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.4.2.3:
  • 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). 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.4.2.3:

Implementing Success Criterion B.4.2.4 Instruction Index:

The documentation contains an index to the instructions for using the accessible content support features. (Level AAA)

Intent of Success Criterion B.4.2.4:

The intent is to help authors discover instructions related to features provided to support the authoring of accessible web content.

Examples of Success Criterion B.4.2.4:
  • Help chapter: An authoring tool includes documentation of its accessible content support features (needed to meet Success Criterion B.4.2.2). This documentation appears in a chapter of the documentation on accessibility. The documentation is also available via other mechanisms, including context sensitive help from the features themselves and from a help search function.
  • Help index: An authoring tool includes documentation of its accessible content support features (needed to meet Success Criterion B.4.2.2). This documentation is spread throughout the other documentation topics as applicable. In addition, there is a help topic on accessible authoring that includes links to the various pieces of distributed documentation. The documentation is also available via other mechanisms, including context sensitive help from the features themselves and from a help search function.
Related Resources for Success Criterion B.4.2.4:
  • N/A

 


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 applicable success criteria defined in the guidelines section. This conformance section describes conformance and lists the conformance requirements.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

Because WCAG 2.0 [WCAG20] is the most recent W3C Recommendation regarding web content accessibility, ATAG 2.0 frequently refers to WCAG 2.0 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 toward producing web content that is accessible to end users with disabilities (in Part B).

Whenever success criteria or defined terms in ATAG 2.0 depend on WCAG 2.0, they are marked with "(WCAG)".

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

Part of conformance to WCAG 2.0 is the requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 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). Therefore:

ATAG 2.0 does not include the accessibility-supported requirement. As a result, ATAG 2.0 success criteria do not refer to WCAG 2.0 "conformance", but instead refer to "meeting WCAG 2.0 success criteria".

Once an authoring tool has been installed and put into use, it would be possible to assess the WCAG 2.0 conformance of the web content that the authoring tool produces, including whether the WCAG 2.0 accessibility-supported requirement is met. However, this WCAG 2.0 conformance assessment would be completely independent of the authoring tool's conformance with ATAG 2.0.

Applicability of Success Criteria

The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g., a photo editor, a CSS editor, a status update field in a social networking application), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s) (e.g., Success Criterion B.1.1.1 applies only to authoring tools that automatically generate web content after the end of authoring sessions).

If a conformance claim is made, a declaration that a success criterion is not applicable requires a rationale.

Conformance Requirements

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

Conformance Levels:

Authoring tools may conform "fully" or "partially" to ATAG 2.0. In either case, the level of conformance depends on the level of the success criteria that have been satisfied.

"Full" ATAG 2.0 Conformance: This type of conformance is intended to be used when developers have considered the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible) and the perspective of end users of web content produced by the authoring tools (Part B: Support the production of accessible content):

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

And the Part A Conformance Applicability Notes and Part B Conformance Applicability Notes have been applied.

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

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

And the Part A Conformance Applicability Notes have been applied.

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

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

And the Part B Conformance Applicability Notes have been applied.

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

Web Content Technologies Produced:

Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g., Full Level A conformance with respect to the production of XHTML 1.0, Partial Level AA Conformance: Content Production with respect to the production of SVG 1.1).

If an authoring tool is capable of producing multiple web content technologies, then the conformance may include only a subset of these technologies as long as the subset includes any technologies that the developer either sets for automatically-generated content or sets as the default for author-generated content. The subset may include "interim" formats that are not intended for publishing to end users, but this is not required.

When Success Criterion B.2.1.1 refers to web content technologies for which the authoring tool provides support for the production of accessible content, it is referring to this subset.

Live publishing authoring tools:

ATAG 2.0 may be applied to authoring tools with workflows that involve live authoring of web content (e.g., some collaborative tools). Due to the challenges inherent in real-time publishing, conformance to Part B of ATAG 2.0 for these authoring tools may involve some combination of support before (e.g., support in preparing accessible slides), during (e.g., live captioning as WCAG 2.0 requires at Level AA) and after the live authoring session (e.g., the ability to add a transcript to the archive of a presentation that was initially published in real-time). For more information, see the Implementing ATAG 2.0 - Appendix E: Authoring Tools for Live Web Content.

Conformance Claims (Optional)

If a conformance claim is made, then the conformance claim must meet the following conditions and include the following information (authoring tools can conform to ATAG 2.0 without making a claim). Claimants are encouraged to claim conformance to the most recent version of the Authoring Tool Accessibility Guidelines Recommendation.

Conditions on Conformance Claims

  1. At least one version of the conformance claim must be published on the web as a document meeting Level A of WCAG 2.0. A suggested metadata description for this document is "ATAG 2.0 Conformance Claim".
  2. Whenever the claimed conformance level is published (e.g., 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 are solely responsible for the accuracy of their claims and keeping claims up to date.

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 Toward Conformance" Statement

Developers of authoring tools that do not yet conform fully to a particular ATAG 2.0 conformance level are encouraged to publish a statement on progress toward conformance. This statement would be the same as a conformance claim except that this statement would specify an ATAG 2.0 conformance level that is being progressed toward, rather than one already satisfied, and report the progress on success criteria not yet met. The author of a "Progress Toward Conformance" Statement is solely responsible for the accuracy of their statement. Developers are encouraged to provide expected timelines for meeting outstanding success criteria within the Statement.

Disclaimer

Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim that has not been published under the authority of the W3C, WAI, or AUWG.


Appendix A: 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, and 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 unobtrusive 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: mock up by AUWG)
See the example caption above for description.

Example A-1b: A source 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: mock up 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: mock up 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: mock up by AUWG)
See the example caption above for description.

(4): Form component 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, component 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: mock up 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):

Example A-7: A source editing-view that suggests accesskey 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: mock up 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: mock up by AUWG)
See the example caption above for description.

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

(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, h3, h4, h5, h6) 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: mock up 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: mock up by AUWG)
See the example caption above for description.

(13): Style sheets:

(14): Clearly written text:

Example A-14a: A source 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: mock up 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: mock up 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: mock up 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: mock up 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: mock up 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: mock up 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: mock up 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: mock up 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 repair, 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: mock up by AUWG)
See the example caption above for description.

(b) Semi-Automated:

In semi-automated repair, 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: mock up by AUWG)
See the example caption above for description.

(c) Automated:

In automated repair, 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: mock up 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: mock up 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: mock up 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: mock up by AUWG)
See the example caption above for description.

 

Appendix E: Authoring Tools for Live Web Content

This section is informative.

Supporting the production of live web content that is also accessible is a challenge. The immediate and continuous time pressures will limit what can reasonably expect from authors. However, there are potential approaches that developers may take to increase the accessibility of the live content produced by their authoring tools:

(a) Determine Participant Requirements: Sometimes it may be possible to determine beforehand the accessibility requirements of the end-user audience. In other cases, polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or matching participant profiles might help determine which types of accessibility practices would offer the greatest advantage in the short time available. However, usually it is impossible to know all of the needs of the actual or potential participants.

(b) Assistant/Peer Author: Consider designating one or more secondary authors, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author(s) might be an unrelated specialist, analogous to a sign language interpreter, a co-author, or in some situations a member of the session audience (e.g., peer descriptions).

(c) Preparation Time: Consider allowing authors time to pre-assemble materials for a live presentation (e.g., a professor preparing for an online class).

(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 live session has ended, but prior to archiving.

Example E-1: A live 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: mock up 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 problems
ATAG 2.0 recognizes two types of accessibility problems:
  • authoring tool user interface accessibility problems: Aspects of an authoring tool user interface that does not meet a success criterion in Part A of ATAG 2.0.
  • web content accessibility problems (WCAG): Aspects of web content that does not meet a WCAG 2.0 success criterion (Level A, AA or AAA).
accessibility information (WCAG)
Any information that web content must contain in order to meet a WCAG 2.0 success criterion (Level A, AA or AAA). Examples include: programmatically associated alternative content (e.g., text alternatives for images), role and state information for widgets, relationships within complex tables).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the accessibility of the web content being edited. These are features that must be present to meet the success criteria in Part B of ATAG 2.0.
alternative content
Web content that is used in place of other content that some people are not able to access. Alternative content fulfills essentially the same function or purpose as the original content. WCAG 2.0 recognizes several general types of alternative content (for more information see WCAG 2.0):
  • text alternatives for non-text content: Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. For example, an image of a chart might have two text alternatives: a description in the paragraph after the chart and a short text alternative for the chart indicating in words that a description follows.
  • alternatives for time-based media: Web content that serves the same function or purpose as one or more tracks in a time based media presentation. This includes: captions, audio descriptions, extended audio descriptions, sign language interpretation as well as correctly sequenced text descriptions of time-based visual and auditory information that also is capable of achieving the outcomes of any interactivity in the time-based presentation.
  • media alternative for text: Media that presents no more information than is already presented in text (directly or via text alternatives). A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.
Importantly, from the perspective of authoring tools, alternative content may or may not be:
  • programmatically associated: Alternative content whose location and purpose can be programmatically determined from the original content for which it is serving as an alternative. For example, a paragraph might serve as a text alternative for an image, but it is only programmatically associated if this relationship is properly encoded (e.g., by "aria-labeledby").
Note: ATAG 2.0 typically refers to programmatically associated alternative content.
ASCII art
A picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
assistive technology
Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of users with disabilities. Some authoring tools may also provide direct accessibility features. Examples include:
  • screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order improve the visual readability of rendered text and images;
  • screen readers, which are used by people who are blind to read textual information through synthesized speech or Braille;
  • text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
  • speech recognition software, which may be used by people who have some physical disabilities;
  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices);
  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
audio
The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real-world sounds, or both.
author actions preventing generation of accessible web content
When the actions of authors prevents authoring tools from generating accessible web content (WCAG). Examples include: turning off accessibility options, ignoring prompts for accessibility information (WCAG), providing faulty accessibility information (WCAG) at prompts, modifying the authoring tool (e.g., via scripting, macros), and installing plug-ins.
authors
People who use authoring tools to create or modify web content. The term may cover roles such as content authors, designers, programmers, publishers, testers, etc. (see also Part B Conformance Applicability Note 6: Multiple authoring roles). Some authoring tools control who may be an author by managing author permissions.
author permission
Authorization that allows modification of given web content.
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., saving, publishing, 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. Authoring practices may or may not be:
authoring session
A state of the authoring tool in which web content can be edited by an author.
  • end of an authoring session: 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 web-based or non-web-based application(s) software (or collection of software components) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).
Note 1: "application(s)": ATAG 2.0 may be conformed to by stand-alone applications or by collections of applications. If a conformance claim is made, then the claim must provide identifying information for each application and also for any required extensions, plug-ins, etc. PROPOSAL-REF "collection of software components": Multiple applications, plug-ins, etc. can be used together to meet ATAG 2.0 (see also note in the "Required Components of an ATAG 2.0 Conformance Claim").
Note 2: "alone or collaboratively":
Multiple authors may contribute to the creation of web content and, depending on the authoring tool, each author may work with different views of the content and different author permissions.
Note 3: "to create or modify web content":
This clause rules out software that collects data from a person for other purposes (e.g., online grocery order form) and then creates web content from that data (e.g., a web-based warehouse order) without informing the person (however, WCAG 2.0 would still apply). This clause also rules out software used to create content exclusively in non-web content technologies.
Note 4: "for use by other people":
This clause rules out the many web applications that allow people to modify web content that only they themselves experience (e.g., web-based email display settings) or that only provide input to automated processes (e.g., library catalog search page).
Examples of software that are generally considered authoring tools under ATAG 2.0:
  • web page authoring tools (e.g., WYSIWYG HTML editors)
  • software for directly editing source code
  • software for converting to web content technologies (e.g., "Save as HTML" features in office document applications)
  • 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 using web content technologies
  • multimedia authoring tools
  • software for creating mobile web applications
Examples of software that are not considered authoring tools under ATAG 2.0 (in all cases, WCAG 2.0 still applies if the software is web-based):
  • customizable personal portals: ATAG 2.0 does not apply because the web content being edited is only available to the owner of the portal
  • e-commerce order forms: ATAG 2.0 does not apply because the purpose of an e-commerce order form is to order a product, not communicate with other people via web content, even if the data collected by the form actually does result in web content (e.g., online tracking pages)
  • stand-alone accessibility checkers: ATAG 2.0 does not apply because a stand-alone accessibility checker with no automated or semi-automated repair functionality does not actually modify web content. An accessibility checker with repair functionality or that is considered as part of a larger authoring process would be considered an authoring tool.
authoring tool user interface
The display and control mechanism that authors use to operate the authoring tool software. User interfaces may be non-web-based or web-based or a combination (e.g., a non-web-based authoring tool might have web-based help pages):
  • authoring tool user interface (non-web-based): Any parts of an authoring tool user interface that are not implemented as web content and instead run directly on a platform that is not a user agent (e.g., Windows, Mac OS, Java Virtual Machine).
  • authoring tool user interface (web-based): Any parts of an authoring tool user interface that are implemented using web content technologies and are accessed by authors via a user agent.
Authoring tool user interfaces may or may not be:
  • accessible authoring tool user interfaces: Authoring tool user interfaces that meet the success criteria of a level in Part A of ATAG 2.0.
checking, accessibility
The process by which web content is evaluated for web content accessibility problems (WCAG). ATAG 2.0 recognizes three types of checking, based on increasing levels of automation of the tests:
  • manual checking: Checking in which the tests are carried out by authors. This includes the case where authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure.
  • semi-automated checking: Checking in which 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.
  • automated checking: Checking in which 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. Content may or may not be:
content properties
The individual pieces of information that make up the web content (e.g., the attributes and contents of elements, stylesheet information).
content (structured)
Web 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.
content generation (content authoring, content editing)
The act of specifying the web content to be rendered, played or executed by user agents (also may be referred to as "content authoring" or "content editing"). This may refer to information perceived by end users or to instructions for the user agents. Content may be author generated or automatically generated: In some cases, responsibility for content generation is shared. For example, an author requests an interactive object be placed on their page (e.g., 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. ATAG 2.0 recognizes several types of content renderings:
  • conventional renderings (or "WYSIWYG"): When content is rendered in a way that is similar to the default rendering a user agent would create from the same content. While "WYSIWYG", standing for "What-you-see-is-what-you-get" is the common term, differences between user agents and end user settings mean that in reality there is no single typical end user experience; or
  • unconventional renderings: When content is rendered differently than it would be in a typical user agent (e.g., rendering an audio file as a graphical wavefront); or
  • partial renderings: When 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).
content transformations
Processes that take content in one web content technology or non-web content technology (e.g., a word processing format) as input and produce content that has been either:
  • optimized: e.g., removing whitespace, re-compressing images; or
  • restructured: e.g., linearizing tables, splitting a document into pages; or
  • re-coded: e.g., HTML to XHTML, a word processing format to HTML.
control settings
Settings that relate to how authors operate 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
Settings that relate to how authors perceive the authoring tool. These include:
  • audio display settings: the characteristics of audio output of music, sounds and speech. Examples include volume, speech voices, voice speed, and voice emphasis.
  • visual display settings: the characteristics of the on-screen rendering of text and graphics. Examples include fonts, sizes, colors, spacing, positioning, and contrast.
  • tactile display settings: 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 by a non-web based authoring tool or user agent. The document object may form part of a platform accessibility service that enables communication with assistive technologies. Web-based authoring tools are considered to make use of the document object that is maintained by the user agent.
element
A pair of markup tags and its content, or an "empty tag" (one that requires no closing tag or content).
end user
A person who interacts with web content once it has been authored. This includes people using assistive technologies.
human language
Language that is spoken, written or signed (through visual or tactile means) to communicate with humans.
informative
For information purposes and not required for conformance.
keyboard interface
An interface used by software to obtain keystroke input. A keyboard interface can allows keystroke input even if particular devices do not contain a conventional keyboard (e.g., a touch screen 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 a keyboard interface may be used to move focus to, but not from, a user interface component or group of components.
label
Text or other component with a text alternative that is presented to users to identify a component. A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
live
Information captured from a real-world event that is published with no more than a broadcast delay.
Note: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.
markup language
A system of text annotations (e.g., 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.
  • markup of some content is the set of annotations that appear in the content.
name
Text by which software can identify a user interface component to the author or end 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 programmatically determined or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text.
normative
Required for conformance. One may conform in a variety of well-defined ways to ATAG 2.0. Content identified as "informative" or "non-normative" is never required for conformance.
option
When an author is presented with choices.
  • default option: A setting or value for an option that is assigned automatically by the authoring tool and remains in effect unless canceled or changed by the author.
platform
The software environment within which the authoring tool operates. Platforms provide a consistent operational environment on top of lower level software platforms or hardware. For web-based authoring user interfaces, the most relevant platform will be a user agent (e.g., browser). For non-web-based user interfaces, the range of platforms includes, but may not be limited to, desktop operating systems (e.g., GNOME desktop on Linux, Mac OS, Windows), mobile operating systems (e.g., Android, BlackBerry, iOS, Windows Phone), or cross-OS environments (e.g., Java), etc..
Note 1: Many platforms mediate communication between applications operating on the platform and assistive technology via a platform accessibility service.
Note 2: Accessibility guidelines for developers exist for many platforms.
platform accessibility service
A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g., MSAA, IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OS X applications, GNOME Accessibility Toolkit API for GNOME applications, Java Access for Java applications). 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)
Information that is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. ATAG 2.0 uses this term in two contexts:
  • Processing content: Whether the authoring tool is able to extract information from the web content (e.g., to extract the language of content from the markup).
  • Communication between the authoring tool and assistive technology: For non-web-based user interfaces, this means making use of platform accessibility services, APIs, and, in some cases, document object models. For web-based user interfaces, this means ensuring that the user agent can pass on the information (e.g., through the use of ARIA).
    Note: All of the success criteria requiring programmatic determinability via a platform accessibility service are all contingent on whether a platform accessibility service is present for the platform and whether the platform accessibility service is capable of supporting the required communication.PROPOSAL-REF
prominence
A heuristic measure of how likely users are to notice a user interface component in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g., size, spacing, color), and even the modality of use (e.g., mouse vs. keyboard use).
  • at least as prominent: For ATAG 2.0, a user interface component A is considered to be "at least as prominent" as another component B when, from a default state, component A becomes displayed (and enabled) with the same number or less "opening" actions than are required for component B to become displayed (and enabled).
    Note 1: When a container is open, all of the enabled components in the container (e.g., items in a list, items in a menu, buttons in a toolbar, all components on a dialog box) are considered to be displayed (and therefore are at least as prominent as each other), even if the container must be scrolled for them to become visible. This takes into account that different screen sizes and author settings will affect which components are visible at a given time.
    Note 2: "Opening actions" are actions made by authors on components within the user interface that result in new components becoming displayed or enabled. For example: (a) keyboard shortcut to a top-level menu item to display a sub-menu, (b) keyboard selection on a button to display a dialog box, (c) mouse click on a checkbox to enable previously disabled sub-items, etc.. Actions that do not cause new components to become actionable (e.g., moving focus, scrolling a list), are not counted as "opening actions".
    Note 3: Keyboard shortcuts to components in closed containers are not counted as "opening actions" because the components have no prominence when they are not displayed. The same is true when authors must use "search" to reveal components in closed containers.
    Note 4: The "default state" is the state of the authoring tool at the beginning of an authoring session as set by the developer. The default state of many document authoring tools is an editing-view.
prompt
Any authoring tool initiated request for a decision or piece of information from authors. The term covers requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word). Well designed prompting will urge, suggest, and encourage authors.PROPOSAL-REF
publishing
Any 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, live streaming).
range
More than one item within a multi-item set.
Informative Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g., the set of all help documentation examples, the set of all templates). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.
relationships
Meaningful associations between distinct pieces of content.
repair (accessibility)
The process by which web content accessibility problems that have been identified within web content are resolved. ATAG 2.0 recognizes three types of repair, based on increasing levels of automation:
  • manual repair: Where the repairs are carried out by authors. This includes the case where authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
  • semi-automated repair: Where the repairs are partially carried out by the authoring tool, but where authors' input or judgment is still required to complete the repair; and
  • automated repair: Where the repairs are carried out automatically by the authoring tool without any intervention by authors.
restrictions, restricted web content authoring
When the web content that authors can specify with an authoring tool either must include or must not include certain content (e.g., elements, attributes, widgets). Many authoring tools restrict authoring in some way, which can either benefit accessibility (e.g., if text alternatives for non-text content are required) or detract from accessibility (e.g., if attributes for defining text alternatives are not available). In contrast, authoring tools that allow unrestricted web content authoring do not require any particular content to be included or not included (e.g., many source editing-views).
reversible actions
Authoring actions that, by their nature, can be completely undone so that the system returns to the state it was in before the action. The opposite of reversible actions are:
  • irreversible actions non-reversible:PROPOSAL-REF 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).
sequential keyboard access
Using a keyboard interface to navigate the focus one-by-one through all of the items in an ordered set (e.g., menu items, form fields) until the desired item is reached and activated. This is in contrast to direct keyboard access methods such as keyboard shortcuts and the use of bypass links.
technology (web content)
A mechanism for encoding instructions to be rendered, played or executed by user agents. Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static web pages to multimedia presentations to dynamic web applications. Some common examples of web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, Silverlight, Flex and JavaScript.
templates
Content patterns that are 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.
  • accessible templates (WCAG): Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true:
    1. The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and
    2. No further authoring occurs
    Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.
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:
  • editing-views: View in which some or all of the content is editable; or
  • previews: Views in which none of the content is editable. Often the purpose is to present content as it would to appear to end-users of user agent. In these cases, previews may be implemented using existing user agents or they may only attempt to emulate some functionality user agent functionality.
ATAG 2.0 also recognizes several approaches to presenting the content in a view:
workflow
A customary sequence of steps or tasks that authors follow to produce a content deliverable. If an authoring tool is composed of a collection of software components, then its workflows may include use of one or more of the components.

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

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

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


[Contents] [Guidelines]