[whatwg] Accesskey in Web Forms 2
mpt at myrealbox.com
Wed Nov 10 07:13:22 PST 2004
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
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?
More information about the whatwg