Review of UA Last Call Document

Sorry about being tardy with my review.  I was traveling for most of the
review period.  I have a few comments to add to the extensive on-list
discussions by other reviewers and the members of the UA working group.  I
have only skimmed many of these an apologize if I plow some of the ground
again.

Comment 1. Word usage.  
1a. There is no definite "right" answer to whether braille is capitalized.
My strong preference is simplicity, so I do not capitalize it.
1b. Braille is a representation of text that depends on the language being
represented.  It is certainly not a natural language.
1c. Braille is tactile, not haptic.  
1d. My preference on politically correct language is to avoid offending
people unnecessarily but to keep it simple.  I personally prefer to be
called a blind person than a person with blindness or a person who is
visually challenged.  The terms physical disability, visual disability,
hearing disability, and cognitive disability  are common well-understood
relatively inoffensive terms.  I suggest that this document not split hairs
over technical correctness of terminology or use ridiculously contorted
language.

Comment 2. The Committee question about Checkpoints 10.1 and 10.2.  My
initial reaction to these checkpoints is that they don't really make much
sense.  Perhaps they would if I had followed the discussion that led to
them, but I didn't, and most readers of the guidelines will be similarly
unenlightened.  10.1 gives priority 1 to provision of access to user-set
input configurations whereas 10.2 gives priority 2 access to author-set
configurations.  10.1 is apparently targeted toward specialty browsers,
screen readers, etc. whereas 10.2 must be taken into account by all user
agents that do not also control content input.  10.1 seems so unnecessary
as to be frivolous (i.e. we don't find it necessary to require a visual
browser to support the video monitor).  On the other hand, an author might
specify an access key that is critical to access, and it is critical that I
know what it is.  Frankly I am unfamiliar with the use of this authoring
technique and couldn't imagine an author specifying input configurations
without telling the reader, so I would think this is more of a authoring
issue than a UA issue.  Without some enlightenment as to what alligator I
am overlooking, my recommendation is to put these into a single checkpoint
and make it priority 2.  It certainly doesn't make sense to make 10.1
priority 1 and 10.3 priority 2, does it?  

On the subject of 10.3,  I strongly urge that the single-controls be
user-selectable.  Chills run down my spine when I think of trying to use a
user agent with a zillion dedicated keystroke and/or voice commands that
are hard-wired into the application.  Add the sentence "The controls must
be user-selectable."

Comment 3. The committee question about checkpoint 6.1.
I do not really understand "relative priority".  I do understand that in
certain circumstances both authors and user agents must violate a
checkpoint in order to provide excellent access.  This is inevitable,
because no set of rules can cover all situations even if the authors of
these guidelines had crystal balls.  However my strong preference would not
be for a nebulous concept like "relative priority" but for a simple
acknowledgement (as suggested by Eric Hansen at the end of his review) that
there are circumstances where WAI rules cannot fully apply.  

That's a long-winded way of saying 6.1 is fine as written.

Comment 4. I am confused about the applicability of many checkpoints to
specific applications.  For example, checkpoints 7.1-7.3 are (I believe)
clearly inapplicable to Netscape, IE, and other general purpose visual
browsers.  So they do not enter into their ratings.  I believe that 7.6-7.8
are applicable, but I can also understand how a software engineer might
conclude that they are not.  (If the search, etc. functionality is not
available to any user then it is just as accessible to people with and
without disabilities and therefore within the stated UA guidelines, right?)
 This kind of confusion may be inevitable for "one size fits all"
guidelines.  At one time some checkpoints noted that they were specifically
applicable to dependent user agents, but that language has apparently been
dropped.  The result may be that the guidelines are more elegant, but they
are also less clear to me.

Comment 5.  It is not at all clear to me that it is necessary to satisfy
each checkpoint in order for a user agent to provide excellent usability to
people with disabilities.  For example, guideline 5 and most of its
checkpoints could probably be violated by an audio-visual browser that
could nonetheless be more usable than most that meet each checkpoint.  In
fact I strongly suspect that it might be actually _NECESSARY_ to violate
some checkpoints to make an excellent universally usable web agent.  These
guidelines should certainly not have the effect of preventing development
of innovative universally accessible user agents.

Therefore I propose that the qualification for a AAA rating be expanded.  A
user agent that meets all functionality described in the guidelines but,
for whatever reason does not fulfill each checkpoint, should be eligible
for a AAA rating.  This flexibility is crucial, since it seems all but
inevitable that WAI guidelines will become law for state and federal
agencies.  If so then mindless bureaucrats can (and almost certainly will)
use an application's WAI rating as a purchasing yardstick.   

John A. Gardner
Professor and Director, Science Access Project
Department of Physics
Oregon State University
tel: (541) 737 3278
SAP URL http://dots.physics.orst.edu/

Received on Sunday, 28 November 1999 17:58:43 UTC