[whatwg] accesskey

[Charles McCathieNevile]

On Mon, 28 Jan 2008 16:31:04 +0100, Mikko Rantalainen  
<mikko.rantalainen at peda.net> wrote:

> Matthew Paul Thomas wrote:
>> Michael(tm) Smith wrote:
>>> Jerason Banes <jbanes at gmail.com>, 2008-01-25 23:41 -0600:
>>>
>>>> Long story short, accesskeys were an idea that worked better on paper  
>>>> than
>>>> they did in practice. They inevitably interfered with normal browser
>>>> operation as well as other accessibility features in such a way as to  
>>>> *
>>>> reduce* the accessibility of many web pages.
>>> Another long story short: accesskey mark is already in use in a
>>> significant amount of existing content, so leaving it unspec'ed
>>> for implementors does not seem like a practical option -- not if
>>> we care about trying to ensure that behavior of that content is
>>> consistent/ interoperable across UAs.
>>
>> But that's precisely the problem: accesskey= *can't* be consistent and
>> interoperable across UAs, or even across browsers, because browsers
>> compete (amongst other things) on their user interfaces, and therefore
>> they have different user interfaces, and therefore they conflict with
>> different values of accesskey=. If that problem had a good solution,
>> removing the attribute would not have been necessary.

It does. Just allow the UA to accept the key a a hint, but provide the  
real binding itself. (And therefore require the UA and not the author to  
provide dscoverability for things with accesskey. As envisioned by the  
UAAG most of a decade ago).

>> The specification could include an explicit statement of the form "UAs
>> must ignore the accesskey= attribute", but any such statement would be
>> in the yet-to-be-written "Rendering" section.
>
> Perhaps the accesskey should be kept but its meaning should be
> transformed a bit. Instead of being a key (letter) it should be a
> keyword for a behavior. A good accesskey values could be "home",
> "index", "search", "contact". The user then could bind the "home"
> accesskey to any "home" button of his selection. It could be CTRL+H or
> perhaps F11 instead. Some keyboards have additional "multimedia" keys
> that could easily be used for such behavior.

This functionality is already available via the rel attribute, and where  
there are good common values it makes more sense to use those than  
accesskey in the first place.
...
> So my suggestion is to turn the "accesskey" to a tag of the behavior or
> feature linked to the element. One could argue that instead the "rel"
> attribute should be used for such behavior and I really cannot claim
> otherwise...

No :) Accesskey is where there isn't something obvious - a function that  
hasn't been common (send was once such a function on the web, before the  
growth of web-based mail systems. Add to shopping basket is another. I am  
sure there are new services we haven't developed yet...).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com