[whatwg] Accesskey in Web Forms 2
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
> 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. :-)
More information about the whatwg