[whatwg] Accesskey in Web Forms 2
mattraymond at earthlink.net
Wed Nov 10 06:02:16 PST 2004
> Laurens Holst wrote:
>> and I yet have to see the
>> first site where accesskeys are visually indicated.
> http://juima.org/events/pic.asp?picid=1649 (Finally something public I
> can link to.) :P
> I have strong doubts about the usefulness of any scheme which relies on
> users to define their own shortcut keys. It would be massively useful
> for power users (so personally I'm completely in favor), but the vast
> majority of users of, for example, this 'photo album' would never even
> conceive of the idea that doing something like that would be possible.
> (And I _highly_ doubt that any useragent would clutter its UI enough to
> get even a tiny percentage of them to discover the possibility.)
> Yet the 'task' these users perform in this photo album is highly
> repetitive (going to next picture, and the next, and the next, ...), and
> based on feedback I've received ever since I put in the access keys,
> shortcut keys make it far easier on them. (Particularly for instances of
> such a vertically large image, which has many users on small
> resolutions scrolling or opting for full-screen mode.)
> Note that this is true regardless of whether a browser opts to follow
> the link on the use of the access key (Mozilla), or to only focus it (IE).
I think you've hit the problem on the nail. We can't expect users to
create their own shortcuts any more than we can expect them to create
customized stylesheets for the web pages they most frequently use. While
in both cases power users could significantly benefit from such
functionality, most users probably wouldn't know the functionality
existed unless they were told about it, and even then they wouldn't use
it most of the time. Like it or not, we need access keys for repetitive
tasks because the whole idea is to have the user do as little work as
possible to get to where they want to go. Creating your own access keys
is MORE work, even though it may save time in the long run.
Also, I'd like to point out that there's virtually no reason to add
markup to enable custom access key functionality to browsers. There's
very little information a browser could get about a control that isn't
already in a control element's semantics and its <label> and |id|,
|name| and |title| attributes. If a UA can't create a list of controls
to bind to from all of these sources of information, I doubt more markup
would help. I like James Graham's idea of simply saying that UAs
"should" provide such functionality and leaving it up to the UA to
There has been the suggestion that <link> should be used for access
keys. The problem with this is that access keys for inputs that are
uncommon would still end up in the customized access key scenario.
> The major use case is of course data entry. I've implemented numerous
> CMSs using access keys wherever possible (and yes, all visually
> indicated) - and having had to actually USE several of these systems
> afterward (doing silly things like manually entering the specifics of a
> few hundred products), I can say I was very glad I did.
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.
> Ian Hickson wrote:
>> Maybe this is one case where we just want a half-assed solution?
> As I think the current situation with access keys can be described as
> "half-assed", my vote is for yes. :) (And then I echo James' comments on
> adding recommendations for best behaviour for user agents.)
I agree. 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.
More information about the whatwg