Can showPicker() focus a control?

[annevk]

On iOS a control cannot show its picker without having focus. Should the web developer handle that or should showPicker() handle it for them? The latter seems somewhat reasonable given the current description of showPicker() (in particular the last step of "show the picker, if applicable"), but this would be worth calling out explicitly given the additional events that would end up firing.

Thoughts?

[lukewarlow]

Is this a platform limitation or is this something that could be addressed within WebKit?

Either way if it's a requirement for showPicker to work effectively for what it's worth I'm supportive of allowing automatic focus.

[annevk]

It's a feature of iOS, as I understand it.

[LeaVerou]

How does input.showPicker() deal with this?
When it comes to manual interaction, is it possible to have a control with an open picker that is not focused?

[lukewarlow]

Currently input.showPicker() doesn't work on iOS except for file inputs. So this spec change would be needed in order to implement it (as far as I understand)

[lukewarlow]

I've confirmed that it does appear to be a requirement for iOS. I personally think it's absolutely fine to focus where required.

Would this require a clarification in the spec or would getting verbal confirmation here enough?

[zcorpan]

Feedback from @jcsteh and @anna-yeddi - showPicker() for input and select should move focus for accessibility.

Would this require a clarification in the spec or would getting verbal confirmation here enough?

The spec should require to move focus.

I guess it should also (attempt to) move focus for file inputs?

[lukewarlow]

This would be a "breaking" change for inputs. I've got no idea if that'd actually be a problem but I'm curious if there's a specific known issue with how it's currently implemented?

[lukewarlow]

@mfreed7 @annevk would updating the spec to forcefully move focus always instead of just when needed by the platform be acceptable to you?

I don't mind either way for select. But for input it would be a change in behaviour from current implementations?

I'd also be curious on the accessibility reasoning for it? Because shouldn't the end result of showPicker be that the picker itself be focused NOT the input?

[zcorpan]

Yeah focusing the picker, and not the input, seems like the right thing. When closing/dismissing the picker, should focus go back to whatever previously had focus, or to the control that has the picker (if it's visible)?

[lukewarlow]

Ah so to clarify this issue is regarding whether the input itself is allowed to be focused as part of this method. On iOS you have to focus the input to then load the picker.

I think the spec should say it can optionally focus the input before the picker where required by the platform. And return focus would go back to either the input in iOS case or the previously focused element (such as a button) in other cases?

[jcsteh]

From an accessibility perspective, focusing the picker is the really important part. Unless I'm missing something, the spec doesn't currently require the picker to be "focused". It just needs to be "displayed"/"shown", which is a subtle but important distinction. So, I think the spec should say (not intended to be actual spec wording):

1. It can optionally focus the input before showing the picker.
2. It should show the picker, which should get focus.

[domenic]

Note that the spec for showPicker() right now works for elements which are not connected to the DOM. So they cannot be focused. I suspect that is actually the majority use case.

[jcsteh]

That's somewhat unfortunate for something like a date input, where the ability to type a date might be far more efficient for some users than using the picker. But that's probably getting out of scope for this particular issue.

[annevk]

@domenic makes sense, but that only applies to <input type=file> and maybe <input type=color>? We could special case those. Or we could allow focus to fail and then still attempt to show the picker, which then may fail due to lack of focus, depending on the platform. Does that seem reasonable?

[domenic]

makes sense, but that only applies to <input type=file> and maybe <input type=color>?

No, it applies to all pickers? Demo with date picker: https://boom-bath.glitch.me/pickers-3.html

Does that seem reasonable?

In general I think the spec seems reasonable as-is, and I'm not sure where this focus requirement is coming from... I agree with other comments upthread that focusing the picker is a good idea, but focusing the element whose existence helps show the picker seems counterproductive. The user wants to manipulate the picker, not the element!

[annevk]

Interesting, though that only seems to work in Chromium. I guess there are no tests for that particular behavior? Also, the specification doesn't make it clear where to show the picker in such cases. Is it relative to the click in some way? Presumably you'd want that to be configurable?

[lukewarlow]

Should we leave this issue open for further discussion cause I agree the offscreen input use case is important (iOS may not allow it other than for file inputs though). And get the select in without mentioning focus for now?

[lukewarlow]

Also, the specification doesn't make it clear where to show the picker in such cases. Is it relative to the click in some way? Presumably you'd want that to be configurable?

Currently Chrome seems to go with 0,0 which doesn't seem great. As you say Firefox doesn't show anything at all. Safari doesn't currently support showPicker() for date inputs but iirc my PR to add it would probably behave like Firefox.

[jcsteh]

And get the select in without mentioning focus for now?

Regardless of whether we focus the control itself, it's important that the picker gets focus for accessibility. I'm guessing you were talking about focus for the control itself, but I think it's important that the spec covers focusing the picker at the very least.

[lukewarlow]

Would something like this be satisfactory?

"If such a user interface is shown, the focusing steps for user interface must be ran."

[lukewarlow]

@jcsteh I've added the above mentioned line to the spec PR

[annevk]

That doesn't work, those UI elements are not focusable areas currently I think.

I'm also not sure it makes sense to expand this feature while it apparently isn't implemented as intended in Gecko or WebKit, and there's no way to pick a position for the UI element in the user agent that does implement it as intended.

[lukewarlow]

I meant to come back and say WebKit currently doesn't focus the picker UI instead keyboard navigating of the input is done through the input element itself (at least for date inputs). Have removed that mention of focus as a result.

In terms of how to proceed I'll leave that up to spec editors. I think there's still value even if it doesn't include elements outside the DOM being triggered (for example the issue that sparked the PR would be addressed).

[annevk]

This can maybe be folded into the more general issue around how showPicker() should work on platforms where the picker doesn't take over the full viewport (which includes mobile platforms these days), but I guess we'll keep it open for now until that issue (not sure if one has been filed even) is more clearly established as solving this.

Possibly we want to run "focusing steps" but that'd require adding these pickers as focusable areas somehow.

[lukewarlow]

require adding these pickers as focusable areas somehow.

Fwiw both Chrome and Firefox's (on desktop) pickers are currently keyboard navigable I think it's just Safari where that might be difficult due to the usage of native UI.

[newtonsgroove]

If the picker is inside of another element (ex: overlay), focus should shift automatically to the picker itself if it is the first interactive element. Once the picker is opened, focus should go to the first element contained therin. If focus is returned to the picker, and the picker is opened, then focus should go to the currently selected element.

[matatk]

Hi all. Paraphrasing TAG's design review comment here, to ask you if there have been any developments...

TAG feels that consistency between the behaviour of select.showPicker() and input.showPicker() is the top priority here.

We noted the discussion on this thread, as to whether the control, or the picker, should be focused by default. Does that mean 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 be focused? (We could think of some, but we're keen to gauge what the development community may want to do with this feature.)

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 .blur()? If the picker is not followed by default, can authors get the other behavior by running .focus()?

[btopro]

real world use-case that I just ran into then found this thread. I think this is something prevalent with design system work in which the select is wrapped as part of another designed asset / larger library.

issue I just ran into

• we have a tag called simple-fields-field which supports array based prop wiring to generate the options in a shadowRoot
• select tag is in the shadowRoot
• design work on this asset in a design system leads to their being padding on the simple-fields-field but not the select
• focus delegation for keyboard works great and opens as expected, but also that the target is outlined appropriately
• clicking in the padding / area just outside of the select causes the select to not open
• focusing on click, then having to click again inside the select tag area breaks the UX and makes the user think they missed the select box (because they did, just not as they are seeing it)

riffing as to my expectations

I would think that showPicker would focus the select tag just as if we had clicked on the select tag. If we could generate a mouse event it would have expanded the picker automatically. I can think of no standard reason a11y wise that I would want to interact with an input / expand it without additionally focusing it as the keyboard operations would take place within an element that is not actually focused outside of a 'tour' in which we are showing the possible options for a color picker (as example).

Tour edge case vs typical use-case

If I was to do a tour, that would imply that select would need to function more like a dialog:

• showModal will perform the top layer as well as the backdrop
• however I could just bind to open or the recommended show() in order to just show the item in question w.o. modal

In this way we'd need something similar where

• select supports open where it could be displayed open. this leads to possibility of breaking a11y in normal settings
• show which would be the preferred way of doing the above and wouldn't focus by default
• showPicker which would do the default accessible behavior of focus / normal blur operations as expected

Another possibility would be that showPicker has a boolean that defaults true for performing the focus behavior. I believe the vast majority of the time it's more of a delegating of focus / action as opposed to simply wanting to see the options. You could also listen for blur and issue focus back to whatever item you previously tracked without issue.

[matatk]

Hi all, just wondering if this is still the right place to be discussing this issue, or if there's some other thread we should be following too? TAG is interested in following developments.