W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2006

ATAG 2.0 editor's draft

From: Jan Richards <jan.richards@utoronto.ca>
Date: Wed, 21 Jun 2006 13:47:07 -0400
Message-ID: <4499861B.50306@utoronto.ca>
To: WAI-AUWG List <w3c-wai-au@w3.org>

Hi,

The new editor's draft is up at:

http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060621/WD-ATAG20-20060621.html

It also includes the checklist doc and version comparison docs:
http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060621/checklist.html
http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060621/version-comparison.html

Between yesterday and today I made a number of editorial changes as well 
as a few changes requiring group consent (marked as editor changes), 
which are listed below:

[1]
- Changing the def'n of Web Content from:
Web Content
Content published on the Web using a *content type*.
TO
Web Content (or shortened to "content")
Any material in a *content type*. If the content type is a *markup 
language*, then the terms cover the information both within the tags 
(i.e., the *markup*) and between them. In this document, the terms are 
primarily used in the context of the material that is authored and 
outputted by *authoring tools*.

REASON: I wanted to make content (which we use a lot in the success 
criteria) a linked definition term but couldn't if the content needed to 
already be published. (with the new definition in, I have linked 
"content" and "Web content" throughout the document.)

[2]
- Rewording A.2.6 from:
A.2.6 For the authoring tool user interface, allow the author to search 
content and markup within the editing views. [Priority 2]
TO
A.2.6 For the authoring tool user interface, allow the author to search 
content, including markup, within the editing views. [Priority 2]

REASON: New definition makes "and" unnecessary.


Cheers,
Jan




Jan Richards wrote:
> Hi everyone,
> 
> I was supposed to publish an updated editor's draft of ATAG 2.0 
> yesterday so that we could vote on whether to send it to last call on 
> our Monday meeting. However, I was quite sick for the latter part of 
> last week and over the weekend and didn't get it out. The only part I 
> have not quite finished updating is the checklist, so I have attached 
> the other items to this message.
> 
> I intend to publish the draft tomorrow without wording changes so you 
> are safe to begin reviewing this doc.
> 
> Cheers,
> Jan
> 
> PS: please note:
> 
> 1. a few non-editorial changes to the draft - marked in red - including 
> the added def'n of "platform" and the description text for the ui image 
> in the glossary.
> 
> 2. the atag 1.0 comparison document.
> 
> ------------------------------------------------------------------------
> 
> [Contents <#toc>] [Techniques </TR/2004/WD-ATAG20-TECHS-20041122/>] 
> [Checklist <checklist.html>]
> W3C <http://www.w3.org/>
> 
> 
>   Authoring Tool Accessibility Guidelines 2.0
> 
> 
>     Editor's Draft 15 June 2006
> 
> This version:
>     http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060526/WD-ATAG20-20060608.html
>     <http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060608/WD-ATAG20-20060608.html>
> Latest version:
>     http://www.w3.org/TR/ATAG20/
> Previous version:
>     http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060526/WD-ATAG20-20060526.html
>     <http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060526/WD-ATAG20-20060526.html>
> 
> Editors:
>     Jutta Treviranus - ATRC, University of Toronto
>     Jan Richards - ATRC, University of Toronto
>     Matt May
> 
> Copyright <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> 
> ©2005 W3C <http://www.w3.org/>^® (MIT <http://www.csail.mit.edu/>, ERCIM 
> <http://www.ercim.org/>, Keio <http://www.keio.ac.jp/>), All Rights 
> Reserved. W3C liability 
> <http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer>, 
> trademark <http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks> 
> and document use 
> <http://www.w3.org/Consortium/Legal/copyright-documents> rules apply.
> 
> ------------------------------------------------------------------------
> 
> 
>     Abstract
> 
> This specification provides guidelines for designing Web content 
> authoring tools <#def-Authoring-Tool> that are more accessible for 
> people with disabilities. An authoring tool that conforms to these 
> guidelines will promote accessibility by providing an accessible user 
> interface to authors with disabilities as well as enabling, supporting, 
> and promoting the production of accessible Web content by all authors.
> 
> "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a 
> series of accessibility guidelines published by the W3C Web 
> Accessibility Initiative <http://www.w3.org/WAI/> (WAI).
> 
> 
>     Status of this document
> 
> /This section describes the status of this document at the time of its 
> publication. Other documents may supersede this document. A list of 
> current W3C publications and the latest revision of this technical 
> report can be found in the W3C technical reports index 
> <http://www.w3.org/TR/> at http://www.w3.org/TR/./
> 
> Publication as a Working Draft does not imply endorsement by the W3C 
> Membership. This is a draft document and may be updated, replaced or 
> obsoleted by other documents at any time. It is inappropriate to cite 
> this document as other than work in progress.
> 
> The AUWG intends to publish ATAG 2.0 as a W3C Recommendation. Until that 
> time Authoring Tool Accessibility Guidelines 1.0 
> <http://www.w3.org/TR/ATAG10/> (ATAG 1.0) [ATAG10] <#ref-ATAG10> is the 
> stable, referenceable version. This Working Draft does not supercede 
> ATAG 1.0.
> 
> This document was produced under the 5 February 2004 W3C Patent Policy 
> <http://www.w3.org/Consortium/Patent-Policy-20040205/>. The Working 
> Group maintains a public list of patent disclosures 
> <http://www.w3.org/WAI/AU/ATAG2/disclosure> relevant to this document; 
> that page also includes instructions for disclosing a patent. An 
> individual who has actual knowledge of a patent which the individual 
> believes contains Essential Claim(s) with respect to this specification 
> should disclose the information in accordance with section 6 of the W3C 
> Patent Policy 
> <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure>.
> 
> This document has been produced as part of the W3C Web Accessibility 
> Initiative <http://www.w3.org/WAI/> (WAI). The goals of the AUWG are 
> discussed in the Working Group charter 
> <http://www.w3.org/WAI/AU/charter4.html>. The AUWG is part of the WAI 
> Technical Activity <http://www.w3.org/WAI/Technical/Activity>.
> 
> 
>     Table of contents
> 
>     * 1 Introduction <#Introduction>
>           o 1.1 Definition of /authoring tool/ <#intro-def-au>
>           o 1.2 Role of authoring tools in Web accessibility <#au-role>
>           o 1.3 Relationship to the Web Content Accessibility Guidelines
>             (WCAG) <#Relationship-To-WCAG>
>     * 2 Conformance <#Conformance>
>           o 2.1 Conformance Model <#Conformance-Model>
>           o 2.2 Conformance Claims <#Conformance-Claim>
>           o 2.3 "Progress Towards Conformance" Statement
>             <#prog-conf-statement>
>     * 3 The Authoring Tool Accessibility Guidelines <#guidelines>
>           o PART A: Make the authoring tool user interface accessible
>             <#part-tool-accessible>
>                 + Guideline A.1: Authoring Tool User Interface must be
>                   Perceivable <#gl-tool-accessible-perceivable>
>                 + Guideline A.2: Authoring Tool User Interface must be
>                   Operable <#gl-tool-accessible-operable>
>                 + Guideline A.3: Authoring Tool User Interface must be
>                   Understandable <#gl-tool-accessible-understandable>
>                 + Guideline A.4: Authoring Tool User Interface must be
>                   Access System Friendly <#gl-tool-accessible-atfriendly>
>           o PART B: Support the production of accessible content
>             <#part-support-production>
>                 + Guideline B.1: Enable the production of accessible
>                   content <#gl-enable-accessible-content>
>                 + Guideline B.2: Support the author in the production of
>                   accessible content <#gl-support-author>
>                 + Guideline B.3: Promote and integrate accessibility
>                   solutions <#gl-promote-integrate>
>     * 4 Glossary <#definitions>
>     * 5 References <#references>
>           o 5.1 How to refer to this document <#this-doc-ref>
>           o 5.2 Normative references <#Normative-ref>
>           o 5.3 Informative References <#Informative-ref>
>     * 6 Acknowledgments <#acknowledgments>
>     * Appendix A. Checklist <checklist.html>
>     * Appendix B. Comparison of ATAG 1.0 checkpoints to ATAG 2.0
>       <version-comparison.html>
> 
> ------------------------------------------------------------------------
> 
> 
>     1. Introduction
> 
> You are reading the Authoring Tool Accessibility Guidelines (WCAG) 
> version 2.0. This document includes recommendations for assisting 
> authoring tool <#intro-def-au> developers to make their tools (and the 
> content that the tools generate) more accessible to all people, 
> especially people with disabilities, who may potentially be either 
> authors <#def-Author> or end users <#def-End-Users>. These guidelines 
> have been written to address the requirements of many different 
> audiences, including, but not limited to: policy makers, technical 
> administrators, and those who develop or manage content. An attempt has 
> been made to make this document as readable and usable as possible for 
> that diverse audience, while still retaining the accuracy and clarity 
> needed in a technical specification.
> 
> ATAG 2.0 is part of a series of accessibility guidelines published by 
> the Web Accessibility Initiative (WAI). The relationship between these 
> documents is explained in "Essential Components of Web Accessibility" 
> [COMPONENTS] <#ref-Components>.
> 
> 
>         This document consists of:
> 
>     * This introduction.
>     * Information about conformance <#Conformance>.
>     * The guidelines <#guidelines> with normative success criteria.
>       (Note: The checkpoints in this section are numbered differently
>       than the content in other sections. For example, "Checkpoint
>       A.1.2" refers to the second checkpoint of the first guideline in
>       the first part of the guidelines).
>     * Links to @@Internal draft at
>       http://www.w3.org/WAI/AU/2006/techs/techs.html@@ a separate
>       non-normative document, entitled "Techniques for Authoring Tool
>       Accessibility Guidelines 2.0" [ATAG20-TECHS] <#ref-ATAG20-TECHS>
>       (the "Techniques document" from here on), that provide sufficent
>       and advisory techniques for how each success criteria might be
>       satisfied. (Note: These techniques are informative examples only,
>       and other strategies may be used or required to satisfy the
>       checkpoints)
>     * References <#references> and a glossary <#definitions>.
>     * Appendices containing a checklist <checklist.html> and a document
>       comparing the checkpoints in ATAG 1.0 to those in this document
>       (ATAG 2.0) <version-comparison.html>.
> 
> 
>       1.1 Definition of /authoring tool/
> 
> ATAG 2.0 defines an "authoring tool" as: any software, or collection of 
> software components, that authors <#def-Author> use to create or modify 
> Web content for publication, where a "collection of software components" 
> are any software products used together (e.g., base tool and plug-in) or 
> separately (e.g., markup editor, image editor, and validation tool), 
> regardless of whether there has been any formal collaboration between 
> the developers of the products.
> 
> The following categories are an informative illustration of the range of 
> tools covered by ATAG 2.0. The categories are used primarily in the 
> Techniques document [ATAG20-TECHS] <#ref-ATAG20-TECHS> to mark examples 
> that may be of interest to developers of particular types of tools. 
> Note: Many authoring tools include authoring functions from more than 
> one category (e.g., an HTML editor with both code-level <#code-level> 
> and WYSIWYG <#wysiwyg> editing views):
> 
>     *
>       *Code-level Authoring Functions: *Authors have full control over
>       all aspects of the resulting Web content that have bearing on the
>       final outcome. This covers, but is not limited to plain text
>       editing, as this category also covers the manipulation of symbolic
>       representations that are sufficiently fine-grained to allow the
>       author the same freedom of control as plain text editing (e.g.,
>       graphical tag placeholders). /Examples:/ text editors, text
>       editors enhanced with graphical tags, some wikis, etc.
>     *
>       *WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions:*
>       Authors have control over entities that closely resemble the final
>       appearance and behavior of the resulting Web content. /Examples:/
>       rendered document editors, bitmap graphics editors, etc.
>     *
>       *Object Oriented Authoring Functions:* Authors have control over
>       functional abstractions of the low level aspects of the resulting
>       Web content. /Examples:/ timelines, waveforms, vector-based
>       graphic editors, objects which represent web implementations for
>       graphical widgets (e.g. menu widgets) etc.
>     *
>       *Indirect Authoring Functions:* Authors have control over only
>       high-level parameters related to the automated production of the
>       resulting Web content. This may include interfaces that assist the
>       author to create and organize Web content without the author
>       having control over the markup, structure, or programming
>       implementation. /Examples:/ content management systems, site
>       building wizards, site management tools, courseware, blogging
>       tools, content aggregators, conversion tools, model-based
>       authoring tools, etc.
> 
> 
>       1.2 Role of authoring tools in Web accessibility
> 
> The guiding principle of ATAG 2.0 is that:
> 
>     /Everyone should have the ability to create and access Web content./
> 
> Authoring tools play a crucial role in achieving this principle because 
> the accessibility of the tool's authoring tool user interface 
> <#def-Authoring-Tool-Interface> determines who can access the tool as a 
> Web content author <#def-Author> and the accessibility of the resulting 
> Web content determines who can be an end user <#def-End-Users> of that 
> Web content.
> 
> The approach taken to the production of accessible content in these 
> guidelines is one of enabling, supporting, and guiding the author. In 
> general, the Working Group does not believe that enforcing particular 
> author behaviour through overly restrictive mechanisms is a workable 
> solution.
> 
> As an introduction to accessible authoring tool design, consider that 
> the authors and end users of Web content may be using the tool and its 
> output in contexts that are very different from that which may be 
> regarded as typical. For example, authors and end users may:
> 
>     * Not be able to see, hear, move, or be able to process some types
>       of information easily or at all;
>     * Have difficulty reading or comprehending text;
>     * Not have or be able to use a keyboard or mouse;
>     * Have a text-only display, or a small screen.
> 
> For more information, see "How People with Disabilities Use the Web" 
> [PWD-USE-WEB] <#ref-PWD-USE-WEB>. In addition, following the guidelines 
> provides benefits for authors and end users beyond those listed in these 
> various disability-related contexts. For example, a person may have 
> average hearing, but still require captions for audio information due to 
> a noisy workplace. Similarly, a person working in an eyes-busy 
> environment may require an audio alternative to information they cannot 
> view.
> 
> 
>       1.3 Relationship to the Web Content Accessibility Guidelines (WCAG)
> 
> This section is normative <#def-Normative>.
> 
> /At the time of publication, version 1.0 of WCAG is a W3C Recommendation 
> [WCAG10] <#ref-WCAG10>, and a second version of the guidelines is under 
> development [WCAG20] <#ref-WCAG20>. Note that the two versions have 
> somewhat different Conformance Models./
> 
> ATAG 2.0 refers to WCAG as a benchmark for judging the accessibility of 
> Web content (see the term "Accessible Web Content 
> <#def-Accessible-Web-Content>") and Web-based authoring tool user 
> interfaces (see the term "Accessible Authoring Tool User Interface 
> <#def-Accessible-Authoring-Interface>"). For more information on how 
> WCAG acts as a benchmark, see "Relative Priority" Checkpoints 
> <#priority-Relative>.
> 
> *Note that the references to WCAG in the guidelines section of ATAG 2.0 
> <#guidelines> are made without an associated version number.* This has 
> been done to allow developers to select, and record in the conformance 
> profile <#conf-profile>, whichever version of WCAG is most appropriate 
> for the circumstances of a given authoring tool. The Working Group does 
> recommend considering the following factors when deciding which WCAG 
> version to use:
> 
>     * The latest version of WCAG will be the most accurate with respect
>       to state-of-the-art technologies and accessibility best practices.
>       Older versions of WCAG may include requirements that are no longer
>       necessary, due to advances in user agent technology.
>     * The versions of WCAG differ with respect to the formats for which
>       there are published WCAG technique documents. This is important
>       because ATAG 2.0 requires published content type-specific WCAG
>       benchmark <#conf-benchmark> documents, which may be based on WCAG
>       technique documents, if they are available.
>     * The versions of WCAG differ in the degree to which they match the
>       legislation and policies that drive author requirements. Many
>       authors will be seeking to use authoring tools to create Web
>       content that meets legislation, corporate policies, etc. It is
>       likely that as WCAG progresses, so too will legislation and
>       policies, albeit at an uneven pace. Authoring tool developers may,
>       therefore, consider supporting both versions of WCAG.
> 
> ------------------------------------------------------------------------
> 
> 
>     2. Conformance
> 
> This section is normative <#def-Normative>.
> 
> 
>       2.1 Conformance Model
> 
> 
>         Conformance Levels
> 
> Authoring tools may claim conformance to ATAG 2.0 at one of three 
> conformance levels. The level achieved depends on the priority 
> <#conf-checkpoint-priorities> of those checkpoints for which the 
> authoring tool has satisfied the success criteria. The levels are:
> 
> *Level "A"*
>     The authoring tool has satisfied all Priority 1 <#priority-1>
>     "regular priority" checkpoints <#priority-Regular> and has also
>     satisfied all of the "relative priority" checkpoints
>     <#priority-Relative> to at least Level 1 <#rp_level1>. 
> *Level "Double-A"*
>     The authoring tool has satisfied all Priority 1 <#priority-1> and
>     Priority 2 <#priority-2> "regular priority" checkpoints
>     <#priority-Regular> and has also satisfied all of the "relative
>     priority checkpoints" <#priority-Relative> to at least Level 2
>     <#rp_level2>.
> *Level "Triple-A"*
>     The authoring tool has satisfied all Priority 1 <#priority-1>,
>     Priority 2 <#priority-2>, and Priority 3 <#priority-3> "regular
>     priority" checkpoints <#priority-Regular> and has also satisfied all
>     of the "relative priority checkpoints" <#priority-Relative> to Level
>     3 <#rp_level3>.
> 
>     Figure 1: A graphical view of the requirements of the ATAG 2.0
>     conformance level "ladder".
>     A graphic that illustrates the levels of conformance as they are
>     explained in the text of the conformance levels, above. A long
>     description appears below the graphic.
>     The graphic is a table with four rows and three columns. The header
>     row labels are "Ladder of ATAG 2.0 Conformance Levels", "Regular
>     Priority Checkpoints" and "Relative Priority Checkpoints". The data
>     rows are labeled Level 'Triple-A' (highest) , Level 'Double-A', and
>     Level 'A' (lowest). Bars superimposed across the rows demonstrate
>     that in order to meet each higher level, additional regular priority
>     checkpoints must be met as well as increasing levels of relative
>     priority checkpoints.
> 
> 
>         Checkpoint Priorities
> 
> Each checkpoint has been assigned a priority level that indicates its 
> importance and determines whether that checkpoint must be met in order 
> for an authoring tool to achieve a particular conformance level 
> <#conf-levels>. There are three levels of "regular priority" checkpoints 
> <#priority-Regular> as well as a special class of "relative priority" 
> checkpoints <#priority-Relative> that rely on WCAG to determine their 
> importance <#Relationship-To-WCAG>.
> 
> 
>           "Regular Priority" Checkpoints:
> 
> *Priority 1*
>     *Significance in Part A:* If the authoring tool does not satisfy
>     these checkpoints, one or more groups of authors with disabilities
>     will find it *impossible* to author for the Web using the tool.
>     Â  *Significance in Part B:* These checkpoints are *essential* to
>     helping all authors to create Web content that conforms to WCAG
>     <#Relationship-To-WCAG>. 
> *Priority 2*
>     *Significance in Part A:* If the authoring tool does not satisfy
>     these checkpoints, one or more groups of authors with disabilities
>     will find it *difficult* to author for the Web using the tool.
>     *Significance in Part B:* These checkpoints are *important* to
>     helping all authors create Web content that conforms to WCAG
>     <#Relationship-To-WCAG>.
> *Priority 3*
>     *Significance in Part A:** *If the authoring tool does not satisfy
>     these checkpoints, one or more groups of authors with disabilities
>     will find it *inefficient* to author for the Web using the tool.
>     *Significance in Part B:* These checkpoints are *beneficial* to
>     helping all authors to create Web content that conforms to WCAG
>     <#Relationship-To-WCAG>.
> 
> 
>           "Relative Priority" Checkpoints
> 
> The importance of each "relative priority" checkpoint depends on the 
> requirements of whichever version of WCAG <#Relationship-To-WCAG> the 
> evaluator has chosen to specify in the conformance profile 
> <#conf-profile>. These checkpoints can be met at one of three levels:
> 
> *Relative Priority - Level 1*
>     *Significance in Part A (/checkpoint A.0.1 only/): *The user
>     interface checkpoint has been satisifed at a *minimal* conformance
>     level (i.e., level A) to WCAG (version 1.0 *or* 2.0) as specified in
>     the conformance profile <#conf-profile> (including content
>     type-specific WCAG benchmark <#conf-benchmark> document).
>     *Significance in Part B:* The content production checkpoint has been
>     satisfied at a *minimal* conformance level (i.e., level A) to WCAG
>     (version 1.0 *or* 2.0) as specified in the conformance profile
>     <#conf-profile> (including content type-specific WCAG benchmark
>     <#conf-benchmark> document).
> *Relative Priority - Level 2*
>     *Significance in Part A *(*/checkpoint A.0.1 only/*)*: *The user
>     interface checkpoint has been satisifed at an *intermediate*
>     conformance level (i.e., level Double-A) to WCAG (version 1.0 *or*
>     2.0) as specified in the conformance profile <#conf-profile>
>     (including content type-specific WCAG benchmark <#conf-benchmark>
>     document)
>     *Significance in Part B:* The content production checkpoint has been
>     satisfied at an *intermediate* conformance level (i.e., level
>     Double-A) to WCAG (version 1.0 *or* 2.0) as specified in the
>     conformance profile <#conf-profile> (including content type-specific
>     WCAG benchmark <#conf-benchmark> document) 
> *Relative Priority - Level 3*
>     *Significance in Part A *(*/checkpoint A.0.1 only/*)*: *The user
>     interface checkpoint has been satisifed at a *stringent* conformance
>     level (i.e., level Triple-A) to WCAG (version 1.0 *or* 2.0) as
>     specified in the conformance profile <#conf-profile> (including
>     content type-specific WCAG benchmark <#conf-benchmark> document)
>     *Significance in Part B:* The content production checkpoint has been
>     satisfied at a *stringent* conformance level (i.e., level Triple-A)
>     to WCAG (version 1.0 *or* 2.0) as specified in the conformance
>     profile <#conf-profile> (including content type-specific WCAG
>     benchmark <#conf-benchmark> document)
> 
> 
>             Relative Priority Checpoints in Practice:
> 
> If an authoring tool developer intends to claim conformance to ATAG 2.0 
> at Level-A, they will first identify, in the conformance claim, a 
> published content type-specific WCAG benchmark <#conf-benchmark> 
> document that is targeted at WCAG conformance Level-A (i.e., the 
> requirements in the benchmark are those required to conform to Level-A 
> of WCAG).
> 
> Then, for each Relative Priotity checkpoint in ATAG 2.0, this document 
> will be used as a benchmark for determining whether the success criteria 
> have been met. For instance, Checkpoint B.2.2 
> <#check-notify-on-schedule> ("Check for and inform the author of 
> accessibility problems") is a Relative Priority checkpoint. To conform 
> to ATAG 2.0 at Level-A, this checkpoint must be met at Relative Priority 
> - Level 1. To do this, the authoring tool must satisfy the success 
> criteria of the checkpoint with respect to /all/ of the requirements in 
> the benchmark document. An example of this can be seen in the first 
> success criteria ("An individual check /must/ be associated with each 
> requirement in the content type-specific WCAG benchmark 
> <#conf-benchmark> document...").
> 
> 
>       2.2 Conformance Claims
> 
> A conformance claim is an assertion by a claimant that an authoring tool 
> has satisfied the requirements of a chosen ATAG 2.0 conformance profile 
> <#conf-profile>.
> 
> 
>         Conditions
> 
>     * At least one version of the conformance claim must be published on
>       the Web as a document that conforms to either WCAG (version 1.0
>       *or* 2.0) Level A [WCAG10] <#ref-WCAG10> or WCAG 2.0 Level
>       Single-A [WCAG20] <#ref-WCAG20>. A suggested metatadata
>       description for this document is "ATAG 2.0 Conformance Claim".
>     * *Whenever the claimed conformance level is published (e.g., in
>       marketing materials), the URI for the on-line published version of
>       the conformance claim must be included in conjunction with that
>       claim.*
>     * The existence of a conformance claim does not imply that the W3C
>       has reviewed the claim or assured its validity. As of the
>       publication of this document, W3C does not act as an assuring
>       party, but it may do so in the future, or it may establish
>       recommendations for assuring parties.
>     * Claimants may be anyone (e.g., developers, journalists, other
>       third parties).
>     * Claimants are solely responsible for the accuracy of their claims
>       and keeping claims up to date.
>     * Claimants are encouraged to claim conformance to the most recent
>       version of the Authoring Tool Accessibility Guidelines
>       Recommendation that is available.
> 
> 
>         Components of a Conformance Claim
> 
>    1. *Required: *The date of the claim.
>    2. *Required:* Information about the authoring tool. If the authoring
>       tool is comprised of components (e.g., markup editor, image
>       editor, and validation tool), then information must be provided
>       separately for each component:
>           * Name and sufficient version information to identify the tool
>             (e.g., vendor name, version number, minor release number,
>             required patches or updates, natural language of the user
>             interface or documentation). The version information may
>             refer to a range of tools (e.g., "this claim refers to
>             version 6.x").
>    3. *Required:* A *conformance profile* that must include the following:
>           * The version and URI of the Authoring Tool Accessibility
>             Guidelines 2.0 document to which it is claimed the authoring
>             tool conforms.
>           * The conformance level <#conf-levels> that has been satisfied
>             (choose one of: "A", "Double-A", "Triple-A").
>           * The content type(s) <#def-Content-Type> produced by the
>             authoring tool that are covered by the claim. For each of
>             these content types, the URI of a content type-specific WCAG
>             benchmark <#conf-benchmark> document must be provided (e.g.,
>             "HTML 4.01,
>             http://www.sample.org/html401_wcag20_benchmark.html"). Note:
>             the authoring tool may produce other content types not
>             covered by the conformance claim.
>           * *For authoring tools with Web-based functionality:*
>                 o The version and URI of the Web Content Accessibility
>                   Guidelines document that the user interface was
>                   evaluated against ( e.g., "Web Content Accessibility
>                   Guidelines 2.0 Working Draft,
>                   http://www.w3.org/TR/WCAG20/"). It is /optional/ to
>                   provide a content type-specific WCAG benchmark
>                   <#conf-benchmark> document for each content types used
>                   in the implementation of the user interface.
>                 o The name and version information of the user agent(s)
>                   <#def-User-Agent> on which the Web-based functionality
>                   was evaluated for conformance.
>           * *For authoring tools with functionality that is not
>             Web-based: *
>                 o The name and version information of the operating
>                   system platform(s) <#def-platform> on which the
>                   authoring tool was evaluated for conformance.
>                 o The name and version of the accessibility platform
>                   architectures employed.
>    4. *Required:* A description of how the normative success criteria
>       were met for each of the checkpoints that are required for the
>       conformance level specified by the conformance profile
>       <#conf-profile>.
>           * For relative priority <#priority-Regular> checkpoints this
>             means describing how the requirements of the content
>             type-specific WCAG benchmark <#conf-benchmark> document are
>             satisfied.
>    5. *Optional: *A description of the authoring tool that identifies
>       the types of authoring tool functions that are present in the
>       tool. Choose one or more of: (a) Code-level authoring functions
>       <#code-level>, (b) WYSIWYG authoring functions <#wysiwyg>, (c)
>       object oriented authoring functions <#object-oriented>, and (d)
>       indirect authoring functions <#indirect>.
>    6. *Optional:* Any additional information about the tool, including
>       progress towards the next conformance level.
> 
> 
>         Content Type-Specific WCAG Benchmark
> 
> The purpose of the Content Type-Specific WCAG Benchmark document (the 
> "Benchmark" from here on) is to ensure that the authoring tool is 
> consistent with respect to production of accessible content. For 
> example, if the checking function detects a problem, the repair function 
> must be able to help the author fix it. *In practical terms, the 
> Benchmark document is just the WCAG Techniques document when one exists 
> for a content type <#def-Content-Type>. However, when a WCAG Techniques 
> document does not already exist for a content type, the claimant may 
> publish their own Benchmark document. *The Benchmark has the following 
> characteristics:
> 
>     * All of the requirements in the Benchmark become normative
>       <#def-Normative> for a particular Conformance Claim
>       <#Conformance-Claim> by the act of including a reference to the
>       URI of the Benchmark in the Conformance Profile <#conf-profile>.
>     * The Benchmark can be created by any person or organization
>       (although the Working Group does suggest checking to see if a
>       Benchmark has already been published by the W3C or other provider
>       for a content type, before creating a new one).
>     * The Benchmark must be published on the Web (the URI will appear in
>       the conformance profile) where it will be open to public and
>       market scrutiny.
> 
> Each Benchmark document must include the following:
> 
>    1. The name and version of the content type(s) covered by the
>       document (e.g., plain "HTML 4.01" or "HTML 4.01 and CSS 1.0" or
>       "SVG 1.0 and PNG images") and /optionally/ the URI of the
>       specification(s). The version may be a defined range, but may not
>       be open-ended range.
>    2. The version and URI of the Web Content Accessibility Guidelines
>       and/or Techniques document(s) used as a basis for the Benchmark
>       (e.g., "Web Content Accessibility Guidelines 2.0 Working Draft,
>       http://www.w3.org/TR/WCAG20/").
>    3. A target WCAG conformance level (e.g., single-"A", double-"A", or
>       triple-"A") that the creator of the Benchmark is claiming that Web
>       content would conform with, if all of the Benchmark requirements
>       are met. If the tool allows the author to choose between different
>       WCAG levels, then each level needs its own Benchmark document.
>    4. For each success criteria in WCAG that is required by the target
>       WCAG conformance level (this is set in point 3 of the Conformance
>       Claim), the Benchmark must provide either at least one requirement
>       for meeting the success criteria or an explanation of why that
>       success criteria is not applicable to the content type in question.
> 
> The Working Group suggests the following resources are relevant when 
> creating a Benchmark document:
> 
>     * *For WCAG 1.0:* WCAG 1.0 guidelines [WCAG10] <#ref-WCAG10> ,
>       "Techniques for WCAG 1.0" [WCAG10-TECHS] <#ref-WCAG10-TECHS>, and
>       the W3C access note series (published for CSS 2.0 [CSS2-ACCESS]
>       <#ref-CSS2-ACCESS>, SVG [SVG-ACCESS] <#ref-SVG-ACCESS>, and SMIL
>       [SMIL-ACCESS] <#ref-SMIL-ACCESS>).
>     * *For WCAG 2.0:* WCAG 2.0 guidelines [WCAG20] <#ref-WCAG20>,
>       "General Techniques for WCAG 2.0" [WCAG20-TECHS-GENERAL]
>       <#ref-WCAG20-TECHS-GENERAL> , technology-specific techniques for
>       WCAG 2.0 (WCAG-GL is developing technology-specific WCAG 2.0
>       techniques for HTML [WCAG20-TECHS-HTML] <#ref-WCAG20-TECHS-HTML>,
>       CSS [WCAG20-TECHS-HTML] <#ref-WCAG20-TECHS-CSS>, and client-side
>       scripting [WCAG20-TECHS-HTML] <#ref-WCAG20-TECHS-SCRIPTING>), and
>       the W3C access note series (published for CSS 2.0 [CSS2-ACCESS]
>       <#ref-CSS2-ACCESS>, SVG [SVG-ACCESS] <#ref-SVG-ACCESS>, and SMIL
>       [SMIL-ACCESS] <#ref-SMIL-ACCESS>), and Understanding WCAG 2.0
>       [WCAG20-UNDERSTANDING] <#ref-WCAG20-UNDERSTANDING>.
> 
> 
>       2.3 "Progress Towards Conformance" Statement
> 
> Developers of authoring tools that do not yet conform fully to a 
> particular ATAG 2.0 conformance level are encouraged to publish a 
> statement on progress towards conformance. This statement would be the 
> same as a conformance claim <#conf-claim> except that this statement 
> would specify an ATAG 2.0 conformance level that is being progressed 
> towards, rather than one already satisfied, and report the progress on 
> success criteria not yet met. The author of a "Progress Towards 
> Conformance" Statement is solely responsible for the accuracy of their 
> statement. Developers are encouraged to provide expected timelines for 
> meeting outstanding success criteria within the Statement.
> 
> ------------------------------------------------------------------------
> 
> 
>     3. The Authoring Tool Accessibility Guidelines
> 
> This section is normative <#def-Normative>.
> 
> 
>         How the guidelines are organized
> 
> The guidelines are divided into two parts, each reflecting a key aspect 
> of accessible authoring tools. Part A <#part-tool-accessible> includes 
> guidelines and associated checkpoints related to ensuring accessibility 
> of the authoring tool user interface <#def-Authoring-Tool-Interface>. 
> Part B <#part-support-production> contains guidelines and checkpoints 
> related to ensuring support for creation of accessible Web content 
> <#def-Accessible-Web-Content> by the tool. The guidelines in both parts 
> include the following:
> 
>     * The guideline number.
>     * The guideline title.
>     * An explanation of the guideline.
>     * A list of checkpoints for the guideline.
> 
> Each checkpoint listed under a guideline is intended to be specific 
> enough to be verifiable, while still allowing developers the freedom to 
> meet the checkpoint in a way that is suitable for their own authoring 
> tools. Each checkpoint definition includes the following parts. Some 
> parts are normative <#def-Normative> (i.e., relate to conformance), 
> while others are informative <#def-Informative> only:
> 
>     * The checkpoint number. (informative <#def-Informative>)
>     * The checkpoint title. (informative <#def-Informative>)
>     * The priority <#conf-checkpoint-priorities> of the checkpoint.
>       (normative <#def-Normative>)
>     * A rationale for the checkpoint. (informative <#def-Informative>)
>     * Note(s) related to the checkpoint. (informative <#def-Informative>)
>     * A pointer to implementation techniques for the checkpoint.
>       (informative <#def-Informative>)
>     * Success criteria for testing whether the checkpoint has been
>       satisfied. (normative <#def-Normative>)
> 
> 
>     PART A: Make the authoring tool user interface accessible
> 
> The checkpoints in Part A are intended to increase the accessibility of 
> the authoring experience for authors with disabilities. For this reason, 
> the requirements are narrowly focused on the accessibility of the user 
> interface that the author uses to operate the tool. The accessibility of 
> the Web content produced is addressed in Part B <#part-support-production>.
> 
> *Note for tools with previews: *The requirement in this section apply to 
> all parts of the authoring tool user interface /except/ for the content 
> view of any built-in preview features (see Checkpoint A.2.9 
> <#check-tool-previews> for requirements on previews). In general, the 
> configuration of the preview mode is not defined by the configuration of 
> the editing views.
> 
> A.0.1 For the authoring tool user interface, ensure that Web-based 
> functionality <#def-Web-Based-UI> conforms to WCAG 
> <#Relationship-To-WCAG>. [Relative Priority]
> 
>     *Rationale:* Authors must be able to have access to Web-based
>     authoring tool user interface functionality just as they do to other
>     Web content.
> 
>     *Note:* For non-Web-based authoring tools, this is a relatively
>     straightforward requirement, likely covering only a few areas of the
>     interface (e.g., Web-based help features). However, for most
>     Web-based authoring tools the requirement will cover the majority of
>     functionality in the tool and overlap many of the other requirements
>     in Part A of the guidelines. When this is the case, a note entitled
>     "For Web-based authoring tool user interface functionality" will
>     appear below the success criteria to provide more information.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.0.1
> 
>     *Success Criteria:*
> 
>        1. All Web-based authoring tool user interface functionality
>           <#def-Web-Based-UI>/ must/ conform to WCAG <#priority-Relative>.
> 
> 
>       GUIDELINE A.1: Authoring Tool User Interface must be Perceivable
> 
> A.1.1 For the authoring tool user interface, provide text alternatives 
> <#def-Text-Alternatives> for all non-text objects 
> <#def-Non-text-objects>. [Priority 1]
> 
>     *Rationale:* People who have difficulty perceiving non-text content
>     are often able to access text alternatives of the same information,
>     since text is more easily transformed between various display
>     methods (e.g., magnification and enhancement, text-to-speech,
>     Braille output)
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.1.1
> 
>     *Success Criteria:*
> 
>        1. All editing interface <#def-ui-editing-interface> non-text
>           objects <#def-Non-text-objects> that are used to convey
>           information (e.g., toolbar icon, graphical depiction of a tag,
>           sound effect) /must/ have a text alternative
>           <#def-Text-Alternatives> (e.g., alternative text label, long
>           text description).
>        2. The author <#def-Author> /must/ have the option to access an
>           accessible multimedia alternative
>           <#def-accessible-multimedia-alternatives> to any multimedia
>           <#def-Multimedia> in the editing interface
>           <#def-ui-editing-interface>.
>        3. All editing views <#def-Editing-View> /must/ always include an
>           option to display any available text alternatives
>           <#def-Text-Alternatives> for non-text objects
>           <#def-Non-text-objects> in the content being edited.
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to success criteria 1 of this
>     checkpoint.
> 
> A.1.2 For the authoring tool user interface, provide synchronized 
> alternatives <#def-Synchronized-Alternatives> for multimedia. [Priority 2]
> 
>     *Rationale:* People who have difficulty accessing or interpreting
>     multimedia-supported information in the authoring tool user
>     interface can have the information made available to them by other
>     means. For example, people who are deaf or have a hearing loss can
>     access auditory information through captions, and people who are
>     blind or have low vision, as well as those with cognitive
>     disabilities, who have difficulty interpreting visually what is
>     happening, can receive audio descriptions of visual information.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.1.2
> 
>     *Success Criteria:*
> 
>        1. All editing interface <#def-ui-editing-interface> multimedia
>           <#def-Multimedia> that is used to convey information (e.g.,
>           tutorial videos) /must/ have synchronized alternatives
>           <#def-Synchronized-Alternatives> (e.g., captions
>           <#def-Captions>, audio descriptions <#def-Auditory-Description>).
>        2. All editing views <#def-Editing-View> /must/ always include an
>           option to display any available synchronized alternatives
>           <#def-Synchronized-Alternatives> for multimedia
>           <#def-Multimedia> in the content being edited.
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.1.3 For the authoring tool user interface, ensure that all display 
> preferences are configurable. [Priority 1]
> 
>     *Rationale:* Some authors require alternative display configurations
>     to use the authoring tool user interface interface.
> 
>     *Note:* The success criteria for this checkpoint are based on the
>     capabilities of platforms <#def-platform> (e.g., operating systems,
>     user agents, GUI toolkits) as defined in the conformance profile
>     <#conf-profile>, however developers are free to provide additional
>     configuration.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.1.3
> 
>     *Success Criteria:*
> 
>        1. If the visual display (e.g. fonts, sizes, colors, spacing,
>           positioning) is controlled by the authoring tool rather than
>           by the platform <#def-platform>, then the authoring tool
>           /must/ provide at least the same configurable properties with
>           at least the same configuration ranges as the platform.
>        2. If the audio display (e.g. volume, speech voices) is
>           controlled by the authoring tool rather than by the platform
>           <#def-platform>, then the authoring tool /must/ provide at
>           least the same configurable properties with at least the same
>           configuration ranges as the platform.
>        3. Editing views <#def-Editing-View> that have their display
>           characteristics set by rendering the content being edited
>           (e.g., WYSWYG <#wysiwyg> editing views <#def-Editing-View>)
>           /must/ override these characteristics if the author
>           <#def-Author> explicitly sets visual or audio display
>           preferences as described in the previous two success criteria.
>        4. Any visual or audio display settings /must/ be saved between
>           authoring sessions.
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.1.4 For the authoring tool user interface, ensure changes to the 
> display settings of editing views <#def-Editing-View> do not affect the 
> content being edited. [Priority 1].
> 
>     *Rationale:* Authors may require settings to render and control the
>     content during editing that differ from the presentation defined for
>     the published content (e.g., providing a high contrast setting to
>     edit content that is not intended to be high contrast).
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.1.4
> 
>     *Success Criteria:*
> 
>        1. The author <#def-Author> /must/ be able to configure the
>           display settings of editing views <#def-Editing-View> without
>           affecting the content being edited.
> 
> A.1.5 For the authoring tool user interface, ensure that information, 
> functionality, and structure can be separated from presentation. 
> [Priority 1]
> 
>     *Rationale:* Separating content and structure from presentation
>     allows the user interfaces of authoring tools to be presented
>     differently to meet the needs and constraints of different authors
>     without losing any of the information or structure. For example,
>     information can be presented via speech or braille (text) that was
>     primarily intended to be presented visually. It can also facilitate
>     automatic emphasis of structure or more efficient navigation. All of
>     these can benefit authors with cognitive, physical, hearing, and
>     visual disabilities.
> 
>     *Success Criteria:*
> 
>        1. For rendered editing views <#def-Editing-View> (e.g., WYSIWYG
>           <#wysiwyg> editing view <#def-Editing-View>), all
>           characteristics of the presentation <#def-presentation> (e.g.,
>           color, boldness, positioning) /must/ be available
>           programmatically <#def-available-programmatically>.
>        2. For authoring tool-controlled presentation <#def-presentation>
>           in editing views <#def-Editing-View> (e.g., coloring
>           misspelled words, identifying tag text in a code-level
>           <#code-level> view), the semantic description of the
>           presentation /must/ be available programmatically
>           <#def-available-programmatically>.
>        3. For the presentation of controls within the editing interface
>           <#def-ui-editing-interface> (e.g., dialog boxes, menus, button
>           bars, user interface controls in the editing view), the
>           semantic description of the presentation (e.g., "paragraph
>           tag" instead of "blue-colored <p>") /must/ be available
>           programmatically <#def-available-programmatically>.
>        4. Any information that is conveyed by color (e.g., different
>           colored underlines to indicate spelling and grammar errors)
>           /must/ meet *at least one* of the following:
>               * visually evident when color is not available (e.g., by
>                 the shape of the underlining), or
>               * provided by an alternative version that meets Part A
>                 <#part-tool-accessible> (e.g., spelling and grammar
>                 checking utilities that provide the same functionality
>                 as the colored underline).
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> 
>       GUIDELINE A.2: Authoring Tool User Interface must be Operable
> 
> A.2.1 For the authoring tool user interface, ensure that all 
> functionality is operable via a keyboard or a keyboard interface 
> <#def-Keyboard-Interface>. [Priority 1]
> 
>     *Rationale:* Some individuals have difficulty manipulating graphical
>     input devices such as a mouse or trackball. Providing alternate
>     means of navigating the user interface that does not rely on such
>     devices provides an accommodation for individuals with limited
>     mobility or those with visual disabilities who cannot rely on hand
>     eye coordination for navigating the user interface.
> 
>     *Note 1:* This does not preclude and should not discourage the
>     support of other input methods (such as a mouse) in addition to
>     keyboard operation.
> 
>     *Note 2:* Also see Checkpoint A.3.1 <#check-tool-conventions> when
>     choosing keystrokes.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.1
> 
>     *Success Criteria:*
> 
>        1. The author <#def-Author> /must/ be able, through keyboard
>           input alone, to perform any authoring task that is available
>           through the authoring tool user interface
>           <#def-Authoring-Tool-Interface> (e.g., navigating, selecting,
>           and editing content within editing views <#def-Editing-View>,
>           operating the editing interface <#def-ui-editing-interface>,
>           installing and configuring the tool, and accessing
>           documentation <#def-Documentation>), except freeform drawing
>           <#def-Freeform-Drawing>. This applies to at least one
>           mechanism per task, allowing non-keyboard accessible
>           mechanisms to remain available (e.g., inserting an image with
>           an "insert image" menu item vs. drag-and-dropping the image
>           file's icon into the document).
>        2. The author <#def-Author> /must/ have the option to ensure that
>           selection is separate from activation (e.g., navigating
>           through the items in a dropdown menu without activating any of
>           the items).
>        3. The author <#def-Author> /must/ have the option to enable
>           single-key access to *both* of the following functionalities:
>               * (a) move content focus to the next enabled control in
>                 the editing interface <#def-ui-editing-interface> (e.g.,
>                 using "tab" key), and
>               * (b) navigate forward and backward within editing views
>                 (e.g., using "arrow" keys).
>        4. The author <#def-Author> /must/ have the option to enable
>           key-plus-modifier-key (or single-key) access to *all* of the
>           following functionalities (if present):
>               * (a) move content focus to the previous enabled control
>                 (e.g., using "shift-tab" key),
>               * (b) navigate between panels or windows,
>               * (c) open help system,
>               * (d) open new content,
>               * (e) open existing content,
>               * (f) save content,
>               * (g) close content,
>               * (h) cut/copy/paste,
>               * (i) undo/redo,
>               * (j) open find/replace function, and
>               * (k) navigate to the start and end of the content.
>        5. Any keyboard operability settings /must/ be saved between
>           authoring sessions.
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet success criteria 1 and 2
>     of this checkpoint. User agent <#def-User-Agent> functionality
>     (e.g., for "cut/copy/paste") or access keys (e.g., for "open new
>     content") may be relied on to achieve success criteria 3 and 4 as
>     long as the applicable user agent(s) are specified in the
>     conformance profile <#conf-profile>.
> 
> A.2.2 For the authoring tool user interface, ensure user configurable 
> access to selectable items. [Priority 3]
> 
>     *Rationale:* Authors who have limited mobility require quick access
>     to the items that they use frequently.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.2
> 
>     *Success Criteria:*
> 
>        1. The author <#def-Author> /must/ have the option to set (and
>           later modify) key-plus-modifier-key (or single-key) access for
>           each selectable item <#def-selectable_items>. The current
>           settings /must/ be displayed in either a centralized fashion
>           (e.g., a list of keyboard shortcuts) or a distributed fashion
>           (e.g., by listing keyboard shortcuts in the menus).
>        2. There /must/ be at least one editing interface
>           <#def-ui-editing-interface> area in which selectable items
>           <#def-selectable_items> can be activated by a single action
>           (e.g., toolbar, palette), where *both* of the following are true:
>               * (a) the author <#def-Author> can change the order of the
>                 items, and
>               * (b) the author <#def-Author> can select which items are
>                 available from the set of all selectable items
>                 <#def-selectable_items>.
> 
> A.2.3 For the authoring tool user interface, allow authors to control 
> time limits. [Priority 1]
> 
>     *Rationale:* Authors who have difficulty typing, operating the
>     mouse, or processing information can be prevented from using systems
>     with short time limits.
> 
>     *Note:* Some time limits may be imposed by external systems. This
>     checkpoint only applies to time limits within the control of the
>     authoring tool.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.3
> 
>     *Success Criteria:*
> 
>        1. If a time limit is not controlled by time-sensitive external
>           constraints (e.g., actions of another author in a
>           collaborative authoring system, external connection
>           time-outs), then the time limit /must/ meet *at least one* of
>           the following:
>               * the author <#def-Author> is able to deactivate the time
>                 limit,
>               * the author <#def-Author> is able to adjust the time
>                 limit over a wide range that is at least ten times the
>                 length of the default setting, or
>               * the author <#def-Author> is warned before time expires
>                 and given at least 20 seconds to extend the time limit
>                 with a simple action (e.g., "hit any key"), and the
>                 author is allowed to extend the time limit at least ten
>                 times.
> 
>     *For Web-based authoring tool user interface functionality
>     <#def-Web-Based-UI>:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.2.4 For the authoring tool user interface, allow authors to avoid 
> content that could cause seizures due to photosensitivity. [Priority 1]
> 
>     *Rationale:* Flashing can cause seizures in people with
>     photosensitive epilepsy.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.4
> 
>     *Success Criteria:*
> 
>        1. If flashing occurs in any part of the user interface (e.g.,
>           within a WYSIWYG <#wysiwyg> editing view <#def-Editing-View>)
>           that violates international health and safety standards for
>           general flash or red flash <#def-Flash>, then the author
>           <#def-Author> /must/ be able to do *at least one* of the
>           following:
>              1. the author <#def-Author> is able to deactivate the
>                 flashing, or
>              2. the author <#def-Author> is able to adjust the rate of
>                 flashing so that it no longer violates international
>                 health and safety standards for general flash or red
>                 flash <#def-Flash>.
> 
>     *For Web-Based Interface Components:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.2.5 For the authoring tool user interface, ensure that editing views 
> <#def-Editing-View> enable the author <#def-Author> to navigate the 
> structure and perform structure-based edits. [Priority 2]
> 
>     *Rationale:* It is often efficient to make use of the structure that
>     may be inherent within Web content in order to navigate editing
>     views and perform edits. This is particularly important for people
>     who are using a slow interface such as a small Braille device,
>     speech output, or a single switch input device. It is equivalent to
>     the ability provided by a mouse interface to move rapidly around the
>     document.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.5
> 
>     *Success Criteria:*
> 
>        1. If editing content that is a structured element set
>           <#def-structured-element-set>, the author <#def-Author> /must/
>           always be able to move the editing focus from any element
>           <#def-Element> to other elements in the set with *any* of the
>           following relationships (if they exist):
>               * (a) the element <#def-Element> immediately above (i.e.,
>                 parent),
>               * (b) the first element <#def-Element> immediately below
>                 (i.e., child),
>               * (c) the element <#def-Element> immediately preceding at
>                 the same level (i.e., previous sibling), and
>               * (d) the element <#def-Element> immediately following at
>                 the same level (i.e., next sibling).
>        2. If editing content that is a structured element set
>           <#def-structured-element-set>, the author <#def-Author> /must/
>           be able to select any element <#def-Element> in the set and
>           perform editing functions (e.g., cut, copy, paste,
>           presentation <#def-presentation>) on that element, its
>           content, and its sub-elements.
> 
> A.2.6 For the authoring tool user interface, allow the author to search 
> content and markup within the editing views <#def-Editing-View>. 
> [Priority 2]
> 
>     *Rationale:* Search functions within the editing views facilitate
>     author navigation of content as it is being authored by allowing the
>     author to move the focus quickly to arbitrary points in the content.
>     Including the capability to search within text equivalents of
>     rendered non-text content increases the efficiency of the search
>     function.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.6
> 
>     *Success Criteria:*
> 
>        1. The author <#def-Author> /must/ be able to perform text
>           searches of all text that is editable by the author, including
>           text alternatives <#def-Text-Alternatives> for non-text
>           objects <#def-Non-text-objects> and metadata.
>        2. The author <#def-Author> /must/ be able to perform text
>           searches of all markup <def-Markup> that is editable by the
>           author.
> 
>     *For Web-Based Interface Components:* Web-based authoring tools
>     mayrely on the "find" function of the user agent <#def-User-Agent>
>     to help perform the searches, as long as the applicable user
>     agent(s) are specified in the conformance profile <#conf-profile>
> 
> A.2.7 For the authoring tool user interface, provide an undo function. 
> [Priority 2]
> 
>     *Rationale:* Authors who have difficulty making fine movements may
>     be prone to making unintended actions. All authors benefit from the
>     ability to easily recover from mistakes.
> 
>     *Note:* It is acceptable to collect text entry actions (e.g., typed
>     words, a series of backspaces) into a single author action.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.7
> 
>     *Success Criteria:*
> 
>        1. Author <#def-Author> actions that modify content /must/ be
>           either reversible by an "undo" function or include a warning
>           to the author that the action is irreversible. An authoring
>           tool may have certain committing actions (e.g., "save"
>           function) that reset the undo history.
>        2. The author <#def-Author> /must /be able to perform consecutive
>           undos up to at least five reversible actions or until an
>           irreversible action or committing action is reached.
>        3. The author <#def-Author> /must/ be able to immediately reverse
>           the most recent undos (i.e., a "redo" function).
> 
>     *For Web-Based Interface Components:* Web-based authoring tools may
>     rely on the "undo" function of the user agent <#def-User-Agent> to
>     perform the undo function for some editing actions that do not
>     involve server communication (e.g., typing in a text area), as long
>     as the applicable user agent(s) are specified in the conformance
>     profile <#conf-profile>
> 
> A.2.8 For the authoring tool user interface, allow the author to have 
> multiple sets of keyboard operability and display preferences settings. 
> [Priority 2]
> 
>     *Rationale:* Providing the ability to save and reload sets of
>     keyboard and display preference settings is a benefit to authors
>     using tools intended to be used by multiple authors as well as
>     authors who have keyboard and display preference settings
>     preferences that differ with fatigue, etc..
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.8
> 
>     *Success Criteria:*
> 
>        1. The author <#def-Author> /must/ be able to save and reload
>           sets of preferences (e.g., personal profiles, personal
>           settings), where each set contains preference settings related
>           to the following (if present):
>               * (a) keyboard operability (unless keyboard operability
>                 preferences are controlled by the platform <#def-platform>),
>               * (b) visual display (unless the visual display (e.g.,
>                 fonts, sizes, colors, spacing, positioning) is
>                 controlled by the platform <#def-platform>), and
>               * (c) audio display (unless the audio display (e.g.,
>                 volume, speech voices) is controlled by the platform
>                 <#def-platform>).
> 
> A.2.9 For the authoring tool user interface, ensure previews emulate the 
> accessible rendering features of target browsers. [Priority 2]
> 
>     *Rationale: *Preview <#def-preview> features are provided in many
>     authoring tools because the workflow <#def-Workflow> of authors
>     often includes periodically checking how content will appear to end
>     users <#def-End-Users> in a user agent. In order to enable authors
>     with disabilities to follow the same workflow as other authors, they
>     must have access to any preview features that exist.
> 
>     *Note 1: * Authors, including those with disabilities, will not be
>     well-served if preview <#def-preview> features diverge too much from
>     the actual functionality of available user agents. Therefore,
>     preview features are exempted from necessarily having to meet all of
>     the other requirements in Part A of this guidelines document, if
>     they meet this checkpoint.
> 
>     *Note 2: *It is understood that the accessibility of the content
>     display of a preview <#def-preview> will be negatively affected if
>     the content being rendered is inaccessible or incomplete. For
>     example, a missing image label will result in an inaccessible image,
>     which is useful information to the author.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.2.9
> 
>     *Success Criteria:*
> 
>        1. If a preview <#def-preview> feature is provided, then a
>           mechanism of returning from the preview (i.e., moving focus
>           back from, exiting from) /must/ be provided that meets
>           Checkpoint A.2.1 <#check-tool-keyboard-access> and is
>           documented in the help system.
>        2. If a preview <#def-preview> is provided, then it /must/ meet
>           *at least one* of the following:
>               * (a) the preview <#def-preview> makes use of an existing
>                 user agent <#def-User-Agent> (e.g., a third-party
>                 browser or browser component), or
>               * (b) the preview <#def-preview> meets all of the
>                 checkpoints in Part A <#part-tool-accessible>.
> 
> 
>       GUIDELINE A.3: Authoring Tool User Interface must be Understandable
> 
> A.3.1 For the authoring tool user interface, observe the accessibility 
> conventions of the platform <#def-platform>. [Priority 2]
> 
>     *Rationale:* Authors are often familiar with accessibility
>     conventions employed by the other applications built on a platform.
>     Departures from those conventions have the tendency to disorient
>     authors by creating an unfamiliar environment.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.3.1
> 
>     *Success Criteria:*
> 
>        1. Focus and selection conventions for the current platform
>           <#def-platform> (specified in the conformance profile
>           <#conf-profile>) /must/ be followed.
>        2. Keyboard accessibility configuration conventions (e.g.,
>           default accelerator key bindings) for the platform
>           <#def-platform> (specified in the conformance profile
>           <#conf-profile>) ///must/ be followed.
> 
>     *For Web-Based Interface Components:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.3.2 For the authoring tool user interface, maintain consistency. 
> [Priority 2]
> 
>     *Rationale:* Authors who may become disoriented easily will have
>     less difficulty when consistent and predictable responses to author
>     actions are provided. In general, consistent interfaces will benefit
>     all authors to some degree.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.3.2
> 
>     *Success Criteria:*
> 
>        1. Editing interface <#def-ui-editing-interface> controls that
>           are identified by the same text label or icon /must/ always
>           perform the same function.
>        2. When the same function (e.g., saving, running a checker or
>           canceling an action) is available in multiple places (e.g., on
>           multiple windows), at least one method of controlling the
>           function /must/ be available in each place using the same text
>           label or icon.
> 
>     *For Web-Based Interface Components:* Meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.3.3 For the authoring tool user interface, document the user interface 
> including all accessibility features. [Priority 1]
> 
>     *Rationale:* While intuitive user interface design is valuable to
>     many authors, some authors may still not be able to understand or be
>     able to operate the authoring tool user interface without proper
>     documentation.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.3.3
> 
>     *Success Criteria:*
> 
>        1. At least one version of the documentation <#def-Documentation>
>           /must/ conform to the minimum requirements (e.g., "Level A")
>           of WCAG <#Relationship-To-WCAG>.
>        2. All features from Part A <#part-tool-accessible> that benefit
>           the accessibility of the editing interface
>           <#def-ui-editing-interface> /must/ be documented (e.g.,
>           keyboard shortcuts).
> 
> 
>       GUIDELINE A.4: Authoring Tool User Interface must be Access System
>       Friendly
> 
> A.4.1 Support interoperability with assistive technologies. [Priority 1]
> 
>     *Rationale:* Assistive technologies that are used by many authors
>     with disabilities (e.g., screen readers, screen magnifiers) rely on
>     the authoring tool to provide data and control via prescribed
>     communication protocols.
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.4.1
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ implement the accessibility platform
>           architecture(s) relevant to the development platform (e.g.,
>           MSAA for Windows applications, Java Access for Java applications).
>        2. *All* of the following information /must/ be published about
>           the implementation of the accessibility platform architecture(s):
>               * (a) Specify if only the default support is provided.
>               * (b) Otherwise, provide information (e.g., accessible
>                 name, accessible description, accessible role) for each
>                 GUI component that can receive focus, as defined by the
>                 accessibility architecture used.
>               * (c) Detail any deviation from their proper use (i.e.,
>                 lack of use, incomplete use, inappropriate use) as
>                 defined by the documentation for the accessibility
>                 platform architecture.
>        3. If there is any authoring tool user interface functionality
>           that is not supported by the relevant accessibility platform
>           architecture(s), then *at least one* of the following must be
>           done :
>               * a) provide an accessible equivalent for the
>                 functionality that is supported by the relevant
>                 accessibility platform architecture(s).
>               * b) provide an alternative interoperability mechanism
>                 with published documentation so that the functionality
>                 would be available to an assistive technology
>                 implementing the mechanism.
>               * (c) describe the inaccessible functionality in the
>                 compliance claim.
> 
>     *For Web-Based Interface Components:* Web-based authoring tools will
>     rely on the accessiblity platform architecture support of the user
>     agent <#def-User-Agent> and therefore meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> A.4.2 Document how the authoring interface makes use of existing 
> accessibility architectures. [Priority 3]
> 
>     *Rationale:* When the use of accessibility architectures is fully
>     documented, assistive technology developers are able to provide
>     enhanced user interface access .
> 
>     *Techniques:* Implementation Techniques for Checkpoint A.3.2
> 
>     *Success Criteria:*
> 
>        1. Additional information /must/ be published describing the
>           nature and use of the information provided in Checkpoint A.4.1
>           <#check-document-interoperability> (e.g., that the long
>           description is different from the associated tool tip).
> 
>     *For Web-Based Interface Components:* Web-based authoring tools will
>     rely on the accessiblity platform architecture support of the user
>     agent <#def-User-Agent> and therefore meeting Checkpoint A.0.1
>     <#check-tool-meet-WCAG> will serve to meet this checkpoint.
> 
> 
>     PART B: Support the production of accessible content
> 
> The checkpoints in Part B are intended to increase the accessibility of 
> the Web content produced by /any/ author <#def-Author> to end users 
> <#def-End-Users> with disabilities. While the requirements in this part 
> do not deal with the accessibility of the authoring tool user interface, 
> it should be noted that any of the features (e.g checker, tutorial) 
> added to meet Part B must also meet the user interface accessibility 
> requirements of Part A <#part-tool-accessible>.
> 
> 
>       GUIDELINE B.1: Enable the production of accessible content
> 
> The creation of accessible content is dependent on the actions of the 
> tool and the author. This guideline delineates the responsibilities that 
> rest exclusively with the tool.
> 
> B.1.1 Support content types <#def-Content-Type> that enable the creation 
> of Web content <#def-Web-Content> that conforms to WCAG 
> <#Relationship-To-WCAG>. [Priority 1]
> 
>     *Rationale:* Content types with published content type-specific WCAG
>     benchmark documents facilitate the creation of Web content that can
>     be assessed for accessibility with WCAG.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.1.1
> 
>     *Success Criteria:*
> 
>        1. Any authoring tool that chooses the content type
>           <#def-Content-Type> used for publication on the Web for the
>           author <#def-Author> /must/ always choose content types for
>           which a published content type-specific WCAG benchmark
>           <#conf-benchmark> document exists.
>        2. Any authoring tool that allows authors <#def-Author> to choose
>           the content type <#def-Content-Type> used for publication on
>           the Web /must/ always support at least one content type
>           <#def-Content-Type> for which a published content
>           type-specific WCAG benchmark <#conf-benchmark> document exists
>           and /must/ always give prominence <#def-Prominence> to those
>           content types.
> 
> B.1.2 Ensure that the tool preserves accessibility information 
> <#def-Accessibility-Information> during transformations 
> <#def-Transformation> and conversions <#def-Conversion-Tool>. [Priority 1]
> 
>     *Rationale: *Accessibility information is critical to maintaining
>     comparable levels of accessibility across transformations and
>     conversions.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.1.2
> 
>     *Success Criteria:*
> 
>        1. During all transformations <#def-Transformation> and
>           conversions <#def-Conversion-Tool> supported by the authoring
>           tool, accessibility information
>           <#def-Accessibility-Information> /must/ always be handled
>           according to the following:
>               * (a) the accessibility information
>                 <#def-Accessibility-Information> is available to end
>                 users <#def-End-Users> in the result of the
>                 transformation <#def-Transformation> or conversion
>                 <#def-Conversion-Tool>, or
>               * (b) if the accessibility information
>                 <#def-Accessibility-Information> cannot be preserved,
>                 notify the author <#def-Author> and keep a copy in the
>                 original form (e.g., by commenting out a table converted
>                 into a list, by saving a document <#def-document> prior
>                 to converting it into a different format).
> 
> B.1.3 Ensure that the author is notified before content is automatically 
> removed. [Priority 2]
> 
>     *Rationale:* Automatically removing markup can cause the
>     unintentional loss of structural information. Even unrecognized
>     markup may have accessibility value, since it may include recent
>     technologies that have been added to enhance accessibility.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.1.3
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ provide an option to notify the
>           author <#def-Author> before permanently removing content using
>           an automatic process.
> 
> B.1.4 Ensure that when the tool automatically generates content it 
> conforms to WCAG <#Relationship-To-WCAG>. [Relative Priority]
> 
>     *Rationale:* Authoring tools that automatically generate content
>     that does not conform to WCAG are a source of accessibility problems.
> 
>     *Note:* If accessibility information
>     <#def-Accessibility-Information> is required from the author during
>     the automatic generation process, Checkpoint B.2.1
>     <#check-prompt-assist-user> applies.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.1.4
> 
>     *Success Criteria:*
> 
>        1. All Web content <#def-Web-Content> that is automatically
>           generated by the authoring tool (i.e., not authored "by hand"
>           <#def-Authored-By-Hand>) /must/ conform to WCAG
>           <#priority-Relative>.
> 
> B.1.5 Ensure that all pre-authored content for the tool conforms to WCAG 
> <#Relationship-To-WCAG>. [Relative Priority]
> 
>     *Rationale:* Pre-authored content, such as templates, images, and
>     videos, is often included with authoring tools for use by the
>     author. When this content conforms to WCAG, it is more convenient
>     for authors and more easily reused.
> 
>     *Note:* If accessibility information
>     <#def-Accessibility-Information> is required from the author during
>     use, Checkpoint B.2.1 <#check-prompt-assist-user> applies.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.1.5
> 
>     *Success Criteria:*
> 
>        1. Any Web content <#def-Web-Content> (e.g., templates, clip art,
>           example pages, graphical widgets) that is bundled with the
>           authoring tool or preferentially licensed to the users of the
>           authoring tool (i.e., provided for free or sold at a discount)
>           /must/ conform to WCAG <#priority-Relative> when used by the
>           author <#def-Author>.
> 
> 
>       GUIDELINE B.2: Support the author in the production of accessible
>       content
> 
> Actions may be taken at the author's initiative that may result in 
> accessibility problems <#def-Web-Content-Accessibility-Problem>. The 
> authoring tool should include features that provide support and guidance 
> to the author in these situations, so that accessible authoring 
> practices <#def-acc-auth-practice> can be followed and accessible web 
> content <#def-Accessible-Web-Content> can be produced.
> 
> B.2.1 Prompt <#def-Prompt> and assist the author <#def-Author> to create 
> content that conforms to WCAG <#Relationship-To-WCAG>. [Relative Priority]
> 
>     *Rationale:* The authoring tool should help to prevent the author
>     from making decisions or omissions that cause accessibility
>     problems. If Web content accessibility problems are prevented, less
>     effort is required to create content that conforms to WCAG.
>     Different tool developers will accomplish this goal in ways that are
>     appropriate to their products, processes, and authors.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.1
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ provide an option to notify the
>           author <#def-Author> when content is added or updated, that
>           requires accessibility information
>           <#def-Accessibility-Information> from the author to conform to
>           WCAG <#priority-Relative> (e.g., using a dialog box, using
>           interactive feedback).
>        2. Instructions provided to the author <#def-Author> by the
>           authoring tool /must/ (if followed) meet *one* of the following:
>               * (a) lead to the creation of Web content
>                 <#def-Web-Content> that conforms to WCAG
>                 <#priority-Relative>, or
>               * (b) inform the author that following the instructions
>                 would lead to Web content accessibility problems
>                 <#def-Web-Content-Accessibility-Problem>.
> 
> B.2.2 Check <#def-Checking> for and inform the author <#def-Author> of 
> accessibility problems <#def-Web-Content-Accessibility-Problem>. 
> [Relative Priority]
> 
>     *Rationale:* Authors may not notice or be able to check for
>     accessibility problems without assistance from the authoring tool.
> 
>     *Note:* While automated checking <#def-Automated-Checking> and more
>     advanced implementations of semi-automated checking
>     <#def-Semi-Automated-Checking> may improve the authoring
>     experience,this is not required to meet the success criteria for
>     this checkpoint.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.2
> 
>     *Success Criteria:*
> 
>        1. An individual check /must/ be associated with each requirement
>           in the content type-specific WCAG benchmark <#conf-benchmark>
>           document (i.e., not blanket statements such as "does the
>           content meet all the requirements").
>        2. For checks that are associated with a type of element
>           <#def-Element> (e.g., |img|), each element instance /must/ be
>           individually identified as potential accessibility problems
>           <#def-Web-Content-Accessibility-Problem>. For checks that are
>           relevant across multiple elements (e.g., consistent
>           navigation) or apply to most or all elements (e.g., background
>           color contrast, reading level), the entire span of elements
>           /must/ be identified as potential accessibility problems, up
>           to the entire content if applicable.
>        3. If the authoring tool relies on author judgment to determine
>           if a potential accessibility problem
>           <#def-Web-Content-Accessibility-Problem> is correctly
>           identified, then the message to the author <#def-Author>
>           /must/ be tailored to that potential accessibility problem
>           (i.e., to that requirement in the context of that element
>           <#def-Element> or span of elements).
>        4. The authoring tool /must/ present checking as an option to the
>           author <#def-Author> at or before the completion of authoring
>           <#def-Comp-Authoring>.
> 
>     *Note:* This checkpoint does not apply to authoring tools that
>     constrain authoring choice to such a degree that it is not possible
>     to create Web content <#def-Web-Content> that does not conform to
>     WCAG <#Relationship-To-WCAG>.
> 
> B.2.3 Assist authors <#def-Author> in repairing <#def-Repairing> 
> accessibility problems <#def-Web-Content-Accessibility-Problem>. 
> [Relative Priority]
> 
>     *Rationale:* Assistance by the authoring tool may simplify the task
>     of repairing accessibility problems for some authors, and make it
>     possible for others.
> 
>     *Note:* While automated repair <#def-Automated-Repairing> and
>     semi-automated repair <#def-Semi-Automated-Repairing> may improve
>     the authoring experience, providing repair instructions is
>     sufficient to meet the success criteria for this checkpoint.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.3
> 
>     *Success Criteria:*
> 
>        1. For each potential accessibility problem
>           <#def-Web-Content-Accessibility-Problem> identified by the
>           checking function (required in Checkpoint B.2.2
>           <#check-notify-on-schedule>), *at least one* of the following
>           /must/ be provided:
>               * (a) repair instructions, for the author <#def-Author> to
>                 follow, that are specific to the accessibility problem
>                 <#def-Web-Content-Accessibility-Problem> or
>               * (b) an automated repair <#def-Automated-Repairing> or
>                 semi-automated repair <#def-Semi-Automated-Repairing>
>                 mechanism.
> 
> B.2.4 Assist authors to ensure that equivalent alternatives for non-text 
> objects are accurate and fit the context. [Priority 1]
> 
>     *Rationale:* Improperly generated equivalent alternatives
>     <#def-Equiv-Alternatives> can create accessibility problems
>     <#def-Web-Content-Accessibility-Problem> and interfere with
>     accessibility checking.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.4
> 
>     *Success Criteria:*
> 
>        1. If the authoring tool offers text alternatives
>           <#def-Text-Alternatives> for non-text objects
>           <#def-Non-text-objects>, then the source of the alternatives
>           for each object /must/ be *at least one* of the following:
>               * (a) text alternatives <#def-Text-Alternatives>
>                 previously entered by authors <#def-Author> for the
>                 non-text object <#def-Non-text-objects> (e.g., by the
>                 same author, or another author on a collaborative system),
>               * (b) text alternatives <#def-Text-Alternatives> stored
>                 with the non-text object <#def-Non-text-objects> in an
>                 image database (or equivalent), or
>               * (c) null text alternatives <#def-Text-Alternatives> for
>                 non-text objects <#def-Non-text-objects> that are only
>                 used only for visual formatting.
>           (Text alternatives <#def-Text-Alternatives> should not be
>           generated from unreliable sources. File names are generally
>           not acceptable, although in some cases they will be (e.g., if
>           they store alternatives previously entered by authors
>           <#def-Author>))
>        2. The authoring tool /must/ allow the author <#def-Author> to
>           accept, modify, or reject equivalent alternatives
>           <#def-Equiv-Alternatives>.
> 
> B.2.5 Provide functionality for managing, editing, and reusing 
> equivalent alternatives <#def-Equiv-Alternatives>. [Priority 3]
> 
>     *Rationale:* Simplifying the initial production and later reuse of
>     equivalent alternatives will encourage authors to use them more
>     frequently. In addition, such an alternative equivalent management
>     system will facilitate meeting the requirements of Checkpoints B.2.1
>     <#check-prompt-assist-user>, B.2.2 <#check-notify-on-schedule>,
>     B.2.3 <#check-dont-require-knowledge> and B.2.4 <#check-no-default-alt>.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.5
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ have the option of storing for
>           future re-use the following author <#def-Author> added
>           equivalent alternatives <#def-Equiv-Alternatives> for non-text
>           objects <#def-Non-text-objects> (if applicable):
>               * plain text text alternatives <#def-Text-Alternatives>
>                 that the authoring tool stores directly (e.g.,
>                 alternative text labels, long text descriptions), and
>               * URI referenced synchronized alternatives
>                 <#def-Synchronized-Alternatives> or accessible
>                 multimedia alternatives
>                 <#def-accessible-multimedia-alternatives> that the
>                 authoring tool stores only indirectly (i.e., as URIs to
>                 external resources) (e.g., captions <#def-Captions> for
>                 video, sign language interpretation videos).
> 
> B.2.6 Provide the author <#def-Author> with a summary of accessibility 
> status. [Priority 3]
> 
>     *Rationale:* This summary will help authors to improve the
>     accessibility status of their work, keep track of problems, and
>     monitor progress.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.6
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ provide an option to view a list of
>           all known accessibility problems
>           <#def-Web-Content-Accessibility-Problem> (i.e., detected by
>           automated checking or identified by the author <#def-Author>)
>           prior to completion of authoring <#def-Comp-Authoring>.
> 
> B.2.7 Provide a tutorial on the process of accessible authoring. 
> [Priority 3]
> 
>     *Rationale:* Authors are more likely to use features that promote
>     accessibility, if they understand when and how to use them.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.2.7
> 
>     *Success Criteria:*
> 
>        1. The authoring tool /must/ provide a tutorial on the accessible
>           authoring process that is specific to the tool.
> 
> 
>       GUIDELINE B.3: Promote and integrate accessibility solutions
> 
> This guideline requires that authoring tools must promote accessible 
> authoring practices <#def-acc-auth-practice> within the tool as well as 
> smoothly integrate features that support accessible authoring 
> <#def-accessible-content-support-features> that have been added to meet 
> the other requirements in this document.
> 
> *Note: *In addition to the normative requirements of this guideline, 
> implementers should consider one other issue: the integration of 
> features that support accessible authoring 
> <#def-accessible-content-support-features> with the "look-and-feel" of 
> other features of the authoring tool. This type of integration has the 
> potential to:
> 
>     * produce a seamless product;
>     * leverage the existing knowledge and skills of authors <#def-Author>;
>     * make authors more receptive to new authoring requirements; and
>     * reduce the likelihood of confusion.
> 
> However, whenever new features are introduced into an authoring tool, 
> striking the right design balance between the similarity with existing 
> features and the provision of new functionality is often more of an art 
> than a science.
> 
> B.3.1 Ensure that the most accessible option for an authoring task is 
> given priority. [Priority 2]
> 
>     *Rationale:* Authors are most likely to use the first and easiest
>     option for a given authoring task.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.1
> 
>     *Success Criteria:*
> 
>        1. When the author has more than one authoring option for a given
>           task (e.g. emphasizing text using semantic markup rather than
>           inappropriately using header markup), then any options that
>           conform to WCAG <#priority-Relative> /must/ have equal or
>           higher prominence <#def-Prominence> than any options that do not.
>        2. Any choices of content types <#def-Content-Type> or authoring
>           option presented to the author (e.g., in menus, toolbars or
>           dialogs) that will lead to the creation of content that does
>           not conforms to WCAG <#priority-Relative> /must/ be marked or
>           labeled so that the author is aware of the consequences prior
>           to making the choice.
> 
> B.3.2. Ensure that sequential authoring processes integrate accessible 
> authoring practices. [Priority 2]
> 
>     *Rationale:* Accessible design as an afterthought or separate
>     process is much more onerous and therefore costly than when
>     accessibility is considered from the start. If the authoring tool
>     supports the author in considering accessibility before and/or
>     during the authoring process it is more likely that accessible
>     authoring practices <#def-acc-auth-practice> will become a common
>     practice. This is analogous to internationalization, which is much
>     easier when it is considered from the beginning rather than handled
>     last.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.2
> 
>     *Success Criteria:*
> 
>        1. Interactive features that sequence author actions (e.g.,
>           object insertion dialogs, templates, wizards) /must/ provide
>           any accessibility prompts <#def-Prompt> relevant to the
>           content being authored at or before the first opportunity to
>           /successfully/ complete the interactive feature.
>        2. For read-only instruction text (e.g., tutorials, reference
>           manuals, design guides) that includes a sequence of steps for
>           the author to follow, the relevant accessibility authoring
>           practices <#def-acc-auth-practice>/ must/ appear in the step
>           sequence before the first opportunity to /successfully/
>           complete the sequence.
> 
> B.3.3 Ensure that features of the tool that support the production of 
> accessible content are prominent in the user interface. [Priority 2]
> 
>     *Rationale:* If the features that support accessible authoring
>     <#def-accessible-content-support-features> are difficult to find and
>     activate, they are less likely to be used.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.3
> 
>     *Success Criteria:*
> 
>        1. All accessible content support features
>           <#def-accessible-content-support-features> /must/ match or
>           exceed the prominence <#def-Prominence> of any corresponding
>           features related to other classes of Web content problems
>           (e.g., markup validity, program code syntax, spelling and
>           grammar).
> 
> B.3.4 Ensure that features of the tool that support the production of 
> accessible content are configurable. [Priority 3]
> 
>     *Rationale:* The accessible content support features
>     <#def-accessible-content-support-features> will be more adaptable to
>     the work habits of authors if they can be turned on and off easily
>     as the author needs them.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.4
> 
>     *Success Criteria:*
> 
>        1. All accessible content support features
>           <#def-accessible-content-support-features> /must/ be turned on
>           by default.
>        2. If the author does turn off an accessible content support
>           feature, then the authoring tool /must/ inform the author that
>           this may increase the risk of content accessibility problems
>           <#def-Web-Content-Accessibility-Problem>.
>        3. If the author does turn off an accessible content support
>           feature, then the author /must/ always have the option to turn
>           the feature back on again.
>        4. The accessible content support feature
>           <#def-accessible-content-support-features> settings /must/ be
>           saved between authoring sessions.
> 
> B.3.5 Document features of the tool that support the production of 
> accessible content. [Priority 1]
> 
>     *Rationale:* Without documentation <#def-Documentation> of the
>     features that support the production of accessible content
>     <#def-accessible-content-support-features> (e.g., prompts for
>     alternatives, accessibility checkers) authors may not find or use them.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.5
> 
>     *Success Criteria:*
> 
>        1. All accessible content support features
>           <#def-accessible-content-support-features> /must/ be
>           documented in the help system.
> 
> B.3.6 Ensure that any authoring practices demonstrated in repair 
> instructions and documentation are accessible. [Priority 3]
> 
>     *Rationale:* If accessible authoring is integrated into instructions
>     and guidance offered by the tool (e.g., documentation
>     <#def-Documentation>, help, tutorials, examples, and workflow
>     <#def-Workflow> processes), authors are more likely to follow
>     accessible authoring techniques if they are demonstrated as common
>     practice. This can also facilitate a better understanding of the
>     reasoning behind and the consequences of authoring accessible content.
> 
>     *Techniques:* Implementation Techniques for Checkpoint B.3.6
> 
>     *Success Criteria:*
> 
>        1. All examples of markup and screenshots of the authoring tool
>           user interface that appear in the documentation
>           <#def-Documentation> and repair instructions /must/
>           demonstrate accessible Web content
>           <#def-Accessible-Web-Content>, with the exception of examples
>           specifically intended to show inaccessible practices which
>           must be avoided.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> 
>     4. Glossary
> 
> This glossary is normative <#def-Normative>. Some defintions may differ 
> from those in other WAI documents. The definitions here serve the goals 
> of this Recommendation.
> 
> a <#a> b c <#c> d <#d> e <#e> f g <#g> h i <#i> j k l m <#m> n <#n> o p 
> <#p> q r <#r> s <#s> t <#t> u <#u> v <#v> w <#w> x y z
> 
> Accessibility Problem, Authoring Tool User Interface
>     An authoring tool user interface accessibility problem is an aspect
>     of an authoring tool user interface <#def-Authoring-Tool-Interface>
>     that fails to meet one of the checkpoint success criteria in Part A
>     <#part-tool-accessible>. The severity of a given problem is
>     reflected in the priority of the checkpoint. 
> Accessibility Problem, Web Content
>     A Web content accessibility problem is an aspect of Web content
>     <#def-Web-Content> that fails to meet some requirement of WCAG
>     <#priority-Relative>. The severity of a given problem is relative
>     and is determined by reference to WCAG <#priority-Relative>.
> Accessible Web Content
>     Web content <#def-Web-Content> (e.g. output of an authoring tool)
>     that conforms to WCAG <#priority-Relative>.
> Accessible Authoring Tool User Interface
>     For Web-based functionality, this is an authoring tool user
>     interface that conforms to WCAG <#priority-Relative>. For
>     non-Web-based functionality this is an authoring tool user interface
>     that meets the success criteria in Part A <#part-tool-accessible>.
>     The severity of a given problem is reflected in the priority of the
>     checkpoints.
> Accessibility Information
>     Accessibility information is the information that is necessary and
>     sufficient for undertaking an accessible authoring practice
>     <#def-acc-auth-practice>. For a particular content type
>     <#def-Content-Type>, this information may include, but is not
>     limited to, equivalent alternatives <#def-Equiv-Alternatives>.
> Accessible Authoring Practice
>     An accessible authoring practice is any authoring activity (e.g.,
>     inserting an element, setting an attribute value), by either the
>     author or the authoring tool, that corrects an existing Web content
>     accessibility problem <#def-Web-Content-Accessibility-Problem> or
>     does not cause a Web content accessibility problem
>     <#def-Web-Content-Accessibility-Problem> to be introduced..
> Accessible Content Support Features
>     All features of the tool that play a role in satisfying the success
>     criteria for checkpoints B.2.1 <#check-prompt-assist-user>, B.2.2
>     <#check-notify-on-schedule>, B.2.3 <#check-dont-require-knowledge>,
>     B.2.5 <#check-have-alt-registry>, B.2.6 <#check-progress-feedback>
>     and B.2.7 <#check-document-process>.
> Alert
>     An alert makes the author <#def-Author> aware of events or actions
>     that require a response. The author response is not necessarily
>     required immediately. The events or actions that trigger an alert
>     may have serious consequences if ignored.
> Audio Description
>     Audio description (also called "Described Video") is an equivalent
>     alternative <#def-Equiv-Alternatives> that provides auditory
>     information about actions, body language, graphics, and scene
>     changes in a video. Audio descriptions are commonly used by people
>     who are blind or have low vision, although they may also be used as
>     a low-bandwidth equivalent on the Web. An audio description is
>     either a pre-recorded human voice or a synthesized voice (recorded
>     or automatically generated in real time). The audio description must
>     be synchronized with the auditory track of a video presentation,
>     usually with descriptions occurring during natural pauses in the
>     auditory track.
> Author
>     An author is the term used for the user of an authoring tool. This
>     may include content authors, designers, programmers, publishers,
>     testers, etc.
> Authored "By Hand"
>     Authoring by hand is a situation in which the author <#def-Author>
>     specifies Web content <#def-Web-Content> at the level to be
>     interpreted by the user agent (e.g., typing into a text editor,
>     choosing an element by name from a list).
> Authoring Action
>     An authoring action is any action that the author <#def-Author>
>     takes using the authoring tool user interface
>     <#def-Authoring-Tool-Interface> with the intention of adding or
>     modifying Web content <#def-Web-Content> (e.g., typing text,
>     inserting an element, launching a wizard).
> Authoring Tool User Interface
>     The user interface of the authoring tool is the display and control
>     mechanism that the author <#def-Author> uses to communicate with and
>     operate the authoring tool software. Authoring tool interfaces may be:
> 
>         * *Web-Based: *tools that are implemented using Web content and
>           run within a user agent, or
>         * *Non-Web-Based:* tools that run directly on application
>           execution environments such as Windows, MacOS, Java Virtual
>           Machine etc.
>         * Note: tools may include both types of interfaces.
> 
>     Most authoring tool user interfaces are composed of two parts:
> 
>         * *Content Display: *The rendering of the content to the author
>           in the editing view <#def-Editing-View> or preview
>           <#def-preview>. This might be as marked-up content (i.e., in a
>           code-level <#code-level> view), input field content (e.g., in
>           an indirect view, dialog boxes), or as rendered text, images,
>           etc. (i.e., in a WYSIWYG <#wysiwyg> editing view).
>         * * Editing Interface:* All of the parts of the user interface
>           that are not the content display (e.g., authoring tool menus,
>           button bars, editing view <#def-Editing-View>, pop-up menus,
>           floating property bars, palettes, documentation windows,
>           cursor). These parts surround and in some cases are
>           superimposed on the content display <#def-ui-content-display>.
>           Preview views are not included in the editing interface.
> 
>     Figure 2: An illustration of the parts of the authoring tool user
>     interface as used in ATAG 2.0.
>     A graphic that illustrates the parts of the authoring tool user
>     interface as they are explained in the text, above. A long
>     description appears below the graphic.
>     The graphic is a highly simplified representation of how the user
>     interface of a typical GUI authoring tools is organized. The
>     illustration includes three different editing views, code-level
>     editing view, a WYSIWYG editing view and an indirect editing view
>     (which is also applicable to dialog boxes used by many tools). Those
>     parts of the user interface that are "editing interface" are colored
>     dark blue, while the editing views are light blue and the content
>     display within the editing views are a mauve color. A preview
>     <#def-preview> view is also included to show that the user interface
>     related to the preview not treated as the "editing interface". In
>     the code-level editing view, the entire text entry area is the
>     editing view and the text within it is the content display. In
>     addition, several editing interface controls are shown for this
>     editing view, including: a super-imposed underline that highlights a
>     misspelled attribute, a pop-up menu, a status bar and a scrollbar.
>     For the WYSIWYG editing view, the background of the editing view is
>     actually controlled by the content display (e.g. a rendered
>     background color from the content - although see Checkpoint A.1.3
>     <#check-tool-config-displays>). In the Indirect editing view (and
>     dialog boxes) representation, the user is constrained to only
>     providing some specific information (in this case some image
>     attribute values and a long description). The text areas that
>     collect this information are marked as editing views and the text
>     they contain is content display.
> 
> Authoring Tool
>     See "Definition of authoring tool" <#intro-def-au>.
> Available Programmatically
>     Capable of providing information to other software (including
>     assistive technologies) by following relevant accessibility platform
>     architectures (e.g., MSAA, Java Access) or, if the available
>     accessibility platform architectures are insufficient, following
>     some other published interoperability mechanism (custom-created by
>     the developer, if necessary).
> Captions
>     Captions are equivalent alternatives <#def-Equiv-Alternatives> that
>     consist of a text transcript of the auditory track of a movie (or
>     other video presentation) and that is synchronized with the video
>     and auditory tracks. Captions are generally rendered graphically.
>     They benefit people who are deaf or hard-of-hearing, and anyone who
>     cannot hear the audio (for example, someone in a noisy environment).
> Checking, Accessibility
>     Accessibility checking (or "accessibility evaluation") is the
>     process by which Web content <#def-Web-Content> is evaluated for Web
>     content accessibility problems
>     <#def-Web-Content-Accessibility-Problem>. ATAG 2.0 identifies three
>     types of checking, based on increasing levels of automation: *Manual
>     Checking * in which the authoring tool only provides instructions
>     for authors to follow in order to identify problems; *Semi-Automated
>     Checking * in which the authoring tool is able to identify potential
>     problems, but still requires human judgment by the author
>     <#def-Author> to make a final decision on whether an actual problem
>     exists; and *Automated Checking * in which the authoring tool is
>     able to check for problems automatically, with no human intervention
>     required. An authoring tool may support any combination of checking
>     types. 
> Completion of Authoring
>     Completion of authoring is the point in time at which an authoring
>     session ends and the author has no opportunity to make further
>     changes. This may be when an author chooses to "save and exit", or
>     "publish", or it may occur automatically at the end of a wizard, etc.
> Content Type
>     A content type is a data format, programming or markup language that
>     is intended to be retrieved and rendered by a user agent
>     <#def-User-Agent> (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript
>     or combinations). The usage of the term is a subset of WCAG 2.0's
>     [WCAG20] <#ref-WCAG20> current usage of the term "Technology".
> Conversion
>     A conversion is a process that takes as input, content in one
>     content type <#def-Content-Type> and produces as output, content in
>     another content type <#def-Content-Type> (e.g.,"Save as HTML"
>     functions).
> Document
>     A document is a structure of elements <#def-Element> along with any
>     associated content; the elements used are defined by a markup
>     language <#def-Markup-Language>.
> Documentation
>     Documentation refers to any information that supports the use of an
>     authoring tool. This information may be found electronically or
>     otherwise and includes help, manuals, installation instructions,
>     sample workflows <#def-Workflow>, and tutorials, etc.
> Editing View
>     An editing view is a view <#def-View> provided by the authoring tool
>     that allows editing by the author <#def-Author> (e.g., code-level
>     <#code-level> editing view, WYSIWYG <#wysiwyg> editing view).
> Element
>     Element is used in the same sense as in HTML [HTML4] <#ref-HTML4>
>     and XML [XML] <#ref-XML>, an element refers to a pair of tags and
>     their content, or an "empty" tag - one that requires no closing tag
>     or content..
> End User
>     An end user is a person who interacts with Web content
>     <#def-Web-Content> once it has been authored. In some cases, the
>     author <#def-Author> and end user is the same person.
> Equivalent Alternative
>     An equivalent alternative is content that is an acceptable
>     substitute for other content that a person may not be able to
>     access. An equivalent alternative fulfills essentially the same
>     function or purpose as the original content upon presentation.
>     Equivalent alternatives include text alternatives and synchronized
>     alternatives. *Text alternatives* present a text version of the
>     information conveyed in non-text objects such as graphics and audio
>     clips. The text alternative is considered accessible because it can
>     be rendered in many different ways (e.g., as synthesized speech for
>     individuals who have visual or learning disabilities, as Braille for
>     individuals who are blind, as graphical text for individuals who are
>     deaf or do not have a disability). *Accessible Multimedia
>     Alternatives* present the same information as is conveyed in the
>     multimedia <#def-Multimedia> via accessible text, navigation, forms,
>     etc..*Synchronized alternatives* present essential audio information
>     visually (i.e., captions <#def-Captions>) and essential video
>     information in an auditory manner (i.e., audio descriptions
>     <#def-Auditory-Description>).
> Freeform Drawing
>     Drawing actions that use the mouse or stylus in a continuous fashion
>     (e.g., a paintbrush feature). This does not cover moving or resizing
>     object-based graphics (including moving or resizing an object that
>     is a previously authored freeform graphic). 
> General flash or red flash
>     *General flash threshold (Based on Wisconsin Computer Equivalence
>     Algorithm for Flash Pattern Analysis (FPA) <#def-wiscequiv>):* A
>     sequence of flashes or rapidly changing image sequences where all
>     three of the following occur:
> 
>        1. the combined area of flashes occurring concurrently (but not
>           necessarily contiguously) occupies more than one quarter of
>           any 341 x 256 pixel rectangle anywhere on the displayed screen
>           area when the content is viewed at 1024 x 768 pixels;
>        2. there are more than three flashes within any one-second
>           period; and
>        3. the flashing is below 50 Hz.
> 
>     (*Note: *For the general flash threshold, a flash is defined as a
>     pair of opposing changes in brightness of 10% or more of full scale
>     white brightness, where brightness is calculated as 0.2126 * ((R /
>     FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2).
>     R, G, and B are the red, green, and blue RGB values of the color; FS
>     is the maximum possible full scale RGB value for R, G, and B (255
>     for eight bit color channels); and the "^" character is the
>     exponentiation operator. An "opposing change" is an increase
>     followed by a decrease, or a decrease followed by an increase. This
>     applies only when the brightness of the darker image is below .80 of
>     full scale white brightness. 
>     *Red flash threshold (Based on Wisconsin Computer Equivalence
>     Algorithm for Flash Pattern Analysis (FPA) <#def-wiscequiv>):* A
>     transition to or from a saturated red where both of the following
>     occur:
> 
>        1. The combined area of flashes occurring concurrently occupies
>           more than one quarter of any 341 x 256 pixel rectangle
>           anywhere on the displayed screen area when the content is
>           viewed at 1024 x 768 pixels.
>        2. There are more than three flashes within any one-second period.
>        3. The flashing is below 50 Hz.
> 
> Inform
>     To inform is to make the author <#def-Author> aware of an event or
>     situation using methods such as alert <#def-Alert>, prompt
>     <#def-Prompt>, sound, flash. These methods may be unintrusive (i.e.,
>     presented without stopping the author's current activity) or
>     intrusive (i.e., interrupting the author's current activity).
> Informative
>     Informative ("non-normative") parts of this document are never
>     required for conformance
> Keyboard Interface
>     Interface used by software to obtain keystroke input.
>     * Note 1:* Allows users to provide keystroke input to programs even
>     if the native technology does not contain a keyboard (e.g., a touch
>     screen PDA has a keyboard interface built into its operating system
>     as well as a connector for external keyboards. Applications on the
>     PDA can use the interface to obtain keyboard input either from an
>     external keyboard or from other applications that provide simulated
>     keyboard output, such as handwriting interpreters or speech to text
>     applications with "keyboard emulation" functionality).
>     * Note 2:* Operation of the application (or parts of the
>     application) through a keyboard operated mouse emulator, such as
>     MouseKeys, does not qualify as operation through a keyboard
>     interface because operation of the program is through its pointing
>     device interface - not through its keyboard interface.
> Markup
>     Markup is a set of tags from a markup language
>     <#def-Markup-Language> that specify the characteristics of a
>     document <#def-document>. Markup can be *presentational* (i.e.,
>     markup that encodes information about the visual layout of the
>     content), *structural* (i.e., markup that encodes information about
>     the structural role of elements of the content) or *semantic* (i.e.,
>     markup that encodes information about the intended meaning of the
>     content).
> Markup Language
>     A markup language is a syntax and/or set of rules to manage markup
>     <#def-Markup> (e.g., HTML [HTML4] <#ref-HTML4>, SVG [SVG]
>     <#ref-SVG>, or MathML [MATHML] <#ref-MATHML>).
> Multimedia
>     Audio or video synchronized with another type of media and/or with
>     time-based interactive components. 
> Non-text objects
>     Content objects that are not represented by text character(s) when
>     rendered in a user agent (e.g., images, audio, video).
> Normative
>     Normative parts of this document are always required for conformance.
> Platform
>     @@The software environment within which the authoring tool operates.
>     For functionality that is not Web-based, this is an operating
>     systems (e.g., Windows, MacOS, Linux), virtual machine (e.g. JVM) or
>     a higher level GUI toolkit (e.g. Eclipse). For Web-based
>     functionality, the term applies more generically to user agents in
>     general, although for purposes of evaluating conformance to ATAG
>     2.0, a specific user agent(s) will be listed in the conformance profile.
> Presentation
>     Presentation is the rendering of the content and structure in a form
>     that can be perceived by the user.
> Preview
>     A non-editable view of the content that is intended to show how it
>     will appear and behave in a user agent <#def-User-Agent>. 
> Prominence
>     The prominence of a control in the authoring tool user interface
>     <#def-Authoring-Tool-Interface> is a heuristic measure of the degree
>     to which authors <#def-Author> are likely to notice a control when
>     operating the authoring tool. In this document, prominence refers to
>     visual as well as keyboard-driven navigation. Some of the factors
>     that contribute to the prominence of a control include: *control
>     size* (large controls or controls surrounded by extra white space
>     may appear to be conferred higher importance), *control order*
>     (items that occur early in the "localized" reading order (e.g., left
>     to right and top to bottom; right to left and top to bottom) are
>     conferred higher importance), *control grouping* (grouping controls
>     together can change the reading order and the related judgments of
>     importance), *advanced options* (when the properties are explicitly
>     or implicitly grouped into sets of basic and advanced properties,
>     the basic properties may gain apparent importance), and
>     *highlighting* (controls may be distinguished from others using
>     icons, color, styling).
> Prompt
>     In this document "prompt" refers to any authoring tool initiated
>     request for a decision or piece of information. Well designed
>     prompting will urge, suggest, and encourage the author.
> Repairing, Accessibility
>     Accessibility repairing is the process by which Web content
>     accessibility problems <#def-Web-Content-Accessibility-Problem> that
>     have been identified within Web content <#def-Web-Content> are
>     resolved. ATAG 2.0 identifies three types of repairing, based on
>     increasing levels of automation: *Manual *repairing in which the
>     authoring tool only provides instructions for authors to follow in
>     order to make the necessary correction; *Semi-Automated* repairing,
>     in which the authoring tool can provide some automated assistance to
>     the author in performing corrections, but the author's input is
>     still required before the repair can be completed; and *Automated*
>     repairing, in which the authoring tool is able to make repairs
>     automatically, with no author <#def-Author> input or confirmation
>     from the author. An authoring tool may support any combination of
>     repairing types. 
> Selectable items
>     Any items that an author may select from within the menus, toolbars,
>     palettes, etc. (e.g., "open", "save", "emphasis", "check spelling")
> Structured element set
>     Content organized into lists, maps, hierachies (e.g., tree views),
>     graphs, etc.
> Transcript
>     A transcript is a non-synchronized text alternative
>     <#def-Text-Alternatives> for the sounds, narration, and dialogue in
>     an audio clip or the auditory track of a multimedia presentation.
>     For a video, the transcript can also include the description of
>     actions, body language, graphics, and scene changes of the visual track.
> Transformation
>     A transformation is a process that takes as input, an object in one
>     content type <#def-Content-Type> and produces as output, a different
>     object in the same content type (e.g., a function that transforms
>     tables into lists).
> User Agent
>     A user agent is software that retrieves and renders Web content.
>     This may include Web browsers, media players, plug-ins, and other
>     programs, including assistive technologies, that help in retrieving
>     and rendering Web content.
> View
>     A view is a rendering of Web content <#def-Web-Content> by an
>     authoring tool. Authoring tool views are usually either editing
>     views <#def-Editing-View> or previews <#def-preview>. 
> Web-based authoring tool user interface functionality
>     That part of an authoring tool user interface
>     <#def-Authoring-Tool-Interface> that is implemented using a content
>     type <#def-Content-Type> and rendered on a user agent
>     <#def-User-Agent>. Some authoring tools are fully Web-based (e.g.,
>     on-line content management system) others have components that are
>     Web-based (e.g., a stand-alone markup editor with on-line help pages).
> Web Content
>     Content published on the Web using a content type <#def-Content-Type>.
> Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)
>     a method developed at the University of Wisconsin, working in
>     conjunction with Dr. Graham Harding and Cambridge Research
>     Associates, for applying the United Kingdom's "Ofcom Guidance Note
>     on Flashing Images and Regular Patterns in Television (Re-issued as
>     Ofcom Notes 25 July 2005)" to content displayed on a computer
>     screen, such as Web pages and other computer content.
>     * Note:* The Ofcom Guidance Document [OFCOM] <#ref-OFCOM> is based
>     on the assumption that the television screen occupies the central
>     ten degrees of vision. This is not accurate for a screen which is
>     located in front of a person. The Wisconsin algorithm basically
>     carries out the same analysis as the Ofcom Guidelines except that is
>     does it on every possible ten degree window for a prototypical
>     computer display.
> Workflow
>     A workflow is a customary sequence of steps or tasks that are
>     followed to produce a deliverable.
> 
> ------------------------------------------------------------------------
> 
> 
>     5. References
> 
> For the *latest version* of any W3C specification please consult the 
> list of W3C Technical Reports <http://www.w3.org/TR/> at 
> http://www.w3.org/TR/. Some documents listed below may have been 
> superseded since the publication of this document.
> 
> *Note:* In this document, bracketed labels such as "[HTML4]" link to the 
> corresponding entries in this section. These labels are also identified 
> as references through markup. Normative references are highlighted and 
> identified through markup.
> 
> 
>       5.1 How to refer to this document
> 
> There are two recommended ways to refer to the "Authoring Tool 
> Accessibility Guidelines 2.0" (and to W3C documents in general):
> 
>    1. References to a specific version of "Authoring Tool Accessibility
>       Guidelines 2.0." For example, use the "this version" URI to refer
>       to the current document:
>       http://www.w3.org/TR/2004/WD-ATAG20-20041122/.
>    2. References to the latest version of "Authoring Tool Accessibility
>       Guidelines 2.0." Use the "latest version" URI to refer to the most
>       recently published document in the series:
>       http://www.w3.org/TR/ATAG20/.
> 
> In almost all cases, references (either by name or by link) should be to 
> a specific version of the document. W3C will make every effort to make 
> this document indefinitely available at its original address in its 
> original form. The top of this document includes the relevant catalog 
> metadata for specific references (including title, publication date, 
> "this version" URI, editors' names, and copyright information).
> 
> An XHTML 1.0 [XHTML10] <#ref-XHTML10> paragraph including a reference to 
> this specific document might be written:
> 
> @@add at final publishing@@
> 
> For very general references to this document (where stability of content 
> and anchors is not required), it may be appropriate to refer to the 
> latest version of this document.
> 
> Other sections of this document explain how to build a conformance claim 
> <#Conformance>.
> 
> 
>       5.2 Normative references
> 
> A document appears in this section if at least one reference to the 
> document appears in a checkpoint success criteria.
> 
> *[WCAG10]*
>     "Web Content Accessibility Guidelines 1.0"
>     <http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/>, W. Chisholm,
>     G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0
>     Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
> *[WCAG20]*
>     "Web Content Accessibility Guidelines 2.0 (Working Draft)
>     <http://www.w3.org/TR/WCAG20/>", W. Chisholm, G. Vanderheiden, and
>     J. White, editors. The latest version of the Web Content
>     Accessibility Guidelines 2.0 is available at
>     http://www.w3.org/TR/WCAG20/. *Note: This document is still a
>     working draft*.
> 
> 
>       5.3 Informative references
> 
> *[ATAG10]*
>     "Authoring Tool Accessibility Guidelines 1.0
>     <http://www.w3.org/TR/2000/REC-ATAG10-20000203/>", J. Treviranus, C.
>     McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000.
>     This W3C Recommendation is available at
>     http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
>  
>      
> *[ATAG20-TECHS]*
>     "Techniques for Authoring Tool Accessibility 2.0
>     <http://www.w3.org/TR/2004/WD-ATAG20-TECHS-20041122/>", J.
>     Treviranus, J. Richards, C. McCathieNevile, and M. May, eds, 22
>     November 2004. The latest draft of this W3C note is available at
>     http://www.w3.org/TR/ATAG20-TECHS.
> *[COMPONENTS]*
>     "Essential Components of Web Accessibility
>     <http://www.w3.org/WAI/intro/components>", S. L. Henry, ed. This
>     document is available at http://www.w3.org/WAI/intro/components.
> *[CSS2-ACCESS]*
>     "Accessibility Features of CSS
>     <http://www.w3.org/1999/08/NOTE-CSS-access-19990804>," I. Jacobs and
>     J. Brewer, eds., 4 August 1999. This W3C Note is available at
>     http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest
>     version of Accessibility Features of CSS
>     <http://www.w3.org/TR/CSS-access> is available at
>     http://www.w3.org/TR/CSS-access.
> *[HTML4]*
>     "HTML 4.01 Recommendation
>     <http://www.w3.org/TR/1999/REC-html401-19991224/>", D. Raggett, A.
>     Le Hors, and I. Jacobs, editors., 24 December 1999. This HTML 4.01
>     Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224.
>     The latest version of HTML 4 <http://www.w3.org/TR/html4/> is
>     available at http://www.w3.org/TR/html4.
> *[MATHML]*
>     "Mathematical Markup Language
>     <http://www.w3.org/1999/07/REC-MathML-19990707/>", P. Ion and R.
>     Miner, editors., 7 April 1998, revised 7 July 1999. This MathML 1.0
>     Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The
>     latest version of MathML 1.0 <http://www.w3.org/TR/REC-MathML/> is
>     available at http://www.w3.org/TR/REC-MathML.
> *[OFCOM]*
>     Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance
>     Note on Flashing Images and Regular Patterns in Television
>     (Re-issued as Ofcom Notes 25 July 2005)" available at
>     http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf) 
> *[PWD-USE-WEB]*
>     "How People With Disabilities Use the Web
>     <http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/20010104.html>", J.
>     Brewer, ed., 4 January 2001. This document is available at
>     http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
> *[SMIL-ACCESS]*
>     "Accessibility Features of SMIL
>     <http://www.w3.org/TR/1999/NOTE-SMIL-access-19990921/>," M.-R.
>     Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Note is
>     available at available at http://www.w3.org/TR/SMIL-access.
> *[SVG]*
>     "Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)
>     <http://www.w3.org/TR/SVG/>", J. Ferraiolo, editor. The latest
>     version of the SVG specification is available at
>     http://www.w3.org/TR/SVG.
> *[SVG-ACCESS]*
>     "Accessibility of Scalable Vector Graphics
>     <http://www.w3.org/TR/SVG-access/>," C. McCathieNevile, M.-R.
>     Koivunen, eds., 7 August 2000. This W3C Note is available at
>     http://www.w3.org/TR/SVG-access.
> *[WCAG10-TECHS]*
>     "Techniques for Web Content Accessibility Guidelines 1.0
>     <http://www.w3.org/TR/WCAG10-TECHS/>," W. Chisholm, G. Vanderheiden,
>     and I. Jacobs, eds. , 6 November 2000. This W3C Note is available at
>     http://www.w3.org/TR/WCAG10-TECHS/.
> *[WCAG20-TECHS-GENERAL]*
>     "General Techniques for WCAG 2.0
>     <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-GENERAL/>," J. Slatin, T.
>     Croucher, eds. *Note: This document is still a working draft*.
> *[WCAG20-TECHS-CSS]*
>     "CSS Techniques for WCAG 2.0
>     <http://www.w3.org/TR/WCAG20-CSS-TECHS/>," W. Chisholm, B. Gibson,
>     eds. *Note: This document is still a working draft*.
> *[WCAG20-TECHS-HTML]*
>     "HTML Techniques for WCAG 2.0
>     <http://www.w3.org/TR/WCAG20-HTML-TECHS/>," M. Cooper, ed. *Note:
>     This document is still a working draft*.
> *[WCAG20-TECHS-SCRIPTING]*
>     "Client-side Scripting Techniques for WCAG 2.0
>     <http://www.w3.org/TR/WCAG20-SCRIPT-TECHS/>," M. May, B. Gibson,
>     eds. *Note: This document is still a working draft*.
> *[WCAG20-UNDERSTANDING]*
>     "Understanding WCAG 2.0
>     <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>," B. Caldwell, W.
>     Chisholm, J. Slatin, G. Vanderheiden, eds. *Note: This document is
>     still a working draft*.
> *[XAG]*
>     "XML Accessibility Guidelines <http://www.w3.org/TR/xag>", D.
>     Dardailler, S. B. Palmer, C. McCathieNevile, editors, 3 October
>     2002. This is a Working Group Draft.
> 
> ------------------------------------------------------------------------
> 
> 
>     6. Acknowledgments
> 
> The active participants of the Authoring Tool Accessibility Guidelines 
> Working Group who authored this document were: Tim Boland (National 
> Institute for Standards and Technology), Barry A. Feigenbaum (IBM), Matt 
> May, Greg Pisocky (Adobe), Jan Richards (Adaptive Technology Resource 
> Centre, University of Toronto), Roberto Scano (IWA/HWG), and Jutta 
> Treviranus (Chair of the working group, Adaptive Technology Resource 
> Centre, University of Toronto)
> 
> Many thanks to the following people who have contributed to the AUWG 
> through review and comment: Kynn Bartlett, Giorgio Brajnik, Judy Brewer, 
> Wendy Chisholm, Daniel Dardailler, Geoff Deering, Katie Haritos-Shea, 
> Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William 
> Loughborough, Charles McCathieNevile, Matthias Müller-Prove, Liddy 
> Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, Gregory 
> Rosmaita, Heather Swayne, Gregg Vanderheiden, Carlos Velasco, and Jason 
> White.
> 
> This document would not have been possible without the work of those who 
> contributed to ATAG 1.0 <http://www.w3.org/TR/ATAG10/#acknowledgments>.
> 
> This publication has been funded in part with Federal funds from the 
> U.S. Department of Education under contract number ED05CO0039. The 
> content of this publication does not necessarily reflect the views or 
> policies of the U.S. Department of Education, nor does mention of trade 
> names, commercial products, or organizations imply endorsement by the 
> U.S. Government.
> 
> Level Double-A conformance icon, W3C-WAI Web Content Accessibility 
> Guidelines 1.0 <http://www.w3.org/WAI/WCAG1AA-Conformance>
> 
> ------------------------------------------------------------------------
> [Contents <#toc>] [Techniques </TR/2004/WD-ATAG20-TECHS-20041122/>] 
> [Checklist <checklist.html>]
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> [Guidelines <WD-ATAG20-20060526.html>] [Techniques 
> </TR/2004/WD-ATAG20-TECHS-20041122/>]
> W3C <http://www.w3.org/>
> 
> 
>   Appendix B. Comparison of ATAG 1.0 checkpoints to ATAG 2.0
> 
> Editors:
>     Jan Richards - ATRC, University of Toronto
> 
> This section is informative.
> 
> This mapping shows how the ATAG 1.0 checkpoints relate to the @@ATAG 2.0 
> Draft released ??@@. Note that ATAG 1.0 is still a draft and the ATAG 
> 2.0 Guidelines and success criteria in no way supersede the checkpoints 
> in ATAG 1.0.
> 
> The Working Group is working carefully to enable developers that are 
> currently using ATAG 1.0 (which remains a stable and referenceable 
> document) to ensure that they will be able to make a smooth transition 
> to ATAG 2.0 when it is released.
> 
> 
>     Compariosn Table
> 
> Where to find the ATAG 1.0 requirements Requirements in ATAG 1.0 
> Recommendation 	Location in ATAG 2.0 Draft
> *Guideline 1. Support accessible authoring practices.* 	*Guideline B.1: 
> <guidelines.html#gl-enable-accessible-content> Enable the production of 
> accessible content *
> 1.1 Ensure that the author can produce accessible content in the markup 
> language(s) supported by the tool. [Priority 1] 	
> 
> /Removed due to the overly general wording. /
> 
> 1.2 Ensure that the tool preserves all accessibility information during 
> authoring, transformations, and conversions. [Priority 1] 	B.1.2 
> <guidelines.html#check-leave-access-content> Ensure that the tool 
> preserves accessibility information during transformations and 
> conversions. [Priority 1]
> 1.3 Ensure that when the tool automatically generates markup it conforms 
> to the W3C's Web Content Accessibility Guidelines 1.0. [Relative 
> Priority] 	B.1.4 <guidelines.html#check-generate-access-markup> Ensure 
> that when the tool automatically generates content it conforms to WCAG. 
> [Relative Priority]
> 1.4 Ensure that templates provided by the tool conform to the Web 
> Content Accessibility Guidelines 1.0. [Relative Priority] 	
> 
> /Made more general:
> /B.1.5 <guidelines.html#check-accessible-preauthored> Ensure that all 
> pre-authored content for the tool conforms to WCAG. [Relative Priority]
> 
> *Guideline 2. Generate standard markup.* 	/Combined under:/
> *Guideline B.1: <guidelines.html#gl-enable-accessible-content>* Enable 
> the production of accessible content.
> 2.1 Use the latest versions of W3C Recommendations when they are 
> available and appropriate for a task. [Priority 2] 	/No longer W3C 
> technology specific:/
> B.1.1 <guidelines.html#check-prefer-w3c> Support content types that 
> enable the creation of Web content that conforms to WCAG. [Priority 1]
> 2.2 Ensure that the tool automatically generates valid markup. 
> [Priority 1] 	/Removed because this is a WCAG-level issue. /
> 2.3 If markup produced by the tool does not conform to W3C 
> specifications, inform the author. [Priority 3] 	/Removed because this 
> is covered by B.1.4 <guidelines.html#check-generate-access-markup>./
> *Guideline 3. Support the creation of accessible content.* 	*GUIDELINE 
> B.2: <guidelines.html#gl-support-author> Support the author in the 
> production of accessible content*
> 3.1 Prompt the author to provide equivalent alternative information 
> (e.g., captions, auditory descriptions, and collated text transcripts 
> for video). [Relative Priority] 	/Made more general:/
> B.2.1 <guidelines.html#check-prompt-assist-user> Prompt and assist the 
> author to create content that conforms to WCAG. [Relative Priority]
> 3.2 Help the author create structured content and separate information 
> from its presentation. [Relative Priority] 	/Combined into B.2.1 
> <guidelines.html#check-prompt-assist-user>. /
> 3.3 Ensure that prepackaged content conforms to the Web Content 
> Accessibility Guidelines 1.0. [Relative Priority] 	/Combined into B.1.5 
> <guidelines.html#check-accessible-preauthored>. /
> 3.4 Do not automatically generate equivalent alternatives. Do not reuse 
> previously authored alternatives without author confirmation, except 
> when the function is known with certainty. [Priority 1] 	B.2.4 
> <guidelines.html#check-no-default-alt> Assist authors to ensure that 
> equivalent alternatives for non-text objects are accurate and fit the 
> context. [Priority 1]
> 3.5 Provide functionality for managing, editing, and reusing alternative 
> equivalents for multimedia objects. [Priority 3] 	B.2.5 
> <guidelines.html#check-have-alt-registry> Provide functionality for 
> managing, editing, and reusing equivalent alternatives. [Priority 3]
> *Guideline 4. Provide ways of checking and correcting inaccessible 
> content.* 	/Combined under:
> / *GUIDELINE B.2: <guidelines.html#gl-support-author> Support the author 
> in the production of accessible content. *
> 4.1 Check for and inform the author of accessibility problems. [Relative 
> Priority] 	B.2.2 <guidelines.html#check-notify-on-schedule> Check for 
> and inform the author of accessibility problems. [Relative Priority]
> 4.2 Assist authors in correcting accessibility problems. [Relative 
> Priority] 	B.2.3 <guidelines.html#check-dont-require-knowledge> Assist 
> authors in repairing accessibility problems. [Relative Priority]
> 4.3 Allow the author to preserve markup not recognized by the tool. 
> [Priority 2] 	/Combined into:/
> B.1.3 <guidelines.html#check-leave-content> Ensure that the author is 
> notified before content is automatically removed. [Priority 2]
> 4.4 Provide the author with a summary of the document's accessibility 
> status. [Priority 3] 	B.2.6 <guidelines.html#check-progress-feedback> 
> Provide the author with a summary of accessibility status. [Priority 3]
> 4.5 Allow the author to transform presentation markup that is misused to 
> convey structure into structural markup, and to transform presentation 
> markup used for style into style sheets. [Priority 3] 	/Removed because 
> this is a repair strategy. /
> *Guideline 5. Integrate accessibility solutions into the overall "look 
> and feel".* 	/Combined into:/
> *GUIDELINE B.3: <guidelines.html#gl-promote-integrate> Promote and 
> integrate accessibility solutions*
> 5.1 Ensure that functionality related to accessible authoring practices 
> is naturally integrated into the overall look and feel of the tool. 
> [Priority 2] 	/Removed because it is not testable. The content has been 
> moved into an informative note for Guideline B.3 
> <guidelines.html#gl-promote-integrate>./
> 5.2 Ensure that accessible authoring practices supporting Web Content 
> Accessibility Guidelines 1.0 Priority 1 checkpoints are among the most 
> obvious and easily initiated by the author. [Priority 2] 	
> 
> B.3.1 <guidelines.html#check-give-priority> Ensure that the most 
> accessible option for an authoring task is given priority. [Priority 2]
> 
> *Guideline 6. Promote accessibility in help and documentation.* 
> /Combined into:/
> *GUIDELINE B.3: <guidelines.html#gl-promote-integrate> Promote and 
> integrate accessibility solutions*
> 6.1 Document all features that promote the production of accessible 
> content. [Priority 1] 	B.3.5 <guidelines.html#check-document-features> 
> Document features of the tool that support the production of accessible 
> content. [Priority 1]
> 6.2 Ensure that creating accessible content is a naturally integrated 
> part of the documentation, including examples. [Priority 2] 	B.3.6 
> <guidelines.html#check-accessibility-everywhere> Ensure that any 
> authoring practices demonstrated in repair instructions and 
> documentation are accessible. [Priority 3]
> 6.3 In a dedicated section, document all features of the tool that 
> promote the production of accessible content. [Priority 3] 	/Removed 
> because this is an implementation option for B.3.5 
> <guidelines.html#check-document-features>./
> *Guideline 7. Ensure that the authoring tool is accessible to authors 
> with disabilities.* 	
> 
> /Expanded into: /
> *GUIDELINE A.1: <guidelines.html#gl-tool-accessible-perceivable> 
> Authoring Tool User Interface must be Perceivable
> GUIDELINE A.2: <guidelines.html#gl-tool-accessible-operable> Authoring 
> Tool User Interface must be Operable
> GUIDELINE A.3: <guidelines.html#gl-tool-accessible-understandable> 
> Authoring Tool User Interface must be Understandable
> GUIDELINE A.4: <guidelines.html#gl-tool-accessible-atfriendly> Authoring 
> Tool User Interface must be Access System Friendly*
> 
> 7.1 Use all applicable operating system and accessibility standards and 
> conventions (Priority 1 for standards and conventions that are essential 
> to accessibility; Priority 2 for those that are important to 
> accessibility; Priority 3 for those that are beneficial to 
> accessibility). 	/Covered in more detail by:/
> A.1.1 <guidelines.html#check-tool-text-alts> For the authoring tool user 
> interface, provide text alternatives for all non-text objects. [Priority 1]
> A.1.2 <guidelines.html#check-tool-synchro-alts> For the authoring tool 
> user interface, provide synchronized alternatives for multimedia. 
> [Priority 2]
> A.1.3 <guidelines.html#check-tool-config-displays> For the authoring 
> tool user interface, ensure that all display preferences are 
> configurable. [Priority 1]
> A.1.5 <guidelines.html#check-tool-sep-presentation>: For the authoring 
> tool user interface, ensure that information, functionality, and 
> structure can be separated from presentation. [Priority 1]
> A.2.1 <guidelines.html#check-tool-keyboard-access> For the authoring 
> tool user interface, ensure that all functionality is operable via a 
> keyboard or a keyboard interface. [Priority 1]
> A.2.2 <guidelines.html#check-tool-configurable> For the authoring tool 
> user interface, ensure user configurable access to selectable items. 
> [Priority 3]
> A.2.3 <guidelines.html#check-tool-control-time> For the authoring tool 
> user interface, allow authors to control time limits. [Priority 1]
> A.2.4 <guidelines.html#check-tool-prevent-flash> For the authoring tool 
> user interface, allow authors to avoid content that could cause seizures 
> due to photosensitivity. [Priority 1]
> A.2.7 <guidelines.html#check-tool-undo> For the authoring tool user 
> interface, provide an undo function. [Priority 2]
> A.2.8 <guidelines.html#check-tool-personal-config> For the authoring 
> tool user interface, allow the author to have multiple sets of keyboard 
> operability and display preferences settings. [Priority 2]
> A.2.9 <guidelines.html#check-tool-previews> For the authoring tool user 
> interface, ensure previews emulate the accessible rendering features of 
> target browsers. [Priority 2]
> A.3.1 <guidelines.html#check-tool-conventions> For the authoring tool 
> user interface, observe the accessibility conventions of the platform. 
> [Priority 2]
> A.3.2 <guidelines.html#check-tool-consistency> For the authoring tool 
> user interface, maintain consistency. [Priority 2]
> A.3.3 <guidelines.html#check-tool-document> For the authoring tool user 
> interface, document the user interface including all accessibility 
> features. [Priority 1]
> A.4.1 <guidelines.html#check-tool-interoperability> Support 
> interoperability with assistive technologies. [Priority 1]
> A.4.2 <guidelines.html#check-document-interoperability> Document how the 
> authoring interface makes use of existing accessibility architectures. 
> [Priority 3]
> 7.2 Allow the author to change the presentation within editing views 
> without affecting the document markup. [Priority 1] 	A.1.4 
> <guidelines.html#check-tool-sep-display-prefs> For the authoring tool 
> user interface, ensure changes to the display settings of editing views 
> do not affect the content being edited. [Priority 1].
> 7.3 Allow the author to edit all properties of each element and object 
> in an accessible fashion. [Priority 1] 	/Removed because editing 
> properties is covered by all of the other checkpoints in Part A 
> <guidelines.html#part-tool-accessible>./
> 7.4 Ensure that the editing view allows navigation via the structure of 
> the document in an accessible fashion. [Priority 1] 	A.2.5 
> <guidelines.html#check-tool-struct-nav> For the authoring tool user 
> interface, ensure that editing views enable the author to navigate the 
> structure and perform structure-based edits. [Priority 2]
> 7.5 Enable editing of the structure of the document in an accessible 
> fashion. [Priority 2] 	/Removed because editing the structure is covered 
> by all of the other checkpoints in Part A 
> <guidelines.html#part-tool-accessible>./
> 7.6 Allow the author to search within editing views. [Priority 2] 	A.2.6 
> <guidelines.html#check-tool-search> For the authoring tool user 
> interface, allow the author to search content and markup within the 
> editing views. [Priority 2]
> 
> ------------------------------------------------------------------------
> [Guidelines <WD-ATAG20-20060526.html>] [Techniques 
> </TR/2004/WD-ATAG20-TECHS-20041122/>]
> 
> ------------------------------------------------------------------------
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896
Received on Wednesday, 21 June 2006 17:50:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT