- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Wed, 21 Jun 2006 13:47:07 -0400
- 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 UTC