W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 1999

Re: More Changes

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 27 Oct 1999 19:45:50 -0400 (EDT)
To: eric hansen <ehansen@ets.org>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.20.9910271933230.23920-100000@tux.w3.org>
Eric,

thanks again for your comments. I hope you find the way we have incorporated
them appropriate. With regard to the definitions of transcripts and captions
We have in fact separated them into distinct definitions.

Charles McCN

On Fri, 22 Oct 1999, eric hansen wrote:

  More Changes
  
  Most of the following suggestions attempt to reinforce more precise word 
  usage per my earlier memos.
  
  http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0084.html
  http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0043.html
  
  
  #1. The definition of "accessible" is circular. The word "accessible" 
  should not be used in the definition of "accessible".
  
  Current AU 1.0 - 10/22/99:
  "Accessible, Accessibility" 
  "Within these guidelines, Accessible and Accessibility are used in the 
  sense of being accessible to people regardless of disability."
  
  Note that WCAG 1.0 does not do this. It says.
  "Accessible Content is accessible when it may be used by someone with a 
  disability. 
  
  There is my proposed revision.
  
  "Accessible, Accessibility"
  "Something is considered accessible if it is usable by people with 
  disabilities."
  ====
  #2. Avoid unecessary capitalization in the Terms and Definitions. There is 
  no need to capitalize them. If is essential to emphasize the words, they 
  could be put in quotes or other formatting.
  
  Current AU 1.0 - 10/22/99:
  "These terms refer to Authoring practices that improve the accessibility of 
  content generated by the tool."
  
  Proposed:
  "These terms refer to authoring practices that improve the accessibility of 
  content generated by the tool."
  
  Please check for other instances of this problem within the AU document.
  ====
  #3. Delete separate definition of "Transcripts". The current definition is 
  problematic. It is not clear what "line by line" refers to -- the written 
  text or the "dialog" or the "action". This definition also muddies rather 
  than reinforces the existing definitions of "text transcript" and "collated 
  text transcript." The definition of Alternative Information already 
  includes definitions of the relevant terms.
  
  "Transcripts" 
  "A transcript is a line by line record of all dialog and action within a 
  video or audio clip."
  ====
  #4 Delete separate definition of "Video Captions". There are several 
  problems with this current definition. The term "video captions" is 
  extremely likely to be confused with the term "video description" or 
  "descriptive video" which is WGBH/NCAM's name for auditory description. The 
  definition for "caption" that is already in the newly revised definition of 
  Alternative Information. If the editors feel that a separate definition is 
  essential, then it should be labeled simply "Captions" rather than "Video 
  Captions." 
  
  Current AU 1.0 - 10/22/99:
  "Video Captions"
  "Captions are essential text equivalents for movie audio. Captions consist 
  of a text transcript of the audio track of the movie (or other video 
  presentation) that is synchronized with the video and audio tracks. 
  Captions are generally rendered visually and benefit people who can see but 
  are deaf, hard-of-hearing, or cannot hear the audio."
  ====
  #5. Correct and add specificity to the example for checkpoint 3.3. The 
  correction is the elimination of the term "video captions" per change #4. I 
  think it makes sense to specific and precise about what is required for 
  movies. 
  
  Current AU 1.0 - 10/22/99:
  "3.3 Ensure that prepackaged content conforms to [WAI-WEBCONTENT]. 
  [Relative Priority] "
  "For example include synchronized text and audio equivalents (such as video 
  captions) with movies. Refer also to checkpoint 3.4."
  
  Proposed:
  "3.3 Ensure that prepackaged content conforms to [WAI-WEBCONTENT]. 
  [Relative Priority] "
  "For example, for movies include captions, auditory descriptions, and 
  collated text transcripts. Refer also to checkpoint 3.4."
  
  Obviously, a link to the definitions of those terms would be appropriate.
  ===
  #6. Refine wording in intro to guideline 3. Note that I recommend sticking 
  with the term "auditory description" rather than "audio description". There 
  are also a lot of other changes.
  
  Current AU 1.0 - 10/22/99:
  "Guideline 3. Support the creation of accessible content"
  "Well structured information, and equivalent alternative information are 
  cornerstones 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. 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. 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 and offered as a choice for the 
  author (e.g., the function of icons in an automatically-generated 
  navigation bar, or expansion of acronyms from a dictionary) the tool will 
  assist the author. At the same time it can reinforce the need for such 
  information and the author's role in ensuring that it is used appropriately 
  in each instance."
  
  Proposed:
  "Guideline 3. Support the creation of accessible content"
  "Providing well-structured content, including equivalent alternative 
  information, is a cornerstone of accessible design, allowing information to 
  be presented in a way most appropriate for the needs of the user with the 
  least amount of additional effort on the part of the author. Yet providing 
  such information can be demanding of an author and authoring tool 
  developers should attempt to automate and facilitate these processes. For 
  example, prompting authors to include the relevant alternative information, 
  such as textual alternatives for images, text transcripts for audio clips, 
  captions, auditory descriptions, and collated text transcripts for movies, 
  and expansions of acronyms or abbreviations, can greatly ease the burden 
  for authors. Where such information can be mechanically determined and 
  offered as a choice for the author (e.g., the function of icons in an 
  automatically-generated navigation bar, or expansion of acronyms from a 
  dictionary) the tool will assist the author. At the same time it can 
  reinforce the need for such information and the author's role in ensuring 
  that it is used appropriately in each instance."
  
  ====
  #7. Revise the wording of checkpoint 3.1 to be more specific.
  
  Current AU 1.0 - 10/22/99:
  "3.1 Prompt the author to provide equivalent alternative information (e.g., 
  captions, long descriptions of graphics). [Relative Priority] "
  
  Proposed:
  "3.1 Prompt the author to provide equivalent alternative information (e.g., 
  textual alternatives for images, text transcripts for audio clips, captions,
   auditory descriptions, and collated text transcripts for movies, and 
  expansions of acronyms or abbreviations). [Relative Priority] "
  Note that there are several other entities not mentioned (frames, tables, 
  objects, etc.) but I think that this is probably enough.
  ====
  #8. Revise the introduction to guideline 1. Remove the word "onus" because 
  it carries such a negative connotation ("onerus burden"). The changes also 
  attempt to tighten the prose, such as by leading off with a sentence that 
  reinforces the guideline statement.
  
  Current AU 1.0 - 10/22/99:
  
  "Guideline 1. Support accessible authoring practices"
  "If the tool automatically generates markup, many authors will be unaware 
  of the accessibility status of the final content 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 specifically intended 
  for the Web such as HTML. Markup changes may also be made to facilitate 
  efficient editing and manipulation. It is essential that these processes do 
  not introduce inaccessible markup, or remove accessibility content, 
  particularly since the markup changes are hidden from the author's view in 
  many tools."
  
  Proposed:
  "Guideline 1. Support accessible authoring practices"
  "Authoring tools should make it as easy as possible to generate accessible 
  content." [OR] "Authoring should tools support, facilitate, and encourage 
  the generation of accessible content." "Authoring tools can do this by 
  automatically generating accessible markup and, where appropriate, guiding 
  the author in producing accessible content. Because authoring tools 
  frequently transform data from one data format to another, its is essential 
  that these transformations neither remove accessibility content nor 
  introduce inaccessible content."
  
  #9. Check for places where there are two periods, "..". Minor typo should 
  be corrected.
  
  =============================
  Eric G. Hansen, Ph.D.
  Development Scientist
  Educational Testing Service
  ETS 12-R
  Rosedale Road
  Princeton, NJ 08541
  (W) 609-734-5615
  (Fax) 609-734-1090
  E-mail: ehansen@ets.org 
  

--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 Wednesday, 27 October 1999 19:45:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC