W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Implementing Accesskey - some techniques

From: Charles McCathieNevile <chaals@opera.com>
Date: Tue, 03 Jul 2007 16:40:45 +0200
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.tuv8d7fvwxe0ny@pc052.coreteam.oslo.opera.com>

On Tue, 03 Jul 2007 12:08:20 +0200, Charles McCathieNevile  
<chaals@opera.com> wrote:

> I will write a response to this mail describing implementation  
> strategies.

Herewith.

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

I will discuss activation, and then discovery:

One strategy available is to use the accesskey, unadorned. iCab does this  
- if there is an accesskey "d" then pressing the "d" key activates the  
element. This is also the strategy commonly applied on phone browsers.

This doesn't interfere with the user's expectations of the interface, but  
does cause a problem if there are multiple elements with the same key  
assigned, and if the user cannot generate the relevant keypress easily  
(such as "月"  or "س" or, for phones, "d" - all of which are legitimate  
accesskey values according to the HTML 4 spec and my proposal).

A better strategy includes the following features:

1. A means to activate accesskey mode and toggle it off and on. (The  
default state may be either - this is a choice about building the best  
UI). This is a simple technique to avoid overloading existing user  
interface conventions. In Opera, this is shift-esc by default, in  
Konqueror it is using the ctrl button on its own, and so on. This strategy  
is common in operating systems to activate keyboard accessibility features  
such as mouse keys or sticky keys, and is also used in screen readers such  
as VoiceOver.

2. The ability to discover the items in the collection, and navigate  
between them. The easiest way to do this is using the available keys -  
ideally the user agent will know enough about the available keys to map  
elements in the collection to keys that are available. Since the user  
agent will not always know exactly which keys are available, or that might  
be the empty set (the iPhone has none, as an obvious example), the user  
agent should present the collection as a list or similar and allow the  
user to navigate the list using ordinary interface conventions.

So what does the discovery mechanism look like?

On desktop, presenting a menu as a list of "links" and the relevant key to  
directly access them in a popup, a panel, or similar is generally a  
preferable option. This allows easy navigation with a mouse or keyboard.  
(Opera's implementation uses various pieces of information (e.g. the title  
of the element, or its content or href) to make this more user friendly,  
but the current version isn't keyboard navigable independently of the  
assigned keys). This approach is also compatible with the common  
convention in mobile (described already by Mike), while not relying on it  
in any way.

It also allows for the user agent remapping access to keys that it  
actually has.

> The rapid access mechanism must be able to focus the relevant element.

This has been considered important on desktop, where IE's first  
implementation confused users by the change of context. However, that may  
be due to the fact that instead of activating something specifically for  
accesskey, they could achieve this result by activating a standard desktop  
shortcut.

The subsequent implementations of accesskey switched to ensure that links  
and submissions were focused rather than activated.

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

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

This is important. Allowing a page to override normal user actions is  
generally considered poor UI design - and without a clear discovery  
mechanism, it is even nastier. The mobile convention described by Mike is  
about the second-least harmful approach (the least harmful is a page where  
you can just fix the explanation. There are also various solutions like  
http://www.clacksweb.org.uk/site/accesskeys/ or ubaccess' pagemap  
(essentially a third party providing a proxy-based implementation of the  
same thing).

cheers

Chaals

-- 
   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 14:41:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT