Re: [WebAIM] More data on accesskeys

On Sat, 02 Dec 2006 14:15:49 +1300, John Foliot <foliot@wats.ca> wrote:

> Charles McCathieNevile wrote:

> But Chaals, there *is* a cognitive issue if I, as a content author state:
>
> "To do _foobar_ use accesskey <span style="text-decoration: underline;>é
> </span>" (&eacute;)
>
> How many English speaking users know how to access that key?  Is that  
> really an appropriate accesskey in the first place?  It troubles me
> greatly that a content author presumes to know which key should be the
> best for the end user - "hinted" or not.  Your own example reveals the
> folly in categorically suggesting that a specific key is the "proper"  
> key.

Ah, I should have more clearly explained my example. The author can set  
any key they like, and it is reasonable to have a hint.

An important requirement (as with any version of accesskeys - not just the  
proposal to bring the HTML one to value) is good browser implementation.  
Which, in particular, means that the browser should treat the key as a  
hint and have no compulsion at all about changing it. The way that scripts  
already do for some implementations. The only reasonable way to handle  
them on a mobile phone, or a joystick-controlled device.

Which has the result that authors SHOULD NOT say "use Alt-F to find things  
in my page". The user agent must show what keys are currently assigned.  
(This was anticipated in UAAG at a time closer to the development of HTML  
4 than to now, but the implementation still needs work. On the other hand,  
the whole role attribute approach needs implementation, so it isn't ahead  
in any way).

>> This means
>> the guys writing the implied japanese site in my accesskey example
>> above don't have to worry in advance about whether WHATWG, W3C,
>> microformats.org or whoever can read their explanation of what their
>> particular value means, because you have a way of applying it
>> afterwards that is lightweight enough to implement in a browser if
>> you want to provide real-time discovery.
>
> OK... But if there is "real-time discovery" capability in the browsers,  
> why again do we even need to hint a key?  onLoad: "Prompt: Attention  
> user, would you like to map a keystroke shortcut to this function?" -  
> user selects key - "Alert: that key is already taken by _foo_, are you  
> sure you wish to change it?" Yes/No; else "Alert: Thank you, that key  
> has now been mapped to _bar_"

Actually, getting to deal with all that, on a page where I frankly don't  
care about the accesskeys anyway, seems like a good argument not to have  
to use real-time discovery unless I clearly ask to do so.

What if, instead, my "acceskeys" button - the one next to the fast-forward  
button, lit up so I knew I could activate accesskeys on the page if I  
wanted them? And by default, the author's title and key-hint were offered  
(assuming it is in the current keymap), along with a simple mechanism for  
getting to the key by activating the mode and then using arrows to select  
 from the short list of accesskeyed controls?

Keeping the simple things simple, as well as the difficult things  
possible, is an important goal, IMHO. Having to assign things to random  
and perhaps confusing roles doesn't qualify to me as simple. Asking a  
browser maker to guess about adefault setup twice so...

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9 now! http://opera.com

Received on Monday, 4 December 2006 03:52:42 UTC