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

Re: Comments on Authoring Tool Accessibility Guidelines 19991026

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 24 Nov 1999 10:27:22 -0500 (EST)
To: Greg Lowney <greglo@microsoft.com>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.20.9911241010160.1028-100000@tux.w3.org>
Hi Greg,

Thanks for your comments (and praise ;-). I have included my own responses,
marked with CMN.

On Tue, 23 Nov 1999, Greg Lowney wrote:

  Hello All, 
  Overall I want to say that I am extremely impressed with the current state
  of the guidelines document. I consider the background and explanations very
  clear, especially for their brevity, and the guidelines themselves very
  reasonable even though they represent a high standard for mainstream tools.
  I did want to give you my thoughts of five issues. None of these comments
  are show stoppers, just suggestions. Please forgive me if you've already
  discussed these issues at length or if it's too late to address them
  (1) 1.3, "Ensure that the tool generates..." This and similar phrases are
  used similar in several places. I don't feel it is made clear whether the
  authoring tool is required to support these in its default configuration, or
  whether this can be a non-default option available on demand. For example,
  if the user *can* generate content that conforms to the WAI-WEBCONTENT
  Priority 1 guidelines, but it does not happen by default, does that mean the
  authoring tool conforms to guideline 1.3? If it was extremely difficult,
  involving manually editing the HTML, does that still count, or is there some
  objective or subjective limit on the inconvenience? This same issue applies
  to several other guidelines, such as 1.2, 2.2, 4.3, etc.
If the tool generates markup that is accessible, but that is not an obvious
option, then it conforms to 1.3 but does not conform to 5.2, so it could make
level-A but not double-A.

GL(2) 4.3, "Allow the author to preserve markup not recognized by the tool",
  This is currently priority 2 but I might rate it as priority 1 given that we
  don't clearly define the minimum set of elements and attributes that we
  expect any conforming tool to recognize. This means, in theory, that a tool
  could strip out all ALT attributes and all LABEL elements and still qualify
  for A-Level conformance. In effect the current priority rating seems to
  contradict the rating on other guidelines such as 1.2 that say the tool must
  preserve all accessibility information.

This does not contradict 1.2, but strengthens it at a P2 level - not only
must the tool implement accessibility features of markup languages and
preserve them in transformations, but it should allow the author to ensure
that no changes are made by the tool to existing markup. (There is of course
the possibility that the tool will then be unable to process the document
further, in which case the author needs to decide whether to use a different
tool or let the tool change the document)
GL(3) 7.3, "Allow the author to edit all properties of each element and object
  in accessible fashion." This seems out of place to me not because it's
  unimportant, but because it is merely one example of what I see as a very
  general rule. Authors should be able to do this, and they should also be
  able to do other tasks that we might take for granted, such as being able to
  insert a new element. If the need to let authors do that in an accessible
  fashion is self-evident or implied by 7.1, then it seems that 7.3 is
  unnecessary. Conversely, if 7.3 is not implied then I expect we really
  should have a number of additional, similiar requirements. 

We discussed this in the face to face meeting to resolve last call
issues. Dick Brown expressed the same opinion, so it appears that Microsoft's
understanding here is very consistent (grin). I agree that it should be
self-evident, however the group resolved that this was a sufficiently
important requirement, and sufficiently badly done in practise, that it
should remain.
GL(4) 7.4, "Ensure the editing view allows navigation via the structure" is
  currently priority 1 but I consider it to be more of a priority 2 or 3. Some
  word processors don't provide structured navigation, and I consider that to
  reduce their usability and accessibility but not to make them inaccessible.
  In our guidelines for Windows-based applications, I would list this as
  something that is beneficial to meeting accessibility goals but is not
  critical; in other words, a recommendation rather than a requirement.

This is an issue that has been discussed several times in the last 18
months. I would be surprised if the group resolved to change it at this
GL(5) 7.1, "Use all applicable operating system and accessibility standards
  and conventions". I know there has been a lot of discussion of this, so I
  won't comment at length, but I'm curious whether the reference to operating
  system standards means, for example, that an authoring tool running on
  Windows needs to be usable with the keyboard but the same tool running on
  Macintosh does not. Or, on the other hand, does the reference to
  accessibility standards mean that a tool running on the Macintosh needs to
  provide better keyboard access than is commonly found on that platform?
Your second interpretation is correct - the MacOS standards are applicable,
so keyboard access should in the first instance be provided, but there are
accessibilty conventions such as making everything possible from the keyboard
(see for example User Agent Guidelines, EITAAC recommendations, TRACE
software guidelines) which also apply.

GL I also looked over the Techniques document briefly, but it does not seem
  nearly as polished as the Guidelines themselves. I felt it could benefit
  from clearer prioritization, pros and cons, or recommendations to help
  developers choose between the various techniques listed for each checkpoint.
  It might would also help to distinguish the bullets that suggest individual
  techniques vs. bullets that list resources vs. bullets that offer critiques
  of what specific products do today (e.g. Guideline 1.1 bullets 1-3, 4-6, and
  7-10 respectively). 

These are good suggestions. While getting the Guidelines ready there has been
relatively low input on the techniques document, although we have identified
some enhancements we would like to make. In the ongoing work of the group
revising the techniques document is a major deliverable, and I hope working
group members will be able to focus more attention on that document so we can
rapidly improve its usefulness.


Charles McCN
Received on Wednesday, 24 November 1999 10:27:25 UTC

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