[Contents]

W3C

Authoring Tool Accessibility Guidelines (ATAG) 2.0

W3C Working Draft 21 May 2009

This version:
http://www.w3.org/TR/2009/WD-ATAG20-20090521/
Latest version:
http://www.w3.org/TR/ATAG20/
Previous version:
http://www.w3.org/TR/2009/WD-ATAG20-20090217/
Editors:
Jan Richards, Adaptive Technology Resource Centre, University of Toronto
Jeanne Spellman, W3C
Jutta Treviranus, Adaptive Technology Resource Centre, University of Toronto
Previous Editors:
Matt May (until June 2005 while at W3C)

Abstract

This specification provides guidelines for designing Web content authoring tools that are 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 by enabling, supporting, and promoting the production of accessible Web content by all authors.

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

Status of This Document

W3C Public Working Draft of ATAG 2.0

This is the W3C Working Draft of 21 May 2009. This draft integrates changes made as a result of comments received on the 17 February 2009 Public Working Draft and also includes changes intended to keep the document harmonized with WCAG 2.0. The Authoring Tool Accessibility Guidelines Working Group expects the next publication to be the Last Call Working Draft, and therefore requests that all interested parties read this draft and submit comments this review period.

Substantial changes include:

  1. The Working Group updated Guideline B.2.4 ("Assist authors with managing alternative content for non-text content.") to more clearly explain how automated tools should treat alternative content.
  2. The Working Group has substantially revised the Introduction with new material aligning with WCAG 2.0. The examples of authoring tools have been expanded and clarified.
  3. The Working Group has extensively reviewed and updated all glossary definitions including adding new definitions where needed for clarity. The glossary definitions that have been aligned with other W3C documents have been noted.
  4. The Working Group has addressed editorial comments received on the 17 February 2009 Working Draft and completed a general editorial review for clarity.

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

Comments made before 11 June 2009 would be particularly valuable so that the comments can be reviewed at the Face to Face meeting of the Authoring Tool Accessibility Guidelines Working Group on 15 June. Comments on the draft should be sent to public-atag2-comments@w3.org (Public Archive).

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

May be Superseded

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

Web Accessibility Initiative

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the AUWG are discussed in the Working Group charter. The AUWG is part of the WAI Technical Activity.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


Table of Contents


Introduction

This section is informative, except where noted.

This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version 2.0. This document includes recommendations for assisting authoring tool developers to make the authoring tools that they develop more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others.

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

Notes:

  1. ATAG 2.0 recommends that authoring tools be capable of producing Web content that conforms with WCAG 2.0. However, even Web content that conforms to the highest level of WCAG 2.0 (AAA) may not be "accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas" (WCAG 2.0). Creation of authoring tools that address more specialized needs is encouraged, but is beyond the scope of this document.
  2. The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.
  3. Authoring tools are just one aspect of Web accessibility. For an overview of the different components of accessibility and how they work together see:

Definition of authoring tool

This section is normative.

ATAG 2.0 defines an "authoring tool" as "any software 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".

Notes on the Definition:

  1. ATAG 2.0 applies to a wide variety of Web content generating applications, including, but not limited to:
    • "conventional" web page authoring tools (e.g., WYSIWYG HTML editors)
    • software for directly editing source code (e.g., text editors)
    • software for converting to Web content technologies (e.g., "Save as HTML" features in office suites)
    • integrated development environments (e.g., for Web application development)
    • software that generates Web content on the basis of templates, scripts, command-line input or "wizard"-type processes
    • software for rapidly updating portions of webpages (e.g., blogging, wikis, online forums)
    • software for generating/managing entire sites (e.g., content management systems, courseware tools, content aggregators)
    • email clients that send messages in Web content technologies
    • multimedia authoring tools
  2. Any ATAG 2.0 guideline that require authors to modify Web content in some way, always assumes that the person has author permission.
  3. Live content authoring tools (e.g., a collaborative tool that archives the conversation as Web content) are only required to meet Part A. However, many guidelines in Part B may still usefully apply, especially if the authoring tool archives as Web content. For more information, see the Techniques - Appendix E: Real-time content production.

ATAG 2.0 Layers of Guidance

The individuals and organizations that use ATAG 2.0 vary widely and include authoring tool developers, authoring tool users (authors), authoring tool purchasers, and policy makers. In order to meet the varying needs of this audience, several layers of guidance are provided including two parts, overall principles, general guidelines, testable success criteria and a collection of sufficient techniques and advisory techniques with examples and resource links.

All of these layers of guidance (parts, principles, guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make authoring tools more accessible. Authoring tool developers are encouraged to view and apply all layers that they are able to, including the advisory techniques.

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

This section is normative.

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

The relationship is as follows:

Understanding Levels of Conformance

In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in the development of authoring tools is as simple as possible, ATAG 2.0 shares WCAG 2.0's three level conformance model: Level A (lowest), AA (middle), AAA (highest).

As with WCAG 2.0, there are a number of conditions that must be met for a Success Criterion to be included in ATAG 2.0. These include:

  1. All Success Criteria must:
    • present authoring tool user interface-related access issues for people with disabilities (Part A). In other words, the access issue must cause a proportionately greater problem for authors with disabilities than it causes authors without disabilities and must be specific to authoring tool software, as opposed to software in general, or
    • present accessible Web content production issues (Part B). In other words, the issue be specific to authoring accessible Web content software, as opposed to authoring Web content in general.
  2. All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether an authoring tool met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence.

The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level in Part A included:

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

Integration of Accessibility Features

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


ATAG 2.0 Guidelines

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

PART A: Make the authoring tool user interface accessible

Applicability Notes:

  1. Scope: The success criteria in Part A apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes functionalities that are independent of the Web 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, documentation, etc.
  2. Reflected Content Accessibility Problems: The authoring tool developers' responsibility covers features that reflect the content being edited (e.g., ensuring that an image label present in the content is available via the platform). However, where an authoring tool user interface accessibility problem is caused directly by a Web content 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.
  3. Applies to Features for Part B: Part A applies to the entire authoring tool user interface, including any of the features (e.g., checking tool , tutorials) added to meet the Part B success criteria.

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

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

Rationale: In addition to generally improving the accessibility of the authoring tool user interface, using accessible Web content to implement Web-based functionality (e.g., authoring tools that implemented as Web applications) facilitates communication with assistive technologies via user agents.

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

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

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

Applicability Notes:

This guideline also applies to any parts of authoring tools that are Web-based (e.g., help systems).

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

Rationale: When authoring tools are not Web-based (i.e., they run directly on platforms such as Windows and MacOS that are not user agents), following existing accessibility standards and/or platform conventions will facilitate access by all people, including those using assistive technologies.

A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (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 2.0 Level A success criteria. (Level A)

A.1.2.2 Non-Web-Based Accessible (Level AA): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) the "Level AA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AA" requirements are those that are functionally equivalent to WCAG 2.0 Level AA success criteria. (Level AA)

A.1.2.3 Non-Web-Based Accessible (Level AAA): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) the "Level AAA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AAA" requirements are those that are functionally equivalent to WCAG 2.0 Level AAA success criteria. (Level AAA)

Applicability Notes:

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

PRINCIPLE A.2: Editing views must be perceivable

Guideline A.2.1 [For the authoring tool user interface] Provide access to alternative content in the Web content. [Techniques]

Rationale: People who have difficulty perceiving non-text content 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).

A.2.1.1 Recognized Alternative Content: If an editing view includes renderings of non-text content (e.g., WYSIWYG view), then authors have access to any alternative content for the rendered non-text content that are recognized by the authoring tool. (Level A)

Applicability Notes:

This guideline does not apply to editing views, such as plain text editors, that do not render non-text content.

Guideline A.2.2 [For the authoring tool user interface] Provide programatic access to information in the editing view. [Techniques]

Rationale: Authors need access to the information signified by presentation added by the authoring tool. In addition, since content rendering editing views support a workflow in which authors are constantly able to observe the end user experience, authors with disabilities also need access to the presentation that will be experienced by end users.

A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of Web content to provide authors with additional information (e.g., underlining misspelled words), then that additional information is made available via the platform. (Level A)

A.2.2.2 Access to Text Presentation (Minimum): If any of the following text presentation properties are editable by the authoring tool (even via a different editing view), then if the property is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform (Level A):

  • (a) text font,
  • (b) text style (e.g., italic, bold),
  • (c) text color, and
  • (d) text size.

A.2.2.3 Access to Text Presentation (Enhanced): If any text presentation property (text size, text positioning, etc.) can be modified by the authoring tool (even via a different editing view), then if it is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform. (Level AAA)

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

Rationale: Some authors need display settings that differ from the presentation that they define for the published Web content (e.g., an author may zoom an editing view in order to modify text that will appear small by default to end users).

A.2.3.1 Independence of Display: Content rendering editing views (e.g., WYSIWYG) allow the authors' visual display settings and audio display settings to take precedence in the editing view without affecting the Web content being edited (i.e., no effect on markup, style sheets, etc.). (Level A)

PRINCIPLE A.3: Editing views must be operable

Guideline A.3.1 [For the authoring tool user interface] Enhance keyboard access to authoring features. [Techniques]

Rationale: Keyboard accessibility provides access to people with limited mobility or visual disabilities, who are not able to use a mouse to navigate.

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

  • (a) open help system,
  • (b) open new content,
  • (c) open existing content,
  • (d) save content,
  • (e) close content,
  • (f) cut/copy/paste,
  • (g) undo/redo, and
  • (h) open find/replace function.

A.3.1.2 Avoiding Content Keyboard Traps: The authoring tool prevents keyboard traps by both of the following (Level A):

  • (a) in the authoring tool user interface: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key) and
  • (b) in the rendered editing views: a documented direct keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus) and a documented direct keyboard command is provided that will always move keyboard focus to the subsequent element that can receive focus.

Applicability Notes:

Web-based authoring tools may rely on the keyboard navigation features of the user agent listed in the conformance profile to help satisfy some of these success criteria.

Guideline A.3.2 [For the authoring tool user interface] Minimize time limits on authors. [Techniques]

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

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

A.3.2.2 Timing Adjustable: If the authoring tool includes time limits, then authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. pressing the enter key to accept more time). (Level A)

A.3.2.3 Moving Targets: If a user interface component that accepts mouse input is capable of movement (e.g., animated vector graphic), provide authors with the option to stop the movement. (Level A)

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

Rationale: Flashing can cause seizures in people with photosensitive epilepsy.

A.3.3.1 Static View: If an editing view renders time-based content (e.g., animations), provide authors with the global option of rendering only the initial state of time-based content. (Level A)

Guideline A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content structure. [Techniques]

Rationale: Authors who have difficulty typing or operating the mouse benefit when authoring tools make use of the structure present in Web content to simplify the tasks of navigation and editing the content.

A.3.4.1 Edit by Structure: If an editing view displays a structured element set, then authors can select any element in the structured element set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. (Level A)

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

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

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

  • (a) Parent: the element immediately above,
  • (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.

Guideline A.3.5 [For the authoring tool user interface] Provide text search. [Techniques]

Rationale: Authors who have difficulty typing or operating the mouse benefit from the ability to navigate to arbitrary points within editing views.

A.3.5.1 Text Search: Authors can perform text searches of Web content in which all of the following are true (Level AA):

  • (a) Search All Editable: authors can search within any information that is text and that the authoring tool can modify(e.g., text content, text alternatives for non-text content, metadata, markup).
  • (b) Bi-Directional: authors can search forwards and backwards. [UAAG 2.0]
  • (c) Case Sensitive: authors can search in both case sensitive and case insensitive modes. [UAAG 2.0]
  • (d) May Switch Views: it is permissible to require that authors switch editing views to perform searching (e.g., from WYSIWYG view to a source content view to search for markup elements by name).

Applicability Notes:

Web-based authoring tools may rely on the "find" function of the user agent listed in the conformance profile to help perform searches.

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

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

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

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) (Level AAA):

A.3.6.3 Options Assistance: An interactive mechanism helps authors configure options related to Part A. (Level AAA)

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

Rationale: Preview features are provided in many authoring tools because the workflow of authors often includes periodically checking how user agent will display the Web content to end users. 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 user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A, if they meet this guideline.

A.3.7.1 Return Mechanism: If a preview is provided, then it is possible for authors to return from the preview using only keyboard commands. (Level A)

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

  • (a) Existing User Agent: the preview makes use of an existing user agent that is specified in the conformance 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
  • (c) UAAG: the preview conforms to the User Agent Accessibility Guidelines [UAAG].

PRINCIPLE A.4: Editing views must be understandable

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

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

A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. (Level A)

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

A.4.1.3 Redo: Authors can immediately reverse the most recent "undo" action(s) (i.e., a "redo" function). (Level AA)

A.4.1.4 Multiple Undos: Authors can reverse at least 5 consecutive reversible authoring actions. (Level AAA)

Applicability Notes:

Guideline A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features. [Techniques]

Rationale: While intuitive user interface design is valuable to many authors, some may still not be able to understand or be able to operate the authoring tool user interface without proper documentation.

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

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

Applicability Notes:

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

PART B: Support the production of accessible content

Applicability Notes:

  1. Author Availability: Any success criteria in Part B that refer to authors only apply during authoring sessions when authors are available.
  2. Responsibility After Authoring Sessions: Authoring tools are not responsible for Web content accessibility problems that result from carrying out instructions made by authors during authoring sessions (e.g., the content of a third-party feed specified by the author), but they are responsible if the Web content accessibility problems are automatically generated (e.g., a content management system developer makes site-wide changes to template in use).
  3. Existing Technologies: The success criteria in Part B only apply to support for accessible authoring practices that can be used with the Web content 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.
  4. 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., an authoring tool could make use of a third-party software accessibility checking and repair tool).

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

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

Rationale: Choosing Web content technologies which support the possibility of accessible Web content is a critical first step.

B.1.1.1 Tool Choice of Technologies: Only accessible technologies are ever automatically selected by the authoring tool. (Level A)

B.1.1.2 Author Choice of Technologies: If the authoring tool provides authors with Web content technology options, then any accessible technology options that are suitable for the task are at least as prominent as any other technology options. (Level A)

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

Rationale: Accessibility information is critical to maintaining comparable levels of accessibility across transformations and conversions.

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

B.1.2.2 Target Cannot Preserve Accessibility Information: If the Web content technology of the output of a the transformation or conversion cannot preserve recognized accessibility information that is required for that Web content to conform to WCAG 2.0 Level A, then both of the following are true:

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

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

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

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

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

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

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

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

Applicability Notes:

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

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

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

See also: For more information on how to prompt, see ATAG 2.0 Techniques - Appendix A: Prompting for Different Types of Accessibility Information. Repair features (see Guideline B.2.3) are also an important aspect of guiding authors.

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

B.2.1.2 Guide Accessible (Level AA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AA (Level AA).

B.2.1.3 Guide Accessible (Level AAA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AAA (Level AAA).

Guideline B.2.2 Assist authors in checking for accessibility problems. [Techniques]

Rationale: Checking as an integrated function of the authoring tool helps make authors aware of Web content accessibility problems during the authoring process, so they can be immediately addressed.

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

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

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

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

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

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

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

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

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

Applicability Notes:

Guideline B.2.3 Assist authors in repairing accessibility problems. [Techniques]

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.

B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level A)

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

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

Applicability Notes:

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

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

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

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

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

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

B.2.4.4 Special Values: The authoring tool follows recommendations on special values for alternative content (e.g., in HTML4, alt="" denotes images that should be ignored by assistive technology). (Level A)

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

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

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

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

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

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

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

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

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

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

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

  • (a) Indicate: the selection mechanism indicates the accessibility status of the pre-authored content (if known).
  • (b) Prominence: any accessible options are at least as prominent as other pre-authored content options.

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

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

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 Web content (in the final Web content technology) created through their proper use.

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

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

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

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

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

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

Guideline B.3.2 Ensure that sequential authoring processes integrate accessible authoring practices. [Techniques]

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

B.3.2.1 Sequencing Features: Features that sequences authoring actions for authors (e.g., "wizard"-type mechanisms) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the sequence. (Level AA)

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 accessible authoring practices in the sequence before the first opportunity to successfully complete the sequence. (Level AA)

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

Rationale: The accessible content support features will be more likely to be used if they are turned on and are afforded reasonable prominence within the authoring tool user interface.

B.3.3.1 Active by Default: All accessible content support features are turned on by default. (Level A)

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

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

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

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

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

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

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

Guideline B.3.5 Ensure that any authoring practices demonstrated in documentation are accessible. [Techniques]

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

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

B.3.5.2 Model "AA" Accessible Practice (Enhanced): Any examples of authoring practices in the documentation demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AAA)

Applicability Notes:

An exception to these success criteria is allowed for examples that are specifically intended to demonstrate inaccessible practices to be avoided.


Conformance

This section is normative.

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

Levels of Conformance

Conformance Levels in Conformance Claims

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

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

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

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

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

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

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

Conformance Claims

A conformance claim is an assertion by a claimant that an authoring tool has satisfied the requirements of a chosen ATAG 2.0 conformance profile.

Conditions on Conformance Claims

Required Components of an ATAG 2.0 Conformance Claim

  1. Name and Affiliation of the Claimant
  2. The date of the claim.
  3. The ATAG 2.0 version, publishing date and status (e.g., "Authoring Tool Accessibility Guidelines 2.0, 24 November 2008, Working Draft ")
  4. 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 authoring tool developer of any of the software components.
  5. The conformance profile, which must include the following:
    • (a) The ATAG 2.0 conformance level that has been satisfied (see Conformance Levels).
    • (b) A list of the Web content technologies edited/produced by the authoring tool. These are the only technologies covered by the conformance claim.
    • (c)For each success criterion:
      • a declaration of whether or not the success criterion has been satisfied or
      • a declaration that the success criterion is not applicable and a rationale for why not.
    • (d) A list of any other Web content technologies produced by the authoring tool that are not covered by the claim.
    • (e) The platform(s) upon which all or part (e.g., help system) of the authoring tool was evaluated:
      • For user agent platform(s) used to evaluate Web-Based user interface functionality, provide the name and version information of the user agent(s).
      • For platforms that are not user agents, provide:

Optional Components of an ATAG 2.0 Conformance Claim

  1. A description of the authoring tool that identifies the types of editing views that it includes.
  2. A description of how the ATAG 2.0 success criteria were met where this may not be obvious.

"Progress Towards Conformance" Statement

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

Disclaimer

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


Appendix A: Glossary

This section is normative.

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

abbreviation [adapted from WCAG 2.0]
Shortened form of a word, phrase, or name where the abbreviation has not become part of the language. Includes:
  1. initialism: shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase (e.g., ESP is an initialism for extrasensory perception).
  2. acronym: abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word (e.g., WAI is an acronym made from the initial letters of the Web Accessibility Initiative).
accessibility problem
ATAG 2.0 refers to two types of accessibility problems:
  1. authoring tool user interface accessibility problem: An aspect of an authoring tool user interface that does not meet a success criterion in Part A.
  2. Web content accessibility problem: An aspect of Web content that does not meet a WCAG 2.0 success criterion.
accessibility information
Any information that is added to Web content for the purpose of conformance with WCAG 2.0 (e.g., text alternatives for images, role and state information, relationships within complex tables).
accessible content support features
Any features of an authoring tool that directly support authors in increasing the accessibility of the content being edited (i.e., features added to meet any of the success criteria in Principle B.2).
alternative content
Content that is used in place of other content that a person may not be able to access. Alternative content fulfills essentially the same function or purpose as the original content. Examples include text alternatives for non-text content, captions for audio, audio descriptions for video, sign language for audio, media alternatives for time-based media. See WCAG 2.0 for more information.
ASCII art [WCAG 2.0]
A picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
assistive technology [adapted from WCAG 2.0]
Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of users with disabilities. Some authoring tools may also provide direct accessibility features. Examples of assistive technologies include, but are not limited to, the following:
  • screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order improve the visual readability of rendered text and images;
  • screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
  • text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
  • speech recognition software, which may be used by people who have some physical disabilities;
  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices);
  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
audio [adapted from WCAG 2.0]
The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real world sounds, or both.
authoring action
Any action that authors can take using the authoring tool user interface that results in creating or editing Web content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., setting preferences, viewing documentation).
authoring outcome
The content or content modifications that result from authoring actions. Authoring outcomes are cumulative (e.g., text is entered, then styled, then made into a link, then given a title).
authoring practice
An approach that authors follow to achieve a given authoring outcome. (e.g., controlling presentation with style sheets). Depending on the design of an authoring tool, authoring practices may be chosen by the authors or by the authoring tool. An accessible authoring practice is one in which the authoring outcome conforms to WCAG 2.0 . Some accessible authoring practices require accessibility information.
authoring session
A state of the authoring tool in which content can be edited by an author. The end of an authoring session is the point at which the author has no further opportunity to make changes without starting another session. The end of an authoring session may be determined by authors (e.g., closing a document, publishing) or by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative system). Note that the end of the authoring session is distinct from publishing. Automatic content generation may continue after the end of both the authoring session and initial publishing (e.g., content management system updates).
authoring tool user interface (non-Web-Based)
Any parts of an authoring tool user interface that are not implemented as Web content and instead run directly on a platform that is not a user agent, such as Windows, MacOS, Java Virtual Machine, etc.
authoring tool user interface (Web-based)
Any parts of an authoring tool user interface that are implemented using Web content technologies and are accessed by authors via a user agent.
authoring tool user interface
The display and control mechanism that authors use to operate the authoring tool software. User interfaces may be non-Web-based or Web-based or a combination (e.g., a non-Web-based authoring tool might have Web-based help pages). An accessible authoring tool user interface is one that meets the success criteria of a level in Part A.
authoring tool
Any software, or collection of software components, that authors can use to create or modify Web content for use by other people. See "Definition of authoring tool" section in the Introduction.
author permission
Whether a person has a right to modify given Web content. In other words, whether they qualify as an author of the content. Some authoring tools are capable of managing authoring permissions in order to prevent unauthorized modifications.
authors
One or more people using an authoring tool to create or modify Web content for use by other people. This may include content authors, designers, programmers, publishers, testers, etc. working either alone or collaboratively. A person only qualifies as an author of some given Web content if (1) the authoring tool supports the relevant Web content technology used to implement that Web content and (2) the person has author permission for that Web content.
checking (accessibility) [harmonized with EARL 1.0]
The process by which Web content is evaluated for Web content accessibility problems. ATAG 2.0 identifies three types of checking, based on increasing levels of automation of the tests:
  1. manual checking: where the tests are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure;
  2. semi-automated checking: where the tests are partially carried out by the authoring tool, but where authors' input or judgment is still required to decide or help decide the outcome of the tests; and
  3. automated checking: where the tests are carried out automatically by the authoring tool without any intervention by the authors.
An authoring tool may support any combination of checking types.
collection of software components
Any software programs that are used either together (e.g., base tool and plug-in) or separately (e.g., markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the software components.
content generation
ATAG 2.0 refers to two types of content generation:
  1. author-generated content: When authors specify content (e.g., typing markup into a text editor, choosing an element by name from a list, entering information into a dialog box).
  2. automatically-generated content: When the authoring tool specifies content (e.g., applying a template, automatically correcting markup errors, dynamically generated content) as programmed by the authoring tool developer.
content rendering
User interface functionality that authoring tools present if they render, play or execute the Web content being edited. In ATAG 2.0 the term covers conventional renderings (e.g., WYSIWYG), unconventional renderings (e.g., rendering an audio file as a graphical wavefront) and partial renderings, in which some aspects of the content are rendered, played, or executed, but not others (e.g., a frame-by-frame video editor renders the graphical, but not the timing aspects, of a video).
conversion
A process that takes as input, content in one Web content technology or non-Web content technology (e.g., a word processing format) and produces as output, content in a different Web content technology (e.g., "Save as HTML" features).
developer
Any entities or individuals responsible for programming the authoring tool. This includes the programmers of any additional software components included by the Claimant in the conformance claim. In some cases, development of the authoring tool is complete before authors can use it to publish Web content. However, in other cases (e.g., some Web-based authoring tools), the developer may continue to modify the authoring tool even after content has been published, such that the Web content experienced by the end user is modified.
direct accessibility features
Features of an authoring tool that provide functionality to meet the requirements of authors with disabilities (e.g., keyboard navigation, zoom features, text-to-speech). Additional or specialized functionality may still be provided by external assistive technology.
display settings
ATAG 2.0 refers to two types of display settings:
  1. display settings (audio): the characteristics of audio output of music, sounds and speech. Examples include volume, speech voices, voice speed, and voice emphasis.
  2. display settings (visual): the characteristics of the on-screen rendering of text and graphics. Examples include fonts, sizes, colors, spacing, positioning, and contrast.
documentation
Any information that supports the use of an authoring tool. This information may be provided electronically or otherwise and includes help, manuals, installation instructions, sample work flows, tutorials, etc.
document object
The internal representation of data in the source content by a non-Web based authoring tool or user agent. The document object may form part of a platform accessibility architecture that enables communication with assistive technologies. Web-based authoring tools are considered to make use of the document object that is maintained by the user agent.
element
A pair of markup tags and its content, or an "empty tag" (one that requires no closing tag or content).
end user
A person who interacts with Web content once it has been authored. This includes people using assistive technologies.
human language [adapted from WCAG 2.0]
Language that is spoken, written or signed (through visual or tactile means ) to communicate with humans.
informative [adapted from WCAG 2.0]
For information purposes and not required for conformance.
keyboard trap
A user interface situation in which the keyboard may be used to move focus to, but not from, a control or group of controls.
label [adapted from WCAG 2.0]
Text or other component with a text alternative that is presented to users to identify a component. A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
markup language
A system of text annotations (e.g., elements in HTML) and processing rules that may be used to specify the structure, presentation or semantics of content. Examples of markup languages include HTML and SVG. The markup of some content is the set of annotations that appear in the content.
name [WCAG 2.0]
Text by which software can identify a component to the user. The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.
non-text content [WCAG 2.0]
Any content that is not a sequence of characters that can be recognized or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text.
normative [WCAG 2.0, UAAG 2.0]
Required for conformance. One may conform in a variety of well-defined ways to this document. Content identified as "informative" or "non-normative" is never required for conformance.
option
When an author is presented with choices. An option may be local (e.g., prompting whether to save before ending an authoring session) or global (e.g., preference settings).
platform
The software environment within which the authoring tool operates. In the case of Web-based authoring user interfaces, this will be user agents. In the case of non-Web-based user interfaces this will be operating systems (e.g., Windows, Mac OS, Linux), virtual machines (e.g., JVM), etc. Information is available via the platform (to assistive technologies) when it is communicated programmatically by the authoring tool to the platform, which then facilitates onward programmatic communication to assistive technologies. For non-Web-based user interfaces, this means via an implemented platform accessibility architecture. For Web-based user interfaces, this means following WCAG so that the user agent can pass on the information.
platform accessibility architecture
A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g., MSAA and UI Automation for Windows applications, AXAPI for MacOSX applications, Gnome Accessibility Toolkit API for Gnome applications, Java Access for Java applications, etc.). On some platforms, it may be conventional to enhance communication further by implementing a document object.
plug-in [UAAG 2.0]
A program that runs as part of the authoring tool (e.g., a third-party checking and repair tool) and that is not part of content being edited. Authors generally choose to include or exclude plug-ins from their authoring tool.
presentation [WCAG 2.0]
Rendering of the content in a form to be perceived by authors.
prominence
A heuristic measure of how likely users are to notice items (e.g., single controls, groups of controls, text messages) in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g., size, spacing, color), and even the modality of use (e.g., mouse vs. keyboard use). For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if:
  1. both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes),
  2. if item B is emphasized, then so is item A, and
  3. item A occurs higher in the reading order or immediately follows item B.
prompt
Any authoring tool initiated request for a decision or piece of information from authors. Well designed prompting will urge, suggest, and encourage authors.
publishing
The point at which the authors or authoring tool make content available to end users (e.g., uploading a Web page, committing a change in a wiki).
recognized (by the authoring tool)
When an authoring tool is able to process encoded information, such as labels, names, roles or relationships, with certainty. For example, an authoring tool would only be able to recognize a particular text string as a text label for non-text content, if this relationship was appropriately encoded (e.g., in an "alt" attribute, by a "labeledby" property). If success criteria apply to recognized types of content (e.g., tool-recognized alternative content), the conformance claim must list the recognized types.
relationships [adapted from WCAG 2.0]
Meaningful associations between distinct pieces of content.
repairing (accessibility) [harmonized with EARL 1.0]
The process by which Web content accessibility problems that have been identified within content are resolved. ATAG 2.0 identifies three types of repairing, based on increasing levels of automation:
  1. manual: where the repairs are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
  2. semi-automated: where the repairs are partially carried out by the authoring tool, but where authors' input or judgment is still required to complete the repair; and
  3. automated: where the repairs are carried out automatically by the authoring tool without any intervention by the authors.
reversible actions
Authoring actions that, by their nature, can be completely undone so that the system returns to the state it was in before the action. Irreversible actions are actions that cannot be reversed and may include certain save and delete actions as well as actions made in a collaborative environment that another author has begun to work with.
role [adapted from WCAG 2.0]
Text or a number by which software can identify the function of a component within Web content (e.g., a string that indicates whether an image functions as a hyperlink, command button, or check box).
structured element set
Content that consists of organized elements (e.g., lists, maps, hierarchies, graphs).
technology (Web content) [harmonized with WCAG 2.0]
A mechanism for encoding instructions to be rendered, played or executed by user agents. Web Content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to multimedia presentations to dynamic Web applications. Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. An accessible technology is a technology that may be used in a way that is "accessibility supported" (For more information on "accessibility supported", see WCAG 2.0).
template
A content pattern that is filled in by authors or the authoring tool to produce content for end users (e.g., document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.
template selection mechanism
A function that allows authors to select templates to use as the basis for new content or to apply to existing content.
transformation
A process that takes content in one Web content technology as input and outputs different content in the same technology (e.g., a function that transforms tables into lists).
tutorial
A type of documentation that provides step-by-step instructions for performing multi-part tasks.
user agent [adapted from WCAG 2.0]
Any software that retrieves, renders and facilitates end user interaction with Web content. Examples include Web browsers, browser plug-ins, and media players.
user interface component [adapted from WCAG 2.0]
A part of the user interface or content display (including content renderings) that is perceived by authors as a single control for a distinct function.
video [WCAG 2.0]
The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.
view
A user interface function that authors use to interact with the content being edited. ATAG 2.0 categorizes views according to whether they support editing and the way in which they present content. There are two options for supporting editing in a view:
  1. editing views are editable.
  2. previews are not editable and present content as it would appear in a user agent.
There are three approaches to presenting the content in a view:
  1. as source content in which the unrendered content is presented (e.g., plain text editors),
  2. as content rendering, and
  3. as pre-built content in which authors set only high-level options that the authoring tool then interprets to generate the resulting content (e.g., a calendar module in a content management system).
(Web) content [adapted from WCAG 2.0]
Information and sensory experience to be communicated to the end user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, "content" is primarily used to refer to the output that is produced by the authoring tool. “Content” may include Web applications, including those that act as Web-based authoring tools. Accessible Web content is Web content that conforms to a particular level of WCAG.
workflow
A customary sequence of steps or tasks authors follow to produce a content deliverable. If an authoring tool is composed of multiple software components then its workflows may include use of one or more of the components.
WYSIWYG
This is an acronym for "What You See Is What You Get". A WYSIWYG user interface displays (to authors) the content being edited in a way that is very similar to how it will appear to end users.

Appendix B: How to refer to ATAG 2.0 from other documents

This section is informative.

There are two recommended ways to refer to the "Authoring Tool Accessibility Guidelines 2.0" (and to W3C documents in general):

  1. References to a specific version of "Authoring Tool Accessibility Guidelines 2.0." For example, use the "this version" URI to refer to the current document:
    http://www.w3.org/TR/2009/WD-ATAG20-20090521/
  2. References to the latest version of "Authoring Tool Accessibility Guidelines 2.0." Use the "latest version" URI to refer to the most recently published document in the series:
    http://www.w3.org/TR/ATAG20/.

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

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

<p>
<cite><a href="http://www.w3.org/TR/2009/WD-ATAG20-20090521/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Richards, J. Spellman, eds.,
W3C Recommendation, http://www.w3.org/TR/ATAG20/.
The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> of this document is available at http://www.w3.org/TR/ATAG20/.</p>

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


Appendix C: References

This section is informative.

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

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

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

Appendix D: Acknowledgments

Appendix Editors:

Participants active in the AUWG at the time of publication:

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

Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen Mardahl, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory Rosmaita, Michael Squillace, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason White.

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

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


Appendix E: Checklist


Appendix F: Comparison of ATAG 1.0 guidelines to ATAG 2.0


[Contents]