风清扬

开发工具无障碍指南

1楼 风清扬


[Table of Contents]  |  [Implementing ATAG 2.0]

Authoring Tool AccessibilityGuidelines (ATAG) 2.0

W3C Recommendation 24 September 2015

This version:

http://www.w3.org/TR/2015/REC-ATAG20-20150924/

Latest version:

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

Previous version:

http://www.w3.org/TR/2015/PR-ATAG20-20150721/

Editors:

Jan Richards, Inclusive Design Institute, OCADUniversity

Jeanne Spellman, W3C

Jutta Treviranus, Inclusive Design Institute, OCADUniversity

Please refer to the errata for this documentfor any errors or issues reported since publication.

See also translations.

Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.


Abstract

The Authoring ToolAccessibility Guidelines (ATAG) 2.0 provides guidelines for designing webcontent authoring tools that are both more accessible to authors withdisabilities (Part A) and designed to enable, support, and promote theproduction 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 andeducational material.

Status of This Document

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

W3C Recommendation of ATAG 2.0

This is the AuthoringTool Accessibility Guidelines (ATAG) 2.0 W3C Recommendation of 24 September 2015from the Authoring Tool AccessibilityGuidelines Working Group. The Working Group created an implementation report that shows the exit criteria have been met. TheDirector approved transition to Recommendation after reviewing this report andafter Advisory Committee vote which supported publication. There are no changesto the text of ATAG 2.0. There have been minor edits to the code to fix spacingand to remove superfluous or commented HTML.

This document hasbeen reviewed by W3C Members, by software developers, and by other W3C groupsand interested parties, and is endorsed by the Director as a W3CRecommendation. It is a stable document and may be used as reference materialor cited from another document. W3C's role in making the Recommendation is todraw attention to the specification and to promote its widespread deployment.This enhances the functionality and interoperability of the Web.

ATAG 2.0 is supportedby the associated non-normative document, Implementing ATAG 2.0. Although thisdocument does not have the formal status that ATAG 2.0 itself has, it providesinformation important to understanding and implementing ATAG 2.0.

The Working Grouprequests that any comments sent to public-atag2-comments@w3.org. The archives for the public commentslist are publicly available. Comments received on the ATAG 2.0 Recommendationcannot result in changes to this version of the guidelines, but may beaddressed in errata or future versions of ATAG. The Working Group does not planto make formal responses to comments. Archives of the ATAG WG mailing list discussions are publiclyavailable, and future work undertaken by the Working Group or subsequent groupmay address comments received on this document.

Web Accessibility Initiative

This document hasbeen produced as part of the W3C WebAccessibility Initiative (WAI). The goals of the AUWG arediscussed in the Working Group charter.

Patents

This document wasproduced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patentdisclosures made in connection with the deliverables of thegroup; that page also includes instructions for disclosing a patent. Anindividual who has actual knowledge of a patent which the individual believescontains Essential Claim(s) must disclose theinformation in accordance with section 6 of the W3C Patent Policy.

This document isgoverned by the 1 September 2015 W3C Process Document.


Table of Contents


Introduction

This section is informative.

This is W3CRecommendation (standard) 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 topeople with disabilities, including auditory, cognitive, neurological, physical,speech, and visual disabilities.

Authoring toolaccessibility addresses the needs of two overlapping user groups withdisabilities:

It is important tonote that while the requirements for meeting these two sets of user needs areseparated for clarity within the guidelines, the accelerating trend towarduser-produced content means that, in reality, they are deeply inter-connected.For example, when a user participates in an online forum, the user frequentlyauthors content that is then incorporated with content authored by other users.Accessibility problems in either the authoring user interface or the contentproduced by the other forum users would reduce the overall accessibility of theforum.

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 ofGuidance

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

  • Parts: ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessibility with respect to authoring tools. Part A relates to the accessibility of authoring tool user interfaces to authors with disabilities. Part B relates to support by authoring tools for the creation, by any author (not just those with disabilities), of web content that is more accessible to end users with disabilities. Both parts include normative "Conformance Applicability Notes" that apply to all of the success criteria within that part: Part A Conformance Applicability Notes and Part B Conformance Applicability Notes.
  • Principles: Under each part are several high-level principles that organize the guidelines.
  • Guidelines: Under the principles are guidelines. The guidelines provide the basic goals that authoring tool developers should work toward in order to make authoring tools more accessible to both authors and end users of web content with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authoring tool developers understand the success criteria. Each guideline includes a brief rationale for why the guideline was included.
  • Success Criteria: For each guideline, testable success criteria are provided to allow ATAG 2.0 to be used where requirements and conformance testing are necessary, such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, multiple levels of full and partial conformance are defined (see Levels of Conformance).
  • Implementing ATAG 2.0 document: The Implementing ATAG 2.0 document provides additional non-normative information for each success criterion, including a description of the intent of the success criterion, examples, and links to related resources.

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

Levels ofConformance

In order to ensurethat the process of using ATAG 2.0 and WCAG 2.0 together in thedevelopment of authoring tools is as simple aspossible, ATAG 2.0 shares WCAG 2.0's three levelconformance model: Level A (lowest), AA (middle), AAA (highest). For moreinformation, see Understanding Levels of Conformance.

Integration ofAccessibility Features

When implementingATAG 2.0, authoring tool developers should carefullyintegrate features that support more accessible authoring into the same"look-and-feel" as other features of the authoring tool. Close integrationhas the potential to:

  • produce a more seamless product;
  • leverage the existing knowledge and skills of authors;
  • make authors more receptive to new accessibility-related authoring requirements; and
  • reduce the likelihood of author confusion.

Guidelines

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

Part A: Make the authoring tool userinterface accessible

Part A ConformanceApplicability Notes:

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

Guideline A.1.1: (For the authoring tool user interface) Ensure thatweb-based functionality is accessible. [Implementing A.1.1]

Rationale: When authoring tools (or parts ofauthoring tools) are web-based, conforming to WCAG 2.0 will facilitateaccess by all authors, including thoseusing assistive technologies.

A.1.1.1 Web-Based Accessible (WCAG):

If the authoring tool contains web-based user interfaces, then thoseweb-based user interfaces meet the WCAG 2.0 success criteria. (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

ImplementingA.1.1.1

Guideline A.1.2: (For the authoring tool user interface) Ensure thatnon-web-based functionality is accessible. [Implementing A.1.2]

Rationale: When authoring tools (or parts ofauthoring tools) are non-web-based, following existing platform accessibility guidelines and implementingcommunication with platform accessibility services facilitates access byall authors, including those using assistive technologies.

A.1.2.1 Accessibility Guidelines:

If the authoring tool contains non-web-based userinterfaces, then those non-web-based user interfaces followuser interface accessibility guidelines for the platform. (LevelA)

ImplementingA.1.2.1

A.1.2.2 Platform AccessibilityServices:

If the authoring tool contains non-web-based userinterfaces, then those non-web-based user interfaces exposeaccessibility information through platform accessibility services. (LevelA)

ImplementingA.1.2.2

Principle A.2:Editing-views are perceivable

Guideline A.2.1: (For the authoring tool user interface) Make alternativecontent available to authors. [Implementing A.2.1]

Rationale: Some authors require access to alternative content in order to interactwith the web content that they areediting.

A.2.1.1 Text Alternatives forRendered Non-Text Content:

If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined. (LevelA)

ImplementingA.2.1.1

A.2.1.2 Alternatives for RenderedTime-Based Media:

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

  • (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or
  • (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives.

ImplementingA.2.1.2

Guideline A.2.2: (For the authoring tool user interface) Ensure thatediting-view presentation can be programmatically determined. [Implementing A.2.2]

Rationale: Some authors need access to details about the editing-view presentation, via their assistivetechnology, when that presentation is used to convey status messages (e.g.underlining misspelled words) or provide information about how the end user will experience the web content being edited.

A.2.2.1 Editing-View StatusIndicators:

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

  • Note: Status indicators may indicate errors (e.g. spelling errors), tracked changes, hidden elements, or other information.

ImplementingA.2.2.1

A.2.2.2 Access to Rendered TextProperties:

If an editing-view renders any textformatting properties that authors can also edit using the editing-view, then theproperties can be programmatically determined. (LevelAA)

ImplementingA.2.2.2

Principle A.3:Editing-views are operable

Guideline A.3.1: (For the authoring tool user interface) Provide keyboardaccess to authoring features. [Implementing A.3.1]

Rationale: Some authors with limited mobility or visual disabilities do notuse a mouse and instead require keyboard interface access to all of thefunctionality of the authoring tool.

A.3.1.1 Keyboard Access (Minimum):

All functionality ofthe authoring tool is operable througha keyboard interface without requiringspecific timings for individual keystrokes, except where the underlyingfunction requires input that depends on the path of the user's movement and notjust the endpoints. (Level A)

  • Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard.
  • Note 2: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
  • Note 3: This success criterion does not forbid and should not discourage other input methods (e.g. mouse, touch) in addition to keyboard operation.

ImplementingA.3.1.1

A.3.1.2 No Keyboard Traps:

If keyboard focus canbe moved to a component using a keyboard interface, then focus can bemoved away from that component using only a keyboard interface. If it requiresmore than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (LevelA)

ImplementingA.3.1.2

A.3.1.3 Efficient Keyboard Access:

The authoring tool user interface includes mechanismsto make keyboard access more efficient than sequential keyboard access. (LevelAA)

ImplementingA.3.1.3

A.3.1.4 Keyboard Access (Enhanced):

All functionality ofthe authoring tool is operable througha keyboard interface without requiringspecific timings for individual keystrokes. (LevelAAA)

ImplementingA.3.1.4

A.3.1.5 Customize Keyboard Access:

If the authoring tool includes keyboardcommands, then those keyboard commands can be customized. (LevelAAA)

ImplementingA.3.1.5

A.3.1.6 Present Keyboard Commands:

If the authoring tool includes keyboardcommands,

then the authoringtool provides a way for authors to determine thekeyboard commands associated with authoring tool user interface components. (LevelAAA)

ImplementingA.3.1.6

Guideline A.3.2: (For the authoring tool user interface) Provide authorswith enough time. [Implementing A.3.2]

Rationale: Some authors who have difficulty typing, operating the mouse, orprocessing information can be prevented from using systems with short time limits or that require fastreaction speeds, such as clicking on a moving target.

A.3.2.1 Auto-Save (Minimum):

The authoring tool does not include session time limits or the authoringtool can automatically save edits made before the session time limits arereached. (Level A)

ImplementingA.3.2.1

A.3.2.2 Timing Adjustable:

The authoring tool does not include time limits or at least one ofthe following is true: (Level A)

  • (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or
  • (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. "press the space bar"), and authors are allowed to extend the time limit at least ten times; or
  • (d) Real-time Exception: The time limit is a required part of a real-time event (e.g. a collaborative authoring system), and no alternative to the time limit is possible; or
  • (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • (f) 20 Hour Exception: The time limit is longer than 20 hours.

ImplementingA.3.2.2

A.3.2.3 Static Input Components:

The authoring tool does not includemoving user interface components that accept inputwhere the movement of these components cannot be paused by authors. (Level A)

ImplementingA.3.2.3

A.3.2.4 Content Edits Saved(Extended):

The authoring tool can be set toautomatically save web content edits made using theauthoring tool. (Level AAA)

ImplementingA.3.2.4

Guideline A.3.3: (For the authoring tool user interface) Help authors avoidflashing that could cause seizures. [Implementing A.3.3]

Rationale: Flashingcan cause seizures in authors with photosensitiveseizure disorder.

A.3.3.1 Static View Option:

If an editing-view can play visualtime-based content, then playing is not necessarily automatic upon loading thecontent and playing can be paused. (Level A)

ImplementingA.3.3.1

Guideline A.3.4: (For the authoring tool user interface) Enhance navigationand editing via content structure. [Implementing A.3.4]

Rationale: Some authors who have difficulty typing or operating the mousebenefit when authoring tools make use of thestructure present in web content to simplifynavigating and editing the content.

A.3.4.1 Navigate By Structure:

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

ImplementingA.3.4.1

A.3.4.2 Navigate by ProgrammaticRelationships:

If editing-views allow editing ofprogrammatic relationships within web content, then mechanisms areprovided that support navigation between the related content. (LevelAAA)

  • Note: Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships.

ImplementingA.3.4.2

Guideline A.3.5: (For the authoring tool user interface) Provide textsearch of the content. [Implementing A.3.5]

Rationale: Some authors who have difficulty typing or operating the mousebenefit from the ability to use text search to navigate to arbitrary pointswithin the web content being edited.

A.3.5.1 Text Search:

If the authoring toolprovides an editing-view of text-basedcontent, then the editing-view enables text search,such that all of the following are true: (Level AA)

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

ImplementingA.3.5.1

Guideline A.3.6: (For the authoring tool user interface) Manage preferencesettings. [Implementing A.3.6]

Rationale: Some authors need to set their own display settings in a way thatdiffers from the presentation that they want todefine for the published web content. Providing theability to save and reload sets of keyboard and display preference settingsbenefits authors who have needs thatdiffer over time (e.g. due to fatigue).

A.3.6.1 Independence of Display:

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

ImplementingA.3.6.1

A.3.6.2 Save Settings:

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

ImplementingA.3.6.2

A.3.6.3 Apply Platform Settings:

The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settingsusing the authoring tool. (Level AA)

ImplementingA.3.6.3

Guideline A.3.7: (For the authoring tool user interface) Ensure thatpreviews are at least as accessible as in-market user agents. [Implementing A.3.7]

Rationale: Preview features are provided by many authoring tools because the workflow of authors often includesperiodically checking how user agents will display the web content to end users. Authors with disabilities need thesame opportunity to check their work.

A.3.7.1 Preview (Minimum):

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

  • (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or
  • (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG10].

ImplementingA.3.7.1

A.3.7.2 Preview (Enhanced):

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

ImplementingA.3.7.2

Principle A.4:Editing-views are understandable

Guideline A.4.1: (For the authoring tool user interface) Help authors avoidand correct mistakes. [Implementing A.4.1]

Rationale: Some authors with disabilities may be more susceptible to inputerrors due to factors such as difficulty making fine movements and speechrecognition system errors.

A.4.1.1 Content Changes Reversible(Minimum):

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

ImplementingA.4.1.1

A.4.1.2 Settings ChangeConfirmation:

If the authoring tool provides mechanismsfor changing authoring tool user interface settings, then thosemechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (LevelA)

ImplementingA.4.1.2

A.4.1.3 Content Changes Reversible(Enhanced):

Authors can sequentiallyreverse a series of reversible authoring actions. (LevelAAA)

ImplementingA.4.1.3

Guideline A.4.2: (For the authoring tool user interface) Document the userinterface, including all accessibility features. [Implementing A.4.2]

Rationale: Some authors may not be able to understand or operate the authoring tool user interface without documentation.

A.4.2.1 Describe AccessibilityFeatures:

For each authoring tool feature that is usedto meet Part A of ATAG 2.0, atleast one of the following is true: (Level A)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).

ImplementingA.4.2.1

A.4.2.2 Document All Features:

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

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).

ImplementingA.4.2.2

Part B: Support the production ofaccessible content

Part B ConformanceApplicability 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: Fullyautomatic 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 willimpose additional repair tasks on authors.

B.1.1.1 Content Auto-GenerationAfter 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). (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

ImplementingB.1.1.1

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

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

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

ImplementingB.1.1.2

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

Rationale: Accessibility information (WCAG) is critical tomaintaining comparable levels of web content accessibility (WCAG) between the inputand output of web content transformations.

B.1.2.1 Restructuring and RecodingTransformations (WCAG):

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

  • (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
  • (b) Warning: Authors have the default option to be warned that accessibility information (WCAG) may be lost (e.g. when saving a vector graphic into a raster image format); or
  • (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.

ImplementingB.1.2.1

B.1.2.2 Copy-Paste Inside AuthoringTool (WCAG):

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

ImplementingB.1.2.2

B.1.2.3 Optimizations PreserveAccessibility:

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

ImplementingB.1.2.3

B.1.2.4 Text Alternatives forNon-Text Content are Preserved:

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

  • Note: This success criterion only applies when the output technology is "included" for conformance.

ImplementingB.1.2.4

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, atminimum, 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 criteriafrom being met. (Level A to meet WCAG 2.0 Level A successcriteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; LevelAAA to meet all WCAG 2.0 success criteria)

ImplementingB.2.1.1

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

Rationale: By guidingauthors from the outset toward the creation and maintenanceof 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 thesame authoring outcome (e.g. styling text),then options that will result in accessible web content (WCAG) are at least as prominent as options that willnot. (Level A to meet WCAG 2.0 Level A successcriteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; LevelAAA to meet all WCAG 2.0 success criteria)

ImplementingB.2.2.1

B.2.2.2 Setting AccessibilityProperties (WCAG):

If the authoring toolprovides mechanisms to set web content properties (e.g. attributevalues), then mechanisms are also provided to set web content propertiesrelated to accessibility information (WCAG). (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

ImplementingB.2.2.2

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

Rationale: Improperlygenerated alternative content can create web content accessibility problems(WCAG) and interfere with accessibility checking.
Note: This guideline onlyapplies 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 isEditable (WCAG):

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

  • Note: An exception can be made when the non-text content is known to be decoration, formatting, invisible or a CAPTCHA.

ImplementingB.2.3.1

B.2.3.2 Automating Repair of TextAlternatives:

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

  • (a) No Generic or Irrelevant Strings: Generic strings (e.g. "image") and irrelevant strings (e.g. the file name, file format) are not used as text alternatives; and
  • (b) In-Session Repairs: If the repair attempt occurs during an authoring session, authors have the opportunity to accept, modify, or reject the repair attempt prior to insertion of the text alternative into the content; and
  • (c) Out-of-Session Repairs: If the repair attempt occurs after an authoring session has ended, the repaired text alternatives are indicated during subsequent authoring sessions (if any) and authors have the opportunity to accept, modify, or reject the repair strings prior to insertion in the content.

ImplementingB.2.3.2

B.2.3.3 Save for Reuse:

If the authoring tool provides thefunctionality for adding non-text content, when authors enter programmatically associated text alternatives for non-text content, then both of thefollowing are true: (Level AAA)

  • (a) Save and Suggest: The text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and
  • (b) Edit Option: The author has the option to edit or delete the saved text alternatives.

ImplementingB.2.3.3

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

Rationale: Providing accessible templates (WCAG) can have severalbenefits, including: immediately improving the accessibility of the web content (WCAG) of being edited, reducingthe effort required of authors, and demonstratingthe 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. (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

ImplementingB.2.4.1

B.2.4.2 Identify TemplateAccessibility:

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

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.

ImplementingB.2.4.2

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 canenable the template selection mechanism to display distinctions betweenaccessible and non-accessible templates that they create. (LevelAA)

  • Note: The distinction can involve providing information for the accessible templates (WCAG), the non-accessible templates or both.

ImplementingB.2.4.3

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

ImplementingB.2.4.4

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 demonstratingthe importance of accessibility.

B.2.5.1 Accessible Pre-AuthoredContent Options:

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

ImplementingB.2.5.1

B.2.5.2 Identify Pre-AuthoredContent Accessibility:

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

  • Note: The distinction can involve providing information for the accessible pre-authored content, the non-accessible pre-authored content or both.

ImplementingB.2.5.2

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 aWCAG 2.0 success criterioncan be violated, then accessibility checking for that successcriterion is provided (e.g. an HTML authoring tool that inserts images shouldcheck for alternative text; a video authoring tool withthe ability to edit text tracks should check for captions). (LevelA to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0success criteria)

ImplementingB.3.1.1

B.3.1.2 Help Authors Decide:

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

ImplementingB.3.1.2

B.3.1.3 Help Authors Locate:

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

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

ImplementingB.3.1.3

B.3.1.4 Status Report:

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

  • Note: The format of the accessibility status report is not specified and they might include a listing of problems detected or a WCAG 2.0 conformance level, etc.

ImplementingB.3.1.4

B.3.1.5 Programmatic Association ofResults:

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

ImplementingB.3.1.5

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, itgreatly enhances the utility of checking and increases thelikelihood 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 isnot met, then repair suggestion(s) areprovided: (Level A to meet WCAG 2.0 Level A successcriteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; LevelAAA to meet all WCAG 2.0 success criteria)

ImplementingB.3.2.1

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

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

Rationale: The accessible content support features will be more likelyto 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 bydefault. (Level A)

ImplementingB.4.1.1

B.4.1.2 Option to ReactivateFeatures:

The authoring tool does not include theoption to turn off its accessible content support features or features whichhave been turned off can be turned back on. (LevelA)

ImplementingB.4.1.2

B.4.1.3 Feature DeactivationWarning:

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

ImplementingB.4.1.3

B.4.1.4 Feature Prominence:

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

ImplementingB.4.1.4

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

Rationale: Some authors need support in determining how to use accessible content productionfeatures (e.g. how to respond to prompts for text alternatives, how to useaccessibility checking tools).Demonstrating accessible authoring as routine practice, or at least notdemonstrating inaccessible practices, will help to encourage acceptance ofaccessibility 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 successcriteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; LevelAAA to meet all WCAG 2.0 success criteria)

Implementing B.4.2.1

B.4.2.2 Feature Instructions:

Instructions forusing any accessible content support features appear in the documentation. (LevelA)

ImplementingB.4.2.2

B.4.2.3 Tutorial:

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

ImplementingB.4.2.3

B.4.2.4 Instruction Index:

The authoring tool documentation contains an index tothe instructions for using any accessible content support features. (LevelAAA)

ImplementingB.4.2.4


Conformance

This section is normative.

Conformance meansthat the authoring tool satisfies the applicable success criteriadefined in the guidelines section. This conformance sectiondescribes conformance and lists the conformance requirements.

Conformance Requirements

Success Criteria Satisfaction

The first step indetermining ATAG 2.0 conformance is to assess whether the Success Criteria havebeen satisfied. The potential answers are:

  • Not Applicable: The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g. a photo editor, a CSS editor, a status update field in a social networking application), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s). If a conformance claim is made, an explanation of why the success criterion is not applicable is required.
  • Yes: In the case of some success criteria, this will include a Level (A, AA, or AAA) with reference to WCAG 2.0. If a conformance claim is made, an explanation is optional, yet strongly recommended.
  • No: If a conformance claim is made, an explanation is optional, yet strongly recommended.

Relationship to the Web Content AccessibilityGuidelines (WCAG) 2.0

At the time ofpublishing, WCAG 2.0 [WCAG20] is the current W3CRecommendation regarding web content accessibility. For this reason, ATAG 2.0refers to WCAG 2.0 when setting requirements for (1) the accessibility of web-based authoring tool userinterfaces (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, ATAG2.0 refers to WCAG 2.0 within its definition of the term "accessible content" (and relatedterms, such as "accessible template"). Thedefinition of "accessible content" is content that would conform toWCAG 2.0, at either Level A, AA, or AAA, under the assumption that any webcontent technologies that are relied upon to satisfy the WCAG 2.0 successcriteria are accessibility supported. The phrase "at either Level A, AA,or AAA" takes into account that the definition of "accessiblecontent" can differ depending on the context of use (e.g. in a Level Asuccess criterion of ATAG 2.0 versus in a Level AAA success criterion). Thedefinition also includes two notes:

  • The first is "If accessibility support for the relied upon technologies is lacking, then the content will not conform to WCAG 2.0 and one or more groups of end-users with disabilities will likely experience difficulty accessing the content."
  • The second is "Conformance to WCAG 2.0, even at the highest level (i.e. Level AAA), still may not make content 'accessible to individuals with all types, degrees, or combinations of disability'." In order to highlight success criteria or defined terms in ATAG 2.0 that depend on WCAG 2.0, they are marked with the parenthetical: "(WCAG)".

Note on "accessibility-supported ways of usingtechnologies":

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

This concept is noteasily extended to authoring tools because manyauthoring tools can be installed and used in a variety of environments withdiffering availabilities for assistive technologies and user agents (e.g.private intranets versus public websites, monolingual sites versus multilingualsites). Therefore:

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

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

Conformance Options and Levels

There are two types ofconformance, each with three levels:

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

This conformanceoption may be selected when an authoring tool can be used toproduce accessible web content (WCAG) without additionaltools or components. The level of conformance is determined as follows:

  • Level A: The authoring tool satisfies all of the applicable Level A success criteria.
  • Level AA: The authoring tool satisfies all of the applicable Level A and Level AA success criteria.
  • Level AAA: The authoring tool satisfies all of the applicable success criteria.

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

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

This conformanceoption may be selected when an authoring tool would requireadditional tools or components in order to conform as a completeauthoring system. This option may be used for components with very limitedfunctionality (e.g. a plug-in) up to nearly complete systems (e.g. a markupeditor that only lacks accessibility checking functionality).

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

Note 1: Authoring toolswould not be able to meet partial conformance if they prevent additionalauthoring process components from meeting the failed success criteria (e.g. forsecurity reasons).
Note 2: The Part A Conformance ApplicabilityNotes and Part B Conformance Applicability Notes must be applied.

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

This conformanceoption may be selected when an authoring tool is unable to meetone 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 featuresare missing.

Web Content Technologies Produced:

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

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

Live publishing authoring tools:

ATAG 2.0 may beapplied to authoring tools with workflows that involve live authoring of webcontent (e.g. some collaborative tools). Due to the challenges inherent in real-timepublishing, conformance to Part B of ATAG 2.0 for these authoring tools may involvesome combination of support before (e.g. support in preparing accessibleslides), during (e.g. live captioning as WCAG 2.0 requires at Level AA) andafter the live authoring session (e.g. the ability toadd a transcript to the archive of a presentation that was initially publishedin 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 softwareapplication, authoring tools can be collections of components. A conformanceclaim can only be made by a responsible entity. Any other attempted"claims" are, in fact, reviews.

Required Components of a ConformanceClaim

  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 ConformanceClaim

In addition to therequired components of a conformance claim above, consider providing additionalinformation 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, norAUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim that has not beenpublished under the authority of the W3C, WAI, or AUWG.


Appendix A: Glossary

This section is normative.

This appendixcontains definitions for all of the significant/important/unfamiliar terms usedin the normative parts of this standard, including terms used in the Conformance section. Please consulthttp://www.w3.org/TR/qaframe-spec/ for more informationon the role of definitions in standards quality.

accessibility problems

ATAG 2.0 recognizes two types of accessibilityproblems:

  • text alternatives for non-text content: Text that is programmatically associated with non-text content or referred to fromtext that is programmatically associated with non-text content. For example, animage of a chart might have two text alternatives: a description in theparagraph after the chart and a short text alternative for the chart indicatingin words that a description follows.

  • alternatives for time-based media: Web content that serves the samefunction or purpose as one or more tracks in a time-based media presentation.This includes: captions, audio descriptions, extended audio descriptions, signlanguage interpretation as well as correctly sequenced text descriptions oftime-based visual and auditory information that also is capable of achievingthe outcomes of any interactivity in the time-based presentation.

  • media alternative for text: Media that presentsno more information than is already presented in text (directly or via textalternatives). A media alternative for text is provided for people who benefitfrom alternate representations of text. Media alternatives for text may beaudio-only, video-only (including sign-language video), or audio-video.

    Importantly, from the perspective of authoring tools,alternative content may or may not be:

  • programmatically associated alternative content: Alternative contentwhose location and purpose can be programmatically determined from the originalcontent for which it is serving as an alternative. For example, a paragraphmight serve as a text alternative for an image, but it is only programmaticallyassociated if this relationship is properly encoded (e.g. by"aria-labeledby").
    Note: ATAG 2.0 typicallyrefers to programmatically associated alternative content.

    assistive technology

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

  • screen magnifiers, and other visualreading assistants, which are used by people with visual, perceptual, andphysical print disabilities to change text font, size, spacing, color,synchronization with speech, etc. in order improve the visual readability ofrendered text and images;

  • screen readers, which are used bypeople who are blind to read textual information through synthesized speech orBraille;

  • text-to-speech software, which isused by some people with cognitive, language, and learning disabilities toconvert text into synthetic speech;

  • speech recognition software, whichare used by some people who have some physical disabilities;

  • alternative keyboards, which areused by some people with 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, whichare used by some people with physical disabilities to simulate mouse pointingand button activations.

    audio

    The technology of sound reproduction. Audio can becreated synthetically (including speech synthesis), recorded from real-worldsounds, or both.

    author actions preventing generation of accessible webcontent

    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 faultyaccessibility 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 coverroles such as content authors, designers, programmers, publishers, testers,etc. (see Part B Conformance Applicability Note 6: Multipleauthoring roles). Some authoring tools control whomay 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 inediting web content (e.g. typing text,deleting, inserting an element, applying a template). In contrast, most authoring tool user interfacesalso enable actions that do not edit content (e.g. saving, publishing, settingpreferences, viewing documentation).

  • reversible authoring action: An authoring action that can beimmediately and completely undone by the authoring tool upon a cancelrequest by an author. Examples of cancelrequests include: "cancel", "undo", "redo" (whenit used to reverse "undo"), "revert", and"roll-back"
    Note: It is acceptable foran authoring tool to collect a series of text entry actions (e.g. typed words,a series of backspaces) into a single reversible authoring action.

    authoring outcome

    The content or content modifications thatresult from authoring actions. Authoring outcomesare cumulative (e.g. text is entered, then styled, then made into a link, thengiven a title).

    authoring practice

    An approach that authors follow to achieve agiven authoring outcome (e.g. controlling presentation with style sheets).Depending on the design of an authoring tool, authoring practicesmay be chosen by authors or by the authoring tool. Authoring practices may ormay not be:

  • end of an authoring session: The point at whichthe author has no further opportunity to make authoring actions without startinganother session. The end of an authoring sessionmay be determined by authors (e.g. closing a document, publishing) or by the authoring tool (e.g. when theauthoring tool transfers editing permission to another author on acollaborative system).
    Note: The end of theauthoring session is distinct from publishing. Automatic content generation may continue afterthe end of both the authoring session and initial publishing (e.g. contentmanagement system updates).

    authoring tool

    Any web-based or non-web-based application(s) thatcan be used by authors (alone orcollaboratively) to create or modify web content for use by otherpeople (other authors or end users).
    Note 1:"application(s)": ATAG 2.0 may be conformed to bystand-alone applications or by collections of applications. If a conformanceclaim is made, then the claim must provide identifying information for eachapplication and also for any required extensions, plug-ins, etc.
    Note 2: "aloneor collaboratively": Multiple authors may contribute tothe creation of web content and, depending on the authoring tool, each authormay work with different views of the content and different author permissions.
    Note 3: "tocreate or modify web content":
    This clause rules out software thatcollects 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 innon-web content technologies.
    Note 4: "for useby other people":
    This clause rules out the many webapplications that allow people to modify web content that only they themselvesexperience (e.g. web-based email display settings) or that only provide inputto automated processes (e.g. library catalog search page).
    Examples of software that are generally considered authoring tools underATAG 2.0:

  • web page authoring tools (e.g. WYSIWYG HTML editors)

  • software for directly editing sourcecode

  • software for converting to web content technologies (e.g. "Save asHTML" features in office document applications)

  • integrated development environments(e.g. for web application development)

  • software that generates web contenton the basis of templates, scripts,command-line input or "wizard"-type processes

  • software for rapidly updatingportions of web pages (e.g. blogging, wikis, online forums)

  • software for generating/managingentire websites (e.g. content management systems, courseware tools, contentaggregators)

  • email clients that send messagesusing web content technologies

  • multimedia authoring tools

  • software for creating mobile webapplications

    Examples of software that are not consideredauthoring tools under ATAG 2.0 (in all cases, WCAG 2.0 still applies if thesoftware is web-based):

  • customizable personal portals: ATAG2.0 does not apply because the web content being edited is only available tothe owner of the portal

  • e-commerce order forms: ATAG 2.0does not apply because the purpose of an e-commerce order form is to order aproduct, not communicate with other people via web content, even if the datacollected by the form actually does result in web content (e.g. online trackingpages)

  • stand-alone accessibility checkers:ATAG 2.0 does not apply because a stand-alone accessibility checker with noautomated or semi-automated repair functionality does not actually modify webcontent. An accessibility checker with repair functionality or that isconsidered as part of a larger authoring process would be considered anauthoring tool.

    authoring tool user interface

    The display and control mechanism that authors use to operate the authoring tool software. Userinterfaces may be non-web-based or web-based or a combination (e.g. anon-web-based authoring tool might have web-based help pages):

  • authoring tool user interface (non-web-based): Any parts of anauthoring tool user interface that are not implemented as web content and instead rundirectly on a platform that is not a user agent (e.g. Windows, MacOS, Java Virtual Machine, iOS, Android).

  • authoring tool user interface (web-based): Any parts of anauthoring tool user interface that are implemented using web content technologies and are accessed by authors via a user agent.

    Authoring tool user interfaces may or may not be:

  • manual checking: Checking in whichthe tests are carried out by authors. This includes thecase where authors are aided by instructions or guidance provided by the authoring tool, but where authorsmust carry out the actual test procedure.

  • semi-automated checking: Checking in whichthe 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 thetests.

  • automated checking: Checking in whichthe tests are carried out automatically by the authoring tool without anyintervention by authors.

    An authoring tool may support any combination ofchecking types.

    content (web content)

    Information and sensory experience to be communicatedto 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 theoutput that is produced by the authoring tool. Content produced byauthoring tools may include web applications, including those that act as web-based authoring tools.Content may or may not be:

  • accessible content (WCAG): Content that wouldconform to WCAG 2.0, at either Level A,AA, or AAA, assuming that any web content technologies relied upon tosatisfy the WCAG 2.0 success criteria are accessibility supported.

    • Note 1: If accessibility support for therelied upon technologies is lacking, then the content will not conform to WCAG2.0 and one or more groups of end users with disabilities will likelyexperience difficulty accessing the content.

    • Note 2: Conformance to WCAG 2.0, even atthe highest level (i.e. Level AAA), still may not make content "accessibleto individuals with all types, degrees, or combinations of disability".

  • content being edited: The web content thatan author can modify during an authoring session. The content beingedited may be a complete piece of content (e.g. image, style sheet) or onlypart of a larger piece of content (e.g. a status update). The content beingedited only includes content in web content technologies that the authoring tool supports (e.g. aWYSIWYG HTML editor allows editing of the HTML content of a web page editable,but not the images).

    content properties

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

    content (structured)

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

    content generation (content authoring, content editing)

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

  • author generated content: Web content for which authors are fully responsible. The author may only beresponsible down to a particular level (e.g. when asked to type a text label,the author is responsible for the text, but not for how the label is marked up;when typing markup in a source editing-view, the author is notresponsible for the fact that UNICODE is used to encode the text ).

  • automatically-generated content: Web content forwhich developer-programmedfunctionality is fully responsible (e.g. what markup to output when an authorrequests to start a new document, automatically correcting markup errors).

  • third-party content generation: Web content forwhich a third-party author is responsible (e.g. community shared templates).

    content rendering

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

  • conventional renderings (or "WYSIWYG"): When content isrendered in a way that is similar to the default rendering a user agent would create fromthe same content. While "WYSIWYG", standing for"What-you-see-is-what-you-get" is the common term, differencesbetween user agents and end user settings mean that in reality there is nosingle typical end user experience; or

  • unconventional renderings: When content isrendered differently than it would be in a typical user agent (e.g. renderingan audio file as a graphical waveform); or

  • partial renderings: When some aspects ofthe content are rendered, played, or executed, but not others (e.g. aframe-by-frame video editor renders thegraphical, but not the timing aspects, of a video).

    content transformations

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

  • Optimizing Content Transformations: Transformations inwhich the content technology is not changed and the structural features of thecontent technology that are employed also stay the same. Changes would not beexpected to result in information loss (e.g. removing whitespace, replacingin-line styles with an external style sheet).

  • Restructuring Content Transformations: Transformations inwhich the content technology stays the same, but the structural features of thetechnology used to markup the content are changed (e.g. linearizing tables,splitting a document into pages.

  • Recoding Content Transformations: Transformations inwhich the content technology used to encode the content is changed (e.g. HTMLto XHTML, a word processing format to HTML).

    Note: Clipboard operations, in whichcontent is copied to or pasted from the platform clipboard, are not consideredcontent transformations.

    control settings

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

    developer

    Any entities or individuals responsible forprogramming the authoring tool. This includes theprogrammers of any additional software components included by the Claimant inthe conformance claim. In some cases,development of the authoring tool is complete before authors can use it to publish web content. However, in othercases (e.g. some web-based authoring tools), the developer maycontinue 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 providefunctionality to meet the requirements of authors with disabilities(e.g. keyboard navigation, zoom features, text-to-speech). Additional orspecialized functionality may still be provided by external assistive technology.

    display settings

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

  • audio display settings: the characteristicsof audio output of music, sounds, and speech. Examplesinclude volume, speech voices, voice speed, and voice emphasis.

  • visual display settings: the characteristicsof the on-screen rendering of text and graphics. Examples include fonts, sizes,colors, spacing, positioning, and contrast.

  • tactile display settings: the characteristicsof haptic output. Examples include the magnitude of the haptic forces and thetypes of vibration.

    documentation

    Any information that supports the use of an authoring tool. This informationmay 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 authoringtool or user agent. The document objectmay form part of a platform accessibility service that enablescommunication with assistive technologies. Web-based authoring tools are considered tomake use of the document object that is maintained by the user agent.

    element

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

    end user

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

    human language

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

    informative

    For information purposes and not required forconformance.

    keyboard interface

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

    keyboard trap

    A user interface situation in which a keyboard interface may be used to movefocus to, but not from, a user interface component or group ofcomponents.

    label

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

    live

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

    markup language

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

  • markup of some content is the set ofannotations that appear in the content.

    name

    Text by which software can identify a user interface component to the author or end user. The name may behidden 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 ofcharacters that can be programmatically determined or where thesequence is not expressing something in human language. This includes ASCIIArt (which is a pattern of characters), emoticons, and images representingtext.

    normative

    Required for conformance. One may conform in avariety 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 withchoices.

  • default option: A setting or value for an option that is assigned automatically by the authoring tool and remains ineffect unless canceled or changed by the author.

    platform

    The software environment within which the authoring tool operates. Platformsprovide a consistent operational environment on top of lower level softwareplatforms or hardware. For web-based authoring user interfaces, the most relevantplatform will be a user agent (e.g. browser). For non-web-based userinterfaces, the range of platforms includes, but may not belimited to, desktop operating systems (e.g. GNOME desktop on Linux, Mac OS,Windows), mobile operating systems (e.g. Android, BlackBerry, iOS, WindowsPhone), or cross-OS environments (e.g. Java), etc.
    Note 1: Many platformsmediate communication between applications operating on the platform andassistive technology via a platform accessibility service.
    Note 2: Accessibilityguidelines for developers exist for manyplatforms.

    platform accessibility service

    A programmatic interface that is specificallyengineered to provide communication between applications and assistive technologies (e.g. MSAA,IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OS Xapplications, GNOME Accessibility Toolkit API for GNOME applications, JavaAccess for Java applications). On some platforms, it may beconventional 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-partychecking and repair tool) and that isnot part of web content being edited. Authors generally choose to include or exclude plug-ins fromtheir authoring tool.

    pre-authored content

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

  • Processing content: Whether the authoring tool is able to extractinformation from the web content (e.g. to extract thelanguage of content from the markup).

  • Communication between the authoringtool and assistive technology: For non-web-based userinterfaces, this means making use of platform accessibility services, APIs, and, in somecases, document object models. For web-based user interfaces, this means ensuringthat the user agent can pass on theinformation (e.g. through the use of WAI-ARIA).

    prominence

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

  • at least as prominent: For ATAG 2.0, a user interface component A is considered tobe "at least as prominent" as another component B when, from adefault state, component A becomes displayed (and enabled) with the same numberor less "opening" actions than are required for component B to becomedisplayed (and enabled).
    Note 1: When a container isopen, all of the enabled components in the container (e.g. items in a list,items in a menu, buttons in a toolbar, all components in a dialog box) areconsidered to be displayed (and therefore are at least as prominent as eachother), even if the container must be scrolled for them to become visible. Thistakes into account that different screen sizes and author settings will affectwhich components are visible at a given time.
    Note 2: "Openingactions" are actions made by authors on components within the userinterface that result in new components becoming displayed or enabled. Forexample: (a) keyboard shortcut to a top-level menu item to display a sub-menu,(b) keyboard selection on a button to display a dialog box, (c) mouse click ona checkbox to enable previously disabled sub-items, etc. Actions that do notcause new components to become actionable (e.g. moving focus, scrolling alist), are not counted as "opening actions".
    Note 3: Keyboard shortcutsto components in closed containers are not counted as "openingactions" because the components have no prominence when they are notdisplayed. The same is true when authors must use "search" to revealcomponents in closed containers.
    Note 4: The "defaultstate" is the state of the authoring tool at the beginning ofan authoring session as set by the developer. The default state of manydocument authoring tools is an editing-view.

    prompt

    Any authoring tool initiated requestfor a decision or piece of information from authors. The term coversboth 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 theterm "range" where absolute measurements may not be practical (e.g.the set of all help documentation examples, the set ofall templates). While the strict testablerequirement is the definition "More than one item within a multi-itemset", implementers are strongly encouraged to implement the successcriteria more broadly.

    relationships

    Meaningful associations between distinct pieces of content.

    repair (accessibility)

    The process by which web content accessibility problems that have beenidentified within web content are resolved. ATAG2.0 recognizes three types of repair, based on increasing levels of automation:

  • manual repair: Where the repairs are carried outby authors. This includes the case where authors are aided byinstructions or guidance provided by the authoring tool, but where authorscarry out the actual repair procedure;

  • semi-automated repair: Where the repairsare partially carried out by the authoring tool, but where authors' input orjudgment is still required to complete the repair; and

  • automated repair: Where the repairsare carried out automatically by the authoring tool without any intervention byauthors.

    restrictions, restricted web content authoring

    When the web content that authors can specify with an authoring tool either must includeor must not include certain content (e.g. elements, attributes, widgets). Manyauthoring tools restrict authoring in some way, which can either benefit accessibility(e.g. if text alternatives for non-text content are required) or detract fromaccessibility (e.g. if attributes for defining text alternatives are notavailable). In contrast, authoring tools that allow unrestricted web contentauthoring 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 thefunction of a component within web content (e.g. a string thatindicates whether an image functions as a hyperlink, command button, or checkbox).

    sequential keyboard access

    Using a keyboard interface to navigate thefocus 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 incontrast to direct keyboard access methods such as keyboard shortcuts and theuse of bypass links.

    technology (web content)

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

    template

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

  • accessible templates (WCAG): Templates that canbe filled in to create web content that meets the WCAG 2.0 success criteria(Level A, AA or AAA), when both of the following are true:

    1. The author correctly follows anyinstructions provided (e.g. correctly responding to prompts, correctly replacinghighlighted placeholders); and

    2. No further authoring occurs

      Note: Under theseconditions, some templates will result in completely empty documents, which areconsidered accessible by default.

      template selection mechanism

      A function beyond standard file selection that allowsauthors to select templates to use as the basisfor 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 anitem, save a change). Examples include: authoring session timeouts, time-basedpresentations (e.g. tutorial video).

      tutorial

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

      user agent

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

  • In-Market User Agent: A user agent thatcan be procured by members of the public (free or otherwise). Usually, anin-market user agent will be a separate software from the authoring tool; however, sometimesa software may combine user agent and authoring tool functionality. These casesinclude:

    • Preview-Only: If the user agent can only renderweb content that it receives from the associated authoring functionality, thenthe software is an authoring tool with a preview feature. Suchpreview-only features are not considered in-market user agents.

    • User Agent with Authoring Tool Mode: If the user agentfunctionality must retrieve and open web content before it can be sent to theauthoring tool functionality, then the software is a user agent with anauthoring tool mode. If the user agent is used to preview content produced bythe authoring tool mode, then it is to be considered an in-market user agent.

    • Combined User Agent/Authoring Tool: A user agent inwhich the default mode of user interaction enables editing the web content.These tools do not need previews because the author is already experiencing thecontent in the same way as end users.

      user interface component

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

      video

      The technology of moving pictures or images. Videocan 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.0categorizes views according to whether they support editing:

  • editing-views: Views in which some or all of thecontent is editable; or

  • previews: Views in which no authoring actions are provided (i.e.the view is not editable). Previews are provided to present the web contentbeing edited by the authoring tool as it would appearto end users of user agents. Previews may beimplemented using actual in-market user agents, but this is notnecessary.

    ATAG 2.0 also recognizes several approaches topresenting the content in a view:

  • source views: The content is presented inunrendered form (e.g. plain text editors); or

  • rendered views: Content renderings (conventional,unconventional or partial) are presented; or

  • property views: Only properties ofthe content are presented. The authoring tool then uses these properties to automatically generate the content to be published (e.g. CMS calendarwidget that generates a calendar from the numeric month and year).

    workflow

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


    Appendix B: References

    For the latestversion of any W3C standards please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Somedocuments listed below may have been superseded since the publication of thisdocument.

    This section is normative

    [UAAG10]

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

    This section is informative.

    [ATAG10]

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


    Appendix C:Acknowledgments

    Participants activein the AUWG at the time of publication:

  • Tom Babinszki (IBM)
  • Tim Boland (National Institute for Standards and Technology)
  • Alastair Campbell (Nomensa)
  • Alessandro Miele (Invited Expert)
  • Jan Richards (Inclusive Design Institute, OCAD University)
  • Jeanne Spellman (W3C)
  • Jutta Treviranus (WG Chair; Inclusive Design Institute, OCAD University)

ATAG Candidate Recommendation Testing Volunteers

  • Victoria Clark
  • Maria Carmen C. Cruz
  • Emanuela Gorla
  • Michael Gower
  • Anne Jackson
  • Taliesin Love Smith

Other previouslyactive 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,Cherie Ekholm, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, PhillJenkins, Len Kasday, Marjolein Katsma, Alex Li, William Loughborough, KarenMardahl, Matt May, Charles McCathieNevile, Ann McMeekin, Matthias Müller-Prove,Liddy Nevile, Sueann Nichols, Graham Oliver, Greg Pisocky, Wendy Porch, SarahPulis, Bob Regan, Chris Ridpath, Andrew Ronksley, Gregory Rosmaita, RobertoScano, Dana Simberkoff, Reed Shaffner, Michael Squillace, Heather Swayne, GreggVanderheiden, Carlos Velasco, and Jason White.

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

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


1楼 发布于:2016-6-16   |   查看数:0   |   回复数:0
初出江湖