Opened 12 years ago

Closed 9 years ago

Last modified 9 years ago

#10251 closed enhancement (fixed)

keyNavContainer: keyboard search by letter

Reported by: Marcus Reimann Owned by: Douglas Hays
Priority: high Milestone: 1.9
Component: Dijit Version: 1.4.0b
Keywords: Cc:
Blocked By: Blocking:


As far as I understand, dijit.form.Select should be the same like a normal <select> HTML element, but with the Dijit API.

I've tested the Widget and it's possible to use the keyboard in order to select an option with the help of the arrow keys, but not with typing the first character of the option.


If you look at test_Select.html, it's possible to set the focus to the first HTML select (the original HTML <select> element) and type in a "o", in order to select the first option with "o" in the beginning (in this case "one").

If you type in a "t" the first time, the first option with "t" ("two" in this case) will be selected and if you type in a second "t", the second option with "t" ("three" in this case") will be selected. If you type in a "t" the third time, the option will switch to "two", because there are only two options with a starting "t" available in this case.

If you're trying the same thing with an dijit.form.Select Widget, it will not work.

Not sure, if this more an enhancement or a bug (regarding to accessibility requirements).

Regards, Marcus

Attachments (2)

[CLA]_KeyNavContainer.diff (1.4 KB) - added by Paul Christopher 10 years ago.
10251.patch (10.0 KB) - added by Douglas Hays 9 years ago.
fix with optional multi-character search support and single item selection

Download all attachments as: .zip

Change History (25)

comment:1 Changed 12 years ago by bill

Milestone: 1.4future
Summary: dijit.form.Select keyboard operationsSelect: keyboard search by letter
Type: defectenhancement

I think it's an enhancement, as it's already accessible. Tree has similar code, actually more complicated since it supports multi-character search, that could be used.

comment:2 Changed 11 years ago by Douglas Hays

Owner: set to Douglas Hays

comment:3 Changed 11 years ago by bill

Component: DijitDijit - Form

comment:4 Changed 11 years ago by Jesper

Any estimation on this ticket ?

comment:5 Changed 11 years ago by Douglas Hays

It's marked future which means no estimation. Please feel free to attach a patch and automated testcase.

comment:6 Changed 10 years ago by Douglas Hays

#14917 is a duplicate of this ticket.

comment:7 Changed 10 years ago by Paul Christopher

Added a patch (against 1.7.2) which enables searching a _KeyNavContainer by typing the first letter of an option's label.

Changed 10 years ago by Paul Christopher

Attachment: [CLA]_KeyNavContainer.diff added

comment:8 Changed 10 years ago by Douglas Hays

Milestone: future2.0

comment:9 Changed 9 years ago by Douglas Hays

Component: Dijit - FormDijit
Milestone: 2.0tbd
Owner: changed from Douglas Hays to bill
Status: newassigned
Summary: Select: keyboard search by letterkeyNavContainer: keyboard search by letter

bill, I think this is a good candidate for 1.9. I attached a patch that enables first letter selection for Toolbar, Menu, and Select.

comment:10 Changed 9 years ago by bill

Thanks for that patch. I agree it's a good candidate for 1.9. A few things:

  • Needs some kind of unit tests.
  • Should replace the code added to Tree in #2193 and #8916. The multi-key search added in #8916 feels like it was overkill but since it's already in Tree maybe the best thing is to move it all to _KeyNavContainer.
  • Like the code in #2193 and #8916, this code presumably doesn't have much support for languages besides English, languages that require multiple keystrokes to input [some of] the letters. I guess it's still an improvement though.

comment:11 Changed 9 years ago by bill

PS: I just remembered that Tree's navigation is more complicated than a plain _KeyNavContainer because it's hierarchical, so it may not be practical to combine the code for letter and/or arrow navigation. But it's worth investigating a bit. It seems like the main difference is getting the list of children/descendants that should be visited by up/down arrow or letter key navigation.

Note that the Tree's navigation is on the Tree itself rather than on the TreeNode. TreeNode just extends _Container, rather than _KeyNavContainer, and Tree (currently) has custom code for navigation.

Last edited 9 years ago by bill (previous) (diff)

comment:12 Changed 9 years ago by Douglas Hays

I think the multikey search in Tree is contrary to default menu handling and will have to stay in Tree. That'll make it difficult to move the code.

comment:13 Changed 9 years ago by bill

Hmm, well now that you mention it, what are you defining as "default menu handling" and where is your definition coming from?

comment:14 Changed 9 years ago by Douglas Hays

While native SELECTs work like Tree, I couldn't find any menus or toolbars that used multi-character search. Can you point me to one?

comment:15 Changed 9 years ago by bill

I don't know any menus with multi-character search, but popular menus don't seem to operate via a simple single character search either.

I checked menus on Mac and Windows, and generally typing a letter will execute one of the menu choices, rather than navigating to it. For example, on IE8, open the File menu and type 'P' and the print dialog opens. But typing "E" navigates to the "Send" submenu rather than executing "Exit", the menu choice that starts with E.

I remember in the old days that menu items would have an underlined letter (for example the "a" in "Save As...") and that would be the shortcut key. But I don't see any underlines in IE8.

So, I'm not sure what the rules for menus should be, but seems complicated.

comment:16 Changed 9 years ago by Douglas Hays

I did notice that on my Windows, the Start -> Documents menu works off of single character selection, but if you type a letter and there's only 1 of that, then it Opens the document. Seems like chaos. I don't know how a keyboard user (especially visually impaired) could ever know how a specific menu is going to work. And timing sensitive seems almost non-deterministic since there's no way to know how much time has passed since the last keystroke, and once you type 2 letters in quick succession that do match, then you have to wait until the "timeout" occurs before going back to single letter searching (and of course you don't know how long that is). Also, if a selection begins with 2 of the same letter (like aardvark, then you can't search for "aa" since that will be 2 single letter searches of "a" (according to native SELECT behavior).

Last edited 9 years ago by Douglas Hays (previous) (diff)

comment:17 Changed 9 years ago by Douglas Hays

I recommend implementing a native SELECT search capability in keyNavContainer, with added provisions of being able to selectively only have single letter searching (set multi duration to 0) per widget, and also have a publish('execute') if only 1 match is made so that widgets can choose to do a select item if desired. Tree can choose later to use this class later if desired.

comment:18 Changed 9 years ago by bill

Selects: I can definitely see the benefit to multi-key search for Selects, since they could have hundreds or thousands of entries (although in that case FilteringSelect is a better choice, except maybe for mobile). Plus, it's good to match native behavior. By the way, I tested on chrome/mac, and it is possible to type "cc" or "aa" to navigate to a native <select> option that starts with a double letter; in other words, it's not a special case.

Menus: Menus are a different ball of wax because they only have a few entries, usually less than 10. Plus, menus have explicitly defined shortcut keys: every menu item [with a shortcut] has a unique shortcut letter, not necessarily the first letter of the label. See for example the underlined letters in the screenshots on By the way, this is especially important in other languages, where the labels do not contain any "english" characters at all, besides for the shortcut in parentheses.

About your Start --> Documents example, I agree that behavior is chaotic. I can see Microsoft was trying to optimize keystrokes as much as possible but seems like branching based on whether or not there are two items starting with the same letter is going too far.

Toolbars: I've never seen a toolbar with keyboard shortcuts, probably because users have no practical way to discover what the shortcuts are (ex: there's no way to find out the "X" selects or activates the toolbar button with the picture of the scissors).

Final Thoughts: So, your patch seems pretty good, given the plan to later change Tree to share the same code. I think the only improvement would be to have explicitly defined shortcuts keys for menu items, like on Without that feature, the "auto-execute of items but only when there's only one matching item" seems too confusing, because of the branching behavior.

comment:19 Changed 9 years ago by Paul Christopher

Maybe it is an idea to make the search functionality configurable, i.e. by adding some new properties to _KeyNav? Setting e.g. "searchByLetter" to true will enable the new search funtionality for the given _KeyNav container. Thus dijit.Select could set this parameter always to true, dijit.Menue by default to false? The same would hold true for a second parameter "multiLetterSearch": If you have only few items, you maybe want a search by first letter only. If there are hundreds of items, you may want to change that to multi letter search? I really depends one the use case which search mode is the better one.

Morever: I have not tested the patch above. But I think one thing has to be made sure: When tabbing into a select (i.e. freshly focusing it by keyboard), pressing a key should open the select and focus the desired option. I could not solve this with my initial patch to _KeyNav: There I needed to open the dropdown and focus it so as to make search by the first letter work.

comment:20 Changed 9 years ago by Douglas Hays

Milestone: tbd1.9
Owner: changed from bill to Douglas Hays

#16262 opened to track implementation of single letter access key support.

Changed 9 years ago by Douglas Hays

Attachment: 10251.patch added

fix with optional multi-character search support and single item selection

comment:21 Changed 9 years ago by bill

#10586 is a duplicate of this ticket.

comment:22 Changed 9 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 9 years ago by Douglas Hays

#16579 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.