[whatwg] accesskey

[Charles McCathieNevile]

On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas  
<mpt at myrealbox.com> wrote:

> Michael(tm) Smith wrote:
>>
>> Jerason Banes <jbanes at gmail.com>, 2008-01-25 23:41 -0600:
...
>> 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 problem does indeed have a god solution, which is to remove the stupid  
suggestion about the activation behaviour (alt/cmd/etc) in the spec. iCab,  
Opera, Amaya and Firefox have already implemented something intelligent  
that lets you avoid conflicts.

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

And an unimaginatve and unintelligent approach anyway.

>> ...
>> Most handsets don't have keyboards or real pointing devices that
>> let you quickly point and click on links; instead they just have
>> numeric keypads and "5-way" directional pads that are basically
>> the equivalent of arrow keys plus an enter key/mouse button.
>>
>> In the context of delivering content to those devices, it's useful
>> to provide numbered access keys for quick access to certain links
>> on a page -- to save users the time and trouble of needing to use
>> the 5-way on the handset to scroll to the links and activate them.
>> ...
>
> Since most pages that contain links don't also use accesskey=, handset
> vendors should find a way to allow easy navigation of links regardless
> of whether the attribute is present.

They do. However, accesskey, which is to primarily designed to give an  
increased navigation priority to certain links, is very useful for  
handsets, and not actually very complicated to implement, in a way that is  
consistent with the existing markup. It might not be the same across all  
implementations, but there is very little restriction needed to make an  
implementation compatible with almost any imaginable UI.

And all of this has been proposed before, implemented by people in various  
ways in javascript or via proxy-based scripting as well as in user agents,  
and is hardly rocket science.

http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html gives  
you a set of implementation techniques, links to a set of minimal changes  
required to the spec, etc. (There is more that could be done in an  
advanced implementation, but it isn't really complicated).

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