Suggestions

GUIDELINES DOCUMENT
//Issue G-01: Clarify the first paragraph of the Introduction//
{NEW:} This document provides guidelines to help Web authoring tool developers (1) design authoring tools that generate accessible Web content and (2) create an accessible interface for the tools.
{OLD: "The guidelines in this document are designed to help authoring tool developers understand, and thereby reduce, barriers to the creation of accessible Web content. "} In these guidelines, the term "authoring tool" refers to the wide range of software used for creating Web content, including:
====
===
//Issue G-02: Improve the clarity of the Introduction//
{OLD: "An accessible authoring tool is accessible software that produces accessible content for the Web. {EH: I disagree with this definition. I think that an "accessible authoring tool" is an authoring tool that can be used by people with disabilities.}Thus the goals of this document can be stated as follows: that the authoring tool be accessible to authors regardless of disability, that the authoring tool generate accessible content by default, and that the authoring tool support and encourage the author in creating accessible content. Because most of the content of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web.{EH: I guess that simple text editors are not within the scope of this document. Is that correct?} Since the Web is both a means of receiving information and communicating information {EH: This previous clause is very confusing.}, it is important that both the Web content produced and the authoring tool it!
self be ac
   cessible."}
{NEW:} 
Authoring tools should (1) produce accessible content and (2) be accessible to authors with disabilities{EH: new paragraph}
Thus the goals of this document can be stated as follows: that the authoring tool be accessible to authors regardless of disability, that the authoring tool enable and facilitate the generation of accessible content. Because most of the content of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web.{EH: Arguably, this last sentence is paragraph and could be deleted.}
====
====
//Issue G-03: Refine the definitions of guidelines and checkpoints.//
{OLD:"
This document includes guidelines which are general principles of accessible design. Each guideline includes:
The guideline number; 
The statement of the guideline; 
The rationale behind the guideline; 
A list of checkpoint definitions. 
The checkpoint definitions in each guideline specify requirements for authoring tools to follow the guideline. Each checkpoint definition includes:
The checkpoint number; 
The statement of the checkpoint; 
The priority of the checkpoint; 
In some cases informative notes, clarifying examples, or cross references to related guidelines or checkpoints; 
A link to a section of the Techniques Document ([WAI-AUTOOLS-TECH]) where implementations and examples of the checkpoint are discussed; "}
--
{NEW:}
This document includes guidelines that are general principles of accessible design. Each guideline includes:
a guideline number,
a statement of the guideline,  
a rationale for the guideline, and
a list of checkpoints. 
Checkpoints specify requirements for following the guidelines. Each checkpoint includes:
a checkpoint number, 
a statement of the checkpoint,  
the priority of the checkpoint, 
in some cases, informative notes, clarifying examples, or cross references to related guidelines or checkpoints, and 
a link to a section of the Techniques Document ([WAI-AUTOOLS-TECH]) where implementations and examples of the checkpoint are discussed.
===
====
//Issue G-04: Clarify discussion of techniques.//
{OLD: "Each checkpoint is intended to be specific enough that it can be verified, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to meet the checkpoint."
"The Techniques provided in th<span class="guidelines-specific">e techniques</span> document are suggestions for how implementation might be done, or where further information can be found. They are informative only, and other strategies may be used to meet the checkpoint as well as, or in place of, those discussed. {EH: This paragraph seems redundant."}
==
Each checkpoint is intended to be specific enough that it can be verified, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to meet the checkpoint.
The techniques provided in the Techniques document are suggestions for how implementation might be done, or where further information can be found. They are informative only, and other techniques may be used to satisfy the checkpoint.
====
//Issue G-05: Put the goals under their own heading and simplify.//
1.1x. Goals
The guidelines in this document are intended to help authoring tool developers to develop tools that fulfill two design goals:
{OLD:"
1.	The authoring tool is accessible
2.	The authoring tool generates accessible content by default
3.	The authoring tool encourages the creation of accessible content"}

{NEW:}
The authoring tool enables and encourages the generation of accessible content. This is covered in guidelines 1 through 6.
The authoring tool is accessible. This is covered in guideline 7.
{EH: Note this is still somewhat redundant with other material in the Introduction.... But I think that this is an improvement.}
1.2 Checkpoint priorities
Each checkpoint has a priority level. The priority level reflects the impact of the checkpoint in meeting the goals of this document. {NOTE: Goals were moved higher}
The three priority levels are assigned as follows:
//Issue G-06: Simplify definition of priorities.//

{OLD:"
[Priority 1]
If the checkpoint is essential to meeting those goals
[Priority 2]
If the checkpoint is important to meeting those goals
[Priority 3]
If the checkpoint is beneficial to meeting those goals"}
=
{NEW:}
[Priority 1]
The checkpoint is essential to meeting those goals
[Priority 2]
The checkpoint is important to meeting those goals
[Priority 3]
The checkpoint is beneficial to meeting those goals"
=====<div class="guidelines-specific">
====
//Issue G-07: Refine description of claims//
{OLD: "Form 2: Include, on each statement of conformance, one of three icons provided by W3C and link the icon to the appropriate W3C explanation of the claim.}{Please note that the term "statement of conformance" is confusing.}
{NEW:}
Form 2: For each page {EH: Is this right?}, include one of three icons provided by W3C and link the icon to the appropriate W3C explanation of the claim.
{EH:>>INSERT HERE an example of this form for making a conformance claim or refer to the one at the bottom of the page.}
====
====
//Issue G-08: Rationales need to be tightened up. I suggest that all rationales have a similar structure. For example, perhaps each rationale should begin with a statement of the main "benefit" of following the guideline. Some of the rationales already seem to do this but not all do.//
{OLD:
{EH: I find this to be a confusing sentence for leading off the rationale section of the first guideline:"Methods for ensuring accessible markup vary with different markup languages. If markup is automatically generated, many authors will be unaware of the accessibility status of the final product unless they expend extra effort to make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, the onus is on the authoring tool to generate accessible markup, and where appropriate, to guide the author in producing accessible content."
"Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format, such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. These processes are usually hidden from the user's view and may create inaccessible markup or cause inaccessible markup to be produced."}
{NEW:}{EH: General suggestion. Note the reference to a benefit.}Supporting accessible authoring practices improves.... {AND SO ON. Sorry I don't have time to work more on this one.} 
=====
====
//Issue G-09: Clarify the intent of checkpoint 1.1.//
{OLD:
"<span class="checkpoint">1.1</span> Ensure the author can implement accessible authoring practices for the markup language(s) supported by the tool.[Priority 1]"}
{NEW: I found this first checkpoint unfocused. Here is my suggestion.} Ensure the authoring tool supports accessible authoring practices that are appropriate for any markup languages supported by the tool.
====
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 1.1</span></div>
====
//Issue G-10: Split priorities are confusing. Someone else noted the confusion that arises regarding these split priorities. They need to make clear whether one is referring to WCAG levels or AU levels or both. Please note that there are several instances of this problem and I am only marking one of them.//
{OLD: "Produce content that conforms to the W3C's Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2 for double-A conformance, Priority 3 for triple-A conformance] }
{NEW:}
Produce content that conforms to the W3C's Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for WAI-Web-Content-level-A conformance, Priority 2 for WAI-Web-Content-double-A conformance, Priority 3 for WAI-Web-Content-triple-A conformance]
====I
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 1.2</span></div>
<span class="checkpoint">1.3</span> Ensure that templates provided by the tool conform to W3C Web Content Accessibility Guidelines [WAI-WEBCONTENT]. [Priority 1 for level-A conformance, Priority 2 for double-A conformance, Priority 3 for triple-A conformance] 
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 1.3</span></div>
====
//Issue G-11: Refine checkpoint 1.4//
{OLD: "<span class="checkpoint">1.4</span> Preserve all accessibility information during authoring, transformations and conversions. <span class="priority1">[Priority 1]"</span> }{NOTE. Does this contradict checkpoint 4.3}
{NEW:} 1.4 Preserve all essential accessibility information during authoring, transformations and conversions. <span class="priority1">[Priority 1]</span> 
<div class="guidelines-specific"><span class="noprint"><div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 1.4</span></div>
Guideline 2. Generate standard markup
Conformance with standards promotes interoperability and accessibility. Where applicable use W3C recommendations, which have been reviewed to ensure accessibility and interoperability. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.
Checkpoints:
===
//Issue G-12: Don't capitalize "recommendations" in W3C recommendations//
{OLD: "<span class="checkpoint">2.1</span> Use applicable W3C Recommendations. <span class="priority2">[Priority 2]"}
</span> {NEW:} <span class="checkpoint">2.1</span> Use applicable W3C recommendations. <span class="priority2">[Priority 2]"
===
These specifications have undergone review specifically to ensure that they do not compromise, and where possible they enhance, accessibility
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 2.1</span></div>
<span class="checkpoint">2.2</span> Ensure that markup is generated in accordance with a published specification <span class="priority1">[Priority 1]</span> 
This is necessary for user agents to be able to transform Web content to a presentation appropriate to a particular user's needs.
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 2.2</span></div>
<span class="checkpoint">2.3</span> Ensure the tool produces markup in a language that enables accessibility <span class="priority1">[Priority 1]</span> 
===
//Issue G-13: Checkpoint 2.3 seems somewhat redundant with 1.1. Also 2.3 should be simplified.//
{OLD: "This is relevant both to the use of an existing document markup language, and to one which is created or extended for a specific purpose.."
{NEW:}This is relevant both existing and new document markup languages.
====END
<div class="guidelines-specific"><span class="noprint">Techniques for checkpoint 2.3</span></div>
Guideline 3. Ensure that no accessibility information is missing
====
//Issue G-14: Need refinement in rationale for GL3.//
{OLD:"
Generating equivalent information, such as textual alternatives for images and audio descriptions of video, can be one of the most challenging aspects of Web design. Along with the necessity for structural information it is a cornerstone of accessible design, allowing information to be presented in a way most appropriate for the needs of the user without constraining the creativity of the author.
Automating the mechanics of this process, by prompting authors to include the relevant information at appropriate times, can greatly ease the burden for authors. Where such information can be mechanically determined (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary) and offered as a choice for the author the tool will assist the author, at the same time as it reinforces the need for such information and the author's role in ensuring that it is used appropriately in each instance."}
==
{NEW:}
Generating accessible alternatives, such as alternative text for images, transcripts for audio clips, expansions for acronyms, as well as captions, collated text transcripts, and auditory descriptions for movie clips, can be one of the most challenging aspects of Web development. Automating the mechanics of this process, by prompting authors to include the relevant information at appropriate times, can greatly ease the burden for authors. Where such information can be mechanically determined (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary) and offered as a choice for the author the tool will assist the author, at the same time as it reinforces the need for such information and the author's role in ensuring that it is used appropriately in each instance.

Checkpoints:
====
//Issue G-15: Refine GL3.1//
{OLD:"
<span class="checkpoint">3.1</span> Prompt the author to provide alternative information (e.g., captions, expanded versions of acronyms, long descriptions of graphics). (Priority 1 for alternative information that is [Web-Content-Priority-1], Priority 2 for alternative information that is [Web-Content-Priority-2], Priority 3 for alternative information that is [Web-Content-Priority-3]) 
{NEW:}
<span class="checkpoint">3.1</span> Prompt the author to provide alternative information (e.g., captions, expansions of acronyms, long descriptions of graphics). (Priority 1 for alternative information that is [Web-Content-Priority-1], Priority 2 for alternative information that is [Web-Content-Priority-2], Priority 3 for alternative information that is [Web-Content-Priority-3]) 
====
<span class="checkpoint">3.2</span> Do not insert automatically generated (e.g., the filename) or place-holder (e.g., "image") equivalent text, except in cases where human-authored text has been written for an object whose function is known with certainty. <span class="priority1">[Priority 1]</span> For example, in an automatically generated navigation bar, it is clear that "search" is appropriate for a button linked to a search function 
/////Issue G-16: It seems that Priority 2 would be more appropriate for checkpoint 3.2 than Priority 1. Should the appropriate priority depend on whether the placeholder values can be recognized upon review as "errors" or gaps in accessibility?//
====
====
//Issue G-17: Fix checkpoint 7.1. Remove final reference to Priority 1.//
{OLD: "7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions which are essential to accessibility, Priority 2 for those that are important to accessibility, Priority 3 for those that are beneficial to accessibility)[Priority 1] "}
{NEW:}
7.1 Use all applicable operating system and accessibility standards and conventions [Priority 1 for standards and conventions which are essential to accessibility, Priority 2 for those that are important to accessibility, Priority 3 for those that are beneficial to accessibility]. 
====
//Issue G-18: "Terms and Definitions" should be called "Glossary" and organized alphabetically.//
====
//Issue G-19: There is a cluster of terms that seems to be defined imprecisely or are used and not defined. Among the defined terms that need refinement are: accessibility information, alternative presentations, alternative information, accessible, accessibility. Among the undefined terms are: alternative representations, equivalent information, textual alternatives, audio descriptions, should be auditory descriptions, alternative information, accessibility information, descriptive text equivalents, text equivalent, caption, auditory description, collated text transcript, transcript, refreshable braille display(?), DTD,. Having so many terms with partly (or completely) overlapping meanings causes lack of clarity and usability of the document. These meanings need to be added, if necessary, and then clarified. Whenever possible this document should use terms already defined in the WCAG document.//
====
TECHNIQUES DOC
Issue T-01. Same issues as in the Guidelines doc regarding imprecise use of some terms. (Same ones listed above.)

Received on Monday, 4 October 1999 23:58:27 UTC