Re: Suggestions

Eric,

thank you for your review. I have included some issues and responses here -
others will be answered during the working group's meeting or after it.

Cheers
Charles McCN

Eric's suggestions marked eric, My repsonses with CMN

On Tue, 5 Oct 1999, eric hansen wrote:

  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:

CMN This seems like a good editorial amendment.

  //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 accessible."}

  {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.}

CMN I would subsititue must for should in your proposed amendments and leave
the last sentence in, but again this seems like a good suggestion.

  //Issue G-03: Refine the definitions of guidelines and checkpoints.//
(CMN minor editorial comment)

eric
  //Issue G-04: Clarify discussion of techniques.//

CMN There is some redundancy in the explanation of the techniques document
and what it is for. However experience has shown that most users of the Web
Content Accessibility Guidelines do not realise there is a techniques
document, and the redundancy seems like a small price to pay.

eric
  //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.}
CMN This represents reopening a question that has been discussed through the
life of the group, although it seems like a fairly small editorial issue. I
will discuss this with the other editors again.
eric
  //Issue G-06: Simplify definition of priorities.//
(CMN minor editorial amendment)  

eric
  //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.}
CMN The conformance claims are not made by pages, but on behalf of a piece of
software.

eric
  //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.//
CMN This is a good general suggestion. The editors will look at improving the
consistency of the rationales.

eric
  //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.//
CMN already noted (as you point out)
eric
  //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}

CMN Issue noted.
eric
  //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.
CMN This is not necessarily redundant, although there is some overlap. I like
the suggested amendment.
eric
  //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.
CMN seems like a good suggestion to me.

eric  
  //Issue G-15: Refine GL3.1//
CMN minor editorial

eric
  /////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?//
CMN referred to the working group
eric
  //Issue G-17: Fix checkpoint 7.1. Remove final reference to Priority 1.//
CMN noted already
eric
  //Issue G-18: "Terms and Definitions" should be called "Glossary" and
  organized alphabetically.//
CMN Agreed. This has been noted already

eric
  //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.//
  
CMN Agreed.  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Tuesday, 5 October 1999 00:57:47 UTC