[whatwg] Accesskey in Web Forms 2

[Matthew Raymond]

Matthew Thomas wrote:
> On 22 Aug, 2004, at 1:21 PM, Matthew Raymond wrote:
>> Ian Hickson wrote:
>>
>>>> I don't think RENDERING of the access key should be optional.
>>>
>>> It has to be. Google is a user agent. You can't require that google 
>>> render access keys, that makes no sense. :-)
>>
>>   ??? Google is a user agent???
> 
> Yep. Its User-Agent: string is "Googlebot/2.1 
> (+http://www.google.com/bot.html)".

    I'm not sure this qualifies as a USER agent, and I'm not sure if 
rendering HTML as HTML is really rendering at all. Aside from that, I 
doubt anyone needs access keys enabled from within search result summaries.

> You'd have more luck requiring behavior from visual user agents in 
> particular. Even then, specifying both that they "must render the value 
> of an access key" and that they should do so "in a way that is 
> consistent with the native operating system or platform UI conventions" 
> would be self-contradictory. With the factory settings of Windows 2000 
> and later, rendering accesskeys "in a way that is consistent with the 
> native operating system or platform UI conventions" means hiding them 
> until Alt is pressed, and in Mac OS X it usually means not rendering 
> them at all. (Most OS X applications have access keys in their Open and 
> Save dialogs, and some have access keys in other dialogs too. But most 
> software -- including the OS itself -- never displays them, and those 
> applications that do only do so when the Command key is held down.)

    Personally, I think this is a mistake on the part of operating 
system vendors. What's the point of access keys if no one knows what 
they are? This problem is only made worse by Ian's idea of automatically 
resolving access key conflicts between the web page and the browser. If 
the user can't see the auto-selected access key, how can they possibly 
know what key to press?

>>    Perhaps the best way to handle access key conflicts between the 
>> webpage and the browser is to simply prompt the user when they press 
>> the conflicted access key in question.
> 
> There might be cases where a prompt is not the worst possible solution 
> to an interface design problem. But I don't think this is one of them.

    I've made other suggestions, like having an "access key mode", but 
I've heard little regarding these suggestions, and no one seems to be 
coming up with any other ideas.