[whatwg] Accesskey in Web Forms 2

[Matthew Raymond]

Matthew Thomas wrote:
> On 23 Aug, 2004, at 9:47 AM, Matthew Raymond wrote:
> "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." 
> <http://www.w3.org/TR/REC-html40/conform.html#didx-user_agent>

    Rather broad definition of the term "user", then. By this 
definition, Mr. Coffee can be a user. What term would you suggest for 
user agents where the user in question is actually a person?

>>>  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.
> <http://bugzilla.mozilla.org/show_bug.cgi?id=25894#c4>
> <http://bugzilla.mozilla.org/show_bug.cgi?id=25894#c20>)

    You don't really explain why you changed your mind. After thinking 
about it, though, I think I understand your position. Only people who 
use the keyboard are ever going to use the access keys, therefore just 
wait until they press "Alt" (or whatever key their OS uses) for the menu 
to show the keys. User's who don't use access keys won't be distracted 
by them when they're not visible.

    The only problem with this is when it comes to access keys for 
buttons and the like. You need to see those to be visible to keyboard 
users all the time. On Windows XP, there solution seems to be that if 
you press "Alt" all the access keys become visible, but that requires a 
keyboard user to use "Alt" in a context they normally wouldn't, and 
could cause problems for developers who have the misfortune of having 
chosen to use dialogs and menus at the same time.

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

    The mode I was referring to need not be permanent. It could end as 
soon as the user presses the access key, or it could time out after a 
few second of no input. (Of course, there is the issue of "chromeless" 
windows, but that's another thread.)

>> and no one seems to be coming up with any other ideas.
> 
> I still like my idea of deprecating the thing. :-)

    That may be what we end up doing for non-menu items, but once you're 
in a menu, access keys can be used without an "Alt" key or the like. 
Therefore, menu-based access keys don't conflict with the browser access 
keys, since menus already have a natural kind of "access key mode".