Re: Implementing Accesskey - some techniques

On Tue, 03 Jul 2007 16:40:45 +0200, Charles McCathieNevile  
<chaals@opera.com> wrote:

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

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

A really really simple "implementation" could just remove everything that  
didn't have an accesskey from the page (not display it), allowing the user  
to see just the things that do. This also provides the rapid navigation  
and easy choice that accesskey is meant to give. The CSS rules

   * {visibility:hidden}
   *[accesskey],*[accesskey] * {visibility:visible}
   *[accesskey]:before {content: '{' attr(accesskey) '} '}

do some of this. This is a quick minimalist hack I made up in 15 minutes  
with the weakest tools available (toggling user stylesheets in Opera), and  
unsurprisingly there are some problems - it only shows labels if they are  
used "implicitly" in the HTML 4 spec sense - that is

   <label accesskey="f"><input ...>The label</label>

(or better, to work with existing technology:

   <label for="testIt" accesskey="f"><input id="testIt" ...>The  
label</label>

since only some things pick up on the nesting of a control in a label and  
others trigger on the for attribute :( ). Otherwise you get radio buttons  
with no text. It also doesn't activate the accesskey mode. Of course I  
expect real programmers to do somewhat better, even if it takes them a  
little longer :)

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

This is a key point. It isn't always obvious to a user agent what keys are  
available, but it often is. And mapping accesskey to those is helpful,  
rather like inputmode is a helpful attribute.

Patrick Lauke wondered

[[[
Just wondering out loud on the recent discussion on how browsers should  
implement accesskeys...how much of that should be defined in the language  
spec itself, and how much should fall under the remit of UAAG?
]]] - http://www.w3.org/mid/468C11E3.8040706@splintered.co.uk (oh for  
multiple inheritance in mail threads)

I think that it is useful to describe some basic implementation approaches  
(I take the fact that people who develop browsers haven't all managed to  
come up with great implementations as reinforcement). I suspect this  
definitely belongs in UAAG (which IMHO should make implementing a rapid  
access mechanism a MUST - something my proposal deliberately doesn't do)  
or UAAG techniques, but HTML should have enough pointers and clues to help  
a developer implement it without assuming that s/he is familiar with a  
collection of other specs. It would not be normative in HTML, of course.

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 Sunday, 8 July 2007 03:42:45 UTC