<select> naming of button and its capabilities

[gregwhitworth]

We resolved in the issue #74 to not allow interactive elements within an option. @levithomason asked if this would also be true of the top part, which currently is named which behaves as a button and an expectation of being a native <button>. That said, the web platform, due to the same issues as the <option> additional interactive elements are not allowed within them. Levi brought up scenarios such as a multi-select that shows the selected options in an input at the top that are clickable to deselect the option.

This is to review whether the current anatomy design would limit this capability or not.

For reference here is the current anatomy design:

Related to #73

[gregwhitworth]

@una based on our discussions regarding the search capability in place of the button. This is another consideration to change it from simply being a button. At minimum it would need to be a part that is not actually a button element. This should be the issue we use to determine if the button being the default top part or input text should be done and it will answer the next steps for this part of the anatomy.

[github-actions]

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.

[josepharhar]

We should allow interactive elements to be slotted in to the marker, button, and selected-value slots but not into the default slot where the <option>s go, right?

[NeilWix]

Wouldn't mixed interaction modes for keyboard users result in a problematic experience for screen reader users? Neil Osman Accessibility engineer @ accessibility team

…

On Tue, Feb 14, 2023 at 2:58 AM Joey Arhar ***@***.***> wrote: We should allow interactive elements to be slotted in to the marker, button, and selected-value slots but not into the default slot where the <option>s go, right? — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMBTHV7RORM2MESUXPHF2SLWXLKCRANCNFSM4MQKHODQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[josepharhar]

There are multi-select and searchable combobox demos here, so I don't think that the current architecture limits these scenarios: https://microsoftedge.github.io/Demos/selectmenu/

I'm adding agenda+ to confirm that the current architecture is sufficient and we can close this issue.

Wouldn't mixed interaction modes for keyboard users result in a problematic experience for screen reader users?

I don't fully understand... are you saying that if parts of a selectmenu are keyboard focusable then screen reader users won't be able to find them? Which part in particular?

[NeilWix]

Exactly. When SR users encounter a combo/list box, their expectations would be to navigate and explore the content with arrow keys only. Placing a tabbable button inside the panel of a listbox/combobox would probably be ignored by SR users

[mfreed7]

So we've discussed and resolved the issue of interactive elements within <options> (in #74) and within the listbox (in #540). This issue seems to be about interactive elements inside the button. My thoughts:

• We obviously need to allow interactive elements to be slotted into the button part. It's a button after all.
• Allowing interactive elements in the marker and selected-value slots feels broken/odd, since both of those parts are inside the button. Per-spec (here), interactive content is not allowed within a button. I think we should not do anything special in these cases, however. We should just do whatever happens today when a developer does <button><input></button> for example.

[css-meeting-bot]

The Open UI Community Group just discussed <select> naming of button and its capabilities, and agreed to the following:

• RESOLVED: The existing behavior is ok as-is.

The full IRC log of that discussion

<gregwhitworth> Topic: <select> naming of button and its capabilities
<gregwhitworth> github: https://github.com//issues/77
<hdv> jarhar: was going to propose closing this issue but then masonf commented
<jh3y> +q
<hdv> masonf: the main issue is interactive content inside the button, which would be an a11y issue. You can replace the button, but also, we have two parts inside the button, the marker and the selected value
<hdv> masonf: those two feel funny to me and could end up broken if we allow interactive content inside of it, if we're going to allow replacing the button
<gregwhitworth> agreed
<gregwhitworth> ack jh3y
<hdv> jh3y: I agree allowing interactive elements inside of marker and selected value that's odd
<gregwhitworth> q+
<hdv> jh3y: if you can select multiple items it can end up weird
<hdv> masonf: in that case you could replace the entire button in which case you're already managing selected value yourself
<hdv> masonf: in that use case you cannot use marker or select ed value slots, because you are replacing the whole button
<hdv> jh3y: you're outside of it
<hdv> masonf: it's on you to put selected value wherever you want it however you like
<hdv> masonf: if you replace the outer button the inner ones will also be gone and need to be managed by yourself
<hdv> gregwhitworth: you can put them wherever you want, but we we're not going to copy anything but a string, so we won't, like, copy innerHTML
<hdv> gregwhitworth: once you're at that use case, I agree we shouldn't actually change anything… and I don't want to go to HTML spec and then try and have this change, to allow putting interactive elements inside of buttons
<gregwhitworth> ack gregwhitworth
<masonf> Proposed resolution: The existing behavior is ok as-is.
<masonf> RESOLVED: The existing behavior is ok as-is.
<hdv> [+1 we don't want to change this behavior of button], would be big a11y issue]