W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2004

[whatwg] Accesskey in Web Forms 2

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 8 Dec 2004 02:30:56 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0412080221530.4755@dhalsim.dreamhost.com>
On Wed, 10 Nov 2004, Sander wrote:

> 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. 

Agreed.


> (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.

For something like the "next" link, we already have rel="next", which the 
UA can take into account. For example, in Opera, hitting the space bar 
when at the bottom of the page will follow a rel="next" link if there is 
one. This will work on any site (it uses heuristics if you don't give a 
rel="next" link), not just those that use the access key.

Other browsers (MacIE, Firefox) allow you to just type the first letter of 
a link to jump to that link. Again, no reliance on the author specifying 
an access key, and it works on all sites.

I think both of those solutions beat the accesskey="" idea.


> 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 have the opposite problem. I use a data entry tool on a regular basis 
(Bugzilla) which uses accesskey="" heavily, and because Firefox lets the 
page override its own access keys, I can no longer access my menus from 
the keyboard. This affects me daily.


> Nearly all (?) popular web-based message board systems (such as 
> vBulletin and phpbb) have two access keys defined for posting messages. 
> "s" for submit and "p" for preview.

UAs could automatically assign access keys for buttons and other controls 
by using the first letter of the button, or the first letter of the 
<label>'s value, quite easily. (Clashes could be resolved by letting the 
access key cycle through each matching control instead of invoking it, if 
there is more than one matching one.) I'm sure I've proposed that before 
and had it shot down, though.

My point, however, was that the author wouldn't have to actually do 
anything explicit to get the alt+s-to-submit behaviour, if UAs did.


> 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.)

We could suggest behaviours, but frankly I'd suggest you just file bugs in 
the relevant bug databases.

At the moment, accesskey="" is deprecated in Web Apps 1.0. Maybe this 
should be made a little less strong, merely pointing out that it has many 
flaws and authors may wish to just let the UA deal with it? I still don't 
see that it is a feature that interactive UAs should support. On phones, 
for instance, with only 10 buttons, you really can't do much with it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 December 2004 18:30:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:38 UTC