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:45:36 +0300
Message-ID: <BANLkTinbAsvoRgV+06hLmDNBKD+g9WD6-g@mail.gmail.com>
To: simon.harper@manchester.ac.uk
Cc: UAWG list <w3c-wai-ua@w3.org>
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:46:18 GMT

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