-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[select] Clarify use of Enter/Space keys for opening/closing listbox #386
Comments
@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? |
Yes, aligning to the ARIA practices does seem like the reasonable thing to do here. |
It also looks like the Open UI spec supports typeahead. Could this cause a conflict as the |
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 :) |
The Open UI Community Group just discussed 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 |
The Open UI Community Group just discussed 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 |
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. |
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 |
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.
i don't think it should, because it could be ambiguous to a user whether or not the element was associated with a form. |
I read through https://w3c.github.io/aria-practices/#combobox and these are my findings: Spacebar when listbox is openSpacebar should be for typeahead instead of selecting an option and/or closing the listbox:
Spacebar when the listbox is closed:
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 Enter when listbox is openThe currently selected option should be chosen and the listbox should be closed:
Enter when the listbox is closed
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? |
@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 |
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.
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. |
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. |
The Open UI Community Group just discussed
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 |
We resolved to do the proposal in my last comment |
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785}
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785}
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785}
This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785}
…ior, a=testonly Automatic update from web-platform-tests selectlist: Implement new keyboard behavior This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785} -- wpt-commits: 020d2129c354423b490e1447f13463829ab92bc0 wpt-pr: 42068
…ior, a=testonly Automatic update from web-platform-tests selectlist: Implement new keyboard behavior This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1207785} -- wpt-commits: 020d2129c354423b490e1447f13463829ab92bc0 wpt-pr: 42068
…ior, a=testonly Automatic update from web-platform-tests selectlist: Implement new keyboard behavior This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarharchromium.org> Reviewed-by: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1207785} -- wpt-commits: 020d2129c354423b490e1447f13463829ab92bc0 wpt-pr: 42068 UltraBlame original commit: ffe5b326db40e78be875dcaa486226af32ff2110
…ior, a=testonly Automatic update from web-platform-tests selectlist: Implement new keyboard behavior This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarharchromium.org> Reviewed-by: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1207785} -- wpt-commits: 020d2129c354423b490e1447f13463829ab92bc0 wpt-pr: 42068 UltraBlame original commit: ffe5b326db40e78be875dcaa486226af32ff2110
…ior, a=testonly Automatic update from web-platform-tests selectlist: Implement new keyboard behavior This patch implements several keyboard behaviors: - Enter while the listbox is closed should not open the listbox and should instead submit the form. - Enter while the listbox is open should select/commit the currently focused option and close the listbox. - Space should open the listbox. - Arrow keys while the listbox is open should not commit the newly focused value. - Arrow keys while the listbox is closed should open the listbox. These were resolved on in OpenUI here: - openui/open-ui#433 (comment) - openui/open-ui#386 (comment) - openui/open-ui#742 This patch also implements the resolution here to stop changing the visible value of the selected option while the user is switching the focused option using the arrow keys: Fixed: 1422275 Change-Id: If5e7328ad739f9c7339dcd17561c57875d4255e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4876791 Commit-Queue: Joey Arhar <jarharchromium.org> Reviewed-by: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1207785} -- wpt-commits: 020d2129c354423b490e1447f13463829ab92bc0 wpt-pr: 42068 UltraBlame original commit: ffe5b326db40e78be875dcaa486226af32ff2110
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.
The text was updated successfully, but these errors were encountered: