Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#16262 closed enhancement (fixed)

Menu: implement single letter accessKey

Reported by: Douglas Hays Owned by: Douglas Hays
Priority: undecided Milestone: 1.9
Component: Dijit Version: 1.8.1
Keywords: Cc:
Blocked By: #16265 Blocking:

Description

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

Attachments (1)

16262.patch (23.8 KB) - added by Douglas Hays 7 years ago.
fix and tests

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by Douglas Hays

Blocked By: 16265 added

comment:2 Changed 7 years ago by 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

comment:3 Changed 7 years ago by Douglas Hays

Milestone: tbd1.9

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?).

comment:4 Changed 7 years ago by 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})

comment:5 Changed 7 years ago by 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

comment:6 Changed 7 years ago by 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.

Changed 7 years ago by Douglas Hays

Attachment: 16262.patch added

fix and tests

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by Douglas Hays

Owner: changed from bill to Douglas Hays
Status: newassigned

comment:9 Changed 7 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

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

comment:23 Changed 7 years ago by 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.

Note: See TracTickets for help on using tickets.