[Contents] [Guidelines]

W3C

Implementing ATAG 2.0

A guide to understanding and implementing Authoring Tool Accessibility Guidelines 2.0

W3C Editors' Draft 20 February 2013

This version:
http://www.w3.org/WAI/AU/2013/ED-IMPLEMENTING-ATAG20-20130220/
Latest version:
http://www.w3.org/TR/IMPLEMENTING-ATAG20/
Previous version:
http://www.w3.org/WAI/AU/2012/ED-IMPLEMENTING-ATAG20-20120716/
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

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 more 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 more accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an authoring tool user interface 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(s).
  5. Accessibility of features provided to meet Part A: 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.
  6. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup).

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

If the authoring tool contains web-based user interfaces, then those web-based 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 more 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.

Note: Even when a web-based user interface has met the requirements of WCAG 2.0, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the end-user's user agent, platform, and assistive technology (if any). It is recommended, therefore, that developers of web-based authoring tools be familiar with the accessibility guidance that the User Agent Accessibility Guidelines (UAAG) provides to the developers of user agents. At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development.

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

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A)

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 more accessible to authors with disabilities. Existing platform accessibility guidelines are referenced because accessibility guidelines already exist for many platforms and this wording allows developers the flexibility to conform with accessibility legislation in their markets.

The note regarding documenting the guidelines that were followed in the conformance claim should encourage developers to follow the appropriate guidelines.

Note 1: Developers should see the documents listed in the "Related Resources for Success Criterion A.1.2.1" section. Unless special 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. Several general software accessibility guidelines are also referenced. It is acceptable to follow one of these sources of general guidance, and in most cases, the techniques for implementing the general guidance on a platform will entail following the same platform accessibility guidelines.

Note 2: Even when a non-web-based user interface has followed the relevant user interface accessibility guidelines for the platform, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any).

Examples of Success Criterion A.1.2.1:
  • Mobile authoring tool: The developer of an authoring tool app for the iPhone platform follows the guidance provided 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:

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. (Level A)

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 more 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 regarding documenting the platform accessibility service(s) that were implemented in the conformance claim should encourage developers to implement services that are well supported by assistive technologies.

Note: Even when a non-web-based user interface has been designed to expose accessibility information through platform accessibility services, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any).

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 IAccessible2. 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, then any programmatically associated text alternatives for the non-text content 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 used to take into account that text alternatives may sometimes 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 without the relationship appearing in the markup).

Examples of Success Criterion A.2.1.1:
  • Non-web-based editor: If an image in the content being edited includes alternative text, this is exposed to assistive technologies via the platform accessibility service.
  • Web-based editor: If an image in the content being edited includes alternative text, this is included in the markup of the editing-view, so that the alternative text will be made available to the user agent.
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)

  • (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or
  • (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives.
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 media 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 within the authoring tool's editing-view. 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 messages (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 Indicators:

If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined. (Level A)

  • Note: Status indicators may indicate errors (e.g., spelling errors), tracked changes, hidden elements, or other information.
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 messages to authors, then authors with disabilities will have the same access to the status messages as other authors.

The note provides some examples of status indicators that are relatively common in authoring tools. For example, many WYSIWYG editors include an option to display an icon to indicate the location of anchor tags and comments, both of which would otherwise be hidden from view. Another common status indicator is underlining spelling errors in red.

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. (Level AA)

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 would be 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 interface 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: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard.
  • Note 2: 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 3: This success criterion does not forbid and should not discourage other input methods (e.g., mouse, touch) 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 success criterion does not require a hardware keyboard to be present. Many mobile platforms lack hardware keyboards, but nonetheless provide "keyboard interfaces".

Note 2 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 3 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.
  • Touchscreen: An authoring tool designed to be used on a touchscreen-equipped device based
Related Resources for Success Criterion A.3.1.1:

Implementing Success Criterion A.3.1.2 No Keyboard Traps:

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, authors are advised of the method for moving focus away. (Level A)

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.

The case of keyboard traps in rendered content within an editing-view (e.g., WYSIWYG) is the more challenging because authors may open content for editing that violate the WCAG 2.0 requirement against keyboard traps in content. The success criterion requires authoring tools to handle these cases.

Examples of Success Criterion A.3.1.2:
  • Non-web-based authoring tool: A non-web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open web content containing keyboard traps for editing 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.
  • Web-based authoring tool: A web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open content containing keyboard traps, the authoring tool relies on a feature in the authors' user agent that always restores keyboard focus to the address bar. The user agent would be 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 WAI-ARIA landmarks (e.g., banner, main, navigation, search) to allow authors to navigate more quickly.
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:

If the authoring tool includes keyboard commands, then those keyboard commands 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 on platforms that support keyboard commands have the ability to remap the authoring tool's default keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g., for one-handed use).

This success criterion only applies to keyboard commands provided by the authoring tool, not keyboard commands provided by the platform on which the authoring tool is based.

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:

If the authoring tool includes keyboard commands,

then the authoring tool provides a way for authors to determine the keyboard commands associated with authoring tool user interface components. (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 on platforms that support keyboard commands 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 Input Components:

If authoring tool user interface components accept input and move, then authors can pause the movement. (Level A)

Intent of Success Criterion A.3.2.3:

The intent of this success criterion is to ensure that authors are not prevented from using the authoring tool by a requirement for either fast reactions (i.e., to click on an object in motion) or the ability to track movement.

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:

If the authoring tool contains editing-views that render and play visual time-based content automatically, then those editing-views 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 navigating 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 in cases where that structure is already exposed to the author.

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> elements) and any content, such as text or images, 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 effect 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. (Level AAA)

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

If the authoring tool provides an editing-view of text-based content, then the editing-view enables 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 presented 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, and author fields).
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 style sheet 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 would be 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, unless authors select more specific display and control settings using the authoring tool. (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 unless the author has specifically selected different settings at the level of the authoring tool. 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 configurations of settings. (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 Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents. [Return to Guideline]

Rationale: Preview features are provided by 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) In-Market User Agent: The preview renders content using a user agent that is in-market; 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 a more 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) used in the market. 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 an in-market 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 an in-market user agent widget nested within the authoring tool's own user interface. The user agent would be cited in any conformance claim.

Option (b) requires that, if a preview is being developed that is already a departure from existing in-market 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):

All authoring actions are either reversible or the authoring tool requires author confirmation to proceed. (Level A)

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.

Examples of Success Criterion A.4.1.1:
  • Non-web-based authoring tool: An authoring tool has an "Undo" action under the "Edit" menu. Activating the "Undo" action reverses the previous authoring action. Activating "Undo" again undoes the previous authoring action and so on.
  • Web-based content management system: A web-based content management system supports two types of reversible actions. Firstly, text entry actions in text fields can be reversed using the "Undo" feature of the user agent. Secondly, "Cancel" buttons are available 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). The user agent would be cited in any conformance claim.
Related Resources for Success Criterion A.4.1.1:

Implementing Success Criterion A.4.1.2 Settings Change Confirmation:

If the authoring tool provides mechanisms for changing authoring tool user interface settings, then those mechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (Level A)

Intent of Success Criterion A.4.1.2:

The intent of this success criterion is to help authors with disabilities avoid making the authoring tool unusable to them as the result of making a mistake while installing the program or modifying preference settings. The success criterion, therefore, requires that mechanisms for changing settings can also be used by authors to return the settings to their original values or, if the setting is not reversible with the same mechanism, the author will have had to confirm the setting. 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:
  • All reversible: All of the preference setting changes in an authoring tool can be reversed by revisiting the preference setting utility and adjusting the settings.
  • Restore defaults: In a preference setting utility, a "restore default settings" button is always available.
  • Upgrade confirmation: An authoring tool has a setting that allows the author to upgrade to the newest version free of charge. However, once the upgrade is made it will not be possible to reverse and the installer for the previous version is no longer available. When the author selects the setting, they receive a warning that the upgrade will not be reversible and they must confirm that they wish to upgrade.
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)

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

Implementing Success Criterion A.4.2.1 Describe Accessibility Features:

For each authoring tool feature that is used to meet Part A of ATAG 2.0, at least one of the following is true: (Level A)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
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 descriptions of how to use the features. These descriptions can be provided in the documentation or user interface of the authoring tool or by the underlying platform, if the feature is in fact a service of that platform.

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:

For each authoring tool feature, at least one of the following is true: (Level AA)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
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 find descriptions of the authoring tool's features. These descriptions can be provided in the documentation or user interface of the authoring tool or by the underlying platform, if the feature is in fact a service of that platform.

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 web content accessibility (WCAG) 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, 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. Accessibility of features provided to meet Part B: 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.
  7. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup).

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 produce web content that includes accessibility problems (WCAG), then this will impose additional repair tasks on authors.

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

If the authoring tool provides the functionality for automatically generating web content after the end of an authoring session, authors can specify that the content be 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 (WCAG).

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

If the authoring tool provides the functionality for automatically generating web content during an authoring session, 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) 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 developer guidance in cases where authors are available to assist in increasing the accessibility of content. The guidance recognizes that authors may often 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 (WCAG) is critical to maintaining comparable levels of web content accessibility (WCAG) 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, and if equivalent mechanisms exist in the web content technology of the output, 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 (WCAG) 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.
Intent of Success Criterion B.1.2.1:

The intent of this success criterion is to encourage authoring tools to preserve accessibility information (WCAG) 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.3) and transformations in which non-text content is preserved (Success Criterion B.1.2.4).

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 imported from another format. 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 imported from another format. 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 Copy-Paste Inside Authoring Tool (WCAG):

If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology. (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.2.2:

The intent of this success criterion is to encourage authoring tools to preserve accessibility information during copy-paste operations. Due to differences in how data is encoded by different applications and the differences between clipboard mechanisms on various platforms, the wording is limited to the case in which both the copy and paste sides of the operation are performed by the same authoring tool. The wording also excludes cases in which documents

However, on platforms with clipboard mechanisms that support structured web content, as many do, it is likely that implementation of this success criterion by multiple authoring tools will also increase the probability of accessibility information being preserved during copy-paste operations between different authoring tools.

The wording of the success criterion does not require that all structured content be preserved, as this can sometimes raise security issues, especially when the copy source is another site.

Examples of Success Criterion B.1.2.2:
  • Plain text clipboard format: A WYSIWYG HTML authoring tool is running on a platform that only provides a plain text clipboard. On copy, the authoring tool places markup, including any textual accessibility information, directly into clipboard as a block of text. On paste, the text is then parsed and placed back into the document, including any accessibility information, and rendered for the author.
  • HTML clipboard format: A WYSIWYG HTML authoring tool is running on a platform that provides an HTML clipboard format. On copy, the authoring tool converts its internal document representation into HTML and places that on the clipboard, including any accessibility information. On paste, the markup is then parsed and placed back into the document, including any accessibility information, and rendered for the author.
Related Resources for Success Criterion B.1.2.2:

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

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

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

  • Note: This success criterion only applies when the output technology is "included" for conformance.
Intent of Success Criterion B.1.2.4:

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.4:
  • Save as HTML: A word processor includes a "Save as Simple HTML" feature that recodes 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> element 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.4:

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: To support accessible web content (WCAG) 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 more 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 alternate 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 "source". 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 conforming to WCAG 2.0 Level A) will result if authors do all of the following:
    • turn on all features that support the production of accessible content; and
    • correctly follow all prompts by features that support the production of accessible content; and
    • 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 Guideline B.2.3: Assist authors with managing alternative content for non-text content. [Return to Guideline]

Rationale: Improperly generated alternative content can create web content accessibility problems (WCAG) 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):

If the authoring tool provides functionality for adding non-text content, then 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 Repair of Text Alternatives During Authoring Sessions:

If the authoring tool attempts to automatically or semi-automatically repair text alternatives for non-text content ("repair strings") during an authoring session, then the following are both true: (Level A)

Intent of Success Criterion B.2.3.2:

The intent of this success criterion is to prevent the production of text alternatives that are not useful to end users because they have not been approved by authors and/or are derived from improper sources.

The limitation against generic or irrelevant strings (a) is intended to reduce the possibility that authors who are unfamiliar with accessibility may approve suggestions that do not properly serve as text alternatives (e.g. the file name, file format) without realizing the problems these can cause for end users. Potentially relevant strings include those derived from:

  • alternative content databases (see also Success Criterion B.2.3.4),
  • contextual information (e.g., the image is the author's profile picture), and
  • image processing. (while not as dependable as a human describer, the intent here is to encourage progress in this rapidly advancing field)

The requirement of author control (b) enables knowledgeable authors to have the final say on text alternatives suggested by authoring tools.

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 Repair of Text Alternatives After Authoring Sessions:

If the authoring tool attempts to automatically repair text alternatives for non-text content after an authoring session has ended, then the following are both true: (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 text alternatives 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 assuming that the alternative content was either provided or approved by an author.

The limitation against generic or irrelevant strings (a) mirrors that in Success Criterion B.2.3.3. It is intended to reduce the possibility that text alternatives will be used that do not properly serve as alternatives (e.g. the file name, file format). Potentially relevant strings include those derived from:

  • alternative content databases (see also Success Criterion B.2.3.4),
  • contextual information (e.g., the image is the author's profile picture), and
  • image processing. (while not as dependable as a human describer, the intent here is to encourage progress in this rapidly advancing field)

The requirement of author control (b) also mirrors that in Success Criterion B.2.3.3, except that, because the author is absent, the text alternatives can be inserted into the content without author approval, on the condition that they will be indicated to the author if and when a subsequent authoring session occurs. This involves some degree of record-keeping, but this is reasonable considering the accessibility problems that uncontrolled automatic generation of text alternatives could cause.

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

 

If the authoring tool provides the functionality for adding non-text content,

when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)
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 (WCAG) can have several benefits, including: immediately improving the accessibility of the web content (WCAG) of 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)

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 templates that are not accessible to create web content because accessible templates do not exist. It is recommended that the accessible options be identified, but this is not required at Level A. Identification is required at Level AA, by Success Criterion B.2.4.2.

Note: ATAG 2.0 uses the term "range" where 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.

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)

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)

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 (WCAG) pre-authored content (e.g., clip art, synchronized media, widgets) can have several benefits, including: immediately improving the accessibility of web content (WCAG) 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)

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: When accessibility checking is an integrated function of the authoring tool, it helps make authors aware of web content accessibility problems (WCAG) 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 in such a way 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:

If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e., manual checking and semi-automated checking), then 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:

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

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

If the authoring tool provides checks, then authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)

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:

If the authoring tool provides checks, then the authoring tool 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 website 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: When repair as an integral part of the authoring process, it greatly enhances the utility of checking and increases the likelihood that web content accessibility problems (WCAG) 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 checking 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.

Note: This success criterion requires that features be on by default, but allows developers to provide authors with the option to turn them off or modify their settings.

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 (WCAG). (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:

All 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 errors 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 accessibility checking tools). Demonstrating accessible authoring as routine practice, or at least not demonstrating inaccessible practices, will help to encourage acceptance of accessibility 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 (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.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, modeling inaccessible authoring practices in the documentation should be viewed in the same way as modeling invalid markup or spelling/grammar errors.

Note: ATAG 2.0 uses the term "range" where 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.

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

The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (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 authoring tool documentation contains an index to the instructions for using any 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.

Conformance Requirements

Success Criteria Satisfaction

The first step in determining ATAG 2.0 conformance is to assess whether the Success Criteria have been satisfied. The potential answers are:

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

At the time of publishing, WCAG 2.0 [WCAG20] is the current W3C Recommendation regarding web content accessibility. For this reason, ATAG 2.0 refers to WCAG 2.0 when setting 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 more accessible to end users with disabilities (in Part B).

In particular, ATAG 2.0 refers to WCAG 2.0 within its definition of the term "accessible content" (and related terms, such as "accessible template"). The definition of "accessible content" is content that would conform to WCAG 2.0, at either Level A, AA, or AAA, under the assumption that any web content technologies that are relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported. The phrase "at either Level A, AA, or AAA" takes into account that the definition of "accessible content" can differ depending on the context of use (e.g. in a Level A success criterion of ATAG 2.0 versus in a Level AAA success criterion). The definition also includes two notes:

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.

Conformance Options and Levels

There are two types of conformance, each with three levels:

ATAG 2.0 Conformance (Level A, AA, or AAA)

This conformance option may be selected when an authoring tools can be used to produce accessible web content (WCAG) without additional tools or components. The level of conformance is determined as follows:

Note 1: The Part A Conformance Applicability Notes and Part B Conformance Applicability Notes must be applied.
Note 2: If the minimum conformance level (Level A) has not been achieved (i.e., at least one applicable Level A success criterion has not been met), it is still beneficial to publish a statement specifying which success criteria were met.

Partial ATAG 2.0 Conformance - Process Component (Level A, AA, or AAA)

This conformance option may be selected when an authoring tool would require additional tools or components in order to conform as a complete authoring system. This option may be used for components with very limited functionality (e.g. a plug-in) up to nearly complete systems (e.g. a markup editor that only lacks accessibility checking functionality).

The level of conformance (A, AA, or AAA) is determined as above except that, for any "no" answers, the tool must not prevent the success criteria from being met by another authoring process component as part of a complete authoring system.

Note 1: Authoring tools would not be able to meet partial conformance if they prevent additional authoring process components from meeting the failed success criteria (e.g., for security reasons).
Note 2: The Part A Conformance Applicability Notes and Part B Conformance Applicability Notes must be applied.

Partial ATAG 2.0 Conformance - Platform Limitations (Level A, AA, or AAA)

This conformance option may be selected when an authoring tool is unable to meet one or more success criteria because of intrinsic limitations of the platform (e.g., lacking a platform accessibility service). The (optional) explanation of conformance claim results should explain what platform features are missing.

Web Content Technologies Produced:

Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g., Level A Conformance with respect to the production of XHTML 1.0).

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 both any technologies that the developer sets for automatically-generated content or that the developer 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.

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)

Note: As with any software application, authoring tools can be collections of components. A conformance claim can only be made by a responsible entity. Any other attempted "claims" are, in fact, reviews.

Required Components of a Conformance Claim

  1. Date of the claim.
  2. Guidelines title, version and URI "Authoring Tool Accessibility Guidelines 2.0 at @@"
  3. Conformance level satisfied.
  4. Authoring tool information: The name of the authoring tool and sufficient additional information to specify the version (e.g., vendor name, version number (or version range), required patches or updates, human language of the user interface or documentation).
    • Note: If the authoring tool is a collection of software components (e.g., a markup editor, an image editor, and a validation tool), then information must be provided separately for each component, although the conformance claim will treat them as a whole.
  5. Platform(s): The platform(s) upon which the authoring tool operates:
  6. A list of the web content technologies produced by the authoring tool that are included in the claim. If there are any web content technologies produced by the authoring tool that are not included in the conformance claim, these must be listed separately. If the authoring tool produces any web content technologies by default, then these must be included.
  7. Results for each of the success criteria: Yes, No, Not Applicable

Optional Components of a Conformance Claim

In addition to the required components of a conformance claim above, consider providing additional information to assist authors. Recommended additional information includes:

  1. An explanation of the success criteria results (Yes, No). (strongly recommended)
  2. Information about how the web content technologies produced can be used to create accessible web content (e.g., links to technology-specific WCAG 2.0 techniques).
  3. Information about any additional steps taken that go beyond the success criteria to enhance accessibility.
  4. A machine-readable metadata version of the conformance claim.
  5. A description of the authoring tool that identifies the types of editing-views that it includes.

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 more 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. The following informative table links the WCAG 2.0 success criteria with examples of accessibility information:

WCAG 2.0 Success Criteria WCAG 2.0 Level

Examples of "Accessibility Information" (**indicates certain WAI-ARIA 1.0 markup may qualify)

1.1.1 Non-text Content Level A Alternative text, long descriptions, indicators that non-text is pure decoration **
1.2.1 Audio-only and Video-only (Prerecorded) Level AA Audio tracks (in case it contains equivalent information for video), alternative for time-based media **
1.2.2 Captions (Prerecorded) Level AA Captions (text tracks in video; marked up captions)
1.2.3 Audio Description or Media Alternative (Prerecorded) Level AA Alternative for time-based media, audio descriptions (secondary audio tracks, marked up audio descriptions)
1.2.4 Captions (Live) Level AAA Captions (text tracks in video; marked up captions)
1.2.5 Audio Description (Prerecorded) Level AAA Audio descriptions (secondary audio tracks, marked up audio descriptions)
1.2.6 Sign Language (Prerecorded) Level AAA Sign language interpretation (secondary video tracks; marked up sign language interpretation)
1.2.7 Extended Audio Description (Prerecorded) Level AAA Secondary audio descriptions (secondary audio tracks, marked up audio descriptions)
1.2.8 Media Alternative (Prerecorded) Level AAA Alternative for time-based media **
1.2.9 Audio-only (Live) Level AAA Alternative for time-based media **
1.3.1 Info and Relationships Level A

Labels for other elements that lack them (e.g., for form controls, table cells)**

1.3.2 Meaningful Sequence Level A Navigation (e.g. tab) order
1.3.3 Sensory Characteristics Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.1 Use of Color Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.2 Audio Control Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.3 Contrast (Minimum) Level AA N/A (contrast is a calculated value not stored information)
1.4.4 Resize text Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.5 Images of Text Level AA Text can considered its own accessibility information (so it is not acceptable to automatically convert text into images and discard the text)
1.4.6 Contrast (Enhanced) Level AAA N/A (contrast is a calculated value not stored information)
1.4.7 Low or No Background Audio Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.8 Visual Presentation Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
1.4.9 Images of Text (No Exception) Level AAA Text can considered its own accessibility information (so it is not acceptable to automatically convert text into images and discard the text)
2.1.1 Keyboard Level A Keyboard handlers, navigation (tab) order.
2.1.2 No Keyboard Trap Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.1.3 Keyboard (No Exception) Level AAA Removing keyboard handlers or elements from the navigation (tab) order.
2.2.1 Timing Adjustable Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.2.2 Pause, Stop, Hide Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.2.3 No Timing Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.2.4 Interruptions Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.2.5 Re-authenticating Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.3.1 Three Flashes or Below Threshold Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.3.2 Three Flashes Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.4.1 Bypass Blocks Level A Intra-page links
2.4.2 Page Titled Level A Page title
2.4.3 Focus Order Level A Navigation (e.g. tab) order
2.4.4 Link Purpose (In Context) Level A

N/A (success criterion can be met by a variety of mechanism, not any particular stored information)

2.4.5 Multiple Ways Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.4.6 Headings and Labels Level AA Heading markup, label markup **
2.4.7 Focus Visible Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)

2.4.8 Location

Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
2.4.9 Link Purpose (Link Only) Level AAA Link text
2.4.10 Section Headings Level AAA Section heading markup **
3.1.1 Language of Page Level A Page language markup
3.1.2 Language of Parts Level AA

Sub-page language markup

3.1.3 Unusual Words Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.1.4 Abbreviations Level AAA Abbreviation markup
3.1.5 Reading Level Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.1.6 Pronunciation Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.2.1 On Focus Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.2.2 On Input Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.2.3 Consistent Navigation Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.2.4 Consistent Identification Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.2.5 Change on Request Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.3.1 Error Identification Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.3.2 Labels or Instructions Level A Label markup **
3.3.3 Error Suggestion Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.3.4 Error Prevention (Legal, Financial, Data) Level AA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.3.5 Help Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
3.3.6 Error Prevention (All) Level AAA N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
4.1.1 Parsing Level A N/A (success criterion can be met by a variety of mechanism, not any particular stored information)
4.1.2 Name, Role, Value Level A WAI-ARIA markup

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)
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).
Note: For the purposes of ATAG 2.0, only programmatically determinable information qualifies. For additional examples, see Appendix A of the Implementing ATAG 2.0 document.
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 editing web content (e.g., typing text, deleting, inserting an element, applying a template). In contrast, most authoring tool user interfaces also enable actions that do not edit content (e.g., saving, publishing, setting preferences, viewing documentation).
  • reversible authoring action is an authoring action that can be immediately and completely undone by the authoring tool upon a cancel request by an author. Examples of cancel requests include: "cancel", "undo", "redo" (when it used to reverse "undo"), "revert", and "roll-back"
    Note: 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.
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) 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.
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 websites (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:
  • accessible content (WCAG): Content that would conform to WCAG 2.0, at either Level A, AA, or AAA, assuming that any web content technologies relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported.
    • Note 1: If accessibility support for the relied upon technologies is lacking, then the content will not conform to WCAG 2.0 and one or more groups of end users with disabilities will likely experience difficulty accessing the content.
    • Note 2: Conformance to WCAG 2.0, even at the highest level (i.e., Level AAA), still may not make content "accessible to individuals with all types, degrees, or combinations of disability".
  • content being edited: The web content that an author can modify during an authoring session. The content being edited may be a complete piece of content (e.g., image, style sheet) or only part of a larger piece of content (e.g., a status update). The content being edited only includes content in web content technologies that the authoring tool supports (e.g., a WYSIWYG HTML editor allows editing of the HTML content of a web page editable, but not the images).
content properties
The individual pieces of information that make up the web content (e.g., the attributes and contents of elements, style sheet 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 actual web content that will be rendered, played or executed by the end user's user agent. While the precise details of how content is created in any given system may vary widely, responsibility for the generation of content can be any combination of the following:
  • author generated content: Web content for which authors are fully responsible. The author may only be responsible down to a particular level (e.g., when asked to type a text label, the author is responsible for the text, but not for how the label is marked up; when typing markup in a source editing-view, the author is not responsible for the fact that UNICODE is used to encode the text ).
  • automatically generated content: Web content for which developer-programmed functionality is fully responsible (e.g., what markup to output when an author requests to start a new document, automatically correcting markup errors).
  • third-party content generation: Web content for which a third-party author is responsible (e.g., community shared templates).
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 waveform); 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 optimized, restructured or recoded:
  • Optimizing Content Transformations: Transformations in which the content technology is not changed and the structural features of the content technology that are employed also stay the same. Changes would not be expected to result in information loss (e.g., removing whitespace, replacing in-line styles with an external style sheet).
  • Restructuring Content Transformations: Transformations in which the content technology stays the same, but the structural features of the technology used to markup the content are changed (e.g., linearizing tables, splitting a document into pages.
  • Recoding Content Transformations: Transformations in which the content technology used to encode the content is changed (e.g., HTML to XHTML, a word processing format to HTML).
Note: Clipboard operations, in which content is copied to or pasted from the platform clipboard, are not considered content transformations.
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
Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected).
Note: 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:
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 in 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).
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" where 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).
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.
time limit
The amount of time that an authoring tool provides to authors to perform a task (e.g., read a message, select an item, save a change). Examples include: authoring session timeouts, time-based presentations (e.g. tutorial video).
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 (e.g., web browsers, browser plug-ins, media players)
  • In-Market User Agent: A user agent, that can be procured by members of the public (free or otherwise). Usually, an in-market user agent will be a separate software from the authoring tool, however, sometimes a software may combine user agent and authoring tool functionality. These cases include:
    • Preview-Only: If the user agent can only render web content that it receives from the associated authoring functionality, then the software is an authoring tool with a preview feature. Such preview-only features are not considered in-market user agents.
    • User Agent with Authoring Tool Mode: If the user agent functionality must retrieve and open web content before it can be sent to the authoring tool functionality, then the software is a user agent with an authoring tool mode. If the user agent is used to preview content produced by the authoring tool mode, then it is to be considered an in-market user agent.
    • Combined User Agent/Authoring Tool: A user agent in which the default mode of user interaction enables editing the web content. These tools do not need previews because the author is already experiencing the content in the same way as end users.
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 no authoring actions are provided (i.e., the view is not editable).Previews are provided to present the web content being edited by the authoring tool as it would appear to end users of user agents. Previews may be implemented using actual in-market user agents, but this is not necessary. See the definition of user agent for more information.
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: Checklist


Appendix I: Comparison of ATAG 1.0 guidelines to ATAG 2.0


Appendix J: Acknowledgments

Participants active in the AUWG at the time of publication:

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

Previous Editors:
Tim Boland, NIST
Matt May (until June 2005 while at W3C)

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, Sarah Pulis, Bob Regan, Chris Ridpath, Andrew Ronksley, 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]