That quote comes from a new Nielsen Norman Group (aka Jakob Nielsen and Don Norman) study of the usability of many websites for disabled and non-disabled users in the U.S. and Japan (PDF).Â The report also includes 75 design tips for improving usability for the disabled.
A Google video about MobileQWERTYâ„¢Â shows how a 3×3 button layout using letter assignments different than the usual abc, def pattern can provide lots of benefits. For example, the speaker says that an average of 2.14 key presses is needed to type each letter of a typical message using an abc layout on a standard phone, but MobileQWERTY’s layout reduces the average to 1.35 key presses.Â That’s 35% more than a full QWERTY keyboard but the abc layout is 114% more!
MobileQWERTYâ„¢Â is shown to provide similar improvements for several Western European languages (and one can see a demo of Japanese at minute 40 in the video). It’s targeted not just at standard mobile keypads (a problem space dominated to this point by Tegicâ„¢ , which owns the IP behind predictive spelling for abc layouts) but also game controllers and input devices for the disabled, children, and the elderly — anyone having trouble managing fine finger movements.
The most impressive thing in the video to me is seeing how fluidly someone trained in MobileQWERTYâ„¢Â can type typical messages.Â I really liked the small form factor of my freebie Sprint Samsung phone, but had to give it up for a Treo650’s fuller keypad.Â I think MobileQWERTYâ„¢ could turn out to be a better solution for mobile than Apple’s touch typing and predictive spelling.Â Let’s hope it’s an option in Google’s Android phone OS.
File inputs are pretty ugly, and can be confusing to naive users (e.g., “Should I type what I want in that box?”).Â Quirksmode describes a nicer solution that mail.aol.com (Compose) happens to use:
But if one cares about Big-A accessibility, such a solution won’t work for users with normal vision who are limited to the keyboard (no mice), such as those with carpal tunnel syndrome.Â The reason it won’t work is that such users rely on tab order, and tabbing into an invisible file input consumes 2 tabs before one sees any visible result — the user won’t know they are on top of the Browse button.
One might suggest putting the nonfunctional button in the tab order, and when it receives focus, call click() on the nonvisible file input. But in my experiments, click() did not trigger a FileOpen dialog.
One might also suggest faking focus on the nonfunctional button by drawing a rectangle around it when the nonvisible file input receives focus.Â But remember that file inputs consume 2 tabs — it might make sense to draw the rectangle on the second tab, when focus is on the Browse button, but what about the first tab?Â Even if there are separate events from the file input from the tabs, which seems doubtful, what would one display for the first tab?
A decent compromise is to get rid of the nonfunctional button and make the file input visible.Â But like the mail.aol.com use, hide the inputs once they are used and show a checkbox with the filename instead, with focus moved to this checkbox (so blind users will be aware of the result of their file selection).
We had been using href=foo for leftNav links instead of href=# because screenreaders read <a href=#…> as “link this page” and that may mislead SR users to tab around looking for the content. (The real action of clicking is to submit a form via an onclick.)
But we have to use href=# because otherwise IE fires onbeforeunload once because href!=# and once because the onclick causes a nav change (because it calls submit() on a form). We can’t use setTimeout to ignore the 2nd firing because we need the form submission to happen, and we can’t skip the 1st firing because we need it when the user clicks a non-link (such as form buttons and the window ‘X’ close button).
So, we have to live with the screenreader (JAWS) behavior of reading these links as “link this page”.