- From: Markku Hakkinen <mhakkinen@acm.org>
- Date: Thu, 16 Jun 2011 19:48:11 +0300
- 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 UTC