Select-Only ComboBox pattern keyboard support clarifications

[silviuaavram]

Hello everyone! I would like to ask a few clarifications about the Select-Only ComboBox.

When menu is closed, UpArrow First opens the listbox if it is not already displayed and then moves visual focus to the first option. However, when I press UpArrow, the visual focus is on the selected item (which incidentally is the first option initially). The same happens on DownArrow, there is no difference. Also on Space and Enter.

What is more, if I change visual focus without selecting an item, close the menu, and open it back again, the visual focus is placed on the item that had visual focus right before closing. Is this expected? Should we update the table with the Function or the actual working example?

I remember that the 1.1 pattern, on up/down arrow, the menu was opened with a -/+ 1 offset relative to the selected item, or to 0 / lenght - 1 if there was no item selected.

Consequently, I would like to understand what is the exact pattern requirements from ARIA and if we need to update anything in that example page. Thanks very much!

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Select-Only ComboBox pattern keyboard support clarifications.

The full IRC log of that discussion

<MarkMcCarthy> TOPIC: Select-Only ComboBox pattern keyboard support clarifications
<MarkMcCarthy> github: https://github.com//issues/2440
<MarkMcCarthy> sarah_h: currently the up arrow moves it to the selected item
<MarkMcCarthy> Matt_King: what about if something isn't selected?
<MarkMcCarthy> sarah_h: since 'choose a fruit' is an option, there's never not something selected
<MarkMcCarthy> sarah_h: right now, the single select doesn't follow focus; we don't HAVE to send focus to the currently selected but...
<MarkMcCarthy> Matt_King: i think we should, but I'm thinking about what the default state should be
<MarkMcCarthy> Matt_King: what would happen if it WASN'T in the list
<MarkMcCarthy> sarah_h: i don't remember why we put focus in there in the first place
<MarkMcCarthy> Matt_King: how does HTML select work?
<MarkMcCarthy> sarah_h: ours mirrors HTML select more - it's impossible to add a placeholder. if you need choose something, it HAS to be in the list
<MarkMcCarthy> sarah_h: one of the nice things about building your own is you don't have to worry about things too much
<MarkMcCarthy> Matt_King: what about open_ui?
<MarkMcCarthy> sarah_h: that's even more flexible
<MarkMcCarthy> siri: maybe one of the reasons we have that is if a user doesn't want to select ANYTHING
<MarkMcCarthy> Matt_King: but if you want to return it to its default state of nothing, how do you do that if it's not in the list?
<MarkMcCarthy> bryan: the way i've done it in the past with aria-select is to allow the spacebar to toggle/unset aria-selected
<MarkMcCarthy> bryan: the way I was able to do that was, for the roving tabindex model, was to put tabindex=0 on the first item
<MarkMcCarthy> bryan: after pressing the spacebar, you can tab away with nothing selected
<MarkMcCarthy> Matt_King: we're combining two behaviors here - 1) selection doesn't follow focus so people can read items without triggering a change.
<MarkMcCarthy> Matt_King: there's a common expectation though that pressing an arrow or letter will jump to that item, and tabbing away/on.blur leaves it selected
<MarkMcCarthy> bryan: to me that's confusing
<MarkMcCarthy> Matt_King: if we made selection follow focus, there's a thought that the display should change if that's the case
<MarkMcCarthy> sarah_h: also the possibility of esc to cancel
<MarkMcCarthy> Matt_King: i guess we could have selection follow focus and no tupdate input?
<MarkMcCarthy> siri: in that case, wouldn't it act more like a radio button then? if there's no way to get back to default
<MarkMcCarthy> Matt_King: the only way you can select an empty value in is to put an empty value in the list
<siri> https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html
<MarkMcCarthy> bryan: if we're going to have selection follow focus, that can cause trouble for mobile users
<MarkMcCarthy> Matt_King: so the root question is, do we need the 'choose a fruit' option in the list?
<MarkMcCarthy> Matt_King: i think it makes it more complicated if it's NOT there
<MarkMcCarthy> sarah_h: i think it'd be possible to remove it from the list, and just make a 'none' options
<MarkMcCarthy> s/options/option
<MarkMcCarthy> sarah_h: the convention having the placeholder text in the list is a byproduct of no placeholder in a native select
<MarkMcCarthy> +1
<MarkMcCarthy> Matt_King: if you have 'choose a fruit' as placeholder, then at that point is 'none' selected?
<MarkMcCarthy> sarah_h: yeah
<MarkMcCarthy> Matt_King: so that doesn't move us anywhere then i guess
<MarkMcCarthy> sarah_h: if you as an author want to give people an ability to move to null as an option, it's gotta be there. and 'none' makes more sense
<MarkMcCarthy> Matt_King: if 'none' is selected, does the placeholder -only- show up on page load and no user interaction?
<siri> can you give correct link?
<MarkMcCarthy> sarah_h: we could do whatever we'd want with that. we could also add it as a new option
<MarkMcCarthy> Matt_King: so, are we proposing that, with this hypothetical one, that nothing is slected at all in the beginning - not choose a fruit, not none, nothing.
<MarkMcCarthy> sarah_h: this is difficult because these considerations would be dictated by real world constraints
<MarkMcCarthy> Matt_King: the reason up arrow goes to the first item in the list is because the first item is selected by default. if nothing were selected, it could move to the last item
<MarkMcCarthy> sarah_h: correct
<siri> https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html - hope this right one :)
<MarkMcCarthy> Matt_King: until we have an attribute like aria-value, it feels like there has to be something selected by default
<MarkMcCarthy> sarah_h: the idea of putting something in that's "not a real value" shouldn't matter much, as long as the actual value makes sense
<MarkMcCarthy> sarah_h: exposing 'choose a fruit' as the programmatic value doesn't mean it has to be in the list
<MarkMcCarthy> Matt_King: if it's not in the list at all, and if nothing is selected, if they press escape and tab away, it'd retain its initial state, then?
<MarkMcCarthy> Matt_King: or, would there be no way to return it to its intial state?
<MarkMcCarthy> Matt_King: it seems scenario dependent
<MarkMcCarthy> sarah_h: in general, the idea of not being unable to return a form field to its virgin state isn't uncommon
<MarkMcCarthy> Matt_King: that's true
<MarkMcCarthy> Matt_King: i guess that's the crux of this discussion, and the answer is no, and a consequence of that is 'choose a fruit' isn't in the ilst, and the outcome of THAT is nothing is selected by default
<MarkMcCarthy> Matt_King: and THAT means pressing the up arrow should select the last item rather than the first
<MarkMcCarthy> sarah_h: the up arrow going to the last item IS different than an HTML select, but I think that's fine
<MarkMcCarthy> MarkMcCarthy: i think that's fine too
<MarkMcCarthy> Matt_King: to address the 'what is more' part --
<MarkMcCarthy> sarah_h: oh that's a bug. it should go to the last selected item when it's reopened
<MarkMcCarthy> Matt_King: that's a great catch
<MarkMcCarthy> s/it should go to the last selected item when it's reopened/it should go to the currently selected item, which may be different from the last selected item
<MarkMcCarthy> sarah_h: in summary, if an item is selected, and you open the combobox, focus goes to the selected. if nothing is selected, up/alt-up/down/alt-down goes to the first/last item
<MarkMcCarthy> sarah_h: might need a slight documentation change
<MarkMcCarthy> Matt_King: as a note, the linked example in this issue is from the editor's draft, not current
<MarkMcCarthy> Matt_King: so it does need doc updating

[silviuaavram]

My bad, the example probably is this one.

Looking at the above discussion:

• If there is a selected item, Up/Down arrow opens the combobox with the selected item highlighted.
  • The current highlight behaviour is a bug, the combobox should not remember the previously highlighted item (which can be different from the selected item) and it should be fixed.
  • What difference does the Alt key make in this case? Should we remove Alt + Down Arrow from the documentation table?
  • We can probably keep the Alt + Up Arrow use case when the menu is open, which performs selection. But this is different from the native <select>, where Alt + Up/Down Arrow work exactly as Home/End when the menu is opened: the first/last item get highlighted.
• If there is no selected item, Up Arrow should open the menu with last item highlighted, and Down Arrow should open the menu with first item highlighted. Note: The native <select> always opens with the first item highlighted, on either Up/Down Arrow.
• More notes: The native <select> just prevents event default when Tab (no selection, no focus switch, nothing). Also, it does not open the menu on Home/End.

Let me know what you think! I'd be happy to create a PR with fixes and doc updates! Thanks!

[smhigley]

My inclination would still be to set the active option to the selected option when the combobox re-opens.

Re: the up arrow going to the last item behavior and the tab behavior: there are some intentional differences between the APG patterns and the native <select>. The tab-to-select behavior in particular is something I've observed is desirable in usability studies. I don't have strong opinions on which item is highlighted on up arrow when nothing is selected, but I wouldn't necessarily tie that behavior to what happens in <select>, particularly if there's something we think we can do better. The native control is a good guide, but definitely not perfect