Allowing interactive elements within an <option>

[gregwhitworth]

As we continue to dig into the <select> one aspect that is abundtly clear when I review the many different ways in which a <select> is used is the need for arbitrary content within an <option>. While this sounds easy on the surface it raises a bunch of interesting questions, one primary one being whether we should allow interactive content within an option or not. I have currently stated in the spec that a select will not allow any additional interactive elements (and then list them out).

When I look at the usecases where interactive elements are common in a control that is <select> like, checkboxes and radio inputs are the most common. For example here is Fluent:

and here is Safari's built in <select>:

Both of these behave in the same manner. The only aspect that is actually "selectable" is the option itself. And if the <option> can take in an SVG there is nothing stopping fluent, or anyone for that matter, to insert a checkbox icon and change it on checked state of the option as this now becomes possible.

While I do like the idea of authors being able to just insert a checkbox input there are far too many implementation and spec edge cases to contend with. Does anyone disagree with this position?

[chrisdholt]

I think the above is in alignment with what we would expect from the control and the flexibility we would need. I feel that the design intent here is visual so providing a way to support that visual styling would solve the issues.

I have currently stated in the spec that a select will not allow any additional interactive elements (and then list them out).

Wholeheartedly agree with this. From a functional standpoint, I think it's a huge can of worms likely from a platform perspective, but also from an AT perspective to include interactive elements within an <option> (or likewise role="option"). While the roles model is different for menus (menuitem, menuitemradio, menuitemcheckbox) the scenario is the same. While unrelated to select, this may be something to create a more broad principle or alignment around.

Either way, I'm in agreement for sure and I think the proposed solution for enabling the ability to include visuals such as a "checkbox" icon.

[nicholasrice]

Agreed with not supporting interactive elements inside of the select option. ARIA addresses this directly: https://www.w3.org/TR/wai-aria-practices-1.1/#Listbox

Thus, if an option contains a semantic element, such as a heading, screen reader users will not have access to the semantics. In addition, the interaction model conveyed by the listbox role to assistive technologies does not support interacting with elements inside of an option. Because of these traits of the listbox widget, it does not provide an accessible way to present a list of interactive elements, such as links, buttons, or checkboxes.

[gregwhitworth]

Based on the current ARIA standards and the expectations that a user has for an option we resolved on this in today's telecon to keep the current verbiage and NOT allow interactive elements within an option.

Minutes are here: https://www.w3.org/2020/04/24-openui-minutes.html