W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2011

Re: HTML5 Sanity Check - before it goes to the Wiki

From: Markku Hakkinen <mhakkinen@acm.org>
Date: Thu, 16 Jun 2011 19:48:11 +0300
Message-ID: <BANLkTinh6_GB00FP0iKp7Ng8yOmGEEWGVA@mail.gmail.com>
To: simon.harper@manchester.ac.uk
Cc: UAWG list <w3c-wai-ua@w3.org>
Miss the reference for [1]

[1] http://dev.aol.com/dhtml_style_guide#popupmenu



On Thu, Jun 16, 2011 at 7:45 PM, Markku Hakkinen <mhakkinen@acm.org> wrote:
> Hi Simon,
>
> And I see what you are saying. Drop down menus are a bid odd. Let me
> try this again.
>
> Using an example from Windows, when the user hits Alt F, File menu is
> exposed and focus is set to the file menu. If the user is still
> holding the down the Alt key, pressing "S" will invoke the menu item
> with the accelerator key S.  If the user releases the Alt, pressing
> "S" will also invoke the menu item with the "S". In the Windows UI,
> once focus is set to an active menu, only the accelerator key alone
> will invoke the item. If you release the alt, and then hit alt S, the
> action is not invoked. As far as the Windows gui goes, accelerators in
> sub-menus require only the key, no modifier (unless you explicitly
> define an additional short cut key).
>
> IAs far as I see it, there is still only one accelerator key per item,
> not a sequence... I still think that if I am coding menus, I would
> rather identify the access key singly in each selectable item, not
> specify the hierarchical set of keys needed to active a nested menu
> item... to me, that becomes a maintenance issue if higher level menus
> are modified.
>
> If we're talking Rich internet applications, I think this gets to be
> quite tricky, if the developer of an app is trying to maintain
> compatibility with the desktop UI conventions.  I just looked at the
> DHTML Style Guide [1] for recommended key board behavior, and it uses
> the first letter of a menu item to act as select, but does not
> activate.
>
> I am not sure if this line of thought is helping with your concern,
> Simon, but in my mind,  I am getting more concerned about how access
> key will play within menu bar/drop down menu structures, in terms of
> desktop UI compatibility.
>
> mark
>
>
>
> On Thu, Jun 16, 2011 at 7:18 PM, Simon Harper
> <simon.harper@manchester.ac.uk> wrote:
>> Hi Mark, I see what you are saying but the sequence is implied in that alt+f
>> focuses the file menu - while S selects the access key of the items
>> currently in focus. Without this alf f would open the file while S might
>> start a search (or whatever) or do nothing... This is the kind of usability
>> based progressive disclosure functionality I was getting at.
>>
>> However, is the menu keyboard handle defined in html5 or other tech - ie the
>> focus will be kept once say Alt+f is selected?
>>
>> Si.
>>
>> =======================
>> Simon Harper
>> http://simon.harper.name/about/card/
>>
>> University of Manchester (UK)
>> Web Ergonomics Lab - Information Management Group
>> http://wel.cs.manchester.ac.uk
>>
>>
>> On 16/06/2011 16:36, Markku Hakkinen wrote:
>>>
>>> Simon,
>>>
>>> Just a comment on 3.2.3
>>>
>>> On Thu, Jun 16, 2011 at 6:08 PM, Simon Harper
>>> <simon.harper@manchester.ac.uk>  wrote:
>>>>
>>>> 3.2.3 Global attributes
>>>> accesskey - By only allowing an accessskey for be one unicode character
>>>> we
>>>> remove the possibly of sequenced entry such as Alt+F S for file save.
>>>
>>> A sequence such as Alt+F S is activating two UI elements in sequence,
>>> the File menu followed by the Save sub menu item.. Although you are
>>> hitting them in sequence, and you the user may perhaps internally
>>> recall the key sequence as a combination to invoke the save action, it
>>> does not imply that the Save menu choice has an access key, or
>>> shortcut, property value of "Alt+F S".
>>>
>>> The handling of sequenced keys should be in the menu keyboard handler,
>>> not through assigning sequences to a given item.
>>>
>>> mark
>>
>
Received on Thursday, 16 June 2011 16:48:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 June 2011 16:48:54 GMT