Accesskey - spec proposal

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.

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

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.

Any focusable element supports the accesskey attribute. Adding an accesskey
to an element makes it focusable.

This example assigns the access key "U" (CAPITAL-U) to a label associated
with an INPUT control.

<form action="..." method="post">
<p><label for="fuser" accesskey="U">User Name <input type="text"
name="user" id="fuser"></label></p>
</form>

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.

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.

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

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com    Catch up: Speed Dial   http://opera.com

Received on Tuesday, 3 July 2007 10:08:35 UTC