[whatwg] Accesskey in Web Forms 2

Matthew Thomas mpt at myrealbox.com
Mon Aug 23 07:56:52 PDT 2004

On 23 Aug, 2004, at 9:47 AM, Matthew Raymond wrote:
> Matthew Thomas wrote:
>> On 22 Aug, 2004, at 1:21 PM, Matthew Raymond wrote:
>>> Ian Hickson wrote:
> ...
>>>> 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,

"An HTML user agent is any device that interprets HTML documents. User 
agents include visual browsers (text-only and graphical), non-visual 
browsers (audio, Braille), search robots, proxies, etc." 

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

Which, I think, was exactly Ian's point. You can't require a particular 
rendering from a user agent (such as Googlebot) that doesn't render. 
And you shouldn't require a particular rendering in a context (such as 
search results) that is inappropriate.

> ...
>>  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.
> ...
>    Personally, I think this is a mistake on the part of operating 
> system vendors.

(FWIW, I used to think the same thing.

> What's the point of access keys if no one knows what they are?

"No-one" is an exaggeration; the point is to make them *difficult* to 
know, so as to maximize the productivity of the population as a whole. 
People who are unable to use a pointing device efficiently (e.g. 
disabled people, or people with very badly-designed or -configured 
pointing devices) will still put in the effort to learn them, but 
people who can use a pointing device efficiently will not be lured into 
regular use of a GUI activation mechanism which they think is faster 
but usually isn't.

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

That's partly why I don't think that idea is a good one. Even if you 
memorized the access key for a particular control, it might change on 
the next page.

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

Invisible (or near-invisible) modes are bad firstly because people 
switch modes by accident (or start in the wrong mode) and don't realize 
until too late; and secondly because part of a person's short-term 
memory needs to be reserved for remembering which mode they're in, 
rather than used for working on the problem at hand. For a few people 
(e.g. vi users) the efficiency they get in return is worth it, but not 
for most people.

> and no one seems to be coming up with any other ideas.

I still like my idea of deprecating the thing. :-)

Matthew Thomas

More information about the whatwg mailing list