[selectmenu] Arbitrary content in <listbox> element

[dandclark]

During an earlier meeting we discussed multi-select for <selectmenu>, and ended up resolving that we should work on specifying a <listbox> element to use for <selectmenu>'s listbox popup.

I want to clarify whether this is going to conflict with one of our early requirements for <selectmenu>, which is that authors can fully customize the contents of a select.

We had clear feedback that one of the main things keeping developers from using the browser's native controls is the lack of control over their content, including the ability to add arbitrary markup. So (speaking for the Edge web platform team here) we would not have a lot of interest in implementing a <selectmenu> that fails to meet this requirement.

Thus if we're using a new <listbox> element for the <selectmenu>'s dropdown, <listbox> would need to allow arbitrary HTML content.

There is a tension here with the <listbox>'s default ARIA role. The listbox role expects that all of its children have the option role, but if developers can include arbitrary content in the listbox then this will not necessarily be the case.

I think this is OK. For most use cases of <selectmenu>, the default listbox aria role will be appropriate for its <listbox>. If a developer builds something more outlandish -- for example a <selectmenu> whose dropdown contains other controls -- then it is the developer's responsibility to specify an appropriate ARIA role.

This will be better than the current state of things where listboxes and select dropdowns are built "by hand" out of <div>s where accessibility is completely dependent on the developer even for very simple re-implementations of these controls.

So, is it OK for the <listbox> to allow arbitrary HTML content? It seems that it must do so in order to support our goal of allowing authors to specify arbitrary HTML for <selectmenu>.

[scottaohara]

seems like defining the level of arbitrary content would be necessary? If these new element proposals are also supposed to be accessible by default, then being completely permissive with allowed content makes that incredibly hard. If there are expected types of elements or sub-components that can be slotted in, then it that sounds like it could meet the needs of what people probably want?

For clarity though, is it an expectation that a listbox should allow for arbitrary content, or that its options were to allow for such? I've found content in open ui / greg's original blog post about styling the select element about the latter, but not the former? I'm sorry if I've missed something.

But, trying to brainstorm here a bit.... under the assumption that it's options that should allow for more types of content as their children, is a potential solution to allow a <selectmenu> to contain a <listbox>, where the <option>s of the listbox could allow for additional content types beyond and styleability beyond what is presently allowed with the current <select> element? Arguably it could be worked out that additional styling elements like <div>s could be treated as expected elements and so long as they didn't contain any content or functional elements of their own, their existence could be suppressed from the accessibility tree.

And to meet the needs of a far more customizable component, could the <selectmenu> then also allow for a descendant <dialog>... which would allow for a wide variety of content types to be a child of the dialog. That would then be able to allow for a pathway forward to a larger level of arbitrary content, without necessitating immediate changes to expectations for listbox descendants? A dialog popup wrapper being a common expectation for more complex combobox UI.

There's a lot of potential details that i'm leaving out here... but i've already likely written too much. :)

[dandclark]

For clarity though, is it an expectation that a listbox should allow for arbitrary content, or that its options were to allow for such?

Ideally we'd like to have both. We know that developers want to be able to put things like images inside options, but there are also scenarios where arbitrary content outside of the options is useful. @captainbrosset's demos show some example use cases, such as the Scroll indicators demo. That one wouldn't have been possible if the scroll indicators weren't allowed to live in the dropdown, outside of any <option>. But it seems like semantically this dropdown is still safely in the realm of a listbox.

Arguably it could be worked out that additional styling elements like divs could be treated as expected elements and so long as they didn't contain any content or functional elements of their own, their existence could be suppressed from the accessibility tree.

I think it's important to allow at least some non-option content that is visible to accessibility in order to build things like headers between sets of related options. Even the old <select> supports a rudimentary version of this via <optgroup>

Patrick's Color Select demo goes further in showing how it can be useful to divide options into separate groups:

I think it would be disappointing if developers couldn't have groups of options that could be separated with styled section headers like this.

Although this demo has more than just the section headers -- the "More colors" button would presumably open some other dialog. It seems useful to be able to build this sort of thing, but does this fall outside the purview of <listbox>? If so, how do we distinguish between things like section headers that should be allowed, and sub-controls like buttons that would be more semantically appropriate for a dialog?

[scottaohara]

@dandclark for the optgroup labels/headers - agreed. we need something here to allow for more styling flexibility beyond the current visible group label which is rendered by optgroup label=foo. but it'd be best if that were allowed in a specific way... as per the current examples Narrator, NVDA and JAWS don't actually associate the grouping/label with the nested options - which makes sense because there's no explicit group or programmatic setup to use the text as an accName for the generic groups that were made.

we don't want the grouping labels to be directly accessible, but we essentially want a mechanism in place that would behave similarly to a fieldset and legend, where authors should be able to specify an optgroup and either provide a visible label via the label attribute to maintain parity with how it can be currently done, or that is thrown out and authors need to explicitly declare something like

<listbox ...>
  <optiongroup>
    <oglegend>put your group label and some other non-interactive content here</oglegend>
    <!-- options -->
  </optiongroup>
</listbox>

per the more colors 'button' - arguably that could very well still be an option so long as the resulting UI that is rendered provides a way to make a selection that will return a value to the invoking combobox to display.

though, as i've mentioned before, this color picker example is definitely pushing the limits of what would be expected here, and not just what's rendered as the listbox content, but the fact that the invoking control is more akin to a splitbutton type control than combobox. (note: that the element that invokes the popup has no accessible name, nor do any of the color options).

So yes. I think we can and should figure out ways to make UI like this easy to create and accessible. But right now, this particular demo is not accessible, so let's keep talking about how to make it so.

[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.

[dandclark]

We resolved in #531 to defer specifying a <listbox> element. The issue of arbitrary content in the selectmenu listbox was discussed in #540, and the issue of optgroup labeling was discussed in #558, so I'm going to close this one out.