W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Accesskey in Web Forms 2

From: Matthew Thomas <mpt@myrealbox.com>
Date: Sun, 22 Aug 2004 16:33:31 +1200
Message-ID: <6BD1E442-F3F4-11D8-B379-000A95AD3972@myrealbox.com>
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)".

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

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

-- 
Matthew Thomas
http://mpt.net.nz/
Received on Saturday, 21 August 2004 21:33:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC