Re: Proposal for Keyboard Shortcuts for HTML5

On 2007-09-22 09:07:39 +0200 Maciej Stachowiak <mjs@apple.com> wrote:
> On Sep 21, 2007, at 10:52 PM, Sander Tekelenburg wrote:

[ ... INPUT and accesskey in iCab ... ]
>> Btw, I'm sure you're aware of iCab's accesskey implementation:
>> showing the @accesskey value right after the element.
> 
> I wasn't aware of it, and I don't see it working in iCab 3.0.3. This
> is my test case: <input accesskey="a">

iCab fails to show the access key when you just put it inside <INPUT>. 
But if you place <INPUT> inside <LABEL> and @accesskey inside <LABEL>, 
then it works:

<label accesskey="a"><input ></label>

It is kind of logical - I would say. Even if it is possible to wish 
that it worked also without <LABEL>. You will see the problem also on 
Jukka Korpela's page (next paragraph), where the accesskeys are 
visible for links - but not for inputs.

[ ... Opera bugs with accesskey ... ]
>>> http://www.cs.tut.fi/~jkorpela/forms/accesskey.html#ex

>> If you visit with Opera, you need to know to hit Shift-Esc to get
>> a floating window listing all accesskeys and their 'labels'. Just
>> type the accesskey value, without any modifier key, to 'access' the
>> element (I don't understand why items in that floating window aren't
>> mouse-clickable).
> 
> I did try shift-esc, [...]

On a PowerPC Mac, using Opera 9.5 alpha, the shift-esc doesn't work. 
That is: Opera brings up an _empty_ floating window - and it also 
tells me that the page doesn't have any accesskeys.

[ ... non-default accesskeys ...]
>> If you visit with iCab, make sure that in its prefs you have
>> accesskey support switched on. 

> Using a non-default preference setting doesn't sound like a win for
> discoverability either.

The problem is that showing the accesskeys - always - can affect the 
look of the web pages. If all UAs supported and used accesskeys - 
always - then of course there would not bee a need for iCab to turn of 
display of them. Just make @ACCESSKEY part of the acid 3 test or 
something ...

>> I tend to agree, and think this is a strong argument for providing a
>> means to semantically indicate an element's function, and let the UA
>> assign the appropriate key combo; not leave that to authors.
> 
> I'm dubious, mainly because I don't think a reasonable-sized list
> could cover enough commands to work for a wide range of web apps.
> Giving a label and some preferred key choices, with the option for the
> UA to pick something else in case of conflict, seems like it will do
> well enough in most cases.

How about, when there is a conflict (the conflict might be inside the 
page itself - or it can conflict with system or application commands), 
simply showing the user a list of the available commands? Defined 
error handeling is an important thing for HTML5.

For example in pop-up menus with country listings, one can typically 
type the first letter of a country name, to jump to that place on the 
menu list. If there are many countries which begins with the same 
letter, you can type the letter multiple times to jump between the 
different countries. (At least many UAs work that way.)
-- 
leif halvard silli

Received on Saturday, 22 September 2007 15:55:47 UTC