[select] Clarify use of Enter/Space keys for opening/closing listbox

[dandclark]

The tables in https://open-ui.org/components/select#events-1 suggest that either Enter key or Spacebar can be used to open the select's listbox when the popup is closed. If the listbox is opened (and contains focus), either Enter key or Spacebar can be used to close it.

The behavior I observe in browsers is a bit different:
Chromium: Either Enter or Spacebar can open the listbox. Only Enter can close it.
Firefox: Only Spacebar can open the listbox. Only Enter can close it.
Safari: Only Spacebar can open the listbox. Either Enter or Spacebar can close it.

Is there any particular reason to prefer any of these? My preference is to keep the current behavior at https://open-ui.org/components/select#events-1, but since all these browsers are different maybe there's some reason to be more restrictive that I'm not understanding.

[chrisdholt]

@dandclark Should we perhaps drive towards a more objective standard here in the ARIA practices documentation? Select is essentially a non-editable combobox (though I suppose we are looking to support that behavior as well). Should the behavior in question align to this document?

[dandclark]

Yes, aligning to the ARIA practices does seem like the reasonable thing to do here.

[andrico1234]

It also looks like the Open UI spec supports typeahead. Could this cause a conflict as the space could both close the select box and type text?

[chrisdholt]

It also looks like the Open UI spec supports typeahead. Could this cause a conflict as the space could both close the select box and type text?

In the case of aligning to ARIA practices, I don't believe space would close the box: https://w3c.github.io/aria-practices/#combobox-keyboard-interaction - a benefit of aligning with that standard rather than with browser specific conventions is that we avoid the issue altogether :)

[css-meeting-bot]

The Open UI Community Group just discussed TPAC Demos, anyone interested?.

The full IRC log of that discussion

<gregwhitworth> Topic: TPAC Demos, anyone interested?
<hdv> scribe: hdv
<hdv> gregwhitworth: I wanted to bring to folks' attention that TPAC is coming up in the middle of October, various groups getting together
<hdv> gregwhitworth: a common thing that happens is that demos are done
<hdv> gregwhitworth: so wanted to ask if there is any work that we have done that we would like to bring to that
<hdv> gregwhitworth: I'm thinking about things like select and spicy sections
<hdv> gregwhitworth: it's like a 'hey this is what we're working on'
<hdv> q+
<gregwhitworth> hdv: I would like to present about stuff here
<masonf> q+
<gregwhitworth> hdv: I realize that I'm not doing the work
<gregwhitworth> hdv: but if they're not I'm happy to help
<gregwhitworth> hdv: it's great work
<gregwhitworth> ack hdv
<gregwhitworth> ack masonf
<nicole> how far along should things be?
<hdv> masonf: I'd be happy to demo the popup
<hdv> gregwhitworth: nicole, it's basically like a snapshot, anything to show, can be in any stage
<nicole> So toggle might be appropriate, great
<hdv> miriam: my understanding is that these are very short videos, 2-5 minutes
<hdv> miriam: I am doing a few too for CSSWG
<hdv> [ +1, 2-5 mins is my understanding too for TPAC demo videos ]
<hdv> gregwhitworth: I can find out some more info, we could also do one 5 min one video about various things
<hdv> gregwhitworth: so would be kind of snapshot
<hdv> dandclark: seems like a short demo would be really good format for showing select
<hdv> github: https://github.com//issues/386
<dandclark> https://w3c.github.io/aria-practices/#keyboard-interaction-6

[css-meeting-bot]

The Open UI Community Group just discussed [select] Clarify use of Enter/Space keys for opening/closing listbox.

The full IRC log of that discussion

<gregwhitworth> Topic: [select] Clarify use of Enter/Space keys for opening/closing listbox
<gregwhitworth> github: https://github.com//issues/386
<hdv> dandclark: I agree with chris, we should follow what's in the ARIA Authoring Practices
<hdv> chrisdholt_: I agree with you and myself
<chrisdholt_> q+
<hdv> gregwhitworth: should we do a resolution?
<hdv> q+
<gregwhitworth> q+
<gregwhitworth> ack chrisdholt_
<hdv> chrisdholt_: there are a lot of things that exist in design systems that exist, but are not necessarily good, they just exist
<hdv> chrisdholt_: so there are certain patterns that implementers and AT drive towards
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I just saw that ARIA practices is a github preview, if we do a resolution there is a link or something?
<gregwhitworth> hdv: there can be a difference so if we link to it we have the correct link
<gregwhitworth> ack hdv
<chrisdholt_> I do believe 1.2 is out...though it may not be the link in my issue
<gregwhitworth> ack gregwhitworth
<chrisdholt_> q+
<nicole> queue
<hdv> gregwhitworth: I do wonder if Authoring Practices TF group has heard any feedback about whether it meets users needs
<nicole> queue+
<gregwhitworth> ack chrisdholt_
<hdv> chrisdholt_: a lot of what I've seen is knowledge… teams did what they felt is best, or what designers specced was based on what they felt was right for users
<hdv> chrisdholt_: I know the current carousel has some feedback
<hdv> chrisdholt_: there is a clear avenue to raise concerns
<gregwhitworth> ack nicole
<hdv> chrisdholt_: we best work with Authoring Practices group and not against them
<hdv> nicole: agreed we should work with these groups, but it is also good to note some patterns are out of date
<gregwhitworth> q+
<hdv> nicole: I've also seen that some components have merged into a single component, like accordion on mobile and tabs on desktop, ARIA guidance kind of prohibits that, so not sure if that's the right thing
<hdv> nicole: so in certain cases need to look at whether we need to update ARIA too
<hdv> q+
<gregwhitworth> ack hdv
<gregwhitworth> hdv: sometimes the ARIA guidance is out of date and it wasn't user tested, it was made with input from experts but not necessarly user tested
<gregwhitworth> hdv: it denotes if you're using the correct ARIA
<gregwhitworth> hdv: if we do our own user testing or find issues then we should update the info
<dandclark> q+
<hdv> gregwhitworth: I feel like there's agreement, based on what folks have seens, currently ARIA Authoring Practices make sense for the use case we're currently discussing (while also acknowledging that for some paterns they aren't always perfect)
<dandclark> q-
<hdv> [ +1 to gregwhitworth ]
<gregwhitworth> Proposed Resolution: any Open UI component that handles Enter/Space in combobox/dropdown/select type controls should defer to Aria Best Practices design
<hdv> chrisdholt_: I think that makes sense… our intent is to follow the authoring practices usually and provide input if needed
<hdv> chrisdholt_: so I think we bent towards using what authoring practices say, and maybe verify if they work and maybe also identify gaps and help the TF close it
<hdv> Resolved: any Open UI component that handles Enter/Space in combobox/dropdown/select type controls should defer to Aria Best Practices design
<hdv> RRSAgent, draft minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2021/09/09-openui-minutes.html hdv
<hdv> gregwhitworth: when I presented this to ARIA WG, they said they wanted the authoring practices not to exist in the long term, if controls would exist that do it
<hdv> gregwhitworth: so another resolution could be to take authoring practices as a starting point for our components
<hdv> chrisdholt_: agreed… 'as a starting point' is the key word
<gregwhitworth> Proposed Resolution: When working on specification text for behaviors and interactions leverage the ARIA Best Practices as a starting point
<chrisdholt_> lgtm
<dandclark> lgtm
<hdv> gregwhitworth: so maybe if we would end up standardising tabs and they are done, the authoring practices could be updated to link to the open ui page for that
<hdv> Resolved: When working on specification text for behaviors and interactions leverage the ARIA Best Practices as a starting point

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[chaance]

I quickly read through the IRC logs and I didn't see it noted, but if the selectmenu is used as a form control I'd expect Enter to trigger an implicit submission for UAs that support it. Would that distinction make a difference for a selectmenu that isn't associated with a form?

[scottaohara]

unless things have somehow changed in the past year+, it seems that Dan's initial observation of behavior was windows specific for chromium? on macOS its consistently space to open (among other keys that are platform specific) and enter to select an option to close across all browsers. and firefox matches that behavior on windows as well.

imo, the opening behavior should match the majority of the implementations. i'm curious why windows chromium deviates.

space does not close the popup so long as focus is actually on an option from the listbox. depending on the platform, focus may not move to the options on initial opening, which would mean that space could close the popup. This seems an area where it'd be nice to align on one behavior across platforms.

Would that distinction make a difference for a selectmenu that isn't associated with a form?

i don't think it should, because it could be ambiguous to a user whether or not the element was associated with a form.

[josepharhar]

I read through https://w3c.github.io/aria-practices/#combobox and these are my findings:

Spacebar when listbox is open

Spacebar should be for typeahead instead of selecting an option and/or closing the listbox:

When focus is in a listbox popup:
Any printable character:
If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.
Otherwise, moves focus to the next option with a name that starts with the characters typed.

Spacebar when the listbox is closed:

When focus is in the combobox:
Printable Characters:
If the combobox is editable, type characters in the combobox. Note that some implementations may regard certain characters as invalid and prevent their input.
If the combobox is not editable, optionally moves focus to a value that starts with the typed characters.

I guess that spacebar should also be for typeahead instead of opening the listbox? However, in the example space opens the listbox...

Personally I don't see any reason why pressing space shouldn't open the listbox, especially since all browsers (on all platforms?) currently open the <select> dropdown with spacebar. @chrisdholt @scottaohara what do you think?

Enter when listbox is open

The currently selected option should be chosen and the listbox should be closed:

When focus is in a listbox popup:
Enter: Accepts the focused option in the listbox by closing the popup, placing the accepted value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.

Enter when the listbox is closed

When focus is in the combobox:
Enter: If the combobox is editable and an autocomplete suggestion is selected in the popup, accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.

It doesn't say what to do when the combobox is not editable. However, the example opens the listbox when enter is pressed. Perhaps we should also open the listbox when enter is pressed? @chrisdholt @scottaohara what do you think?

[josepharhar]

@scottaohara @aleventhal If yall have any thoughts about my last comment and/or could attend the next openui meeting to discuss it would be greatly appreciated

[scottaohara]

I guess that spacebar should also be for typeahead instead of opening the listbox? However, in the example space opens the listbox...

per my previous comment, space is used to open the combobox - matching the native HTML select element - which is what the linked example is attempting to emulate (sans platform specific behaviors, since that'd be annoying for a developer to do). since selectmenu isn't an editable combobox, all the behaviors associated with editable combobox should be ignored for now.

Enter when the listbox is closed

I also touched on this in my previous comment. Enter to open is odd since that key SHOULD be used to submit a form (if the element is associated with a form). Windows Chromium is the outlier in behavior - this seems like a potential bug unless there is some reasoning for the deviation, as also the deviation ONLY on the Windows version. Chromium on macOS also only allows space to open the select element, matching other browsers on both macOS and Windows.

Reminder that APG is a good reference, but it does not represent official behavior. especially since being custom implementations to demonstrate ARIA, the authors made specific choices of browser behaviors to emulate from the different platforms.

[josepharhar]

Thanks scott! Here is my proposed behavior/resolution:

1. Spacebar while the listbox is closed should open the listbox.

As scott mentioned, this is what the existing select element currently does. This is also what the ARIA practices example does.

2. Spacebar while the listbox is open should do typeahead.

This is what the existing select element does and is what the ARIA practices says to do.

3. Enter when the listbox is open should choose the selected item and close the listbox.

This is what the existing select element does and is what the ARIA practices says to do.

4. Enter when the listbox is closed should submit the form.

This is what the existing select element does except on windows chromium. The ARIA practices is unclear and their example opens the listbox, but as scott suggested it would be better to match the existing select element and we should not open the listbox even if the selectmenu isn't associated with a form.

[css-meeting-bot]

The Open UI Community Group just discussed Clarify use of Enter/Space keys for opening/closing listbox, and agreed to the following:

• RESOLVED: Up, down, left, and right open the listbox without changing the selected option
• RESOLVED: Spacebar while the listbox is closed should open the listbox. Spacebar while the listbox is open should do typeahead. Enter when the listbox is open should choose the selected item and close the listbox. Enter when the listbox is closed should submit the form.

The full IRC log of that discussion

<gregwhitworth> Topic: Clarify use of Enter/Space keys for opening/closing listbox
<hdv> RESOLVED: Up, down, left, and right open the listbox without changing the selected option
<gregwhitworth> github: https://github.com//issues/386
<hdv> jarhar: there's the open question about what Enter/Space should do for selectmenu
<hdv> jarhar: I have a proposal: when the listbox is closed, it should open the listbox which is what current <select> does across platform and also what ARIA Authoring Practices does
<hdv> jarhar: for the Enter key, when listbox is open it should select the item and close
<hdv> jarhar: then when the listbox is closed and you press the Enter key, it should submit the form the selectmenu is associated with, it is what the select does on all platforms (APG is a bit unclear but Scott mentioned better to look at what <select> does across platforms)
<hdv> masonf: if there's no form or other thing to submit, nothing happens?
<bkardell_> q+
<gregwhitworth> q?
<hdv> jarhar: correct
<gregwhitworth> ack bkardell_
<hdv> jarhar: Scott emphasised the Enter key should submit the form
<hdv> bkardell_: nice to hear that these all align. The one that doesn't align… APG, it's volunteer work not a spec… did you or Scott file an issue with APG? would be good to get it aligned with all the other stuff
<hdv> jarhar: not yet
<hdv> [ jarhar: APG repo is here: https://github.com/w3c/wai-aria-practices )
<jarhar> Proposed resolution: Spacebar while the listbox is closed should open the listbox. Spacebar while the listbox is open should do typeahead. Enter when the listbox is open should choose the selected item and close the listbox. Enter when the listbox is closed should submit the form.
<masonf> +1
<gregwhitworth> RESOLVED: Spacebar while the listbox is closed should open the listbox. Spacebar while the listbox is open should do typeahead. Enter when the listbox is open should choose the selected item and close the listbox. Enter when the listbox is closed should submit the form.
<gregwhitworth> Zakim, end meeting

[josepharhar]

We resolved to do the proposal in my last comment