Skip to content
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

HTMLSelectElement showPicker() #178

Open
w3cbot opened this issue Dec 20, 2023 · 1 comment
Open

HTMLSelectElement showPicker() #178

w3cbot opened this issue Dec 20, 2023 · 1 comment
Labels
agenda+ To be discussed on the next APA WG call s:html https://html.spec.whatwg.org/multipage/ tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response from a11y

Comments

@w3cbot
Copy link

w3cbot commented Dec 20, 2023

This is a tracker issue. Only discuss things here if they are a11y group internal meta-discussions about the issue. Contribute to the actual discussion at the following link:

§ w3ctag/design-reviews#900

@w3cbot w3cbot added pending Issue created by the tracker tool and may need to be refined tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response from a11y labels Dec 20, 2023
@plehegar plehegar added the s:html https://html.spec.whatwg.org/multipage/ label Dec 21, 2023
@matatk matatk added agenda+ To be discussed on the next APA WG call and removed pending Issue created by the tracker tool and may need to be refined labels Mar 8, 2024
@niklasegger
Copy link

niklasegger commented Mar 27, 2024

This is a really tricky issue and also a bit of a rabbit hole.

We have talked about the consistency between select.showPicker and input.showPicker. However, it seems that even within the input.ShowPicker cosm, the browser implementation differs greatly.
For example, you can tab into the date input picker in Chrome and Firefox (on macOS). In Safari (introduced in version 17.4) you can also see the picker, but you cannot focus it. You navigate within the input using the arrow keys and the corresponding date change is only displayed in the picker (also macOS. Maybe I missed something, just tested this briefly). So nothing to focus there. Mobile is another story.

Nevertheless, I personally tend to say that the picker or the first focusable element of the picker should be focused when opened by the showPicker function. Both for select and for the input elements. And if this is not possible, focusing the select / input element could be a backup.

I think you can also argue that the new popover API is quite similar to the pickers on a first glance (like a small overlay window that can also be opened programmatically). In a short test with Safari/Chrome and macOS, the popover was not focused after it was opened through a code function. Probably outside the scope of this discussion, but I wanted to mention it anyway.

An interesting question from zcorpan, which I would also like to mention again here, is what happens when the picker is opened by showPicker and then closed (to the comment)? Where should the focus move to? To the button that triggered the function or to the input? In my opinion, there are good points in favor of both sides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ To be discussed on the next APA WG call s:html https://html.spec.whatwg.org/multipage/ tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response from a11y
Projects
None yet
Development

No branches or pull requests

4 participants