Re: Accesskey - spec proposal

On Jul 3, 2007, at 3:08 AM, Charles McCathieNevile wrote:

>
> Hi,
>
> Summary: the HTML 4 markup is fine, but the existing specification is
> too vague in parts, and suggests (without requiring) implementation
> approaches that are harmful. So, here is an approach to specifying it
> better.
>
> It doesn't really talk much about how to implement, but there are  
> various
> approaches. Experience (the bitter experience of a lot of  
> implementations
> that are not very good, mostly getting one thing or other right and  
> a lot
> wrong) suggests that it would be worth making it very easy to find  
> such
> suggestions from the spec, but I haven't put them in here. I will  
> write a
> response to this mail describing implementation strategies.
>
> Still lacking from this proposal:
>
>  * how to handle empty string or more than one character (I suggest  
> by putting them into the collection. Since, unlike HTML 4, this  
> proposal uses the key as a hint rather than relying on it being  
> available and convenient for the user to use, it doesn't really  
> matter. One alternative is to allow any kind of string as content,  
> and suggest that it should be a single key.)
>
>  * what happens if an accesskey is added while a user is using the  
> access mechanism? (In the current proposal it is not possible to  
> detect whether the user is "in media res". Either the  
> implementation adds something, or doesn't - it may, like iCab, have  
> an effectively instantaneous mechanism anyway, or it may (should?)  
> lock the collection while the author is in the process of selecting  
> something)
>
>  * how to handle multiple occurences of the same value in a page.  
> (Make them work, but non-conforming? Same reasoning applies as for  
> null/more than one character, I think. This is something I have  
> seen in the wild).
>
>  * what to do with iframes and popups.
>
>  * Test cases. I will write these where they are not already  
> available.

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.

>
> [[[
> The accesskey attribute creates a list of important navigation  
> points in
> the document.
>
> This is an important strategy to provide rapid navigation for keyboard
> users and those for whom input is very difficult (mobile phones,  
> people
> using switch access and similar). In many ways it is like providing
> keyboard shortcuts for common application or OS functionality, but  
> should
> not interfere with those.
>
> This attribute assigns an access key to an element. Its value is a
> single character from the document character set. Elements with  
> accesskey
> form a collection. User agents should provide a user interface for  
> users
> to discover what elements are in that collection, and a rapid access
> mechanism for those elements.

Can you give an example of a decent user interface for this?

> The rapid access mechanism must be able to focus the relevant element.
> User agents may provide a configuration to directly activate the  
> element.
> The rapid access mechanism may use the assigned accesskey as an
> accelerator.

Focus as the default action is not consistent with what OS-native  
shortcut keys would do on various popular platforms, so it seems like  
an odd requirement. Having ways to both focus and activate doubles  
the footprint of available key combinations required for the feature.

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

> In this example, we assign an access key to a link defined by the A
> element. Typing this access key takes the user to another document, in
> this case, a table of contents.
>
> <p><a accesskey="c" rel="contents"
> href="http://example.com/contents.html">Table of Contents</a></p>
>
> 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.

It also seems that accesskey would not work very well on mobile  
devices, which often have limited keyboards. And screen real estate  
is too precious to add a menu just for this relatively obscure feature.

Regards,
Maciej

Received on Tuesday, 3 July 2007 10:30:32 UTC