This specification provides guidelines for designing Web contentauthoring
tools that are more accessible for people with disabilities. An authoring
tool that conforms to these guidelines will promote accessibility by providing
an accessible user interface to authors with disabilities as well as enabling,
supporting, and promoting the production of accessible Web content by all
authors.

This document provides non-normative information
to authoring tool developers who wish to satisfy the guidelines in the "Authoring
Tool Accessibility Guidelines 2.0" [ATAG20].
It includes suggested techniques, sample strategies in deployed tools, and
references to other accessibility resources (such as platform-specific software
accessibility guidelines) that provide additional information on how a tool
may satisfy each ATAG 2.0 guideline.

The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0)
is part of a series of accessibility guidelines published by the
W3CWeb
Accessibility Initiative (WAI).

May be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Editor's Draft of ATAG 2.0

This document is the internal working draft used by the ATAG WG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.

The Working Group (AUWG) intends
to publish the Implementation Techniques for ATAG 2.0 as a W3C Note. A Techniques document was also published for ATAG 1.0 [ATAG10], entitled "Techniques for Authoring Tool Accessibility Guidelines 1.0" [ATAG10-TECHS]. The Working Group expects to update this document in response to queries raised by implementers of the Guidelines, for example to cover new technologies. Suggestions for additional techniques are welcome.

Web Accessibility Initiative

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 obsolesced by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version
2.0. This document includes recommendations for assisting developers to make the authoring tools more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others. However, even authoring tools that conform to ATAG 2.0 may not be able to address the needs of people with all types, degrees and combinations of disabilities.

In order to achieve accessibility, authoring tools must address the needs of two (potentially overlapping) user groups:

end
users of Web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible
Web content, with the assumption that many authors will not be familiar with the specific needs of end users with disabilities (see Part B of the guidelines).

The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people
with disabilities than on other people.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Creation of authoring tools that address the specialized needs of these communities for is encouraged, but is outside the scope of this document.

These guidelines have been written to address the requirements
of many different audiences, including, but not limited to:

This is a Working Draft of the Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0. While the Authoring Tool Accessibility Guidelines 2.0 [ATAG20] provides a generic description of the requirements for authoring tools that are accessible to people with disabilities, these implementation techniques provide an interpretation of the guidelines as they apply to real tools. This interpretation represents the best thinking of the Authoring Tool Accessibility Guidelines Working Group (AUWG) and as such is a good guide to achieve conformance to ATAG 2.0. The Working Group encourages developers to implement these techniques where appropriate. However, these techniques do not provide a final definition of ATAG 2.0 conformance and it may be possible to meet the guideline requirements without following these techniques and thus this document is informative. As new methods of conforming to the guidelines come to the attention of the Working Group, these techniques will be updated.

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

ATAG 2.0 defines an "authoring tool" as any application, part of an application, or collection of applications that authors interact with to create, modify or assemble Web content to be used by other people.

The definition applies to all or part of the following types of applications:

Notes on the Definition:

Any guidelines that require the ability of authors to modify content in some way always assume that the person has author permission.

Live content authoring tools (e.g., chats, collaboration tools, whiteboards, etc.) are only required to meet Part A. However, many guidelines in Part B may still usefully apply, especially if the tool archives as Web content. For more information, please see the Techniques - Appendix E: Real-time content production.

Components of Web Accessibility

Authoring tools are just one aspect of accessibility. For an overview of the different components of accessibility and how they work together see:

Accessibility
solutions must be promoted and integrated -Authoring tools should encourage the discovery of tools, features, or functionality which support accessible authoring practices, while at the same time, integrating functions related to accessibility in order to ensure that authors make them common practice.

Note: While the requirements in Part B do not
deal with the accessibility of the authoring tool user interface per se, it should
be noted that any of the features (e.g., checker, tutorial) added to an authoring tool to meet
the Part B success criteria must also meet the user interface accessibility requirements of Part
A.

Success Criteria

Under each guideline there are success criteria that describe specifically what must be achieved in order to conform. They are similar to the "checkpoints" in ATAG 1.0. Each success criterion is written as a statement that will be either true or false when a specific authoring tool is tested against it. While all of the ATAG 2.0 success criteria are written to be testable and some test automation may be possible, human testing will usually be required. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest).

Each of the success criteria has a link to the Techniques document that provides:

"Sufficient" techniques for meeting the success criteria, and @@define@@

optional "Advisory" techniques.@@define@@

Note: Any success criteria that are judged not applicable
to a particular authoring tool are treated as satisfied for
conformance purposes, as long as a rationale is provided.

Implementation Techniques

The list of techniques for each success criteria are not exhaustive. Rather, these techniques represent an illustrative sampling of approaches. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria.

Some techniques are labeled as "Sufficient". These techniques are judged by the Working Group to meet the success criteria to which they apply. Conditional wording may limit the applicability of any given sufficient technique to a particular type of content or authoring tool. Inclusion does not imply that the description will be verified or is verifiable. When multiple techniques must be implemented together to be sufficient, they are labeled "Sufficient in combination".

Some techniques are labeled as "Advisory". These techniques are included as additional information.

Note: Use of "mock" screenshots is for general illustrative purposes only. They do not imply endorsement of similar tools by the Working Group or suggests that these screenshots represent the best or only implementations.

Levels of Conformance

Authoring tools may claim full conformance
to ATAG 2.0 at one of three "full" conformance levels. The level achieved depends
on the level of the success
criteria that have been satisfied. The full conformance
levels are:

Full ATAG 2.0 Conformance at Level "A"
The authoring tool satisfies all of
the Level A success criteria.

Full ATAG 2.0 Conformance at Level "Double-A"
The authoring tool satisfies all of
the Level A and Level
AA success criteria.

Full ATAG 2.0 Conformance at Level "Triple-A"
The authoring tool satisfies all of
the success criteria.

@@Maybe remove partial@@

In addition, a "partial conformance" claim option is available
in cases where an authoring tool has satisfied all of the success criteria
at a specified level in one of the two Parts of the document (i.e., "Part
A: Make the authoring tool user interface accessible" and "Part
B: Support the production of accessible content"). The partial
conformance levels are:

Partial ATAG 2.0 Conformance Level "A":
Authoring Tool User InterfaceThe authoring tool satisfies all of the Level
A success criteria in Part A. Nothing is claimed about Part B.

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

Partial ATAG 2.0 Conformance Level "A":
Content Production"The authoring tool satisfies all of the Level
A success criteria in Part B. Nothing is claimed about Part A.

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

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

Note: The Working Group remains committed
to the guiding principle that: "Everyone should
have the ability to create and access Web content". Therefore, it is
recommended that partial conformance be claimed as a step towards full conformance.

Relationship
to the Web Content Accessibility Guidelines (WCAG)

ATAG 2.0 is intended to be used in conjunction with WCAG 2.0 or similar Web content accessibility guidance (e.g., WCAG 1.0, regulations that include WCAG 2.0, etc.).

The relationship is as follows:

The normative requirements of ATAG 2.0 have been formulated to apply to many different types of authoring tools that in turn may produce a range of Web content technologies.

ATAG 2.0 points to the WCAG 2.0 success criteria in order to define the ATAG 2.0 concept of "accessible authoring practices", which authoring tools are required to support in various ways.

The normative requirements of WCAG are themselves not technology-specific. However, specific informative guidance for satisfying the success criteria for particular Web content technologies are provided in separate documents.

ATAG 2.0 Conformance Claims are supported by WCAG-conforming examples of Web content produced by the authoring tool (e.g., samples of automatically-generated content).

Applicability of Techniques and Examples

Since the techniques and examples are intended to be as informative as possible, many of them are specific to certain approaches to presenting the content being edited . Where this is the case they have been marked with icons as follows:

Meta-contentin which authors set high-level options that the authoring tool then interprets to generate the resulting content (e.g., a content management system that only lets authors set the month and year on a built-in calendar module).

ATAG 2.0 Guidelines ATAG 2.0 Implementation Techniques

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

The guidelines and success criteria are included here for informative purposes. The normative version appears in the Authoring Tool Accessibility Guidelines 2.0 [ATAG20].

PART A:
Make the authoring tool user interface accessible

Applicability Notes:

Scope: The success criteria in Part A apply to all aspects of the authoring tool user interface that are under the control of the developer. This includes functionalities that are independent of the content being edited, such as what is sometimes referred to as the authoring tool's "chrome" (e.g., menus, button bars, status bars, etc.) and also user preferences and documentation, etc. In addition, the developers' responsibility covers certain aspects of other functionalities that reflect the content being edited (e.g., ensuring that an image label present in the content is available programmatically). However, where an accessibility problem in the user interface is caused directly by an accessibility problem in the content it is reflecting (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.

Example: Throughout development of an authoring tool, with the tool in various representative states, the editing interface (including test content being authored) is tested using accessibility evaluation software. Problems are corrected and the process iterates.

Applicability Notes:

This guideline also applies to any parts of authoring tools that are non-Web-based (e.g., client-side file uploaders).

Level A Success Criteria for Guideline A.1.2

A.1.2.1 Non-Web-Based Accessible (Level A):

Technique A.1.2.1-1 [Sufficient]: Implementing the input, focus, selection and product installation sections of accessibility guidelines and best practice documents that are relevant to the platform. These may include:

Non-Web-based authoring tool user interfaces comply with, and cite in the conformance claim, the "Level A" requirements of standards and/or platform conventions that benefit accessibility. The "Level A" requirements are those that are functionally equivalent to WCAG Level A success criteria.

Level AA Success Criteria for Guideline A.1.2

A.1.2.2 Non-Web-Based Accessible (Level AA):

Technique A.1.2.1-1 [Sufficient]: Implementing the input, focus, selection and product installation sections of accessibility guidelines and best practice documents that are relevant to the platform. These may include:

Level AAA Success Criteria for Guideline A.1.2

A.1.2.3 Non-Web-Based Accessible (Level AAA):

Technique A.1.2.1-1 [Sufficient]: Implementing the input, focus, selection and product installation sections of accessibility guidelines and best practice documents that are relevant to the platform. These may include:

PRINCIPLE
A.2: Editing views must be perceivable

Rationale: People
who have difficulty perceiving non-text objects are often able to
access text alternatives of the same information because there are a variety of ways to display text (e.g., magnification, enhancement, text-to-speech, Braille output)

Applicability Notes:

This guideline does not apply to plain text editors as they do not render non-text content.

Level A Success Criteria for Guideline A.2.1

A.2.1.1 Alternative equivalents in the content:

Technique A.2.1.1-1 [Sufficient]: In editing views that render non-text objects, displaying in an editable fashion any text alternatives
(e.g., short text labels, long text descriptions) associated with the objects (e.g., within a properties dialog).

Technique A.2.1.1-2 [Sufficient]: When appropriate for a Web technology (i.e., the technology is human-readable), providing an source content editing view that allows direct editing of all properties.

Technique A.2.1.1-3 [Advisory]: Providing an option to toggle between rendered non-text objects and the text alternatives for the objects.

Example: An option to toggle fully rendered images with their text alternatives.
On the left is the image (of the "earth rise" as seen from the
moon) rendered as usual. On the right is a different rendering, this
one including an area for editing the alternate text and a link to edit the
long description. A small preview rendering of the image is included
to provide context. (Source: mockup by AUWG)

Rationale:Authors need to have access to and control over both the functional significance of presentation and also, in the context of authoring, the presentation that will be experienced by the end user. This is especially important for user interface components that do not implement an accessibility platform architecture or leverage existing implementations (e.g. custom user interface components built via JavaScript and CSS). Some authors require display settings that differ from the presentation that they intend to define for the published content (e.g., using a high contrast setting during editing content that is not intended to be high contrast).

Level A Success Criteria for Guideline A.2.2

A.2.2.21 Purpose of Added Presentation: If the authoring tool modifies the presentation of the content being edited, then the functional purpose for the modification is made available via the platform (e.g., if misspelled text is underlined, the fact that it is misspelled is made available).

Technique A.2.2.2-1 [Sufficient]: Making available programmatically the semantics of any presentation that is added to the editing view by the authoring tool.

Example: A change tracking feature displays inserted text in green and deleted text in red with a strike through. Instead of implementing this using simple CSS selectors, the XHTML elements ins and del are used, since they have associated semantics.

A.2.2.32 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties are made available via the platform:

(a) font,

(b) style (e.g., italic, bold),

(c) color, and

(d) size.

Technique A.2.2.3-1 [Sufficient]: Making available via the platform, information on the size, font, foreground and background color, font weight, and position of any text that is under the control of the author.

Example: Using a WYSIWYG authoring tool, an author is able to mark a paragraph using a "footnote" style class, then query the text to check on the rendered size of the text to ensure that the styling information has been picked up properly.

Level AA Success Criteria for Guideline A.2.2

(No level AA success criteria for Guideline A.2.2)

Level AAA Success Criteria for Guideline A.2.2

A.2.2.43 Access to Text Presentation (Enhanced): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and are editable by any editing view are available via the platform.

See Techniques for A.2.2.3, but for all text presentation properties rendered and editable by the authoring tool.

Guideline A.2.3: Ensure the independence of the authors' display preferences.

Rationale: Some authors will require display settings that differ from the presentation that they intend to define for the published content (e.g., an author uses large fonts for themselves, while editing content that is not intended to have a large font in the final content).

A.2.2.13 Independence of Display:Editing
views that usually have their display characteristics set
by rendering the content being
edited (e.g., WYSIWYG editing views) allows the authors' visual and audio display settings to override these characteristics without
affecting the content (e.g.,
markup, style sheets, etc.) being edited.

Technique A.2.2.1-1 [Sufficient]: Providing
the author with the ability to change the fonts, colors, sizing (zoom), etc.
within rendered editing views (or by changing the platform display settings), independently
of the ability to control the markup that is actually produced.

Example: A WYSIWYG authoring tool includes editing interface controls for setting the text and background colors as they will appear to the end user, but also includes a "View" area in its preference settings, where the author can choose to override the WYSIWYG rendering with their own text and background color settings.

Technique A.2.2.1-2 [Advisory]: Allowing the author
to specify a preferred style sheet that is used in the editing view to override the actual "published" style of
the document.

Rationale: Providing alternate keyboard accessibility provides access for people with limited mobility and people with
visual disabilities, who cannot rely on hand-eye coordination for
navigating the user interface.

Applicability Notes:

Level A Success Criteria for Guideline A.3.1

A.3.1.1 Important Command Functions: If the authoring tool includes any of the following functions, authors can enable
key-plus-modifier-key (or single-key) access to them (where allowed by the operating environment):

Level AAA Success Criteria for Guideline A.3.1

Rationale: People
who have difficulty typing, operating the mouse, or processing information
can be prevented from using systems with short time limits.

Applicability Note: Several of the success criteria in this guideline only apply when there are time limits put on the author.

Level A Success Criteria for Guideline A.3.2

A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then authors have the global option to ensure that the content being edited is saved. For Web-Based Authoring Tools, this applies to any content that has already been submitted to the server by the user agent.

A.3.2.2 Timing Adjustable: The user is 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").

A.3.2.3 Moving Targets: If the user interface includes any targets for authors' actions (e.g.,a selectable component of an animation), then authors can stop that movement.

Technique A.3.2.3-1 [Sufficient]: All components that can be targets for author actions can be stopped.

Example: In a timeline-based animation editor, a draggable time indicator moves when the animation is being previewed. This movement can be stopped with the "Stop" button.

Level AA Success Criteria for Guideline A.3.2

(No level AA success criteria for Guideline A.3.2)

Level AAA Success Criteria for Guideline A.3.2

A.3.2.4 No Time Limits: Authors have the option to remove time limits on authoring sessions.

Technique A.3.2.4-1 [Sufficient]: Ensuring that the authoring tool never imposes time limits

Technique A.3.2.4-2 [Advisory]: Even if an external process is causing a time limit, considering ways to reduce the impact on the author (e.g., giving advance warning, assisting with the time-limited action, etc.).

Technique A.3.4.1 [Sufficient]: Ensuring that when an element is selected, any content, including sub-elements, of the element are also selected. Then, ensuring that when a selected element with content, including sub-elements, is the subject of an operation (cut, copy, styling, delete) the element's content should also be subject to the same operation unless the operation targets the element only. Note that various editing functions will apply differently when performed on a selected element. These differences might be classified according to their scope, as follows:(a) "element, content and sub-elements": These functions target the entire selection. Examples of these functions include cut, copy, and delete.

Example: In an HTML editor , when a <table> element is selected and the "delete" operation is performed, the entire table is deleted including sub-elements ( <tr> and <td>) and any text content etc. within the table.

(b) "element only": These functions only target the top level element of the selection, even if the effect cascades down to sub-element content when it is rendered. Examples of functions of this type include, "Emphasis" which should apply styling to the top level element (e.g., <p>) while not making any source changes to sub-elements (e.g., strong) (even though the content of sub-elements may be rendered differently) and “strip element tags” that deletes the markup of the top level element without affecting its sub-element.

Example: In an HTML editor, when a <table> element is selected and the "strip element tags" operation is performed, the operation targets the <table> only, so this set of tags is removed, leaving sub-elements ( <tr> and <td>) and any text content etc.

(c) "content and sub-elements only": These functions target the content, including sub-elements of the top level element of the selection without having any affect on the markup of that top level element. An example of this might be a “Replace Contents” function:

Level AA Success Criteria for Guideline A.3.4

A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next identical element.

A.3.4.3 Navigate By Headings: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the heading, regardless of level.

A.3.4.43 Navigate Tree Structures: If an editing
view displays a structured
element set, authors can, with a simple action, move
the editing focus from any element to
other elements in the set with any of the following
relationships (if they exist):

(a) Parent: the element immediately
above,

(b) Child: the first element immediately
below,

(c) Previous Sibling: the element immediately
preceding at the same level, and

(d) Next Sibling: the element immediately
following at the same level.

Technique A.3.4.3-1 [Sufficient]: Providing the ability to move focus from any element to the element that contains it (i.e., parent element), if any. Also providing the ability to move focus from any element to the first sub-element that it contains (i.e., first child element), if any. Also providing the ability to move focus from any element to the element immediately preceding it as a sub-element of the same parent element (i.e., previous sibling). Also providing the ability to move focus from any element to the element immediately following it as a sub-element of the same parent element (i.e., next sibling).

Example: An authoring tool in which a <tr> element
has current focus and is therefore highlighted in the editing view. As
well, breadcrumbs in the status bar trace the path from the root element
to the current element, <html> <body> <table> <tr>.
A pop-up menu from the selected element shows that keystrokes are available
to move the selection focus to the parent element, <table>,
of the current element, to the child elements, in this case two <td> elements
and to the next and previous element pointed to by the same parent element
(in this case to preceding and following <tr> elements).
(Source: mockup by AUWG)

Technique A.3.4.3-2 [Advisory]: Providing an "outline"
or "structure" view of the document that organizes the structured element set into a document tree or graph.

Technique A.3.4.3-3 [Advisory]: If loops are possible within the structured element set, providing a mechanism for alerting the author when they have completed a loop.

Technique A.3.4.3-4 [Advisory]: Ensuring that a smooth transition exists between navigation via the content structure to a particular element and commencing to edit that element.

Technique A.3.5.1-1 [Sufficient]: Supporting bi-directional, case sensitive searching for plain text sequences within the content (i.e., text between the open and close tags of an element, text in a content management database) and within text alternatives for non-text content (i.e., short text labels, long text descriptions, etc.) even when this textual information is actually encoded as part of the markup (e.g., as an attribute value).

Example: Searching for a term yields occurrences within regular page content but also in the alt-text of images, long descriptive text, and metadata values.

Example: Searching for the text string "able", with the source code option checked, yields results that include <table> elements.

Example: A search facility that makes effective use of structure. Here the author has chosen to find the "element" with the name "img", "with attribute" "height" "equal to" "100", where each value in quotation marks was 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 facility also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)

Level AAA Success Criteria for Guideline A.3.5

Rationale: Providing
the ability to save and reload sets of keyboard and display preference
settings benefits people using multi-user tools as well as people who have needs that differ over time (e.g., due to fatigue).

Level A Success Criteria for Guideline A.3.6

(No level A success criteria for Guideline A.3.6)

Level AA Success Criteria for Guideline A.3.6

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

Example: In a Web-based authoring tool, the author must log in. Once they do, they are presented with display/control preferences profiles that they have previously customized. The author can change their profile at any time.

Level AAA Success Criteria for Guideline A.3.6

A.3.6.2 Multiple Sets: Choosing between multiple sets of preferences (e.g., personal profiles,
personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform):

Technique A.3.6.2-1 [Sufficient]: Providing the option of multiple configuration sets of options. Each set contains the configuration settings (not controlled by the platform) for (a) keyboard operability, (b) the visual display, (c) for the auditory display.

A.3.6.3 Options Wizard:Authors are provided with an accessibility option-setting "wizard" to configure options related to Part A.

Technique A.3.6.3-1 [Sufficient]: Providing a wizard that walks the user through the configuration options, providing explanations and previews of how the configuration options will change the display.

Example: The wizard follows an interview format, asking the author about general preference areas (e.g., seeing the screen, using the keyboard) and only becoming more detailed if the author affirms an area.

Rationale: Preview features
are provided in many authoring tools because the workflow of authors often includes periodically checking how content will appear
to end users in
a user
agent. Authors with disabilities need to be able to follow
the same workflow.

Note: Previews are treated differently than editing views because authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this guideline.

Level A Success Criteria for Guideline A.3.7

A.3.7.1 Return Mechanism: If a preview is provided, then it is possible to return from the preview using a simple action which is documented in the help system.

A.3.7.2 Preview: If a preview is provided, then it meets at least one of the following:

(a) Existing User Agent: the preview makes
use of an existing user
agent that is specified in the conformance
profile (e.g., opening the
content in a third-party browser, browser component, video player, etc.)

(b) Part A.1: the preview meets
all of the Level A guidelines in Principle A.1 of these guidelines, or

Level AAA Success Criteria for Guideline A.4.1

Technique A.4.1.4-1 [Sufficient]: Maintaining a queue of the five most recent actions (from most to least recent) and providing a function that can reverse the actions one-by-one starting with the most recent.

Level AA Success Criteria for Guideline A.4.2

Level AAA Success Criteria for Guideline A.4.2

A.4.2.2 Accessibility Feature Tutorials: Tutorials are provided for some of the features that are specifically required to meet Part A of these guidelines.

PART
B: Support the production of accessible content

Applicability Notes:

Authors Availability: Any success criteria in Part B that refer to authors only apply during authoring sessions when authors are available.

Responsibility After Authoring Sessions: Authoring tools are not responsible for accessibility problems that result from carrying out instructions made by the author during authoring sessions (e.g., the content of a third-party feed specified by the author), but they are responsible if the changes are automatically generated (e.g., the developer makes site wide changes to a CMS).

Existing Technologies: The success criteria in Part B only apply to support for accessible authoring practices that are relevant to technologies that the authoring tool already has the ability to create or edit. For example, a markup authoring tool that adds images by simply linking to their URIs would be required to support the production of alternative text for images in the markup, but it would not be required to add image editing functionality to ensure sufficient contrast in case any images are of text.

Authoring Systems: As per the definition of authoring tool, several software tools can be used in conjunction to meet the requirements of Part B. (e.g. a authoring tool could make use of a 3rd party software accessibility checking and repair program.

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

Rationale: Choosing technologies which support the possibility of accessible authoring is the first step in ensuring that the content produced is accessible.

Level A Success Criteria for Guideline B.1.1

B.1.1.1 Tool Choice of Technologies (Level A): Any Web content technologies that is automatically selected by the authoring tool can conform to WCAG Level A.

Technique B.1.1.1-1 [Sufficient]: A Web content technology could be considered able to conform to WCAG Level A if multiple content developers have publicly claimed WCAG Level A conformance for content developed using the technology.

Example: A content management tool is implemented using HTML templates, JavaScript and CSS for both the user interface and author generated content. One factor in the developer choosing this combination of technologies is that Web resources already exist that are implemented using these technologies and that have publicly claimed WCAG Level A conformance.

Technique B.1.1.1-2 [Sufficient]: A Web content technology could be considered able to conform to WCAG Level A if a WCAG Techniques document exists for the technology, regardless of whether the author of the Techniques document is the W3C-WAI WCAG Working Group or a third party (e.g., the developer of a non-W3C document format).

B.1.1.2 Author Choice of Technologies (Level A): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level A are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task.

Technique B.1.1.2-1 [Sufficient]: When prompting authors to choose between technologies, begin the list with technology options that can conform to WCAG Level A (see Techniques B.1.1.1-1, B.1.1.1-2, B.1.1.1-3 for methods to determine the accessibility of the options).

Example: An authoring tool only claims ATAG 2.0 conformance for HTML documents, but allows production of CSS style sheets, and MathML. When the author requests a new document, HTML is the first technology listed.

Technique B.1.1.2-2 [Advisory]: Displaying a warning when the author chooses to create Web content with a technology that cannot conform to WCAG Level A or with a technology that theoretically could conform to WCAG Level A, but for which the authoring tool does not provide accessibility support.

Example: A sample warning might read "Accessibility support is not available for documents in this format".

Level AA Success Criteria for Guideline B.1.1

B.1.1.3 Tool Choice of Technologies (Level AA): Any Web content technologies that is automatically selected by the authoring tool can conform to WCAG Level AA.

See Techniques for B.1.1.1 using level WCAG Level AA.

B.1.1.4 Author Choice of Technologies (Level AA): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level AA are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task.

See Techniques for B.1.1.2 using level WCAG Level AA.

Level AAA Success Criteria for Guideline B.1.1

B.1.1.5 Tool Choice of Technologies (Level AAA): Any Web content technologies that is automatically selected by the authoring tool can conform to WCAG Level AAA.

See Techniques for B.1.1.1 using level WCAG Level AAA.

B.1.1.6 Author Choice of Technologies (Level AAA): If the authoring tool provides authors with Web content technology options, technology options that can conform to WCAG Level AAA are listed with at least as much prominence as any other options and the tool guides the author towards the most accessible technology for the task.

(a) Preserve in Output: the accessibility
information is preserved and available for end
users in the resulting content;

(b) Preserve Input and Notify: a copy of the accessibility
information is retained (e.g., as a "comment", by saving a backup
copy) and the authors are notified of the location and of the fact that it will not be available to end users; or

(c) Author Queried: the authors are queried for an action for each piece of accessibility information that will not be preserved and is notified that this may result in accessibility problems.

Example: If converting between HTML and SVG the contents of alt attributes can be stored in desc attributes.

Technique B.1.2.1-2 [Sufficient for (a)]: Where necessary, preserve accessibility
information in a dissimilar, but accessible way.

Example: If transforming a SMIL presentation with a closed-caption text track into a video-only format, provide the option of an open-captioned video.

Technique B.1.2.1-3 [Sufficient for (b)]: Automatically archiving a backup copy of the original content if accessibility
information will be lost and notifying the author of both the location and the fact that the new location will not be available to end users needing the information.

Technique B.1.2.1-4 [Advisory]: When importing images with associated descriptions into a markup document,
make the descriptions available through appropriate markup.

Technique B.1.2.1-5 [Advisory]: Avoid transforming text into images. Use style sheets for presentation
control, or use an XML application that keeps the text as text.
If this is not possible, ensure that the text is available as equivalent
text for the image.

Technique B.1.2-1.6 [Advisory]: Notifying the author before changing the technology (including the DTD) of the content being authored.

Technique B.1.2.1-7 [Advisory]: Allow authors to edit transformation or conversion templates to specify the way presentation conventions should be converted into structural markup.

Technique B.1.2.1-8 [Advisory]: Ensure that changes to graphical layouts do not reduce readability when the document is rendered serially. For example, confirm the linearized reading order with the author.

Technique B.1.2.1-9 [Advisory]: When transforming a table to a list or list of lists, ensure that table
headings are transformed into headings and that summary or caption information
is retained as rendered content.

Technique B.1.2.1-11 [Advisory]: When converting from an unstructured word-processor format to markup,
ensure that headings and list items are transformed into appropriate structural
markup (appropriate level of heading or type of list, etc.).

Technique B.1.2.1-12 [Advisory]: When developing automatic text translation functions, strive to make the resulting text as clear and simple
as possible.

Level AA Success Criteria for Guideline B.1.2

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

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

(a) Preserve Accessibility Information: the authoring tool only automatically deletes content that it can detect is not accessibility
information;

(b) Notification Option: authors have the option to receive notification before deletion; or

(c) No Deletion Option: authors have the option to turn off the automatic deletion.

Technique B.1.2.2-1 [Sufficient]: Detecting and avoiding the deletion of any author-generated content.

Technique B.1.2.2-2 [Sufficient for (a)]: Detecting and avoiding the deletion of author-generated content that is accessibility
information.

Technique B.1.2.2-3 [Sufficient for (b)]: Providing the author the option to confirm or override removal of content either on a change-by-change basis or as a batch process.

Technique B.1.2.2-4 [Sufficient for (c)]: When an automatic process is to be performed that cannot be completed without removing content (even including unrecognized markup), providing the author with the option of canceling the operation.

This guideline applies to the automated behavior specified by the authoring tool developer under the assumption that authors will respond properly to any prompts.

The guideline does not apply when actions of the authors prevent generation of accessible content (e.g., by setting less strict preferences, ignoring prompts for accessibility information, providing faulty information, writing their own automated scripts, etc.).

Level A Success Criteria for Guideline B.1.3

B.1.3.1 Automatic "A" Accessible: If the authoring tool automatically
generates content, then that content meets WCAG Level A at the conclusion of the automatic generation process (e.g., when inserted into the existing content).

Technique B.1.3.1-1 [Sufficient]: Ensuring that any action that the authoring tool takes without complete author knowledge that causes content to be added or modified has the result of not introducing new WCAG Level A contraventions.

Technique B.1.3.1-2 [Advisory]: Using prompting to elicit information from the author when necessary (see Guideline B.2.1).

Level AA Success Criteria for Guideline B.1.3

B.1.3.2 Automatic "AA" Accessible: If the authoring tool automatically
generates content, then that content meets WCAG Level AA at the conclusion of the automatic generation process.

See Techniques for B.1.3.1 using WCAG Level AA.

Level AAA Success Criteria for Guideline B.1.3

B.1.3.3 Automatic "AAA" Accessible: If the authoring tool automatically
generates content, then that content meets WCAG Level AAA at the conclusion of the automatic generation process.

See Techniques for B.1.3.1 using WCAG Level AAA.

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

Applicability Notes:

Principle B.2 applies to authoring tool processes that interact with human authors, and the authoring choices that author is making or the authoring choices under the control of the authoring tool. Authoring choices include choice of style sheets, templates, scripts, etc

Implementation Notes: Prompting in the ATAG 2.0 context is not to be interpreted as necessarily implying intrusive prompts, such as pop-up dialog boxes. Instead, ATAG 2.0 uses prompt in a wider sense, to mean anytool initiated process of eliciting author input that is triggered by author actions (e.g., adding or editing content that requires accessibility information from the author in order to prevent the introduction of accessibility problems). The reason for this is that it is crucial that that accessibility information be correct and complete. This is more likely to occur if the author has been convinced to provide the information voluntarily. Therefore, overly restrictive mechanisms are not recommended for meeting this guideline. The author experience of prompting will be very similar to that of checking (see Guideline B.2.2) for some implementations. For example, in a tool that checks continuously for accessibility problems, the markings used to highlight discovered problems can be considered to be a form of prompting.

Level A Success Criteria for Guideline B.2.1

B.2.1.1 Guide "A" Accessible: If authors are prompted for any information as content is being added or updated (e.g., by an image modification dialog), then the tool also prominently prompts for any accessibility
information required for that content to meet WCAG Level A.

B.2.1.2 Warn "A" Accessible: If an authoring action or instruction will always lead to the creation
of content that cannot be made to meet WCAG Level A other than by making an alternative version, then
a warning is displayed.

Technique B.2.1.2-1 [Sufficient]: Ensuring that all instruction text would, if followed exactly by the author, leads to content being created or modified so as to meet WCAG Level A.

Technique B.2.1.2-2 [Sufficient]: Consistently labeling help documents or other documentation such that, if followed exactly by the author, it would lead to content being created or modified to not meet WCAG Level A.

Level AA Success Criteria for Guideline B.2.1

B.2.1.3 Guide "AA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet WCAG Level AA.

See Techniques for B.2.1.1 using WCAG Level AA.

B.2.1.4 Warn "AA" Accessible: If an authoring action or instruction will always lead to the creation
of content that cannot be made to meet WCAG Level AA other than by making an alternative version, then
a warning is displayed.

See Techniques for B.2.1.2 using WCAG Level AA.

Level AAA Success Criteria for Guideline B.2.1

B.2.1.5 Guide "AAA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet WCAG Level AAA.

See Techniques for B.2.1.1 using WCAG Level AAA.

B.2.1.6 Warn "AAA" Accessible: If an authoring action or
instruction will always lead to the creation of content that cannot be made to meet WCAG Level AAA other than by making an alternative version, then
a warning is displayed.

Implementation Notes: Despite prompting assistance from the tool (see Guideline B.2.1), accessibility problems may still be introduced. For example, the author may cause accessibility problems while coding by hand or by opening content with existing accessibility problems for editing. In these cases, the prompting mechanisms that operate when markup is added or edited (i.e., insertion dialogs and property windows) must be backed up by a more general checking system that can detect and alert the author to problems anywhere within the content (e.g., attribute, element, programmatic object, etc.). It is preferable that checking mechanisms be well integrated with repair mechanisms (see Guideline B.2.3), so that when the checking system detects a problem and informs the author, the tool immediately offers assistance to the author.

This guideline does not apply if the authoring tool controls the authoring process to such an extent that it is not possible for authors to introduce accessibility problems.

This guideline does not apply to content that is not available at publishing (e.g., the actual content of third-party "feeds").

Level A Success Criteria for Guideline B.2.2

B.2.2.1 Check Accessibility (Level A): At least one individual check is associated with each WCAG Level A Success Criterion that the tool has the functionality to modify (e.g., a tool that inserts images should check for alt text; a tool that can edit captions should check for them).

Technique B.2.2.1-1 [Sufficient]: Providing accessibility checking for the various success criteria in WCAG, identified as Level A. In some cases several checks may be required to appropriately test whether a WCAG success criterion has been met.

Technique B.2.2.1-2 [Advisory]: Providing a listing of the checks performed in the conformance claim.

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

Technique B.2.2.2-1 [Sufficient]: Providing accessibility checking as an action (e.g., as a menu item, etc.) at all times.

Technique B.2.2.2-2 [Sufficient]: Prompting the author to perform an accessibility check if the author chooses to close or publish the content

Example: A instruction-level authoring tool displays errors in a separate pane by the line number of the first element in the span.

Example: A instruction-level authoring tool displays errors in-line by underlining all of the markup for the affected span of elements.

Example: A WYSIWYG authoring tool displays errors in-line with the rendered content in the WYSIWYG editing view as blue outlining around or under the affected span of elements.

Technique B.2.2.3-2 [Advisory]: Displaying manual checks in a way that balances the need for the author to make specific changes to some kinds of content (e.g., non-text objects, acronyms, table cells, etc.) while not overwhelming the author with numerous manual checks for other kinds of content that can be checked more generally (e.g., background color contrast, reading level, etc.). Excessively general checks (e.g., "does the page meet
all of the requirements?") should be avoided.

Technique B.2.2.4-1 [Sufficient]: Ensuring that the wording of prompts answers the following questions: "What part of the content should be examined?" and "What is present or absent in the event that the problem exists?".

Technique B.2.2.1-3 [Advisory]: Saving author judgments for manual checks and only prompting for new judgments after substantial changes is a more user-friendly approach.

Technique B.2.2.4-2 [Advisory]: Providing preview modes to authors view their content in ways it may be viewed by others, but that they may not have considered:

an alternative content view (with images and other multimedia replaced by any alternative content)

a monochrome view (to test contrast)

a collapsible structure-only view (to test keyboard navigation)

a text to speech view (to test the availability of text alternatives)

no scripts view

no frames view

no style sheet view

Example: A WYSIWYG authoring interface includes a list of rendering options as sub-menu options of a View menu. The options include "All" (i.e., render as in a generic browser), "text-only" (i.e., non-text items replaced by textual equivalents), "no styles", "no frames", and "grayscale" (used to check for sufficient contrast). In the background, the "earth rise" image in the WYSIWYG view can be seen in grayscale. (Source: mockup by AUWG)

Level AA Success Criteria for Guideline B.2.2

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

See Techniques for B.2.2.1 using WCAG level AA.

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

Technique B.2.2.6-1 [Sufficient]: Providing the option to view a single consolidated list of all of the accessibility problems that are detected by the checking function (see Guideline
B.2.2), organized by problem type and number of instances.

Technique B.2.2.6-2 [Advisory]: Providing direct links to additional help and repair assistance from the list of accessibility problems.

B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking , authors have the option to save the list to facilitate interoperability between checking and repair.

Technique B.2.2.7-1 [Sufficient]: Providing the option of storing accessibility
status information in a format that can be processed by a variety of tools (e.g., using Evaluation and Repair Language[EARL]).

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

Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility
problems will be properly addressed.

Implementation Notes: Once a problem has been detected by the author or the tool (see Guideline B.2.2), the tool may assist the author to correct the problem. As with accessibility checking, the extent to which accessibility correction
can be automated depends on the nature of the problems. Some repairs
are easily automated, whereas others that require human judgment may be semi-automated
at best.

Level A Success Criteria for Guideline B.2.3

Technique B.2.3.1-1 [Sufficient]: For each potential accessibility problem identified by the checking function (required in Guideline B.2.2), providing repair instructions that an author (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem. At the developer's discretion, semi-automated repairs (that prompts the author for required information) or automated repairs (that are able to complete the repair without prompting the author) may be substituted.

Technique B.2.3.1-3 [Advisory]: When appropriate, reusing affected elements' property editing mechanisms. This has the advantage that the author is already somewhat familiar with the interface. However, this practice does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction.

Technique B.2.3.1-4 [Advisory]: Implementing a special-purpose correcting interface, analogous to a spelling or grammar checker, that includes only the input field(s) for the information currently required. Additional information and tips that the author may require in order to properly provide the requested information can be added.

Example: A special-purpose correction interface supports the author's repair task by providing (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"). (Source: mockup by AUWG)

Technique B.2.3.1-5 [Advisory]: Presenting accessibility problems and repair options in a sequential manner analogous to a typical spelling or grammar checking "wizard". Because of the wider range of problems an accessibility checker needs to handle (i.e., missing text, missing structural information, improper use of color, etc.), the interface template will likely need to be especially flexible.

Example: A sequential accessibility checker. The special-purpose correction interface from the previous example is supplemented by a progress indicator ("5 of 25") and navigation buttons to move backwards ("back") and forwards ("skip") through the list of repair tasks. Buttons to "repair", get "help" and "cancel" are also provided. (Source: mockup by AUWG)

Technique B.2.3.1-6 [Advisory]: Where an authoring tool is able to detect site-wide errors, allowing the author to make site-wide corrections. This should not be used for equivalent alternatives when the function is not known with certainty (see Guideline B.2.4).

Technique B.2.3.1-7 [Advisory]: Providing a mechanism for authors to navigate sequentially among uncorrected accessibility errors. This allows the author to quickly scan accessibility problems in context.

Technique B.2.3.1-8 [Advisory]: Consulting the Techniques for Accessibility Evaluation and Repair Tools [AERT] Public Working Draft document for evaluation and repair algorithms.

Level AA Success Criteria for Guideline B.2.3

B.2.3.2 Repair Accessibility (AA): For each WCAG Level AA accessibility
problem that is identifiable during checking, repair assistance is provided.

See Techniques for B.2.3.1 using WCAG Level AA.

Level AAA Success Criteria for Guideline B.2.3

B.2.3.3 Repair Accessibility (AAA): For each WCAG Level AAA accessibility
problem that is identifiable during checking, repair assistance is provided.

Level A Success Criteria for Guideline B.2.4

B.2.4.1 Accept, Modify, Reject:Authors have
the opportunity to accept, modify, or reject any authoring tool-supplied equivalent
alternative, prior to insertion.

Technique B.2.4.1-1 [Sufficient]: Providing a mechanism for the author to accept, modify, or reject any equivalent alternatives that the authoring tool supplies during the insertion process.

Technique B.2.4.1-2 [Advisory]: Allowing the author to accept patterns of future uses of an equivalent alternative under certain conditions (e.g., whenever the same object is marked with the same semantic role).

Technique B.2.4.1-3 [Advisory]: If the author changes the alternative equivalent for a non-text object,
asking the author whether all instances of the object with the same
known function should also be updated.

Technique B.2.4.2-2 [Advisory]: Providing an editing capability for any equivalent alternatives managed by the tool.

Example: A text equivalents registry viewer allows the author to query and edit the various text equivalents stored in the registry. For maximum flexibility, the design takes into account multiple non-text objects of the same name, multiple types of text equivalents for each non-text 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 "object" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the object has three text labels. The author has selected one ("An earth rise as seen from the moon") in order to edit it. In addition some authoring tips are included ("Alternate text should be 10 words or less and should include any text in the image", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have "bullet" as alternate text."(Source: mockup by AUWG)

Level AA Success Criteria for Guideline B.2.4

B.2.4.3 Acceptable Sources: Authoring tools only supply equivalent alternatives from the following sources:

(a) Author-Entered: equivalent
alternatives previously entered by authors for
the same non-text
object (e.g., by the same author, or another author on
a collaborative system),

Technique B.2.4.3-1 [Sufficient]: Placing, within the appropriate field of the non-text object editing dialog box, a text alternative (or multiple alternatives if a drop-down is used) that was obtained from one of the acceptable sources.

Level AAA Success Criteria for Guideline B.2.4

B.2.4.4 Save for Reuse: Authors can store, for future reuse, both of the following author-assigned equivalent
alternatives (as applicable):

Technique B.2.4.4-1 [Sufficient]: Maintaining a registry
that associates object identity information with the text and URIs of alternative information (e.g., making use of the Resource Description Framework (RDF) [RDF10]). Whenever an object
is used and an equivalent alternative is collected, via prompting (see Guideline B.2.1)
or repair (see Guideline B.2.3) the object's identifying information and the alternative information is added to the registry. The stored alternative
information is presented back to the author as default text in the appropriate field, whenever
the associated object is inserted.

Technique B.2.4.4-2 [Advisory]: Allowing several different versions of alternative information to be associated with a single object.

TechniqueB.2.4.4-3 [Advisory]: Ensuring that the stored alternative information required
for pre-authored content (see Guideline B.1.5) is made interoperable with the management
system to allow the alternative equivalents to be retrieved whenever the
pre-authored content is inserted.

Technique B.2.4.4-4 [Advisory]: Using the stored alternatives to support keyword searches of the object database (to simplify the task of
finding relevant images, sound files, etc.).

Technique B.2.4.4-5 [Advisory]: Allowing the equivalents alternatives registry to be made shareable between authors in collaborative systems.

Note: Equivalent
alternatives should not be automatically generated from unreliable sources (e.g., file
names should not be used as text alternatives).

Applicability Notes:

Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of content (in the final technology) created through their proper use.

Level A Success Criteria for Guideline B.2.5

B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG Level A when used.

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

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

See Techniques or B.2.5.3 for ways in which the status might be stored.

Technique B.2.5.4-3 [Advisory]: Advising the author that templates should be held to a high accessibility standard, since they will be repeatedly reused.

B.2.5.6 Templates in Repository: If the authoring tool provides a
repository of templates, then each of the templates has a recorded accessibility status.

See Techniques for B.2.5.3 for ways in which the status might be stored.

B.2.5.7 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:

Example: 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 associations have all been pre-loaded into the equivalent alternative management system so that whenever the author inserts an image its equivalent alternatives are automatically retrieved.

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

See Techniques for B.2.5.3 for ways in which the status might be stored.

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

Note: In addition to the normative requirements of
this principle, implementers should also consider close integration of features
that support accessible authoring with the "look-and-feel" of
other features of the authoring tool. This type of integration has the
potential to:

However, whenever new features are introduced into an authoring tool,
striking the right design balance between the similarity with existing
features and the provision of new functionality is often more of an art
than a science.

Technique
B.3.1.1-2 [Sufficient]: Providing the more accessible choice with a higher position in the menus and having it appear in interface shortcuts such as toolbars.

Example: 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.). An (Source: mockup by AUWG)

Level AA Success Criteria for Guideline B.3.1

B.3.1.2 Accessible Actions Prominent (Enhanced): If authors are provided with a choice of authoring
actions to achieve the same mainstream rendered outcome, then actions that implement accessible
authoring practices are more prominent than the other action(s).

Level AAA Success Criteria for Guideline B.3.1

Rationale: When accessibility considerations are a natural part of the workflow, they become a routine part of authoring.

Level A Success Criteria for Guideline B.3.2

(No level A success criteria for Guideline B.3.2)

Level AA Success Criteria for Guideline B.3.2

B.3.2.1 Sequencing Features: Function that sequences authoring actions for authors (e.g., wizards) provide any accessibility prompts relevant to the content being
edited at or before the first opportunity to successfully complete
the function.

B.3.2.2 Sequenced Instructions: Instructions (e.g., tutorials,
reference manuals, design guides) that consist of a sequence of
steps for authors to follow include the relevant accessibility
authoring practices in the sequence before the first
opportunity to successfully complete
the sequence.

Level AAA Success Criteria for Guideline B.3.2

(No level AAA success criteria for Guideline B.3.2)

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

Level A Success Criteria for Guideline B.3.3

Technique B.3.3.1-1 [Sufficient]: Ensuring that all accessible content support features are turned on by default within the authoring tool preferences area.

Example: The preference setting area of an authoring tool, open to an "Accessibility" section, shows the default settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the following options: "Check accessibility as you type", "Check accessibility after saving", "Auto-correct when possible", "Highlight accessibility related fields", "Prompt when highlighted fields are left blank", and "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)

B.3.3.2 Reactivate Option: If authors deactivate
an accessible
content support feature, then they can always
reactivate the feature.

Technique B.3.3.2-1 [Sufficient]: Providing an authoring tool preferences area where any deactivated features can be reactivated.

Level AA Success Criteria for Guideline B.3.3

B.3.3.3 Deactivation Warning: If authors deactivate
an accessible content support feature, then the authoring tool informs
them that this may increase the risk of content accessibility problems.

Technique B.3.3.3-1 [Sufficient]: Providing the author with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.

Example: In an authoring tool, the author has unchecked a "highlighting accessibility
related fields" feature the tool. As a result the tool displays a warning that reads "You have just
turned off the highlighting accessibility related fields feature. This feature
is designed to inform you when information must be provided in order for
your documents to comply with your target accessibility setting. Turning
this feature off could cause your documents to be less accessible to many
users. In some jurisdictions accessibility is a legal requirement. Are you
sure you want to proceed?". The author has the option to answer "Yes", "No" or "Cancel". (Source:
mockup by AUWG)

Technique B.3.3.4-1 [Sufficient in combination]: Ensuring that prompting for accessibility information
has the same prominence as prompting for information critical to content correctness (e.g., a tool that prompts the author for a required multimedia file name attribute has prompts with the same prominence
for short text labels and long descriptions for that object.

Example: An "Image Properties" dialog box in which the input fields
are ordered (from top to bottom, left to right): source ("src"), short label ("alt"), long description ("longdesc"), height, and width. The buttons at the bottom are "More...", "OK" and "Cancel". (Source: mockup by AUWG)

Technique B.3.3.4-2 [Sufficient in combination]: Ensuring that utilities for checking and repairing accessibility problems
has the same prominence as utilities for checking for information critical to content correctness (e.g., a tool that checks for spelling, grammar, or code syntax will
have checks with the same prominence as checking for accessibility problems).

Example: An authoring interface that checks
for and displays spelling and accessibility errors with the same prominence in that both are shown as underlines, one red, one blue.
In this case, the author has activated a right-click pop-up menu on the word "CHZ" that includes
spelling repair options ("1 Khz", "2 Chi", "Check Spelling...") and accessibility repair options ("Repair: Set acronym expansion…", "Skip", "Ignore", and "Check Accessibility...") and "Help...". (Source: mockup by AUWG)

Technique B.3.3.4-3 [Sufficient in combination]: Ensuring that documentation for accessibility has the
same prominence as documentation for information critical to content correctness.
(e.g., a tool that documents any aspect of its operation will have documentation
with the same prominence for accessibility).

Example: Accessibility documentation
is part of the main documentation of an authoring tool, with very similar prominence
to that of the spelling-related features. In the right pane is the documentation table of contents, where "Accessibility Features" appears as a top level topic just below "Spelling Features". In the left panel is the help text, demonstrating a style typical of the rest of the help system: "Checking for Accessibility: A variety of accessibility checking options are available: Accessibility verifier, Check accessibility as you type, Manual test support materials.
These are suitable for use at different times during the authoring process and all have options that can be changed with the accessibility preferences. To get more information on accessible Web content, see the References.". (Source: mockup by AUWG)

Level AAA Success Criteria for Guideline B.3.3

(No level AAA success criteria for Guideline B.3.3)

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

Level A Success Criteria for Guideline B.3.4

Technique B.3.4.1-1 [Sufficient]: Ensuring that the help system answers
the question "What features of the tool encourage the production
of accessible content?" with reference to all of the accessible content support features and for each feature identified, the help system answers the question "How are these features operated?".

Technique B.3.4.1-2 [Advisory]: Providing direct links from accessible content support features to context sensitive
help on how to operate the features.

Technique B.3.4.1-3 [Advisory]: Providing direct links from within the accessibility-related documentation that take the author directly to the relevant accessible content support features.

Technique B.3.4.1-4 [Advisory]: During prompting and repairs, providing the author
with immediate access to some basic accessibility documentation and one-step
access to more comprehensive documentation.

Example: An accessibility
checker includes some limited tips for authoring short text labels listed beneath the
text entry area as well as a "Help" button linking to the full documentation. The tips are: "Alternate text should be 10 words or less and should include any text in the image.", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have 'bullet' as alternate text.". The screen shot also includes the name of the problem ("Missing Alternate Text Label for an Image"), a field for adding the short text label and a preview rendering of the image ("earthrise"). At the bottom are five buttons: "Help", "< Back", "Repair", "Skip", and "Cancel". (Source:
mockup by AUWG)

Level AA Success Criteria for Guideline B.3.4

(No level AA success criteria for Guideline B.3.4)

Level AAA Success Criteria for Guideline B.3.4

B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible
authoring process that is specific to the authoring tool is provided.

Technique B.3.4.2-1 [Sufficient]: Providing a tutorial that describes how to use the authoring tool to increase the accessibility of Web content. The tutorial begins at the typical starting point for the tool (e.g., empty document) and, for example, describes how accessibility prompting should be followed as content is being added or modified. The tutorial also covers when and how checking and repair should be performed.

Technique B.3.4.2-2 [Advisory]: Ensuring that wherever rationales appear, the text avoids referring to accessibility features
as being exclusively for particular groups (e.g., "for blind authors"). Instead, the 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).

Technique B.3.5.1-1 [Sufficient]: Ensuring that in the authoring tool documentation, all examples of content conform to WCAG Level
A and also that all screen shots of the authoring tool interface are in states that corresponds with the production of content that conforms to Level A (e.g., prompts filled in, optional accessibility features turned on, etc.).

Example: Documentation for
the input element in this instruction-level authoring tool makes use
of the label element in an example in order to reinforce the routine nature
of the pairing. The help text reads: "Input Element: Input elements are form controls. They let the reader of your page use text entry, checkboxes, radio buttons, etc. to interact with your page. The most important attribute of the INPUT element is type. The value of type can be: button, checkbox, file, hidden, image, password, radio, reset, submit, and text. Examples:<label>Enter your name: <input type="text" name="name" maxlength="30"></label><input type="submit">. (Source: mockup by AUWG)

Conformance
Claims

Conditions on Conformance
Claims

At least one version of the conformance claim must be published on the
Web as a document meeting level "A"
of Web content accessibility. A suggested metadata description
for this document is "ATAG 2.0 Conformance Claim".

Whenever the claimed conformance level is published (e.g., in marketing
materials), the URI for the on-line published version of the conformance
claim must be included.

The existence of a conformance claim does not imply that the W3C has
reviewed the claim or assured its validity.

Claimants may be anyone (e.g., developers, journalists, other third parties).

Claimants are solely responsible for the accuracy of their claims and
keeping claims up to date.

Claimants are encouraged to claim conformance to the most recent version
of the Authoring Tool Accessibility Guidelines Recommendation that is available.

Required Components of an ATAG 2.0 Conformance Claim

The name of the authoring tool and sufficient additional information
to specify the version (e.g., vendor name, version number, minor release
number, required patches or updates, natural language of the user interface
or documentation). The version information may be a range (e.g., "this
claim refers to version 6.x").

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. Note: The burden is on the conformance claimant rather than the developer of any of the software components.

The version and URI of the Web Content Accessibility Guidelines
document used to evaluate the accessibility of the Web-based
functionality.

For non-user agent platforms, provide:

The name and version information of the platform(s) (e.g., operating system, Java virtual machine, etc.).

The name and version of the accessibility platform architecture(s)
employed.

Optional Components of an ATAG 2.0 Conformance Claim

A description of the authoring tool that identifies the types of editing views that it includes.

A description of how the normative ATAG 2.0 success criteria were met where this may not be obvious.

"Progress
Towards Conformance" Statement

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

(e) If the tool offers the author previously used labels or special
function label text (see (c)) then editable text entry boxes with drop-down lists should be used to allow the author the option of entering different text (see Example
A-1a).

(f) In code-based tools, prompt the author with short text labels that are already marked up appropriately (see
Example A-1b).

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

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

(a) Prompts for multiple text labels may be similar to those for short
text labels, with allowance made for rapidly adding several labels (e.g. a spreadsheet type of control). (see Example
A-2)

(b) Provide a rendered view of the various objects being labeled, while the author is composing the labels. (see Example
A-2)

(c) If the objects have URIs (e.g. image map areas), display these as a hint for the labels. (see Example
A-2)

(d) If the objects have URIs (e.g. image map areas), offer to automatically generate a set of plain text links from the
labels that the user completes. (see Example
A-2)

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

(a) Begin by prompting the author as to whether the inserted object
is adequately described with an existing short text label. Providing a
view of the page with rendering of the object turned off may help the author decide. (see
Example A-3)

(b) If the short text label is determined to be inadequate, prompt the author for the
location of a pre-existing description. (see
Example A-3)

(c) If the author needs to create a description, provide a special writing
utility that includes a rendered view of the object and description writing
advice.

(d) Implement automated routines that detect and ignore some objects
that do not require long text descriptions (e.g., bullets, spacers, horizontal
rules).

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

(4):
Prompting and assisting for form control labels:

(b) For formats in which form control labels are external to the actual form control elements (e.g. HTML), allow the author to either directly add a form control label or identify pre-existing text
strings that are already serving implicitly as labels.

(c) It may be helpful to render the form controls with indicators of label associations or missing labels.

(d) It may be helpful to redisplay the controls in spreadsheet form to assist the author in determining author which controls are lacking labels. (see
Example A-4)

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

(5):
Prompting and assisting for form field place-holders:

(b) Provide authors with the option of directly selecting nearby text
strings that are serving implicitly as labels and use the text as place-holders.

(6): Prompting
and assisting for TAB order sequence:

(a) At the very least, provide a field for entering the TAB order number for any element that can appear in the TAB order.

(b) Manage the TAB order to prevent duplicate TAB indices and to reduce the need for manual renumbering.

(c) Provide contextual information to supplement the basic TAB order numbers, such as the label or name of controls.

(d) Provide the author with a point-and-click numbering tool that they can use to select
controls to quickly create a TAB order.

(e) Provide a list of links and controls to check the TAB order.

(f) Where there are only a few links that change in each page of a collection, ask the author to confirm whether these links receive focus first. If so, then the tool can appropriately update the tabindex order.

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

(8):
Prompting and assisting for contrasting colors:

(b) To help the author test the contrast, provide gray scale and black and white views or suggest that the author
activate the operating system high contrast mode.

(c) Emphasize "Web-safe" colors.

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

(a) Prompt the author for the location of pre-existing alternative
resources for multimedia.

(b) Provide a single utility where the various alternative resources can be managed at the same time.

(c) Although producing alternative resource for multimedia can be a
complex process for long media files, production suites do exist or authoring
tools can include simple utilities, with built-in media players, for producing
simple alternative resources.

(d) The tool should make an attempt to access existing alternative resources for multimedia,
which may be incorporated into media (e.g., as text or secondary audio tracks) or be located separately but nearby within content.

(11):
Prompting and assisting for document structure:

(a) Alert the author to the occurrence of unstructured content in a way
that is appropriate to the workflow of the tool.

(b) Provide the author with options for creating new content that is structured,
such as:

templates (with pre-defined structure),

wizards (that introduce structure to content through a series of
system-generated queries), or

real time validators (that may be set by the author to prevent the
creation of improperly structured content)

(c) Provide the author with options for imposing structure on existing unstructured
content.

For tools that support explicit structural mechanisms offer authors
the opportunity to use those mechanisms. For example, for DTD or schema
based structures, provide validation in accordance to the applicable
DTD or schema.

For tools that do not support explicit structural mechanisms, offer
authors the option of deriving structure from format styles. For example,
provide authors a mechanism to map presentation markup that follows
formatting conventions into structural elements. For example, patterns
of text formatting may be interpreted as headings (see
Example A-11) and multiple lines of text beginning items
with certain typographical symbols, such as "*" or "-",
may be interpreted as list items.

(d) Provide structure-based editing features, such as:

hide/show content blocks according to structure,

shift content blocks up, down, and sideways through the document
structure, or

hierarchical representation or network diagram view of the document
structure, as appropriate.

(g) It is not necessary to prohibit editing in an unstructured mode. However,
the tool should alert authors to the fact that they are working in an
unstructured mode.

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

(12):
Prompting and assisting for tabular structure:

(a) Prompt the author to identify tables as used for layout or data
or implement automated detection mechanisms.

(b) Differentiate utilities for table structure from utilities for document
layout - use this when tables are identified as being for layout.

(d) Prompt the author to group and split columns, rows, or blocks of
cells that are related.

(e) Provide the author with a linearized view of tables (as tablin does).

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

(13):
Prompting and assisting for style sheets:

(a) Use style sheets, according to specification, as the default mechanism
for presentation formatting and layout.

(b) If content is created with a style sheet format, along with a content
format, the use of that style format must also meet the requirements of
WCAG.

(c) Conceal the technical details of style sheet usage to a similar
degree as for usage of other markup formats supported by the tool.

(d) Assist the author by detecting structural markup (e.g., header tags, etc.) that has been misused
to achieve presentation formatting and, with author permission, transforming
it to use style sheets. (see Example A-13)

(e) Prompt the author to create style classes and rules within and across
document, rather than using more limited in-line styling.

(f) Assist the author by recognizing patterns in style sheet use and
converting them into style classes and rules.

(h) Assist the author with the issue of style sheet browser compatibility
by guiding them towards standard practices and detecting the existence
of non-standard practices.

(i) Assist the author by providing a style sheet validation function.

(j) Maintain a registry of styles for ease of re-use.

(k) For prompting and assisting with specific types of information required
by style sheets, see the other sections in this technique. For example:
font/background colors (see (8)) and document structure (see (12)).

(l) Consult the following references: Accessibility Features of CSS [CSS2-ACCESS] and XML languages [XAG].

Example A-13: A WYSIWYG authoring tool that indicates to the author that
a heading has been misused to indicate emphasis. In the WYSIWYG editing view, some text ("VERY HOT") is rendered large and bold because it has been improperly marked as a heading and it is therefore marked with a blue underline as an accessibility problem. The author has brought up a pop-up menu for the text and sees the following options: "Repair: Mark with style (a sub-menu displays the different styles available: .bodytext, .quotetext, .hot_emphasis, .cold_emphasis)", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG).

(14): Prompting
and assisting for clearly written text:

(a) Prompt the author to specify a default language of a document.

(b) Provide a thesaurus function.

(c) Provide a dictionary lookup system that can recognize changes of
language, terms outside a controlled vocabulary as well as known abbreviation
or acronym expansions.

(d) Provide an automated reading level status. (see
Example A-14a)

(e) Prompt the author for expansions of unknown acronyms, recognizable
in some languages as collections of uppercase letters. (see Example
A-14b)

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

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

(15): Prompting
and assisting for device independent handlers:

(a) During code development, prompt the author to include device-independent
means of activation.

(16):
Prompting and assisting for non-text supplements to text:

(b) Where subject metadata is available, look up appropriate illustrations.

(c) If the author has identified content as instructions then provide
templates or automated utilities for extracting flow charts, etc.

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

(17): Prompting and assisting the author to make use of up-to-date technologies:

(a) Default to the most up-to-date technologies available whenever the author
has not specified a technology.

(c) Provide tools that convert content in older technologies into more up
to date ones.

(d) Fully or partially automate some of the more complex aspects of
more up to date technologies, including document structure (see (11))
and use of style sheets (see (13)).

Appendix B: Levels of Checking Automation

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 errors ("Image missing alternate text" and "Text boxes missing labels) with number of errors appended (e.g., "[6]") and the sub-items are the problem instances with line numbers appended (e.g., "(Line:45)"). (Source:
mockup by AUWG)

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

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

(b) Semi-Automated Checking:

In semi-automated checking, the tool is able to identify potential problems,
but still requires human judgment by the author 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 the at this is indeed an accessibility
problem by choosing and move on to the repair stage by choosing "Yes" or press "No" to mark the potential problem, as not a problem at all. Additional help is available in the form of a tip: "An image requires descriptive text when the information it contains cannot be conveyed in 10 words or less using an alternate text label." (Source:
mockup by AUWG)

(c) Manual Checking:

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

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

Appendix C: Levels of Repair Automation

This list is representative, but not necessarily complete.

(a) Repair Instructions:

In manual repairing, the tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial 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 the author to follow the instructions and make the repair by themselves. This is the most time consuming option for authors and allows the most opportunity for human error.

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

(b) Semi-Automated:

In semi-automated repairing, the tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete. For example, the tool may prompt the author 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 the author to make the final selection. This type of repair is usually appropriate for corrections of a semantic nature.

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

(c) Automated:

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

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

Appendix D: Author Interruption Timing Options

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.

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

(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 errors which causes them not to meet a "standard of publishing" the author has set for themselves in the options. As a result the files are selected, a message is displayed ("The selected files do not meet your specified standard for publishing.") and the "publishing" button is grayed out. This standard is referred to generally since it is assumed that it might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)

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

Appendix E: Real-Time Content Production

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

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

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

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

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

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

Implementing the management functionality for equivalent alternatives (see Guideline B.2.4). This way, if the author uses an object that has been used before, the tool can suggest the previously stored alternative, which the author can quickly accept or decline without substantial workflow disruption.

Providing a voice recognition capability so that the author's real-time speech input can be converted into captioning.

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

Shortened form of a word, phrase, or name where the abbreviation has not become part of the language. Includes:

initialism: shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase (e.g., ESP is an initialism for extrasensory perception).

acronym: abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word (e.g., WAI is an acronym made from the initial letters of the Web Accessibility Initiative).

accessibility
platform architecture

A programmatic interface that is specifically engineered
to enhance communication between mainstream software applications and assistive technologies (e.g., MSAA and IAccessible2
for Windows applications, Gnome Accessibility Toolkit API for Gnome applications, Java
Access for Java applications). On some platforms it may be conventional to enhance communication further via implementing a document object.

accessibility
problem

ATAG 2.0 refers to two types of accessibility problems:

authoring tool user interface accessibility
problem: An aspect of
an authoring
tool user interface that does not to meet one of the guideline success
criteria in Part A of this document. The severity of
a given problem is reflected in the level of the failed success criteria.

Any features of an authoring tool that directly support authors in increasing the accessibility of the content being authored. Specifically, this will include any functionality that is used to meet the success criteria for B.2.1, B.2.2, B.2.3, B.2.4, and B.2.5.

ASCII art[WCAG 2.0]

Picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).

Software and/or hardware that provides services to meet the requirements of users with disabilities that go beyond direct accessibility features offered by mainstream software applications and hardware. Such services include alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible). Examples of assistive technologies that are important in the context of this document include the following:

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order improve the visual readability of rendered text and images;

screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;

text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

voice 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;

alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

Mainstream software applications and hardware may also provide services directly that meet the requirements of users with disabilities.

audio
description - also called described video, video description and descriptive narration[WCAG 2.0]

An equivalent
alternative that takes the form of narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. In standard audio description, narration is added during existing pauses in dialogue. In extended audio description, the video is paused so that there is time to add additional description.

authoring
action

Any action that authors take
using the authoring
tool user interface with the intention of editing content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., setting preferences for the tool, searching the help system).

authoring
outcome

A characteristic of content that
results from one or more authoring actions being applied.
Authoring outcomes exist at different levels (e.g., making a paragraph bold vs. deploying a site-wide navigation system) and are cumulative (e.g., text is entered, then styled, then made into a link, then given title). Mainstream rendered (authoring) outcomes are only the subset of content characteristics that are apparent to end-users of mainstream user agents (e.g., text that is bold, a seamless patchwork of images; but not commented code or table relationships).
Often, multiple authoring practices exist that will result in the same mainstream rendered authoring outcome, but the outcomes may differ with respect to accessibility (e.g., styled text may appear identical to an image of text on the screen, but will appear differently in audio output).

A state of the authoring tool during which content can be edited by the author. The end of an authoring session is the point in time at which a session ends and the author has no further opportunity to make changes without starting another session. This may be under the control of the author (e.g., closing a document, publishing) or it may be controlled by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative system). Note: Automated content generation may continue after the end of an authoring session (e.g., CMS updates).

Whether a person has a right to modify given Web content. In other words, whether they qualify as an author of the content. Some authoring tools are capable of managing authoring permissions in order to prevent unauthorized modifications.

authors

Any person using an authoring tool to create or modify Web
content for use by other people. This
may include content authors, designers, programmers, publishers, testers,
etc. working either alone or collaboratively. A person will only qualify as an author of given Web content if the (1) the authoring tool provides functionality to create or modify the relevant Web content technology and (2) the person has author permission for that particular Web content.

Switch back and forth between two visual states in a way that is meant to draw attention. It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash.

An equivalent
alternative that takes the form of text presented and synchronized with synchronized media to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers. In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, "subtitle" (or its translation) is used to refer to both.

Change of view or focus. Content that changes the function or meaning of an interface. A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

manual
checking: where the tests are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure;

semi-automated
checking: where the tests are partially carried out by the authoring tool, but where authors' input or judgment is still required to decide or help decide the outcome of the tests; and

automated
checking: where the tests are carried out automatically by the authoring tool without any intervention by the authors.

An authoring tool may support any combination of checking types.

collection
of software components

Any software programs that are used either together (e.g., base tool
and plug-in) or separately (e.g., markup editor,
image editor, and validation tool), regardless of whether there has been
any formal collaboration between the developers of the programs.

content being edited

The Web content that is currently being modified by the authoring tool
for use by other people.

Information and sensory experience to be communicated to the user by means of a user
agent, including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, "content" is primarily
used in the context of the output that is produced by the
authoring tool. This includes Web applications, including those that, in turn, act as Web-based authoring tools.
Accessible Web content is Web content that does not contain accessibility
problems. Usually this refers to a particular level of accessibility (e.g., Web content that meets Level "A" Web content accessibility). Accessible Web content is shorthand for content that meets a given set of accessibility criteria. This does not not necessarily mean that it will be accessible to every person with a disability.

User interface functionality that the authoring tool presents as it
renders, plays or executes Web content. In this document the term
covers conventional renderings (e.g., "WYSIWYG"), unconventional
renderings (e.g., rendering an audio file as a graphical wavefront) and partial renderings, in which some aspects of the content are rendered,
played, or executed, but not others (e.g., a frame-by-frame video editor
renders the graphical, but not the temporal aspect, of a video).

A process that takes as input, content in one Web content technology (or non-Web content technology, such as a word processing format) and produces as output, content in a different Web content technology (e.g., "Save as HTML" functions).

Any people responsible for programming the authoring tool. This will include the programmers of any components included by the claimant in the conformance claim. In some cases, development of the authoring tool is complete before the author uses it, however in other cases (e.g., some Web-based tools) the developer may continue to modify the authoring tool after content is published by the author such that the Web content experienced by the end user is modified.

display settings (audio): the characteristics of
audio output of music, sounds and speech and include volume, speech voices,
voice speed, and voice emphasis.

display settings (visual): the characteristics of
the on-screen rendering of text and graphics and include fonts, sizes,
colors, spacing, positioning, and contrast.

documentation

Any information that supports the use of an authoring
tool. This information may be found electronically or otherwise and includes
help, manuals, installation instructions, sample work flows,
and tutorials, etc.

Content that is an acceptable substitute
for other content that a person may not be able to access. An equivalent
alternative fulfills essentially the same function or purpose as the original
content upon presentation:

full text alternative for synchronized media including any interaction [WCAG 2.0]: document including correctly sequenced text descriptions of all visual settings, actions, speakers, and non-speech sounds, and transcript of all dialogue combined with a means of achieving any outcomes that are achieved using interaction (if any) during the synchronized media.

A sequence of flashes or rapidly changing image sequences where all three of the following occur:

there are more than three flashes within any one-second period,

the flashing is below 50 Hz, and

the combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).

Notes: For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. For the red flash threshold, a flash is defined as any transition to or from a saturated red. For general Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances.

To provide authors with information via the authoring tool user interface. Informing mechanisms range from unobtrusive (i.e., information presented without
stopping the authors' current activity) to intrusive (i.e., interrupting
the author's current activity). Information may be provided as part of a prompt.

informative[WCAG 2.0]

For information purposes and not required for conformance.

label[WCAG 2.0]

Text or other component with a text alternative that is presented to authors to identify a component. A label is presented to all authors 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.

mainstream applications and hardware - also called mainstream technology

Software applications and hardware for which augmenting accessibility is secondary to some other purpose (as opposed to assistive technology where it is the primary purpose). Mainstream technologies may include direct accessibility features.

markup

A set of tags from a markup
language. Markup can be presentational (i.e., markup that encodes information about the visual layout of the content), structural (i.e.,
markup that encodes information about the structural role of elements of the content) or semantic (i.e., markup that encodes
information about the intended meaning of the content). A markup language is a syntax and/or set of rules to manage markup (e.g.,
HTML, SVG, MathML).

name[WCAG 2.0]

Text by which software can identify a component to the user. The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.

non-text
content[WCAG 2.0]

Any content that is not a sequence of characters that can be made available via the platform or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which is character substitution), and images representing text.

normative[WCAG 2.0, UAAG 2.0]

Required for conformance. One may conform in a variety of well-defined ways to this document. Content identified as "informative" or "non-normative" is never required for conformance.

When an author is presented with choices. An option may be local (e.g., prompting whether to save before closing a piece of content) or global (e.g., preference settings).

platform

The software environment within which the authoring tool
operates. For non-Web-based user interface functionality this will be an operating
system (e.g., Windows, Mac OS, Linux), virtual machine (e.g., JVM) or a
higher level GUI toolkit (e.g., Eclipse). For Web-based authoring user interface functionality, "platform" applies more generically to user agents in
general, although for purposes of evaluating conformance to ATAG 2.0 a
specific user agent(s) will be listed in the conformance
profile. Available via the platform: For non-Web-based user interface functionality this means via
an implemented accessibility platform architecture. For Web-based user interface functionality this means following relevant Web content accessibility design guidelines so that the user agent can pass on the information.

plug-in [UAAG 2.0]

A program that runs as part of the authoring
tool (e.g., a third-party evaluation and repair tool) and that is not part of content being edited. Authors generally
choose to include or exclude plug-ins from their authoring tool.

A heuristic measure of the degree to which authors are likely to notice components in the authoring tool user interface when operating the authoring tool. In this document, prominence refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a component include:

Any authoring tool initiated
request for a decision or piece of information from authors. Well designed
prompting will urge, suggest, and encourage authors.

publishing

The point at which the authors of content intend to make it available to end users (e.g., uploading a Web page, committing a change in a wiki).

recognize

When an authoring tool is able to process encoded information, such as properties or relationships, with certainty. For example, an authoring tool would only be able to recognize a particular text string as a text label for a non-text object, if this relationship was appropriately encoded (e.g., in an "alt" attribute, by a "labeledby" property).

relationships[WCAG 2.0]

Meaningful associations between distinct pieces of content.

relative luminance[WCAG 2.0]

The relative perceived brightness of any point, normalized to 0 for darkest black and 1 for lightest white.

The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).

Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace.

Note 3: For dithered colors, use average values of the colors used (average R, average G, and average B).

Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

manual: where the repairs are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;

semi-automated: where the repairs are partially carried out by the authoring tool, but where authors' input or judgment is still required to complete the repair; and

automated: where the repairs are carried out automatically by the authoring tool without any intervention by the authors.

reversible
actions

Authoring actions that, by their nature, can be completely undone so that the system returns to the state it was
in before the action. Actions that are not reversible may include certain
save and delete actions as well as actions made in a collaborative environment
that another author has begun to work with.

role [WCAG 2.0]

Text or a number by which software can identify the function of a component within Web content (e.g., a number that indicates whether an image functions as a hyperlink, command button, or check box).

A mechanism for encoding instructions to be rendered, played or executed by user agents. Web Content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to multimedia presentations to dynamic Web applications. Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript.

A content pattern that is filled in by authors or the authoring tool to produce content for end users (e.g., document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.

Any software that retrieves and presents Web content for end users. Examples include Web browsers, media players, plug-ins, and other programs including assistive technologies, that help in retrieving, rendering and interacting with Web content.

A part of the user interface "chrome" or content display (including renderings) that is perceived by authors as a single control for a distinct function. In ATAG 2.0, the term is used to denote any part of the user interface of the authoring tool involved with display or control.

User interface functionality that authors use to interact with the content being edited. In addition to being editable (i.e., editing views) or non-editable (e.g. a preview that presents content as it would appear in a user agent), there are several broad approaches to presenting the content:

meta-content in which authors set high-level options that the authoring tool then interprets to generate the resulting content (e.g., a content management system that only lets authors set the month and year on a built-in calendar module).

workflow

A customary sequence of steps or tasks authors follow to produce a deliverable.

References to the latest version of "Authoring Tool Accessibility
Guidelines 2.0." Use the "latest version" URI to refer to
the most recently published document in the series: http://www.w3.org/TR/ATAG20/.

In almost all cases, references (either by name or by link) should be to
a specific version of the document. W3C will make every effort to make this
document indefinitely available at its original address in its original form.
The top of this document includes the relevant catalog metadata for specific
references (including title, publication date, "this version" URI,
editors' names, and copyright information).

An XHTML 1.0 paragraph including a reference to this specific document
might be written:

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

Appendix CE: References

For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.

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

"What is Accessible Software," James W. Thatcher, Ph.D., IBM, 1997. This paper, available at the IBM Accessibility Center, gives a short example-based introduction to the difference between software that is accessible, and software that can be used by some assistive technologies.

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