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

Re: Last Call for Authoring Tool Accessibility Guidelines

From: Charles McCathieNevile <charles@w3.org>
Date: Sun, 3 Oct 1999 23:43:44 -0400 (EDT)
To: Edna French <ednafrench@home.com>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.10.9910032341460.28671-100000@tux.w3.org>
Edna, thank you for your comments.

Those which are editorial in nature will probably be addressed by the
editors, and the rest will be on the agenda for the forthcoming face to face
meeting of the group.

Cheers

Charles McCathieNevile

On Sun, 3 Oct 1999, Edna French wrote:

  October 3, 1999
  
  Comments on the "Authoring Tool Accessibility Guidelines" to:
  
  Charles McCathieNevile (W3C Staff contact) and
  Jutta Treviranus (chair)
  for the Authoring Tool Guidelines Working Group
  
  Note to Archives:  These are my final comments.  Please disregard comments
  received from me prior to this date.
  
  Thank you,
  Edna H. French
  
  The Authoring Tool Accessibility Guidelines and the accompanying Techniques
  document are very impressive and show the immense amount of work and
  thinking that the group has done to evolve and communicate its ideas.  My
  comments in no way denigrate these documents and are intended only to be the
  observances of a new reader, and one who is new to writing for the Web.
  
  I do, however,  have a background in reviewing this kind of document.  For
  three years I managed the General Aviation Regulations Branch of the Federal
  Aviation Administration (FAA).  The branch produced pilot regulations,
  exemptions,
  and denials to petitions for exemption.  During that time and in subsequent
  years I wrote and reviewed many policy documents, and conducted policy
  presentations to upper management including the Secretary of Transportation.
  Now that I no longer work for the FAA, I'm taking Kynn's course "Designing
  for Universal Accessibility."   I'm sure that you will detect that influence
  in my comments.
  
  
  **A.  Both The Authoring Tools Accessibility Guidelines and the related
  Techniques Document should be written to conform to the Web Contents
  Accessibility Guidelines.  The following are suggestions; the checkpoints
  referenced come from the Web Contents Accessibility Guidelines:**
  
      1.    Regarding the Table of Contents, which is a list of links:
  Checkpoint 13.6 - Group related links, identify the group (for user agents),
  and, until user agents do so, provide a way to bypass the group. [Priority
  3]
  
      2.  It would be very helpful to provide links to the Top of the Document
  and to the Table of Contents between each section of the document:
  Checkpoint - 13.5 Provide navigation bars to highlight and give access to
  the navigation mechanism. [Priority 3]
  
      3.  Tabbing through the document takes the reader only to links.  This
  is disorienting to the reader.   It would be helpful to have TABINDEX used
  in the links and at the elements listed in the Table of Contents, so the
  reader could tab through the document in a logical fashion. Checkpoint - 9.2
  Ensure that any element that has its own interface can be operated in a
  device-independent manner. [Priority 2].  Providing better internal
  navigation would also bring this Techniques Document into conformance with
  its own Checkpoint 7.5, bullet two, "To minimally satisfy this checkpoint,
  allow navigation from element to element."
  
      4.  After using the keyboard to access a given Technique, there is no
  keyboard way to return to the Authoring Tools Accessibility Guidelines other
  than that provided by the browser.  - Checkpoint 9.2 Ensure that any element
  that has its own interface can be operated in a device-independent manner.
  [Priority 2]
  
      5.  A mouse click on an item listed in the Table of Contents takes the
  reader to the proper section of the document, as does using the "enter" key.
  However, there is no keyboard way provided to return to the Table of
  Contents.  Checkpoint - 9.2 Ensure that any element that has its own
  interface can be operated in a device-independent manner.
  [Priority 2]
  
      6.  The ACRONYM tag could be very effective in educating readers who are
  new to web design to the meaning of the technical shorthand that can act as
  a barrier to inclusion.  Surely acceptance is part of accessibility.
  
  
  
  **B.  I have reviewed both the Authoring Tools Accessibility Guidelines and
  the associated Techniques.  Following are the comments pertinent to both
  documents.**
  
      1.  In the Abstract and Introduction sections, it would be very helpful
  to have specific words and phrases linked to a definitions section or page
  as is done in the Web Content Accessibility Guidelines.
  
      2.    The last paragraph of the Abstract states, "This document is part
  of a series of accessibility documents published by the W3C Web
  Accessibility Initiative."  I believe that it would help the reader of this
  document understand its context if a brief description of the Web Contents
  Accessibility Guidelines and the User Agent Accessibility Guidelines were
  included at this point.  This would also provide a place to link to a more
  detailed definition of these terms, which are frequently used later on in
  this document.  (See also comment B.1 above.)
  
      3.  Wherever the term  [Priority 1] is used by itself it is colored red
  which makes it stand out for those people who can see the color red.  This
  could be a problem for those with red/green color blindness or for those not
  using style sheets.  However, since the Priorities are always enclosed in
  square brackets, this should meet the Web Content Accessibility Guidelines.
  However, to be consistent, when [Priority 1] is used together with other
  Priorities, as in [Priority 1 for level-A conformance, Priority 2 for
  double-A conformance, Priority 3 for triple-A conformance], it would be
  helpful for it still to be colored red.  The red color alone is insufficient
  to show the importance of this Priority to all readers.
  
      4.  For clarity and consistency in structure, it would be helpful for
  each checkpoint to present the checkpoint number and statement as is
  currently done.  Then under the statement, indented, should be (as needed)
  first the [Priority], then each "bullet",  "note", "other information" and
  "Technique(s)."  Each bullet should begin with an active verb to emphasize
  its importance, while the other information need not.  This kind of written
  structure would meet the intent of Checkpoint - 14.3 (in the Web Contents
  Accessibility Guidelines) Create a style of presentation that is consistent
  across pages. [Priority 3] Note: This is only a suggested style.  The
  important thing is to establish a consistent style of presentation.
  
      For example:
  
          Checkpoint 1.xx   Ensure that ....etc.
                  [Priority 1]
                  *    bullet (begin with active verb)...
                  *    Note:...
                  *    Refer to: ...
                  *    Techniques: ...
  
  
  
  
  **C.  Following are comments pertinent to the Authoring Tool Accessibility
  Guidelines:**
  
  
      1.  The fourth paragraph of the Introduction begins with this sentence,
  "A separate document, entitled Techniques for Authoring Tool Accessibility
  [WAI-AUTOOLS-TECH], provides suggestions and examples of how each checkpoint
  might be satisfied, "  First, I note that the sentence ends with a comma
  (apologies to the proof-readers).
      Secondly, there seem to be some broken or misdirected links.  The link
  [WAI-AUTOOL-TECH] in this paragraph (in first document) takes you to another
  link labeled CONTENTS at the bottom of what is purportedly the Techniques
  Document (second document).  Following that link does not take you to the
  contents section of the document that you are in as you might expect, but
  instead returns you to the contents section of the first document.
      What is worse, the second document  appears to have the same content as
  the Authoring Tool Accessibility Guidelines, but with a different URL.
      The Authoring Tool Accessibility Guidelines (first document) is located
  at www.w3.org/TR/WAI-AUTOOLS.  The second document (accessed by following
  the link in the fourth paragraph of the Introduction of the first document)
  takes you to the URL: www.w3.org/TR/WAI-AUTOOLS/#ref-WAI-AUTOOLS-TECH.  Both
  documents are titled, "Authoring Tool Accessibility Guidelines 1.0 (working
  draft) W3C Working Draft 3 September 1999."
      I'm still trying to find the Techniques Document.
  .    If you cursor down to Checkpoint 1.1 and double-click on "Techniques
  for Checkpoint 1.1", you access a detailed document with the
  URL: www.w3.org/TR/1999/WAI-AUTOOLS-TECHS/#check-support-access-features.
  This document is titled, "Techniques for Authoring Tool Accessibility W3C
  Working Draft 3 September 1999."
      There is another link to the Techniques Document in the References
  Section.  This link is:  http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS/
      However, that provided in the 3 September, 1999, e-mail from Charles
  McCathieNevile (W3C Staff contact) and Jutta Treviranus (chair) for the
  Authoring Tool Guidelines Working Group is:
  http://www.w3.org/TR/WAI-AUTOOLS-TECHS.
      Aha, I believe that I have finally located the ubiquitous Techniques
  Document.  Later in this message, my comments on the Techniques Document
  will refer to this final URL (http://www.w3.org/TR/WAI-AUTOOLS-TECHS) .
      If this sounds confusing, it is.  I did not intentionally check other
  links within the document.
  
      2.  Checkpoint 2.2 introduces the term,  "user-agent".  As far as I can
  determine this term is not defined anywhere in the document.  Since it is so
  important to the series of accessibility documents published by the W3C Web
  Accessibility Initiative, I believe that it should be defined in the
  Abstract or Introduction.
  
      3.  Guideline 3, second paragraph, second sentence could have a stronger
  impact if divided into two sentences.  Suggest:  "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 it will reinforce the need for such
  information and the author's role in ensuring that it is used appropriately
  in each instance."
  
      4.  Guideline 4, first paragraph states, "To ensure accessibility,
  authoring tools must be designed so that they may automatically identify
  inaccessible markup, and enable its correction even when the markup itself
  is hidden from the author."  In this sentence, the words, "must", and "may"
  contradict each other.  I believe that the intent of the guideline would
  best be served by deleting the word, "may."
  
      5.  Guideline 7 - I do not know if  the word, "user", used twice in the
  first sentence, refers to "author" or "user-agent".  Other places within
  this document clearly refer to "author" or "browser".  As mentioned above,
  the term "user-agent" is not defined.  I confess that I simply do not
  understand the first paragraph, despite
  repeated reading.  On the other hand, the second and third paragraphs convey
  both pertinent information and well-reasoned considerations.
  
      6.  In the Terms and Definitions section, under "Rendered Content", the
  word "user agent" is used again without definition or reference to the User
  Agent Accessibility Guidelines.  Am I simply standing on a soapbox?  I truly
  believe that consistency in the use of terms improves comprehension of the
  document's contents.
  
      7.  The definitions would be more "accessible" if they were in
  alphabetical order.
  
  
  *D.  Following are comments pertinent to the Techniques Document:
  (http://www.w3.org/TR/WAI-AUTOOLS-TECHS/)*
  
      1.  The Introduction states clearly and compassionately the imperatives
  behind the Web Accessibility Initiative.  The link to the Authoring Tool
  Accessibility Guidelines, however, takes you to the bottom of the document
  which both links and refers you to the (almost a last call) version.  I did
  not check other links in the document.
  
      2.  I particularly like the second bullet in Checkpoint 1.1, because I
  believe it is important that the software not "get in the way" of hands-on
  editing.
  
      3.  I think it would be clearer if the last four bullets were presented
  as suggested the Item B.4 above.
  
      4.  In the fourth bullet of Checkpoint 1.1, there is no link to the
  HTML4.0 specification, although it appears that one is intended.
  
      5.  Checkpoint 2.2 introduces the very important term, "user-agent",
  without prior definition, reference to the User Agent Accessibility
  Guidelines, or definition anywhere in the document that I can find.
  
      6.  Guideline 3, second paragraph could be revised as mentioned in Item
  C.3 above.
  
      7.  Checkpoint 3.2 implies that automatically generated text may be
  inserted when "For example, in an automatically generated navigation bar, it
  is clear that "search" is appropriate for a button linked to a search
  function."  At times, the author may want the search button to state
  something other than the word, "search".  Perhaps the Authoring Tool should
  prompt the author instead of handling this automatically.  Or perhaps I
  don't understand the "Technique" prompt.
  
      8.  I believe that Checkpoint 3.3 would have more impact if written,
  "Including pre-written descriptions for all multimedia files (e.g.,
  clip-art) packaged with the tool would save authors time and effort, provide
  them with convenient models to emulate when they write their own
  descriptions, and illustrate the importance of description writing.   It
  would also increase the number of professionally written descriptions
  circulating on the Web."
  
      9.  Checkpoint 3.4 uses the acronym, "ACM", without any explanation or
  expansion.
  
      10.  Guideline 4, first paragraph states, "To ensure accessibility,
  authoring tools must be designed so that they may automatically identify
  inaccessible markup, and enable its correction even when the markup itself
  is hidden from the author."  In this sentence, the words, "must", and "may"
  contradict each other.  I believe that the intent of the guideline would
  best be served by deleting the word, "may."
  
      11.  Checkpoint 4.2, third bullet, the word "an" is misspelled, "na".
  
      12.  Guideline 4, Techniques - I wonder if it would be appropriate to
  remind the developers of Authoring Tools that some of their users will be
  using assistive technology themselves.  Some "prompt" and "alert" examples
  appropriate for the Authors described in the Introduction Section should be
  included.  Some of the examples described here may not be sufficient by
  themselves.
  
      13.  The first two bullets in Checkpoint 5.1 in effect state that if the
  Authoring Tool was originally inaccessible to Authors with Disabilities,
  then after integrating the accessibility solutions into the overall "look
  and feel", the tool would remain inaccessible.  This would negate the intent
  of Guideline 7, "Ensure that the Authoring Tool is Accessible to Authors
  with Disabilities."
  
      14.  Checkpoint 6.1, bullet two does not have a link to
  [WAI-WEBCONTENT], although it appears as though one is intended.
  
      15.  The link [WAI-AUTOOLS] in Checkpoint 6.2, bullet four takes you to
  the bottom of the page and that referenced link takes you to the (almost a
  Last Call) version.
  
      16.  In Checkpoint 6.4, do you mean non-deprecated or deprecated?
  
      17.  Checkpoint 7.1 lists two sets of priorities, i.e., "(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]."  The first set is in
  parentheses and black in color, while the Priority 1 is in square brackets
  and red in color.  I find this somewhat confusing (and would find it more so
  if I were colorblind).   What level of Priority does this Checkpoint have?
  If Checkpoint 7.1 is Priority 1, and the standards and conventions have
  their own levels of importance, perhaps it would be better to retain the use
  of the word, "Priority" only for the Checkpoint itself, and use a different
  word for the standards and conventions.  On the other hand, perhaps the
  phrase, "(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)", should be
  deleted or moved to an informational bullet.
  
      18.  Checkpoint 7.1, bullet 4 uses the term, "User interfaces."  Perhaps
  this term is self-evident, but then again perhaps it could be confused with
  Author interfaces or User Agent interfaces.
  
      19.  Checkpoint 7.1, "Following Standards", bullets two and four use the
  acronym "API" without defining or expanding it.  It is also used in "User
  Focus", bullet one.
  
      20.  Checkpoint 7.2, bullet two states, "Allow the user to create audio
  style sheets using a visual representation rather than an audio one ..."
  Would it be helpful to rephrase this to state, "Allow the user to create
  audio style sheets using a visual representation and/or an audio one..."?
  
      21.  In the Appendix - Sample Implementations, each platform illustrates
  one or more Techniques for Checkpoints.  The Checkpoints seem to be listed
  in random order rather than in numerical order.
  
      22.  The section on Terms and Definitions has this caveat, "[Editors'
  note: This section will be reviewed by the group, and is expected to be
  updated in future drafts]."   Should this be deleted before the "Last Call"
  becomes a "Proposed Recommendation"?
  
      23.  The definition of Publishing Tool states, "A tool that allows
  content to be uploaded in an integrated fashion. Sometimes these tools makes
  changes such as local hyper-reference modifications..."  The word *makes*
  should be changed to *make*.
  
      24.  In several Checkpoints, the *information* is not clearly separated
  from the *recommended techniques*.  For example, in Checkpoint 3.3, the
  first four bullets are techniques, while the introductory Note and the last
  two bullets are information.   Another example is found in Checkpoint 4.1.
  The last  two bullets are information, but are not labeled as such to
  distinguish them from techniques.  In Checkpoint 4.3, a similar thing
  happens in that the Notes/information come *before* the techniques.  Other
  Checkpoints are arranged in similar haphazard fashion.
      I suggest that  for consistency and clarity, the bulleted techniques
  come first, each beginning with an active verb.  Then the notes,
  information, etc., could follow in a fashion similar to that outlined in
  Item B.4 above.
  
  
  
  I appreciate the opportunity to comment on these documents.
  
  Sincerely,
  
  Edna French
  ednafrench@home.com
  
  
  
  
  
  

--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 Sunday, 3 October 1999 23:44:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:22 UTC