re:thoughts, suggestions, comments for UA Guidelines ?

hi Jon et. al.

As part of some other work I'm doing, I recently had a few moments to review the UA guidelines at:

http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19980814

and I had some thoughts, suggestions, comments.  Please let me know if any of this doesn't make sense or needs further explanation.  I hope I'm also looking at the latest release...

Mark Novak

==

In section 4.6, alternative representation of tables, under #2, the serialization of tables, the second example which shows a table serialized on "column order".  Shouldn't the order be reversed with the "E" and "B" 's?  In other words, shouldn't the order be "A,D,B,E,C,F"?


In section 5.3, element and event notification, #1, I'd suggest that instead of saying "provide a mechanism for assistive technologies to identify which....", to something more like, "provide a mechanism for technologies other than the user agent (e.g., scripting tools, automated test engines, assistive technologies, etc. ) to identify which.....".  In other words, lots of other technologies could make use of this information, not just assistive technologies, so why limit the scope?  Further, later on in #1, I'd suggest changing the "DHTML events through accessibility APIs" to just "DHTML events through APIs" .  Again, why limit the use or give readers the impression that these changes are only for assistive technologies, or that you need to make special changes for assistive technologies.


In section 6.4, direct access navigation, #1, I could argue both ways that if a search finds the text of interest, that the agent ought to have the capability to move the focus to "said" text, whether or not the text occurs in a link.  For example, if the user was searching for text in a particular "header", why couldn't they be allowed to move focus to that header.  Likewise, what about a particular form entry?  Just a thought.


In section 8.3, compatibility with third-party assistive technology, under built-in accessibility options, I'd suggest changing the word "filter keys" to a specific feature (e.g., MouseKeys), or remove it all together in the context it is being used.  FilterKeys is the "term" Microsoft has chosen to use to describe the collective group of "SlowKeys, RepeatKeys and BounceKeys".  FilterKeys itself, is not a feature, and thus when used in the sentence as you have it, with several other features can be confusing.


In section 9, built in accessibility features of some current operating systems, under 9.1, 9.2, and 9.3, there are some errors (e.g., ToggleKeys does not use the modifier keys) and omissions (e.g., Sticky Keys in the Apple Macintosh has four modifier keys), and the differing descriptions for similar features I also think is a problem.  Please note, these comments might seem "nit-picking" fine points, but because I'm assuming this document is for review, in a large part by people outside the rehabilitation field, I think it is very important for those of us in the field to use consistent terminology.  That is why I think the features listed in sections 9.1, 9.2, and 9.3 should have as similar a description as possible (with in the scope of each OS).  If people are in agreement, I'd be happy to take a first pass at this task.

Received on Tuesday, 13 October 1998 18:35:29 UTC