[whatwg] Accesskey in Web Forms 2

[Matthew Raymond]

Sander wrote:
> 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 
decide how.

    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.