- From: John Gardner <john.gardner@orst.edu>
- Date: Sun, 28 Nov 1999 15:00:57 -0800
- To: w3c-wai-ua@w3.org
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