Menu: implement single letter accessKey

[Douglas Hays]

When a menu has focus, normally child items have single letters underline that act like shortcuts.

[bill]

See for example

the underlined letters in the screenshots on ​http://www.homeandlearn.co.uk/csharp/csharp_s4p3.html, or for languages where the shortcut key is not part of the label: ​http://support.microsoft.com/library/images/support/kbgraphics/public/ja/kblight/t007/7/25g.gif

[Douglas Hays]

From ​http://msdn.microsoft.com/en-us/library/75y70dx3(v=vs.80).aspx, "The difference between access keys and keyboard shortcuts is that you can use a keyboard shortcut to choose a menu item without first displaying its menu.". The current accelKey is a shortcut, and this feature is definitely an access key. The problem is that dijit's Menu widgets remain active in the minds of browsers (at least Chrome) even when inactive. If the Menu widgets' accesKey definition cannot be hidden in this scenario (seems it would involve removing accessKey from all child items and reapplying later), then the new attribute name for this feature should be something similar to accessKey but disambiguated to reflect it only works when the Menu has focus and not with ALT (focusedAccessKey?).

[Douglas Hays]

What is there's no attribute name at all but rather the access key is embedded in the data stream to better allow for translations. Then the set label method can easily strip out the {},
File becomes {F}ile
編集 becomes 編集 ({E})

[Douglas Hays]

\ would be nice as well since it better implies special treatment for a single letter:
Save \As in markup or "Save \\As" in JS

[bill]

From ​http://msdn.microsoft.com/en-us/library/75y70dx3(v=vs.80).aspx, "The difference between access keys and keyboard shortcuts is that you can use a keyboard shortcut to choose a menu item without first displaying its menu.". The current accelKey is a shortcut, and this feature is definitely an access key.

Yes, it's clear the terminology used by browsers is confusingly different than the terminology used by Microsoft.

I also noticed in that link that:

If you don't assign an access key to a menu title or menu item, Visual FoxPro automatically assigns the first letter as the access key. For example, the Customer menu created previously didn't have a defined access key. Accordingly, Visual FoxPro assigned the first letter (C) as the access key."

It's an interesting idea since it makes menu behavior consistent, rather than behaving slightly differently (ex: focusing but not executing) based on whether or not the app specified a shortcut key (or whatever you want to call it).

The only downside I see is that if menus are unlucky enough to have two items that start with the same letter, they need to explicitly specify a shortcut for one of them, or the behavior will not be well defined. That seems like a reasonable restriction, except in special cases like menus listing things like documents (ex: the "recently opened" submenu under the "File" menu).

the new attribute name for this feature should be something similar to accessKey but disambiguated to reflect it only works when the Menu has focus and not with ALT (focusedAccessKey?). ... What is there's no attribute name at all but rather the access key is embedded in the data stream to better allow for translations.... File becomes {F}ile 編集 becomes 編集 ({E})

By "better allow for translations" I guess you are saying that part of the "translation" is to change the shortcut letter. Not true for Japanese but I think it's true for other languages like German, so this seems like a good idea. Plus, as you implied, it means you don't need to think of a name for a new parameter.

One more note: seems like setting accessKeys (in web terminology) on web pages have ​a lot of issues, most notably that if the app designer isn't very careful, they will mask access to the browser's menu, thus reducing accessibility rather than making it better.

[Douglas Hays]

fix and tests

[Douglas Hays]

Refs #10251
bill, I attached a patch that implements both #10251 and #16262 since they ended up being dependent. One thing that still needs to be resolved is what get('label') returns: File or {F}ile. Currently it returns {F}ile so that set('label', get('label') works.

[Douglas Hays]

In [29912]:

Fixes #16262, #10251. Add multiple letter search capability to _KeyNavContainer. Also added single letter navigation to Menu triggered by a special {} MenuItem? label syntax (e.g. {F}ile) in which the letter is underlined when the Menu has focus. Changed SelectMenu? to inherit from DropDownMenu? instead of Menu. Added automated tests. !strict

[bill]

In [29929]:

I think for the doc parser to work you need to actually define shortcutKey as a string (but inside /*==== =====*/ comment is OK). Refs #16262 !strict.