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

Comments on Authoring Tool Accessibility Guidelines 19991026

From: Greg Lowney <greglo@microsoft.com>
Date: Tue, 23 Nov 1999 23:00:44 -0800
Message-ID: <3D2036E25376D31197A100805FEAD89203771160@RED-MSG-02>
To: w3c-wai-au@w3.org
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.

(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.

(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. 

(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.

(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?

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). 

	Greg Lowney
Received on Wednesday, 24 November 1999 02:01:19 UTC

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