Re: Accesskey Discussion

  Hi Simon, Bim,

The thing about that is, accesskey was originally put in specifically so it *would* use the same modifier key as the browser UI. At least as it was discussed within Microsoft, the goal was to allow HTML authoring of forms, dialog boxes, and other user interfaces have the platform's "look and feel" so the user wouldn't have to know or care whether UI was written using HTML or the native Windows API, VB, etc. Since Windows menus and dialog box controls used the Alt-key modifier, so did accesskey.

Of course a browser can use a different modifier key for accesskey (or its equivalent) than for its built-in UI, but that would make HTML-authored dialog boxes and forms extremely confusing for users. Imagine if a dialog box comes up and you have to guess which modifier key to press to activate its controls, because you don't know whether it's native or author-defined...

Luckily, the Windows UI (based on IBM's CUA standard) included a mechanism for handling conflicts: if more than one element in the active context shared the same underlined access key, pressing that key or key combination would move the focus to the next element with that access key, but not automatically activate it, leaving the user to either navigate away (by repeating the access key or other means) or press a key to activate the element. Thus, at least in native applications, you could still do everything in a way that was pretty much optimal given the conflict, but the UI did change enough that it could confuse users who weren't used to this convention or to accesskeys suddenly changing behavior.

     Thanks,
     Greg

-------- Original Message  --------
Subject: Re: Accesskey Discussion
From: Simon Harper <simon.harper@manchester.ac.uk>
To: Egan, Bim <Bim.Egan@rnib.org.uk>
Cc: UAWG list <w3c-wai-ua@w3.org>
Date: 9/24/2010 2:00 AM
> Hi there Bim, this is really just a problem of the browser not implementing the bindings in rationale way. Indeed, a modifier key would easy sort this out.
>
>
> Cheers
> Si.
>
> =======================
>
> Simon Harper
> University of Manchester (UK)
>
> More: http://simon.harper.name/about/card/
>
> On 23/09/2010 19:04, Egan, Bim wrote:
>> Sorry to butt in here, but it concerns me that as accesskey bindings
>> frequently conflict with keyboard access to browser  toolbars or
>> plug-ins, and can also change settings in access technology that runs in
>> the background while being sensitive to all keystrokes, such as screen
>> readers, defined accesskeys could result in all HTML5 pages using them
>> being inaccessible to people  who navigate via keyboard or use access
>> tech software, instead of the current situation where it is difficult
>> only on some sites using code that conforms to specification.
>>
>> Bim
>>
>> -----Original Message-----
>> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
>> Behalf Of Simon Harper
>> Sent: 23 September 2010 18:44
>> To: UAWG list
>> Subject: Accesskey Discussion
>>
>> I seems to me that HTML5 is becoming increasingly platform like. In this
>> case I suggest that HTML5 specify a number of predefined accesskeys for
>> common functionality including those useful for WebApps.
>>
>> Cheers
>> Si.
>>
>> =======================
>>
>> Simon Harper
>> University of Manchester (UK)
>>
>> More: http://simon.harper.name/about/card/
>>
>>
>>
>>   To report this e-mail as Spam, please forward it to:
>> spam@mailcontrol.com
>>
>>
>