#900: HTMLSelectElement showPicker()

Visit on Github.

Opened Sep 20, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of the showPicker() method for HTMLSelectElement.

The showPicker() element is a new addition to HTMLSelectElement which addresses a common request from web developers: programmatically showing the options picker for select controls.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: None
  • The group where the work on this specification is currently being done: WHATWG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): N/A
  • Major unresolved issues with or opposition to this specification: https://github.com/whatwg/html/issues/9757
  • This work is being funded by:

You should also know that...

https://github.com/w3ctag/design-reviews/issues/688 is the relevant review request for the input element. It was closed as unsatisfied because there's no way to detect if the method does anything. While the spec doesn't mandate this do anything for <select> all implementations have a picker and therefore it will so hopefully that problem doesn't matter for this request.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @lukewarlow

Discussions

Comment by @LeaVerou Sep 20, 2023 (See Github)

Hey, thanks for submitting this. Vast array of developer use cases, so this is exciting. Main issue I see is lack of multi stakeholder support. Have standards positions been requested from WebKIt and Mozilla? If so, could you please link to them?

Also, Chromestatus URL seems to be private?

<img width="799" alt="image" src="https://github.com/w3ctag/design-reviews/assets/175836/0acea764-c047-4990-bfcf-aad1839ce542">
Comment by @miketaylr Sep 20, 2023 (See Github)

Also, Chromestatus URL seems to be private?

Seems like just a mis-pasted URL. Try https://chromestatus.com/feature/5111537299881984

Comment by @lukewarlow Sep 20, 2023 (See Github)

Apologies have corrected that. Will also file standards positions now

Comment by @LeaVerou Oct 2, 2023 (See Github)

Removing "fast track?" as @cynthia had some concerns about a11y. @cynthia could you please elaborate here?

Comment by @lukewarlow Oct 2, 2023 (See Github)

Just to keep Tag in the loop I've filed an intent to ship. https://groups.google.com/a/chromium.org/g/blink-dev/c/qew_ILTXWSY/m/AxHrcWzuAQAJ Obviously if any major concerns arise I'll address where possible before shipping.

Comment by @cynthia Oct 2, 2023 (See Github)

So if I understand the proposal correctly, calling showPicker() would show the picker (which presumably would change the accessibility tree, since the picker is expanded now) but not necessarily move the focus. Has this been tested with a screen reader for usability?

Concern is that from a content author perspective the expansion of the picker would imply that the user is able to enumerate the choices (visually), but that assumption may not hold when the user depends on AT.

Comment by @lukewarlow Oct 2, 2023 (See Github)

I have tested on macOS with Voice Over and it seems to behave as I would expect. You can focus the button when you press enter it moves focus to the first item in the select picker selecting an option returns focus to the button you're on. (or Ctrl + Option + Space moves focus to the menu arrow keys correctly navigate and it otherwise works like enter)

I don't have access to other desktop platforms to test but https://select-show-picker.glitch.me/ can be used in Chrome Canary (experimental flag on) to test it.

As for the correct aria markup for the button I am not sure but the same issue would arise with the existing input.showPicker(). https://github.com/keithamus/invoker-buttons-proposal should help with the declarative aspect of this.

Comment by @LeaVerou Oct 2, 2023 (See Github)

Concern is that from a content author perspective the expansion of the picker would imply that the user is able to enumerate the choices (visually)

Not necessarily, the <select> element may be scrolled out of the viewport, so a sighted user wouldn't notice either.

Not sure if focusing the control first would preclude this from satisfying any of its use cases, but since input.showPicker() does not focus the control first either, it would definitely make it inconsistent, which I think is worse.

Actually, it would be good to have a list of use cases for both. The explainer for this does not list any use cases, and neither did the TAG review for input.showPicker(), which makes it hard to weigh the different tradeoffs.

Comment by @lukewarlow Oct 2, 2023 (See Github)

Based on https://github.com/whatwg/html/issues/9757 the spec may explicitly allow focusing the target element where required but the default would be to not focus the input (or select).

I don't think the select method would add any new confusion beyond that which might exist for the input method.

Comment by @lukewarlow Oct 2, 2023 (See Github)

https://github.com/whatwg/html/issues/7957 includes an example use case for this function.

Discussed Dec 1, 2023 (See Github)

Matthew: the PR to HTML has been merged... And I'm aware that there's an existing similar thing input.shoePicker method... couple of questions - one is about use cases. Issue of focus management was brought up. Not clear to me. Another question - more practical - how it behaves on certain devices.

matthew to ask questions on the issue

Matthew: developer ask was cited as justification - yes developers are asking for it but not saying what they're going to use it for - so not clear what the use cases will be. I can see "open attribute" - another is "programatically open"... not clear what that is. A particular solution has bee chosen... the ship may have sailed but would be good to know what they're trying to do. If they want to open the popup because of a user action I'd err on the side of not doing focus management... I think they're not doing focus management...

we agree we will come back to it at the plenary

Discussed Jan 1, 2024 (See Github)

reassigned and we decided not to talk about it this week

Comment by @matatk Jan 12, 2024 (See Github)

Hi @lukewarlow. Thank you for your patience.

We feel that consistency is the top priority here: if select.showPicker() and input.showPicker() do not behave consistently, this could create worse accessibility issues, not to mention DX.

We note there's ongoing discussion in whatwg/html#9757 as to if the control, or picker, should be focused by default, which perhaps indicates that the behavior of input.showPicker() can still be changed?

It's important to have a clear idea of the expected use cases. Are there any use cases that require the control/picker to not be focused?

How easy the default behavior is to escape is also a factor. If the picker is focused by default, can authors get the alternate behavior by running input.blur()? If the picker is not followed by default, can authors get the other behavior by running input.focus()?

We suggest that you talk with the Accessible Platform Architectures (APA) WG to arrive at some guidance for authors that could be incorporated into the spec as a note.

Looking forward to your response, especially around use cases.

Discussed Mar 1, 2024 (See Github)

Matt: no progress since we posted that issue... right now it's open - our main concern is consistency... We're hoping if we need to change what the default is that it's still new enough to do that. I'd like to post on this WHATWG thread... to encourage them to come back and let us know "this is why we think it would be the default behaviour"... OK? I will subset the TAG comment. Some assistive tech people have said "you should do this" some platform providers "you should do that"...

Dan: Sounds good to me.

Discussed Apr 1, 2024 (See Github)

Matthew: no movement on the thread... but in the WHATWG thread it's still open - one of APA's members commented on this. There are some people in that thread who are in a position to make a change if it's needed. It looks like we're still in an area where we could positively impact the consistency issue... So I'll bump the WHATWG thread... When I bump, I will let Lea know. The one thing we've (TAG) asked for - to show the picker (but it's whether it gets focussed or not) - we need to make call of what the use case is... Is common use case one where it gets focus, or not? [what is the default].

Discussed May 1, 2024 (See Github)

Note from Breakout A: @matatk pinged on the WHATWG thread

Discussed May 1, 2024 (See Github)

Matthew: I pinged them in the WHATWG thread.

we re-assign to a later breakout - breakout D

Discussed Jun 1, 2024 (See Github)

Matthew: there is an update - last month I posted a comment on the WHATWG issue - to make sure our advice was imparted to a wider group. There has been some feedback. Looks like feedback from use cases they have experienced as a developer. Quite extensive feedback. But no more discussion from the people involved... I can have a look at the developer feedback. Our main concern was consistency. There's a window of opportunity if needed. Between all of us we thought of cases on both sides. It needs to be consistent & documented and there needs to be an escape hatch. There was a subplot involving whether the picker or the control can be focused and that hasn't been resolved. Potentially some confusion here...

we agree we should keep monitoring and we can re-review at the f2f

Discussed Jul 1, 2024 (See Github)

Matthew: last things that happened were - we asked for more info on the TAG thread... looking at more use cases... desire for consistency... we didn't get any response... then I posted on the whatwg thread paraphrasing our concerns on there.. No input on that thread at all except for a comment from a web developer... So I don't know if we're missing some other place where this is being discussed... so not much progress. The concern is that the longer it goes on the longer the current behaviour is entrenched. We might propose to put a note in the spec to expand on any a11y issues.

Dan: what was the feedback from the web developer?

Matthew: it's about what they think the typical use case is... mostly coming down on one side of that... The thing we're concerned about is... we've had time to think about use cases one way or the other way but we are concerned with the default...

Matthew: posted a comment to check on status

Discussed Nov 1, 2024 (See Github)

Matthew: I think this has no updates... essentially we asked for their idea about use cases... we particularly pointed out that they need to behave the same way... we really wanted to know about use cases... we asked. No reply. I periodically have checked the WHATWG thread and not much activity.

Tess: No insight.

Peter: I also had concerns about feature detection... it would be nice to tell if it's available... people outside the TAG didn't seem to care. I think it's important.

Jeffrey: it's in a weird state - caniuse doesn't mention it https://chromestatus.com/feature/5111537299881984 says it's shipped - and somewhere else says it missed a window. So I will reply on the thread and ask what happened. Also staff changes might have disrupted work on this.

let's revisit at plenary

Reply on blink-dev: it did ship in 121 and is listed at https://developer.mozilla.org/en-US/docs/Web/API/HTMLSelectElement/showPicker as having shipped in Firefox too.