Authoring Tool Accessibility Guidelines (ATAG) 2.0 (original) (raw)

[Contents] [Implementing]

W3C

W3C Editors' Draft 28 October 2013

This version:

http://www.w3.org/WAI/AU/2013/ED-ATAG20-20131028/

Latest version:

http://www.w3.org/TR/ATAG20/

Previous version:

http://www.w3.org/WAI/AU/2013/ED-ATAG20-20131002/

Latest Editor's Draft

http://www.w3.org/WAI/AU/ATAG20/

Editors:

Jan Richards, Inclusive Design Institute, OCAD University

Jeanne Spellman, W3C

Jutta Treviranus, Inclusive Design Institute, OCAD University

Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This standard provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities (Part A) and designed to enable, support, and promote the production of more accessible web content by all authors (Part B). See Authoring Tool Accessibility Guidelines (ATAG) Overview for an introduction and links to ATAG technical and educational material.

Status of This Document

Editor's Draft of ATAG 2.0

This document is the internal working draft used by the AUWG 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.

This Editor's Draft is intended to be published as a Candidate Recommendation draft. The text below is intended to be the Status section of the Candidate Recommendation draft.

This is a Candidate Recommendation of Authoring Tool Accessibility Guidelines (ATAG) 2.0 from the Authoring Tool Accessibility Guidelines Working Group. This version integrates minor editorial changes identified since the publication of the 10 September 2013 Last Call Working Draft. The Working Group received 1 comment on this draft which AUWG addressed by a change to Implementing ATAG 2.0.

A Candidate Recommendation is a document that has been widely reviewed and is ready for implementation. Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. Before the standard can progress to Proposed Recommendation, the CR exit criteria must be met. A test suite and an implementation report will be made during the Candidate Recommendation period.

Besides these implementations, feedback on implementation and use of this standard is welcome, including from implementations not selected as part of the formal implementation report for exiting Candidate Recommendation.

Working closely with authoring tool developers, we expect to receive initial implementations by @@ date @@ and to show evidence of meeting the exit criteria by @@ date @@

Comments on these changes are due on or before @@ December 2013. Comments should be sent to public-atag2-comments@w3.org (Public Archive).

Exit Criteria

The Authoring Tool Accessibility Guidelines Working Group intends to submit this document for consideration as a W3C Proposed Recommendation as soon as the following conditions are met.

  1. [Tool by tool] Two independent [1] authoring tools must conform to ATAG 2.0 level AA (which includes level A).
  2. [Tool by category] At least one authoring tool from each of the following authoring tool categories must conform to ATAG 2.0 Level A (i.e. will conform to all applicable Level A success criteria.):
    • WYSIWYG web page editing tools
    • Content management tools
    • Development tool for applet, scripts, or applications
    • Non-text media (e.g. video, audio, images) editing tools
    • Social media content authoring tools (e.g. blogs, wikis, social networks)
  3. [Success criterion by success criterion] Each ATAG 2.0 success criterion must be implemented [2] by two independent authoring tools. For the thirteen ATAG 2.0 success criteria that are dependent on WCAG 2.0 [3] for their levels, each ATAG 2.0 success criterion must be implemented for two WCAG 2.0 success criteria at each level: A, AA, and AAA. These six WCAG 2.0 success criteria are a sampling of the requirements of WCAG (e.g. text alternatives for non-text content, keyboard accessibility, sufficient contrast).

Note 1: "Independent authoring tools" are tools by different developers that do not share (or derive from) the same source code for the relevant feature(s). Sections of code that have no bearing on the implementation of this standard are exempt from this requirement. The authoring tools must be a shipping product or other publicly available version. Experimental implementations, specifically designed to pass the test suite and not intended for normal usage, are not permitted.

Note 2: "Implemented" refers to situations in which a success criterion is applicable to a given authoring tool and the authoring tool meets the success criterion. This is in contrast to situations in which a success criterion is not applicable.

Note 3: For example, if the WCAG success criteria at level A are satisfied, then the ATAG success criteria is satisfied at level A. If the WCAG success criteria at level A and AA are satisfied, then the ATAG success criteria is satisfied at level AA. If the WCAG success criteria at level A, AA, and AAA are satisfied, then the ATAG success criteria is satisfied at level AAA.

Features At Risk

As a part of the Candidate Recommendation process, any items that might change or where there may not be implementations are marked as "at risk." "At risk" in no way implies that these success criteria are less important to accessibility. It is a W3C requirement to identify any provision for which the Working Group believes it may not be able to document the required implementations by the end of the Candidate Recommendation period.

Items At Risk for Change

If at least two implementations of each of the following success criteria do not exist at the end of the Candidate Recommendation period, the success criteria may be modified as stated:

Items At Risk for Removal

If at least two implementations of the following success criterion do not exist at the end of the Candidate Recommendation period, the folowing success criterion may be removed.

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.

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 their authoring tools more accessible to people with disabilities, including auditory, cognitive, neurological, physical, speech, and visual disabilities.

Authoring tool accessibility addresses the needs of two overlapping user groups with disabilities:

It is important to note that while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that, in reality, they are deeply inter-connected. For example, when a user participates in an online forum, he (or she) frequently author content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the content produced by the other forum users would reduce the overall accessibility of the forum.

Notes:

  1. The term "authoring tools" has a specific definition in ATAG 2.0. The definition, which includes several normative notes, appears in the Glossary.
  2. The term "accessible content (WCAG)" and related terms, such as "accessible template (WCAG)" is used by ATAG 2.0 to refer to "content that would conform to WCAG 2.0", at either Level A, AA, or AAA, assuming that any web content technologies relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported. The definition of the term reflects the WCAG 2.0 note that even content that conforms to the highest level of WCAG 2.0 (Level AAA) may not be "accessible to individuals with all types, degrees, or combinations of disability". For more information, see "Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0".
  3. ATAG 2.0 does not include standard usability recommendations, except where they have a significantly greater impact on people with disabilities than on other people.
  4. Authoring tools are just one aspect of web accessibility. For an overview of the different components of web accessibility and how they work together see:

ATAG 2.0 Layers of Guidance

The individuals and organizations that may use ATAG 2.0 vary widely and include authoring tool developers, authoring tool users (authors), authoring tool purchasers, and policy makers. In order to meet the varying needs of these audiences, several layers of guidance are provided:

See Authoring Tool Accessibility Guidelines (ATAG) Overview for links to additional ATAG technical and educational material.

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). For more information, see Understanding Levels of Conformance.

Integration of Accessibility Features

When implementing ATAG 2.0, authoring tool developers should carefully integrate features that support more accessible authoring into the same "look-and-feel" as other features of the authoring tool. Close integration has the potential to:

Guidelines

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

Part B: Support the production of accessible content

Part B Conformance Applicability Notes:

  1. Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
  2. Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. third-party plug-ins, user-defined templates, user modifications of default settings).
  3. Applicability after the end of an authoring session: Authoring tools are responsible for the web content accessibility (WCAG) of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).
  4. Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any conformance claim) can be used in conjunction to meet the requirements of Part B (e.g. an authoring tool could make use of a third-party software accessibility checking tool).
  5. Accessibility of features provided to meet Part B: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g. checking tools, repair tools, tutorials, documentation).
  6. Multiple authoring roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g. a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular authoring role. Accessible content support features should be made available to any authoring role where it would be useful.
  7. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria only apply when these semantics are encoded programmatically (e.g. text describing an image can only be considered a text alternatives for non-text content when this role is encoded within markup).

Principle B.1: Fully automatic processes produce accessible content

Guideline B.1.1: Ensure that automatically-specified content is accessible. [Implementing B.1.1]

Rationale: If authoring tools automatically produce web content that includes accessibility problems (WCAG), then this will impose additional repair tasks on authors.

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

The authoring tool does not automatically generate web content after the end of an authoring session or authors can specify that the content be accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

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

If the authoring tool provides the functionality for automatically generating web content during an authoring session, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Guideline B.1.2: Ensure that accessibility information is preserved. [Implementing B.1.2]

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

B.1.2.1 Restructuring and Recoding Transformations (WCAG):

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

B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG):

If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.1.2.3 Optimizations Preserve Accessibility:

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

B.1.2.4 Text Alternatives for Non-Text Content are Preserved:

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

Principle B.2: Authors are supported in producing accessible content

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

Rationale: To support accessible web content (WCAG) production, at minimum, it is possible to produce web content that conforms with WCAG 2.0 using the authoring tool.

B.2.1.1 Accessible Content Possible (WCAG):

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

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

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

B.2.2.1 Accessible Option Prominence (WCAG):

If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g. styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.2.2.2 Setting Accessibility Properties (WCAG):

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

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

Rationale: Improperly generated alternative content can create web content accessibility problems (WCAG) and interfere with accessibility checking.
Note: This guideline only applies when non-text content is specified by authors (e.g. inserting an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.1.

B.2.3.1 Alternative Content is Editable (WCAG):

If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.2.3.2 Automating Repair of Text Alternatives:

The authoring tool does not attempt to repair text alternatives for non-text content or the following are all true: (Level A)

B.2.3.3 Save for Reuse:

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

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

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

Rationale: Providing accessible templates (WCAG) can have several benefits, including: immediately improving the accessibility of the web content (WCAG) of being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG).

B.2.4.1 Accessible Template Options (WCAG):

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

B.2.4.2 Identify Template Accessibility:

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

B.2.4.3 Author-Created Templates:

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

B.2.4.4 Accessible Template Options (Enhanced):

If the authoring tool provides templates, then all of the templates are accessible template (to WCAG Level AA). (Level AAA)

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

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

B.2.5.1 Accessible Pre-Authored Content Options:

If the authoring tool provides pre-authored content, then a range of accessible pre-authored content (to WCAG Level AA) options are provided. (Level AA)

B.2.5.2 Identify Pre-Authored Content Accessibility:

If the authoring tool includes a pre-authored content selection mechanism and provides any non-accessible pre-authored content (WCAG Level AA) options, then the selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

Principle B.3: Authors are supported in improving the accessibility of existing content

Guideline B.3.1: Assist authors in checking for accessibility problems. [Implementing B.3.1]

Rationale: When accessibility checking is an integrated function of the authoring tool, it helps make authors aware of web content accessibility problems (WCAG) during the authoring process, so they can be immediately addressed.

B.3.1.1 Checking Assistance (WCAG):

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

B.3.1.2 Help Authors Decide:

If the authoring tool provides accessibility checking that relies on authors to decide whether potential web content accessibility problems (WCAG) are correctly identified (i.e. manual checking and semi-automated checking), then the accessibility checking process provides instructions that describe how to decide. (Level A)

B.3.1.3 Help Authors Locate:

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

B.3.1.4 Status Report:

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

B.3.1.5 Programmatic Association of Results:

If the authoring tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

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

Rationale: When repair is an integral part of the authoring process, it greatly enhances the utility of checking and increases the likelihood that web content accessibility problems (WCAG) will be properly addressed.

B.3.2.1 Repair Assistance (WCAG):

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

Principle B.4: Authoring tools promote and integrate their accessibility features

Guideline B.4.1: Ensure the availability of features that support the production of accessible content. [Implementing B.4.1]

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.4.1.1 Features Active by Default:

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

B.4.1.2 Option to Reactivate Features:

The authoring tool does not include the option to turn off its accessible content support features or features which have been turned off can be turned back on. (Level A)

B.4.1.3 Feature Deactivation Warning:

The authoring tool does not include the option to turn off its accessible content support features or, if these features can be turned off, authors are informed that this may increase the risk of content accessibility problems (WCAG). (Level AA)

B.4.1.4 Feature Prominence:

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

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

Rationale: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use accessibility checking tools). Demonstrating accessible authoring as routine practice, or at least not demonstrating inaccessible practices, will help to encourage acceptance of accessibility by some authors.

B.4.2.1 Model Practice (WCAG):

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

B.4.2.2 Feature Instructions:

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

B.4.2.3 Tutorial:

The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (Level AAA)

B.4.2.4 Instruction Index:

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

Conformance

This section is normative.

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

Conformance Requirements

Success Criteria Satisfaction

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

Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0

At the time of publishing, WCAG 2.0 [WCAG20] is the current W3C Recommendation regarding web content accessibility. For this reason, ATAG 2.0 refers to WCAG 2.0 when setting requirements for (1) the accessibility of web-based authoring tool user interfaces (in Part A) and (2) how authors should be enabled, supported, and guided toward producing web content that is more accessible to end users with disabilities (in Part B).

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

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

Part of conformance to WCAG 2.0 is the requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported." In broad terms, WCAG 2.0 considers a web content technology to be "accessibility supported" when (1) the way that the web content technology is used is supported by users' assistive technology and (2) the web content technology has accessibility-supported user agents that are available to end users.

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

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

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

Conformance Options and Levels

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

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

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

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

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

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

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

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

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

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

Web Content Technologies Produced:

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

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

Live publishing authoring tools:

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

Conformance Claims (Optional)

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

Required Components of a Conformance Claim

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

Optional Components of a Conformance Claim

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

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

Disclaimer

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

Appendix A: Glossary

This section is normative.

This appendix contains definitions for all of the significant/important/unfamiliar terms used in the normative parts of this standard, including terms used in the Conformance section. Please consult http://www.w3.org/TR/qaframe-spec/ for more information on the role of definitions in standards quality.

accessibility problems

ATAG 2.0 recognizes two types of accessibility problems:

accessibility information (WCAG)

Information that web content must contain in order to meet a WCAG 2.0 success criterion (Level A, AA or AAA). Examples include: programmatically associated alternative content (e.g. text alternatives for images), role, and state information for widgets, relationships within complex tables).
Note: For the purposes of ATAG 2.0, only programmatically determinable accessibility information qualifies. For additional examples, see Appendix A of the Implementing ATAG 2.0 document.

accessible content support features

Any features of an authoring tool that directly support authors in increasing the accessibility of the web content being edited. These are features that must be present to meet the success criteria in Part B of ATAG 2.0.

alternative content

Web content that is used in place of other content that some people are not able to access. Alternative content fulfills essentially the same function or purpose as the original content. WCAG 2.0 recognizes several general types of alternative content:

assistive technology

Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of people with disabilities (authors and end users). Some authoring tools may also provide direct accessibility features. Examples include:

audio

The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real-world sounds, or both.

When the actions of authors prevent authoring tools from generating accessible web content (WCAG). Examples include: turning off accessible content support features, ignoring prompts for accessibility information (WCAG), providing faulty accessibility information (WCAG) at prompts, modifying the authoring tool (e.g. via scripting, macros), and installing plug-ins.

authors

People who use authoring tools to create or modify web content. The term may cover roles such as content authors, designers, programmers, publishers, testers, etc. (see Part B Conformance Applicability Note 6: Multiple authoring roles). Some authoring tools control who may be an author by managing author permissions.

author permission

Authorization that allows modification of given web content.

authoring action

Any action that authors can take using the authoring tool user interface that results in editing web content (e.g. typing text, deleting, inserting an element, applying a template). In contrast, most authoring tool user interfaces also enable actions that do not edit content (e.g. saving, publishing, setting preferences, viewing documentation).

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 authors or by the authoring tool. Authoring practices may or may not be:

authoring session

A state of the authoring tool in which web content can be edited by an author.

authoring tool

Any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).
Note 1: "application(s)": ATAG 2.0 may be conformed to by stand-alone applications or by collections of applications. If a conformance claim is made, then the claim must provide identifying information for each application and also for any required extensions, plug-ins, etc.
Note 2: "alone or collaboratively": Multiple authors may contribute to the creation of web content and, depending on the authoring tool, each author may work with different views of the content and different author permissions.
Note 3: "to create or modify web content": This clause rules out software that collects data from a person for other purposes (e.g. online grocery order form) and then creates web content from that data (e.g. a web-based warehouse order) without informing the person (however, WCAG 2.0 would still apply). This clause also rules out software used to create content exclusively in non-web content technologies.
Note 4: "for use by other people": This clause rules out the many web applications that allow people to modify web content that only they themselves experience (e.g. web-based email display settings) or that only provide input to automated processes (e.g. library catalog search page).Examples of software that are generally considered authoring tools under ATAG 2.0:

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

checking, accessibility

The process by which web content is evaluated for web content accessibility problems (WCAG). ATAG 2.0 recognizes three types of checking, based on increasing levels of automation of the tests:

content (web content)

Information and sensory experience to be communicated to the end user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, the term is primarily used to refer to the output that is produced by the authoring tool. Content produced by authoring tools may include web applications, including those that act as web-based authoring tools. Content may or may not be:

content properties

The individual pieces of information that make up the web content (e.g. the attributes and contents of elements, style sheet information).

content (structured)

Web content that includes machine-readable internal structure (e.g. markup elements), as opposed to unstructured content, such as raster image formats or plain human language text.

content generation (content authoring, content editing)

The act of specifying the actual web content that will be rendered, played or executed by the end user's user agent. While the precise details of how content is created in any given system may vary widely, responsibility for the generation of content can be any combination of the following:

content rendering

User interface functionality that authoring tools present if they render, play or execute the web content being edited. ATAG 2.0 recognizes several types of content renderings:

content transformations

Processes that take content in one web content technology or non-web content technology (e.g. a word processing format) as input and produce content that has been optimized, restructured or recoded:

control settings

Settings that relate to how authors operate the authoring tool, for example using the keyboard or mouse.

developer

Any entities or individuals responsible for programming the authoring tool. This includes the programmers of any additional software components included by the Claimant in the conformance claim. In some cases, development of the authoring tool is complete before authors can use it to publish web content. However, in other cases (e.g. some web-based authoring tools), the developer may continue to modify the authoring tool even after content has been published, such that the content experienced by the end user is modified.

direct accessibility features

Features of an authoring tool that provide functionality to meet the requirements of authors with disabilities (e.g. keyboard navigation, zoom features, text-to-speech). Additional or specialized functionality may still be provided by external assistive technology.

display settings

Settings that relate to how authors perceive the authoring tool. These include:

documentation

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

document object

The internal representation of data in the source by a non-web based authoring tool or user agent. The document object may form part of a platform accessibility service that enables communication with assistive technologies. Web-based authoring tools are considered to make use of the document object that is maintained by the user agent.

element

A pair of markup tags and its content, or an "empty tag" (one that requires no closing tag or content).

end user

A person who interacts with web content once it has been authored. This includes people using assistive technologies.

human language

Language that is spoken, written or signed (through visual or tactile means) to communicate with humans.

informative

For information purposes and not required for conformance.

keyboard interface

Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g. a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected).
Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.

keyboard trap

A user interface situation in which a keyboard interface may be used to move focus to, but not from, a user interface component or group of components.

label

Text or other component with a text alternative that is presented to users to identify a component. A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

live

Information captured from a real-world event that is published with no more than a broadcast delay.
Note: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.

markup language

A system of text annotations (e.g. elements in HTML) and processing rules that may be used to specify the structure, presentation or semantics of content. Examples of markup languages include HTML and SVG.

name

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

non-text content

Any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text.

normative

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

option

When an author is presented with choices.

platform

The software environment within which the authoring tool operates. Platforms provide a consistent operational environment on top of lower level software platforms or hardware. For web-based authoring user interfaces, the most relevant platform will be a user agent (e.g. browser). For non-web-based user interfaces, the range of platforms includes, but may not be limited to, desktop operating systems (e.g. GNOME desktop on Linux, Mac OS, Windows), mobile operating systems (e.g. Android, BlackBerry, iOS, Windows Phone), or cross-OS environments (e.g. Java), etc.
Note 1: Many platforms mediate communication between applications operating on the platform and assistive technology via a platform accessibility service.
Note 2: Accessibility guidelines for developers exist for many platforms.

platform accessibility service

A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g. MSAA, IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OS X applications, GNOME Accessibility Toolkit API for GNOME applications, Java Access for Java applications). On some platforms, it may be conventional to enhance communication further by implementing a document object.

plug-in

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

pre-authored content

Pieces of web content, created prior to anauthoring session, that the authoring tool developer makes available to authors to use in the content being edited. Examples include clip art, sample videos, user interface widgets.
Note 1: For templates, an incomplete form of pre-authored content, see Guideline B.2.4.
Note 2: If the authoring tool uses pre-authored content automatically, see Guideline B.1.1.

pre-authored content selection mechanism

A function beyond standard file selection that allows authors to select pre-authored content to use in an authoring session (e.g. clip art gallery, widget palette).

presentation

Rendering of the content in a form to be perceived by authors or end users.

programmatically determined (programmatically determinable)

Information that is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. ATAG 2.0 uses this term in two contexts:

prominence

A heuristic measure of how likely authors are to notice a user interface component in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g. size, spacing, color), and even the modality of use (e.g. mouse vs. keyboard use).

prompt

Any authoring tool initiated request for a decision or piece of information from authors. The term covers both requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word).

publishing

Any point at which the authors or authoring tool make web content available to end users (e.g. uploading a web page, committing a change in a wiki, live streaming).

range

More than one item within a multi-item set.
Informative Note: ATAG 2.0 uses the term "range" where absolute measurements may not be practical (e.g. the set of all help documentation examples, the set of all templates). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.

relationships

Meaningful associations between distinct pieces of content.

repair (accessibility)

The process by which web content accessibility problems that have been identified within web content are resolved. ATAG 2.0 recognizes three types of repair, based on increasing levels of automation:

restrictions, restricted web content authoring

When the web content that authors can specify with anauthoring tool either must include or must not include certain content (e.g. elements, attributes, widgets). Many authoring tools restrict authoring in some way, which can either benefit accessibility (e.g. if text alternatives for non-text content are required) or detract from accessibility (e.g. if attributes for defining text alternatives are not available). In contrast, authoring tools that allow unrestricted web content authoring do not require any particular content to be included or not included (e.g. many source editing-views).

role

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

sequential keyboard access

Using a keyboard interface to navigate the focus one-by-one through all of the items in an ordered set (e.g. menu items, form fields) until the desired item is reached and activated. This is in contrast to direct keyboard access methods such as keyboard shortcuts and the use of bypass links.

technology (web content)

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

templates

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

template selection mechanism

A function beyond standard file selection that allows authors to select templates to use as the basis for new content or to apply to existing content.

time limit

The amount of time that an authoring tool provides to authors to perform a task (e.g. read a message, select an item, save a change). Examples include: authoring session timeouts, time-based presentations (e.g. tutorial video).

tutorial

A type of documentation that provides step-by-step instructions for performing multi-part tasks.

user agent

Any software that retrieves, renders and facilitates end user interaction with web content (e.g. web browsers, browser plug-ins, media players)

user interface component

A part of the user interface or content display (including content renderings) that is perceived by authors as a single control for a distinct function.

video

The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.

view

A user interface function that authors use to interact with the web content being edited. ATAG 2.0 categorizes views according to whether they support editing:

workflow

A customary sequence of steps or tasks that authors follow to produce a content deliverable. If an authoring tool is composed of a collection of applications (e.g. markup editor, image editor, and validation tool), then its workflows may include use of one or more of the applications.

Appendix B: References

This section is informative.

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

[ATAG10]

"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000.

[UAAG]

"User Agent Accessibility Guidelines 1.0,", I. Jacobs, J. Gunderson, and E. Hansen, eds.17 December 2002.

[WCAG20]

"Web Content Accessibility Guidelines 2.0 ", B. Caldwell, M. Cooper, L. Guarino Reid, and G. Vanderheiden, eds. 11 December 2008.

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

Previous Editors:

Tim Boland, NIST

Matt May (until June 2005 while at W3C)

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

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

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

[Contents]