After some discussion with bill on IRC about this, I thought we should start a forum topic to discuss what is meant by "Combobox-like" behavior. This is the first stab at it...debate is welcome. Much of these just came from looking at the behavior of the URL bars of Firefox and Safari...(which is a great example, in my opinion of "Combobox-like" behavior)
First, some background: There are quite a few times when widgets need to behave as a text box with a dropdown of sorts (a Combobox). The Combobox and FilteringSelect are examples - but this would also extend to things like DateTextBox and TimeTextBox (and possibly others). There are a few commonalities between all of these items (or, in the case of Date and Time TextBoxes, there *should* be these commonalities, and bugs exists requesting these abilities in those widgets) - these are up for debate:
1 - They all have a textbox that allows the user to enter data manually
2 - They all have a "helper" dropdown that allows them to pick from pre-defined values (using keyboard or mouse)
3 - They support some sort of "filtering" based on what is typed in.
4 - They can provide some sort of "autocompletion"
And some behavior - these are also up for debate:
1 - They should allow for navigation of the dropdown without losing focus of the text box - that way, you can type values at any time without needing to switch focus
2 - When the dropdown items are hovered via mouse navigation, they should be "highlighted", but the contents of the textbox should not change
3 - When the dropdown items are clicked via mouse navigation, they should be "selected", and the contents of the textbox should change, the dropdown is closed, and focus remains on the text box.
4 - When the dropdown items are focused via keyboard navigation, they should be "highlighted", and the contents of the textbox should change to be the value of the focused item with some portion of it (or all of it) "selected" - that is text-selection in the textbox.
5 - When the dropdown items are clicked via mouse navigation (enter or space), the item should be "selected", and the contents of the textbox should change with no selection, the dropdown closed, and focus remains on the text box.
6 - If the textbox loses focus (via a tab), the dropdown is closed, and any possible text-selection in the textbox (via an autocomplete) should be deselected (in effect, "accepting" the autocompletion) and focus passes to the next item in the tab order.
7 - If the dropdown is opened, the escape key closes the dropdown (but doesn't remove any autocompletion, or undo any text selection in the text box).
8 - If the dropdown is closed, the escape key reverts the value of the textbox back to its original value ("undo").
What are peoples' thoughts on these?
| Attachment | Size |
|---|---|
| ibmUsabilityComments.pdf | 127.5 KB |
sounds good
Thanks, that's a really good detailed description.
This suggestion sounds good to me, mainly because it matches how a native select performs. The main issue for me is whether "the currently selected value" and "the value with keyboard focus" should be the same thing, or move independently. IIUC the usability folks were suggesting that keyboard focus and selection be independent, which seems strange to me, although admittedly that's how the color picker is MS word works (but the font drop down does not; keyboard focus and selection are the same).
Since TimeTextBox is so similar to ComboBox it seems obvious to make them work the same. For DateTextBox I think that it should also work the same, although perhaps that's where the debate will be, since a calendar is a grid like a color picker. Although frankly I don't see why MS word's color picker works differently than the font selection.
=========
Bill Keese
Project Lead (aka BDFL) of Dijit
comments from IBM usability group
David Schwartz sent me a response to this including the PDF file I attached above, which has suggested changes to the "spec" listed in the original post. Quoting his response:
===========
===========
(BTW the image looked prettier before but got blurry in MS-word. No matter, you can see the point of the mockup, about how keyboard focus, mouse hover, and selection are all distinct.)
Basically, his team is advocating a very different approach, where keyboard navigation works like mouse navigation, in the sense that the input box value doesn't change until you "click" something in the drop down, using the space key (or enter key?). And keyboard navigation in the drop down actually puts (keyboard) focus in the drop down, rather than just highlighting the current entry.
different philosophy
I'm replying to you guys here in the hope (demand?) that we have this conversation on the forum rather than privately.
So, this suggestion is a big change to dijit and I'm wary of it for a few reasons, but of course we can consider it. My hesitations are:
Also, keep in mind that for FilteringSelect the current value often isn't in the drop down list. For example, if the user types "a" into the text box, neither "Alabama" nor "Arkansas" is the current value (nor is anything else). ComboBox is even more complicated since any input value is valid, not just the items in the drop down list.
On the other hand, I do see your points that:
In addition, I do see your point about the up/down arrow keys cycling through the values w/out opening the drop down; I confirmed that's how IE/FF work, if you focus on the field by tabbing into it rather than by using the mouse. That suggestion is not as controversial as is the one to make keyboard focus and selection independent.
As per the line items in the initial post:
=========
Bill Keese
Project Lead (aka BDFL) of Dijit
Yes - it should have read
Yes - it should have read "Keyboard Navigation" - though the same behavior would apply if clicked by a mouse as well.
Yes - I agree that #6 should happen regardless of whether it is displayed or not.
A11y perspective
I would like to add keyboard support to the calendar drop down for 1.2 and thus would like to see further discussion and a decision on this.
With regards as to whether focus remains in the textbox or in the dropdown list I have mixed feelings. For the combobox it would be easier for the screen reader if the focus was in the actual drop down list. The screen reader would speak each entry as it received focus (and speak "n of m items" to indicate the place in the list But, we do have the screen reader working with the current combobox where the focus remains in the textbox although there is a current screen reader issue that only the selected portion is spoken and "n of m items" is not spoken. This issue is being investigated.
In the case of the combobox, I think that the value of the textbox should also be updated as the user focuses a choice since this is how the Firefox, IE and Safari URL comboboxes all work and is what the user expects. Following this same model of keeping focus in the textbox makes implementation of the calendar dropdown easier in order to support screen readers. If the user opens the calendar dropdown via an arrow key press and navigates from day to day using the arrows, it is much harder to provide the full date information to the screen reader user if focus is on a day in the drop down list rather than on the textbox. If focus is on the textbox, the screen reader will speak the contents as it gets changed. So if I have highlighted April 24, 2008 in the calendar drop down via the keyboard, the textbox contents would be updated to 04/24/08 and the screen reader will speak "04/24/08". However, if focus is on the 24 in the calendar drop down the screen reader will just speak "24". It would take extra work on the part of the widget to add the describedby ARIA property to point to the month text string displayed in the top portion of the calendar drop down and the current year in the lower portion of the drop down. This would make the information spoken more thorough, "24 April 2008", than just "04/24/08" but I'm not sure it is worth the extra code. I'm also not certain how useful a screen reader user would find navigating in a calendar drop down unless we can also provide feedback about what day of the week the date falls upon.
For the calendar drop down I can accept that the textbox value does not change until the user selects a date either via the mouse or the keyboard (although the implementation to support screen readers is more difficult as noted above). However, like I stated above I do not like that behavior for the standard combobox as that is not how the URL bars in IE, Firefox and Safari. I do think that the combobox and date picker with a calendar drop down should work the same - what are people's thoughts on this?
Here is a brief description of the calendar drop down and how navigation with the keyboard would work (irregardless of where focus goes).
The calendar drop down list has three sections - the top bar with the text display of the month with arrows to increase or decrease the month. The middle section is a grid of days with the day of the week as column headers. The bottom section currently shows a range of three years to allow decreasing or increasing the year.
For picking a single date, here is a brief overview of the keystrokes used to navigate the drop down calendar. Opening the drop down should position the highlight on the date value in the textbox or the current date if there is no value. The user can then press the left and right arrow keys to increase by day. The up and down arrow keys will decrease/increase by week/row. Pageup/pagedown will decrease/increase by a month with the highlight staying on the same numeric day rather than the day of the week. Ctrl+pageup/pagedown will decrease/increase by a year. This comes from the proposal from the DHTML style guide working group (http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0372.html). As the user navigates from month to month/year to year the calendar display updates accordingly. The keyboard user will never navigate via the top month section nor the lower year section.
That's my two cents. How can we get the issue of focus and how the value gets updated resolved?
And, to throw additional confusion into the discussion, I also like how the Mac has implemented the date picker.
In this case focus always remains in the textbox. The user left and right arrows within the text box to the part of the date to be modified (month, day or year) and that portion is highlighted. Once highlighted the up and down arrow keys change the value for that portion and the drop down display changes to match what is displayed in the textbox. I'm not sure the usability is great as it takes a bit of learning but once the pattern is recognized it is very quick to change a date. I'll have to see how the Apple VoiceOver screen reader speaks the information.
I think that I may have
I think that I may have inadvertently confused the issue in speaking of "value" of the text box.
When focusing (navigating around via keyboard) different dates, a change in the highlighted date would change the value (the *displayed* value) of the text box to correspond. Focus remains in the text box. That, if I understand you correctly, would be good for the screen readers.
The value (the *widget* value) would not be changed, however until an actual selection of the date (via or , or by tabbing away from the widget). That is, the onChange() events won't fire until that point - and calling getValue() on the widget won't return the new value until that point.
Pressing one time would close the dropdown (but leave the displayed value) - pressing esc a second time (with the dropdown closed) would revert the displayed value back to the widget value.
As mentioned by bill on http://trac.dojotoolkit.org/ticket/6430, I think that left/right should be passed to the calendar while it is opened....if a person wants to use those keys to edit a date, then they'll need to close the popup. Again, not *perfect*, but it's better than nothing.
Another thing is that we can work on getting this as good as possible - and get some feedback. I've found that at times it can get a bit hard to judge usability ideas based completely off paper...sometimes you just need to see it in action to get a good feel of where it's going.