HTMLSelectElement showPicker()

[lukewarlow]

こんにちは 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.

• Explainer¹ (minimally containing user needs and example code): inline in https://github.com/whatwg/html/pull/9754
• Specification URL: draft at https://whatpr.org/html/9754/input.html#dom-select-showpicker
• Tests: PR at https://github.com/web-platform-tests/wpt/pull/42091
• User research: None
• Security and Privacy self-review²: Hopefully not necessary; if you think it is let me know and I can fill it out.
• GitHub repo (if you prefer feedback filed there): https://github.com/whatwg/html/pull/9754
• Primary contacts (and their relationship to the specification):
  • Luke Warlow (@lukewarlow, Unafilliated, specifier and one potential implementor)
• Organization(s)/project(s) driving the specification: [organization and/or project name]
• Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/whatwg/html/issues/7957 original request for something like this. The spec largely follows that of the showPicker on HTMLInputElement so most discussion occured for that.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/5111537299881984
  • https://github.com/mozilla/standards-positions/issues/886
  • https://github.com/WebKit/standards-positions/issues/258

Further details:

• [x] 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 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

LeaVerou commented 9 months ago

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?

miketaylr commented 9 months ago

Also, Chromestatus URL seems to be private?

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

lukewarlow commented 9 months ago

Apologies have corrected that. Will also file standards positions now

LeaVerou commented 9 months ago

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

lukewarlow commented 9 months ago

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.

cynthia commented 9 months ago

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.

lukewarlow commented 9 months ago

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.

LeaVerou commented 9 months ago

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.

lukewarlow commented 9 months ago

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.

lukewarlow commented 9 months ago

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

matatk commented 5 months ago

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.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[LeaVerou]

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?

[miketaylr]

Also, Chromestatus URL seems to be private?

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

[lukewarlow]

Apologies have corrected that. Will also file standards positions now

[LeaVerou]

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

[lukewarlow]

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.

[cynthia]

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.

[lukewarlow]

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.

[LeaVerou]

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.

[lukewarlow]

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.

[lukewarlow]

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

[matatk]

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.