- From: Bryan Campbell <bryany@pathcom.com>
- Date: Wed, 01 Dec 1999 18:27:54 -0500
- To: w3c-wai-ua@w3.org
Hello, This review deals with the usability of navigation tools & UA setup. As someone with Cerebral Palsy I've typed with a headwand for 37 years, 21 years on small computers (12 years with DOS & Windows) while watching technological developments. Use of macro programs to reduce work loads & distances traveled over the keyboard while running programs led to experience on optimizing keystroke commands. Checking key pad layout is a theme with me as I can work TV & VCR remote controls (& other devices) with my left hand if the buttons are not too small, not too far to 1 side, & have space around them (some similar spacing also makes browser keystroke commands more usable). Making keystroke commands most attractive is that keyboards are system constants which work in the absence of other technology. Which isn't to say 1 technology is inherently easier to use than another, that is determined by the nature of the controls. Computer programs have great usability only if frequently used commands are readily available without making people think about where the commands are. For the purposes of this review usability means a program can be run for hours without undue fatigue or annoyance at the command structure. For people using 1 hand, a few fingers, or a headwand's lone pointer usability means 1 or at most 2 key presses execute 1 command, avoiding 3 or 4 steps to use a menu item. The Save command is often used (in some programs) so I've always put the command sequence into a keyboard macro activated by F11 making Save a 1 key command; in current browsers F3 starts Find, a 2nd example of a 1 key command. Of course, Find itself isn't so easy to use since forming search strings entails much travel over a keyboard. For people with reduced mobility or motor control (making typing less accurate) current keyboards are a large area to cover so use of the whole thing is something to avoid (the Function keys are useful enough not to switch keyboard styles). To UAs that means some forms of Direct access wont be as beneficial as it seems at first blush. To make it more useful the Guildline should state that Direct access must load a link & move the link highlight to that link (as an option), then when users return to the page they'll be in place to key to other links. Decreasing hand travel is mentioned by Jakob Nielson on this page http://www.zdnet.com/devhead/alertbox/991114.html he cites "Fitts' law" that states short mouse moves are better than long ones as it is faster to click items that are closer to your current position. Movement is basically movement whether it is across a screen or keyboard, to me only the target type differs as one is virtual & the other physical. When specifying what is needed where needs some attention. A link from Dr. Nielson's page led to ideas that should be used as guides for placing commands & determining the usefulness of Direct access. Bruce Tognazzini on this page http://www.asktog.com/basics/firstPrinciples.html in a section titled "Efficiency of the user" explains that even making a system do extra work makes people more efficient. His point is that it is faster for a person to set a microwave oven timer for 1:11 (1 minute & 11 seconds) than for other 3 digit times since 1:11 (or 2:22) entails no finger movement & little thought about the next push. Making a microwave run a bit longer takes less time than for folks to select 3 different numbers like 1:09. For people with disabilities the ability to use one button repeatedly is much more efficient than repositioning over a 2nd button. I say repositioning because it gives a better sense of how people with reduced dexterity reach the next button or key with accuracy decreasing as the distance to subsequent keys goes up. The ease of Sequential access is underplayed in Guildline 10.3 in a manner that could lead developers not to pursue Sequential access enough to make it more effective! Direct access is appealing, but the point needn't be made at the expense of other methods. The microwave example shows that searching out a search string has its own inefficiencies. Important to note is that keyboards have dedicated Web keys to enhance the Web experience. The strength of the tend is seen in Microsoft's 2 updated keyboards with dedicated Web navigation keys: 'Microsoft Natural Keyboard Adds Web, CD Keys' page http://cgi.zdnet.com/slink?11110:803742 Microsoft Internet Keyboard page http://www.winmag.com/reviews/hardware/column/1999/1099/1029.htm PC Magazine's Jim Seymour page http://www.zdnet.com/pcmag/stories/opinions/0,7802,2385241,00.html loves the Internet Keyboard saying, "it's the first to win me over to the new dedicated-button approach to using the Internet." PC Magazine's hottest "Editor's Choice" among new PCs lists Internet keys in the first paragraph of the review page http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385263,00.html If the keyboards weren't built for 2 handed use they'd be getting my rugous tests. UA developers need to be told about ideas like well laid 1 key commands to make their programs truly usable for people with disabilities. Perhaps the most words important I've read on the UA list are from Scott Luebking <phoenixl@netcom.com> 30 Nov 1999 in "A couple of comments" page http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0479.html Suggesting how the Guildline opens Mr. Luebking says, {Quote "It probably should say that the guidelines can help avoid pitfalls, but it is quite possible to follow the guidelines and still end up with an inaccessible user agent." Unquote} Accessibility doesn't often equal usability. An example of that is mainstreams UA using Tab, Shift-Tab, & Enter as the primary navigation keys. That arrangement is very difficult to run because Tab is a vast distance away from Enter while Shift-Tab employs 2 key pushes (which often becomes 4 keystrokes for people who are unsteady) to move back one link. That contrasts the highly usable 4 year old standard for keystroke browsing set by NCSA Mosaic & Opera. The hardware trend clearly endorses dedicated Web keys as have been available in software for many years so by making 1 key browsing commands a Priority 1 the UA Group will merely extend the trend to the folks that can most use it! The priority is only for main UAs. Gregory J. Rosmaita <unagi69@concentric.net> in a note to the UA Group at page http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0268.html says that in many programs the Accessibility 'bar' is very low & that this Guildline must bring the 'bar' to a reasonable height. Part of raising the 'bar' will only be fulfilled by stating the importance of 1 key browser commands using the main alphanumeric character area of keyboards. The software keyboard Mouse, "Mouse Keys", is a prime example of hugely changing the regular interface without bothering regular users. Such options should be very easy to turn On & then Off so that worries about 'interface inconsistency' for regular users needlessly leads to Accessibility features that are difficult to use. To avoid that people with disabilities should be involved in program design as Mr. Luebking mentioned his note (2nd link up). Yet I can see practical difficulties in making that happen so input for efforts like this Guildline must gleaned on indirectly created whenever possible. For keyboard issues I can help; & point to Bill McMurray's <billmcm@earthlink.net> home page http://home.earthlink.net/~billmcm/ remarks about Opera to give more insight into 1 keystroke browser commands. More generally the AT professionals on W3C WAI lists should give approximations of how people with various disabilities run computers so developers can work from rough compasses. To illustrate here is a way to approximate a lack of motor control: Put the keyboard Repeat Delay to very short & Repeat rate to very fast (or whatever rate is bothersome) when the slightest touch or accidental bump generates a key press typing is wholly different & key combinations become a huge challenge to say the least. We'd do well to try such experiments before writing Guildlines. Most importantly such tests would allow creation of input layouts so developers & users wouldn't have to continually reinvent the wheel. Guildline 10.3 says users should control input which would likely be a complex task for most folks. With the proper information to use Guildline 10.3 could say provide a selections users to choose from, that will likely be easier for programmers to do than for UAs to have what amounts to miniature keyboard macro programs. Guildline 4 should do the same for CSS. Besides getting folks off to quick starts developers will receive less questions about how to configure UAs. As for Speech Recognition a new PC Magazine review says it succinctly on this page http://www.zdnet.com/pcmag/stories/reviews/0,6755,2385295,00.html Speech Recognition works well if you have the equipment {Quote "and the ability to speak clearly at all times" Unquote} which isn't promising for people with physical disabilities. In preparing for the future we mustn't overlook what now & for the mid-term. On a specific Guildline 7 talks of *tabbing* in regard to Sequential access: that should be changed to keying through because using the word Tab implies uses of the Tab key itself which is too far away from other Page movement keys. Indeed, all browser commands should be near the Cursor-Pad area where Page Up & Down etc. are to reduce traverses across the keyboard. Regards, Bryan Campbell --> "Just because we call it the Web does not mean it should tangle people up!"
Received on Wednesday, 1 December 1999 18:29:16 UTC