Re: Accesskey - spec proposal

On Tue, 03 Jul 2007 12:30:20 +0200, Maciej Stachowiak <>  

> On Jul 3, 2007, at 3:08 AM, Charles McCathieNevile wrote:
>> ... I will write a
>> response to this mail describing implementation strategies.
> I think the main problem with the proposal is that it says that browsers  
> should solve the well-known problems with accesskey, without specifying  
> or even suggesting how to solve them. Examples of possible solutions  
> would increase confidence that viable solutions exist.
>> Where a link can be described accurately using a technique with  
>> predefined
>> semantics such as the rel attribute, authors should use that in  
>> preference
>> to accesskey. This enables browsers to provide a standard interaction
>> mechanism common to the entire web, not just for one site, for those
>> functionalities. Authors may choose to use both, in order to offer
>> functionality in older browsers, but increasing the number of accesskeys
>> in a page reduces the overall effectiveness.
> It's not clear to me how rel and accesskey are substitutes for each  
> other. Do we expect rel values to have predefined keyboard shortcuts in  
> browsers?

Yes. or some other simple mechanism for activating it - that provides  
consistency much wider than a single website for common things like next,  
table of contents, etc.

>> The invocation of access keys should not interfere with the underlying
>> system. For instance, on machines running MS Windows, using the "alt"  
>> key in addition to the access key would in many cases interfere with
>> default functions, so this should not be the rapid access method.
> What's an example of a suitable rapid access method? On the Mac, I don't  
> think any single modifier key would work. For example, command-A,  
> option-A, control-A and shift-A all have a predefined standard action in  
> text fields. I know control and alt are often used for commands on  
> Windows. It seems like other options would not be discoverable, usable,  
> or indeed rapid.
>> The rendering of access keys depends on the user agent. Authors should  
>> not
>> include the access key in label text or wherever the access key is to
>> apply, since user agents may select another key or another method for
>> activation.]]]
> If browsers can freely reassign the actual keyboard shortcut or whether  
> there even is one, it will be hard to write documentation for web apps  
> that use access keys, and hard for users to switch. But basic mouse  
> interaction is fairly interoperable, as are regular key events.

If you can use a mouse, which in accessibility scenarios is not a given.  
Key events are also problematic (as you would be aware from the list of  
people who haven't managed to complete the task of specifying them for the  
WebAPI group) in that generating arbitrary key events under conditions  
such as switch access or a limited keyboard can be quite difficult

> It also seems that accesskey would not work very well on mobile devices,  
> which often have limited keyboards.

The WAP forum (now OMA) obviously disagreed with you, since on WAP  
browsers accesskey (although restricted to numbers 1-9) is widely  

> And screen real estate is too precious to add a menu just for this  
> relatively obscure feature.

When browsing a large amount of content on a small screen, rapid  
navigation to a point of interest is in fact something people seem to  
appreciate. While on a large mobile device you can afford to do it like  
Opera mini 4, nokia, and apple with an overview first, on a smaller screen  
such as many feature phones today that is less advantageous. The WML  
markup (developed on monochrome screens effectively much smaller than we  
have now) did indeed use screen real estate for this, since there is in  
fact a lot of benefit.

Anyway, as noted in my original email, I will describe some implementation  
strategies and where else they have been used.


   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk    Catch up: Speed Dial

Received on Tuesday, 3 July 2007 11:08:49 UTC