[whatwg] Accesskey in Web Forms 2

[Matthew Thomas]

On 11 Nov, 2004, at 3:02 AM, Matthew Raymond wrote:
> ...
>    I think you've hit the problem on the nail. We can't expect users 
> to create their own shortcuts

As I wrote when I originally suggested that scheme, it was "an example" 
of how a UA could "provide access mechanisms that are appropriate for 
the particular device and operating environment" without any need for 
special markup.

More common, perhaps, would be for UAs to automatically create (and 
display on the page) shortcuts for form controls that had been used 
frequently in the past.

Non-conflicting keyboard shortcuts could be created by the user with 
the help of the UA (as in my original example), or by the UA with the 
help of the user (as in my example above). What accesskey= does, 
however, is to place the responsibility of creating shortcuts on the 
author -- *the only party* involved who can't possibly know enough to 
do a decent job of it.

> ...
>    Also, I'd like to point out that there's virtually no reason to add 
> markup to enable custom access key functionality to browsers.

I don't think anyone has suggested any extra markup.

> ...
>    I don't think anyone can argue that there isn't a use case for 
> access keys. The argument is that they can't be used in all 
> situations. While there is some truth to this in many current 
> browsers, it's a lot harder to train a bunch of technophobic employees 
> to create their own access keys than it is to teach a key combination.

Teaching the key combination is not the problem. (Well, it's a problem, 
but only because UA vendors haven't bothered to implement the necessary 
underlining, not because of any spec deficiency.) The problem is that 
the spec gives authors the near-impossible task of choosing an 
accesskey that does not conflict with any UA, on any operating 
environment, in any locale, with any combination of accessibility and 
other utility software running.

> ...
> Many of the problems with |accesskey| could be fixed with some 
> creative thinking on the part of UA vendors. Let's come up with 
> suggestions and guidelines for how to fix these problems rather than 
> creating a more complicated system most users won't use.

UA vendors have had over six years to come up with non-awkward support 
for accesskey=. But creative thinking, by them or by anyone else, will 
not create new modifier keys on existing non-Macintosh keyboards; nor 
will it reduce the awkwardness of keyboard shortcuts involving three or 
more keys; and nor will it reduce the extent to which most humans 
dislike modal interfaces. What other possibilities are there?

-- 
Matthew Thomas
http://mpt.net.nz/