[whatwg] accesskey

[Mikko Rantalainen]

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

The spec could describe that for backwards compatibility UAs should
expect to find keywords such as "1", "2", "3", ... and "a", "b" etc. and
that those keywords should be considered to be static for the site but
have no specific meaning otherwise. A mobile device could map keyword
"1" to button "1" by default if it seems to make sense.

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

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080128/549fa355/attachment-0001.pgp>