[selectmenu] Restricting interactive content in <selectmenu> listbox

[dandclark]

A goal of <selectmenu> is that it is accessible by default.

The way this will be achieved is that when an author provides their own instances of the <selectmenu>'s predefined parts (button, listbox, and options), the platform will ensure that they have the correct a11y semantics by applying appropriate ARIA roles and specifying relationships like aria-haspopup="listbox".

Ensuring that the <selectmenu> is fully accessible becomes more difficult when the author adds arbitrary interactive content via the <selectmenu>’s named slots, particularly inside the listbox part. Adding, for example, extra buttons inside the listbox is problematic because ARIA and accessibility tech doesn’t expect to find interactive content in a listbox aside from the options themselves. See the content restrictions of the listbox role.

Through extensions to ARIA, accessibility tech, and <selectmenu> controller code, it may eventually be possible to make some or all of these scenarios accessible by default. In particular, see the aria-actions may eventually provide a mechanism for supporting interactive content inside of listbox options.

In the meantime, to guide developers away from creating inaccessible scenarios, I'm proposing that <selectmenu> emit a console warning when an author slots any interactive content into the <selectmenu> (aside from the elements designated as button, listbox, and option parts). “Interactive content” for this purpose is defined as any of:

• Form controls
• Any other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others...
• <iframe>
• Anything given focusability via tabindex, e.g. <div tabindex="0">.

We could also consider more restrictive enforcement of this, such as making the <selectmenu> inoperable if interactive content is present. This is likely overkill though. There are some scenarios where interactive content can exist without breaking the control for AT users, for example the Scroll Indicators demo here. If we completely prevent devs from using <selectmenu> for these types of scenarios, they will build these scenarios with <div>s (as is the case today) without any a11y support and without console messages to warn them about potential a11y issues.

This was previously discussed in the context of <listbox> at https://github.com/openui/open-ui/issues/458, but I want to scope the discussion here to specifically interactive content. We're exploring other potential ways for handling accessibility of noninteractive content like optgroup headers -- more to come on that later.

[smhigley]

I like the idea of sending a console warning for unsupported content! I'd also like to throw a few other possibilities out too -- my one misgiving with only the console warning is whether it sets up the idea that interactive content is not allowed while also allowing it in practice. I'm worried that sort of equivocation from the browser will end up being confusing to authors, and risks being simply ignored -- at least without clear guidance on what to do about it.

I'd love other people's thoughts on these additional options:

• Instead of making <selectmenu> fully inoperable when interactive content is present, remove the prohibited tags, similar to what happens with <select> and other elements today
• Assuming the goal is to eventually allow some types of interactive content, take the console warning for supported-in-the-future content (e.g. secondary actions within options) while removing elements in places that will never be supported
• If the idea is there are some valid uses of interactive content that depend on author implmentation, could we nail down what those are and make sure the console warning gives guidance (or links to guidance) about what an authors needs to do to make the interactive content OK?

Regarding that last point, I was wondering if anyone had more examples of interactive content within a <selectmenu> that can be made accessible by an author. The linked Scroll Indicators demo doesn't actually look like it has interactive content to me, so I think that one wouldn't be blocked no matter what approach is taken.

I think more concrete examples of potentially OK interactive content would help a lot, since I can't think of any right now that could be made accessible by an author without fully changing the semantics of the listbox, or the keyboard behavior, or both. I know I work with a pretty biased range of UI though, so I know I'm not thinking of all possible use cases :).

I did write up a list of the types of content I could think of authors attempting to put within a <selectmenu> and the semantics and keyboard functionality that would need to be implemented to have be accessible: https://gist.github.com/smhigley/5eb3ee829f1ee963c01397ba4db2da1a. It's not comprehensive, but I thought I'd link it here in case anyone finds it helpful.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox #540.

The full IRC log of that discussion

<hdv> Topic: [selectmenu] Restricting interactive content in <selectmenu> listbox #540
<hdv> github: https://github.com/openui/open-ui/issues/540
<JonathanNeal> dandclark: right now in a select menu, authors can put whatever they want. very early in the process we talked about what kinds of restrictions this would have, and we didn’t add any. more customizability seemed good. now there seems to be a good reason to restrict this content; accessibility. the accessibility model does not expect to see anything in there but basic options; they don’t expect to find any other kinds of content like
<JonathanNeal> widgets. such non-option things would break stuff. what do we do about this? we don’t want to encourage patterns that will not be accessible.
<flackr> q+
<Travis> auto-inert for such typically interactive elements?
<JonathanNeal> dandclark: in the issue, i recommend the restrictions trigger a console, and I learned recently we could use another pane in the developer tools.
<JonathanNeal> dandclark: the restrictions would include things like form controls, summary/details, media elements, or things that could receive tabindex; just interactive content.
<masonf> q?
<dandclark> Proposed resolution: When interactive content is inside a selectmenu's listbox, the selectmenu will continue functioning but the UA should should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex.
<sarah_higley> q+
<AlexanderFutekov_> q+
<hdv> ack flackr
<JonathanNeal> flackr: I feel like this is really limiting the use-cases. like “choose the day” with something inside like “choose the time slot”. is there not a way to expose these that the accessibility tool would be ready to handle these more complex cases?
<masonf> q+
<JonathanNeal> sarah_higley: I probably have to see an example of what you mean. Do you mean something like “select a day” and then the entire select menu changes?
<JonathanNeal> flackr: this would be more common in the case with select menus that do not auto-dismiss. I'm trying to think thru some of the richer content authors might use.
<dandclark> q+ to mention that if there are compelling scenarios involving interactive content, ARIA and ATs could be enhanced to make these scenarios accessible, and <selectmenu> could be made more permissive to allow them.
<bkardell_> q+
<JonathanNeal> sarah_higley: I did make a gist that has some examples of more advanced content. What you are describing seems more like a dialog popup. It would have to not dismiss any click. It would have to trap arrow keys, tabs. I’m guessing it would have a dialog role at the top and non-list semantics inside. That would mean restructuring all of the semantics for many things, which seems like something that wouldn’t be easy for authors to do
<JonathanNeal> with the select menu.
<JonathanNeal> flackr: another example off the top of my head would be summary/details.
<masonf> q?
<JonathanNeal> sarah_higley: I've seen people try to make that. I feel like the way to do that is, if you want to keep this in a select-menu, is to do something different like a grid menu, or make one of the options be clickable to expand something else.
<hdv> ack sarah_higley
<JonathanNeal> sarah_higley: I am very open to being wrong about this, but I suspect there is not a way to make extra-interactive content accessible. I suspect if people want to play with the default interactivity, their best bet is to just use the options. Those have their own pitfalls, but they would be better than throwing in buttons, links, or whatever. Perhaps beyond a console warning, the browser should just remove those elements entirely.
<JonathanNeal> sarah_higley: my worry with a console warning is that it is just a warning, like “we do not think you should do this, but we will let you do this”.
<Travis> I don't think we have an option of removing elements that were explicitly placed there (e.g., selectMenu.append shouldn't fail)
<JonathanNeal> sarah_higley: if the answer is “you can never do this” then I think it should just remove it, and a warning is not sufficient.
<Travis> q+
<JonathanNeal> sarah_higley: another warning would be letting authors know it could be removed in the future, but not yet.
<JonathanNeal> flackr: that makes sense; if we think it could never be accessible, we would just remove it.
<JonathanNeal> flackr: I am mostly concerned with allowing things that could not be made accessible.
<masonf> q?
<sarah_higley> ack me
<JonathanNeal> hdv: perhaps we shouldn’t allow it until this is fixed, otherwise it would create inaccessible experiences.
<hdv> ack alex
<Travis> HTML parser issues get dumped to dev tools console in some UAs
<JonathanNeal> AlexanderFutekov_: I have a concern about the console message. I don’t think we have that for any element in HTML. Do any other elements do this, like marquee?
<Travis> (does not cover dynamic changes via DOM tree APIs).
<JonathanNeal> masonf: there are other examples — not many — but examples of things in the parser that trigger warnings about invalid values, so it can be done.
<hdv> ack masonf
<sarah_higley> q+
<JonathanNeal> masonf: I am strongly in favor of not breaking the control and allowing these use cases, with perhaps a warning. There is a secondary actions proposal that may change things in the future. If we allow all things, but warn on things we think cannot be done, we will funnel the use cases by developers. If we break it, then developers will just use divs. That’s what they do today. And then we’d not even have a way to warn developers.
<Travis> q-
<hdv> ack sarah_higley
<Travis> Mason covered my feedback
<JonathanNeal> sarah_higley: I don’t disagree. There is a balance. Where I might disagree is that I do not thing select menu would never be the right thing for some of these things; things where this should be a dialog.
<JonathanNeal> sarah_higley: in those cases, I think it’s better that people build their own.
<JonathanNeal> sarah_higley: if we muddy the waters of what select menu is now, then it may be harder in the future to get people to use a more right element for the usage they went for.
<JonathanNeal> masonf: there are 3 categories of things that are ‘funny’. Interactive content (beside?) options, interactive content in options, and non-interactive content in non-options.
<JonathanNeal> sarah_higley: when I think of good interactive content in options being secondary options.
<JonathanNeal> s/being/I think of being
<Travis> s/secondary options/secondary actions/
<JonathanNeal> thank you, Travis ❤️
<masonf> q?
<hdv> ack dan
<Zakim> dandclark, you wanted to mention that if there are compelling scenarios involving interactive content, ARIA and ATs could be enhanced to make these scenarios accessible, and
<Zakim> ... <selectmenu> could be made more permissive to allow them.
<JonathanNeal> dandclark: I still have worry about it being overkill. Like a scroll experience inside a listbox. That scroll experience would not prevent a user of accessible tech from using the control. I would not want to push the author making that to divs.
<JonathanNeal> sarah_higley: I did take a look at that. In my opinion, those (scrolling?) arrows would just be divs. To me, those should be implemented as generic elements with hover handlers.
<JonathanNeal> masonf: I could see those being built with buttons
<JonathanNeal> sarah_higley: I think that is a problem if those are built with buttons.
<Travis> are scroller (anything with overflow) elements considered "interactive"?
<JonathanNeal> sarah_higley: if the arrows are a mouse affordance, then I see not reason to put those into the accessibility tree or to be able to get focus
<masonf> q?
<Travis> Can something be mouse focusable but not keyboard focusable? I didn't think so...
<JonathanNeal> flackr: I'm still on the side of not restricting these options. I’m thinking the issue is more that we haven’t found the right accessibility semantics to express that.
<bkardell_> Travis: tabindex -1 could be?
<JonathanNeal> sarah_higley: If select menu can handle that kind of content, switching keyboard behaviors and semantics, then I could understand allowing that kind of content. But if the intent is for select menu to always be a list box, then I think that sort of content is never going to fit in that.
<hdv> ack bkardell_
<masonf> q+
<Travis> bkardell_: ah, right.
<JonathanNeal> bkardell_: my complicated thought is — it depends. I would like to see us collect a large sample of things people could do (and I realize there are an infinite number of things people could do).
<JonathanNeal> bkardell_: in many cases, there are a ‘gradient’ of things, where ‘Thing A’ seems like ‘Thing B’.
<JonathanNeal> bkardell_: but they might have different implications and different limitations.
<dandclark> q+
<JonathanNeal> bkardell_: and then there are all these ‘gotchas’, like the affordances that sarah_higley brought up.
<JonathanNeal> bkardell_: where something might be button-like in there, like for the scrollbars, and allowing them to be scrolled with a keyboard.
<JonathanNeal> bkardell_: I think we should probably collect a sample of things before we make a decision.
<hdv> ack masonf
<JonathanNeal> bkardell_: If we do go the route of trying to prevent things — like by removing content — then we should think about the level of complexity we are adding (like how removing content changes based on whether it comes from static HTML or dynamic DOM)
<JonathanNeal> masonf: its still on the table for the select menu to modify the behaviors of other things like popup and ‘do the right thing’. I think it would be okay for the controller code to ‘do the right thing’ if it sees interactive content there and change the role to dialog.
<hdv> ack dandclark
<hdv> q?
<JonathanNeal> masonf: if we make it so that putting something invalid gets removed, then we would not be able to add it back in later, because some sight would rely on it being removed.
<JonathanNeal> dandclark: I think there is a subset of things here we can agree on. For interactive content that is inside of options, adding a warning.
<dandclark> Proposed resolution: When interactive content is inside a selectmenu's listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. Behavior for
<dandclark> content inside listbox but outside of options is to be determined.
<Travis> 💖controller code figures out how to make particular patterns accessible.
<masonf> +1
<JonathanNeal> +1 to the warning
<sarah_higley> +1
<JonathanNeal> JonathanNeal: I would expect it to match current behavior for other console warnings, but agree with masonf that it is an implementation detail.
<masonf> https://microsoftedge.github.io/Demos/selectmenu/
<JonathanNeal> bkardell_: it would be really great to see a few examples to discuss what exactly we mean.
<JonathanNeal> masonf: there aren’t many or any demos in that link that fall into the category we are discussing.
<JonathanNeal> bkardell_: if we are going to resolve on something, then I think we should have an example.
<JonathanNeal> masonf: the thing we are resolving today would be like where a list of options has an ‘X’ that would remove the option.
<JonathanNeal> s/that would remove/beside each option that would remove
<JonathanNeal> bkardell_: an explanation of the use case, or a reference to something in a design system somewhere, or a website that is doing it.
<JonathanNeal> flackr: I don’t know why we want to make this limitation in a select menu, when I could see things in there that would be interactive.
<JonathanNeal> bkardell_: do we make it possible to make a menu with a select box?
<sarah_higley> https://github.com/w3c/aria/issues/1440
<JonathanNeal> narrator: folks began looking at the examples. not everyone had their flags enabled. it was good, confusing fun.
<JonathanNeal> masonf: the action item is to find/make more demos?
<JonathanNeal> bkardell_: I would feel more comfortable if we laid out a bunch of possibilities and discussed them.
<JonathanNeal> sarah_higley: I think it would be good to discuss the intent of select menu in its final form.
<hdv> q?
<JonathanNeal> hdv: we will leave this on the agenda for next week
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been JonathanNeal, miriam, Travis, bkardell_, flackr, dandclark, masonf, hdv, sarah_higley, dbaron, tantek
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/06/09-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye

[dandclark]

In the previous discussion on this there was a request for examples of how we expect that interactive content would actually be used in a <selectmenu>'s listbox once a11y tech made it possible.

For interactive content inside <option>s, some scenarios are:

• A listbox with frequently- or recently-used items pinned at the top, which have an 'x' button for removing them or restoring them to their original position in the list. @smhigley's page at has an example pictured here.
• Some options might offer a way to get more info about that option. This could be a link, a <summary>/<details>, or even something like a button that opens a nested popup with info.
• Options in an order form's dropdown listbox might have '+'/'-' buttons to increment/decrement the quantity of widgets desired.

Interactive content in the listbox but outside any <option>s tends to fall more into dialog rather than listbox semantic territory. But it's worth thinking through what kinds of things developers might try to build, if only to decide how best to prevent them from doing so with <selectmenu> due to a11y issues.

• Buttons at the top of a listbox to control how the options are sorted.
• A textbox at the top of the listbox to search for particular options (like a combobox, but inside the listbox rather than outside).

All of the above is pretty speculative, so if there are any existing examples that folks have found in the wild of interactive content in custom select-like control listboxes, please share!

[mfreed7]

You alluded to it in your first list, but one use case that deserves its own bullet point is a nested menu. I.e. a <selectmenu> contained within an <option>.

Interestingly, to me at least, both of your example use cases for interactive content outside the <option>s would be better achieved (and accessible, I think) by putting those controls in the button element, rather than in the listbox.

[css-meeting-bot]

The Open UI Community Group just discussed Restricting interactive content in <selectmenu> listbox.

The full IRC log of that discussion

<gregwhitworth> Topic: Restricting interactive content in <selectmenu> listbox
<hdv> github: https://github.com/openui/open-ui/issues/540
<masonf> ok
<hdv> dandclark: the goal for selectmenu that we set out at the beginning is that selectmenu should be accessible by default. Currently developers can put whatever they want into selectmenus and items
<masonf> Just to point it out, the notes from https://github.com/openui/open-ui/issues/548#issuecomment-1171536146 don't call out the resolution
<hdv> dandclark: but, the way accessibility APIs work is that interactive content inside listboxes is not expected and would lead to problems. Only groupings and options are expected
<hdv> dandclark: so today, it would be pretty easy for developers to make something that is not accessible, and developers wouldn't necessarily even realise that what they're building is not accessible
<hdv> dandclark: so we thought about adding a warning
<hdv> dandclark: what we diverged to last time was some kind of console warning and maybe squiggly lines under the element, to warn the developer that what they're building would cause problems
<una> q+
<hdv> dandclark: down the line, there is work in motion around aria-action, if those things would be supported we could change what we recommend here
<hdv> dandclark: my thinking, based on what sarah_higley wrote about this, you may want something like 'recently searched for' in a search engine, or in a listbox you may have a button or link for people to get more information or a button with a popup that flies out… there are various things where users might want to get more detail about an option
<hdv> dandclark: or a form might have plus/minus buttons where the quantity could be changed. These are all things developers may want to buikld today and we want to warn them that if they do, it would be inaccessible today
<sarah_higley> q+
<hdv> dandclark: in the future we may be able to add the right semantics automatically
<gregwhitworth> ack una
<hdv> una: I want to talk to the warning thing first… to me, this sounds like a dev tools thing. Are you aware of anything else warning inline to compare it to?
<hdv> dandclark: I mean it like a dev tools thing, yes, not something on the page that users would see if the dev tools are closed
<gregwhitworth> q+
<hdv> dandclark: in the issues tab in dev tools today, you can see some warnings about accessibility today. And it also causes a red squiggle in the DOM in the dev tools
<hdv> una: that makes sense to me. As someone working closely with dev tools: great idea, totally doable.
<masonf> The spec just needs to say "the UA will warn the developer in an appropriate way".
<hdv> una: it does seem to be sort of a different issue… we may see this as two things: a specification issue vs a tooling issue. I don't know if there are changes to the spec we should be making?
<hdv> una: what would be the resolution we would want on this?
<hdv> dandclark: alternatives that are more impactful would require a spec change, for instance if we break the control if developers try to do this
<hdv> dandclark: in the last meeting, we also talked about interactive content that is inside the listbox but outside of options… we could automatically remove it from the DOM, not sure if we would want to but we could
<hdv> dandclark: so the question is if we want to do something more than just warning
<masonf> I think we could normatively require the UA to warn, right?
<hdv> dandclark: in the spec something like this would exist as a comment/warning, but not in the normative text. The resolution for Open UI would be something like 'don't break the control when devs do this, but we should add a warning'
<hdv> masonf: we could maybe normatively require this?
<hdv> una: do we have a precedent for this where a spec text prescribes how a UA should warn?
<hdv> dandclark: not sure if we do, I'm all for it?
<hdv> gregwhitworth: we could also be a precedent, by the way
<hdv> una: this is where I think the difference between web platform and tooling for a user agent matters?
<gregwhitworth> ack sarah_higley
<hdv> gregwhitworth: this would depend on what we put in 'should' in the spec?
<scotto> q+
<hdv> sarah_higley: I just wanted to confirm that this is specifically for interactive content within an option, not outside of options
<hdv> sarah_higley: the warning makes sense for things where selectmenu would be able to do it in the future, but for things where we know it could never be supported, we would probably want more than just a warning
<sarah_higley> ack me
<hdv> gregwhitworth: one thing I'm curious about when talking about just a warning vs breaking the control. Has anyone tried to build one of these in the current world?
<hdv> gregwhitworth: we talked about removing these warnings in the future… let's say we ship this in the following year… how much friction would I hit, as an author, to make this accessible in the future, when aria actions would be supporte?
<hdv> s/supporte/supported
<hdv> sarah_higley: I could explain what it would look like
<hdv> gregwhitworth: I mean the world where selectmenu would ship today
<sarah_higley> here's my testing page for what it is like today: https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
<vicgutt_> q+
<hdv> gregwhitworth: could we add an example of how we add interactive content to an option and it is fully accessible? would that be doable?
<hdv> sarah_higley: I have done a fair amount of testing with things like putting buttons inside of listboxes, both inside of options and adjacant to options
<masonf> ...and a follow-on question to Greg's question: is there a way for the UA to *detect* that such content has been made accessible, so we don't need to show the warning?
<gregwhitworth> ^ good question masonf
<gregwhitworth> ack gregwhitworth
<hdv> sarah_higley: the failures are not terrible… one of the most common things is when you send focus to the button, Windows will pop out of application mode and give you a virtual cursor, accessible name could have problems
<hdv> sarah_higley: it generally doesn't blow up the basic functionality of the listbox
<hdv> sarah_higley: there are also things you or browsers could do to mitigate that
<gregwhitworth> ack scotto
<dandclark> Proposed resolution: When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. Behavior for
<dandclark> content inside listbox but outside of options is to be determined. We still need to decide what to do for interactive content that's in the listbox but outside of the options.
<hdv> scotto: with regards to what Sarah said… I did some recent testing and found things kind of work on Windows… on macOS and iOS things fall down pretty hard, particularly with things like buttons inside of listboxes, likem you can't get to things at all. I don't know if this has changed recently
<dandclark> Proposed resolution (edited): When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. We
<dandclark> still need to decide what to do for interactive content that's in the listbox but outside of the options.
<sarah_higley> yeah, VoiceOver was the sole SR that didn't access the nested buttons at all for me. The listbox continued to work, but not the nested buttons :/
<hdv> scotto: I did add myself to the queue for the convo on warnings… there is some precedent in the HTML spec, there is some info on warnings with alt text for images and there are other parts in the spec about warnings, that are also consumed by things like the HTML validator
<gregwhitworth> ack vicgutt_
<hdv> scotto: that would help people find issues right in the browser, without having to go to another app for validation
<hdv> vicgutt_: let's say in the scenario a developer would put interactive element inside the option, like, add a link… there's a deadline, they don't care… what would happen, would it behave like a link, but it would just not be accessible?
<andrico1234> q+
<hdv> vicgutt_: I don't know if a warning would discourage people enough?
<masonf> Very good point about a <div> with a click handler. That seems worse.
<gregwhitworth> ack andrico1234
<gregwhitworth> ack andrico
<hdv> andrico1234: my question would be… what would the dev tools look like when the user was using a website builder like Squarespace, would it give a lot of errors in the dev tools?
<masonf> You'd see the warnings still, likely.
<hdv> dandclark: as we're discussing it here, we give flexiblity to the user agent
<hdv> dandclark: my expectation would be when you open the Dev Tools, you would see it in the Console
<hdv> andrico1234: i guess that would incentivise larger companies like that to get their accessibility in check
<masonf> +1 to the resolution.
<una> SGTM
<scotto> +1
<JonathanNeal> +1
<sarah_higley> +1
<hdv> +1
<andrico1234> +!
<vicgutt_> +1
<andrico1234> +1
<dandclark> Resolved: When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. We still need to decide
<dandclark> what to do for interactive content that's in the listbox but outside of the options.
<masonf> (You do need all caps RESOLVED for the resolution to get called out in the notes.)

[gregwhitworth]

The resolution is:

RESOLVED: When interactive content is inside a 's listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. ,

/

,

[dandclark]

Markdown ate the elements in the above copy/paste from the minutes; here's the resolution with those included:

Resolved: When interactive content is inside a <selectmenu>'s listbox's options, the selectmenu will continue functioning but the UA should warn the developer that this is not accessible. Interactive content in this context means form controls, other element that users are expected to interact with, e.g. <a href>, <summary>/<details>, <video>, others..., <iframe>, and any element given focusability via tabindex. We still need to decide what to do for interactive content that's in the listbox but outside of the options.

[dandclark]

Adding back Agenda+ to discuss what to do with interactive content that is inside the listbox, but outside any <option>s. Is there any use case for such content in <selectmenu>? If not, should <selectmenu> do something more aggressive like removing the content from the DOM, or is a console warning (or equivalent) enough?

[VicGUTT]

My thinking as of now, with limited knowledge, is the following:

Unless a listbox can only ever have <option>s as direct children, then the rule for restricting "interactive content that is inside the listbox" should NOT be more agressive/restrictive than to one for "interactive content is inside a <selectmenu>'s listbox's option". Otherwise, I think non valid elements should simply be ignored.

My thinking behind this general/base rule is that I believe <option>s themselves are more restrictive than listboxs. I might totally be wrong though. I haven't done extensive research on the matter.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Restricting interactive content in listbox #540.

The full IRC log of that discussion

<hdv> Topic: [selectmenu] Restricting interactive content in listbox #540
<hdv> github: https://github.com/openui/open-ui/issues/540
<JonathanNeal> dandclark: this is a follow with restricting content in select menu list boxes.
<JonathanNeal> dandclark: I can put buttons and links inside this place, but AT tools today won’t know how to express those things.
<JonathanNeal> dandclark: I can limited to things like options and optgroups, so we want to help devs not build things that would not show up for ATs
<JonathanNeal> dandclark: we decided to leave a soft warning when a developer does this for now; soft because ARIA may evolve in the future to allow this.
<JonathanNeal> dandclark: there’s a related question for allowing something like a button alongside the options but not inside the options.
<JonathanNeal> dandclark: one suggestion was to remove these things from the DOM because they would never be allowable.
<JonathanNeal> dandclark: my position is that we should do the same thing, emit a console warning.
<flackr> +1
<bkardell_> q+
<JonathanNeal> dandclark: anything stronger would have some practical difficulties, like with the old select element. I think standards bodies are more reluctant to implement parser changes, due to the potential for regressions.
<flackr> q+
<masonf> q+
<JonathanNeal> dandclark: another option would be to remove the content dynamically. I think that would be suspicious. There’s no precedent for the DOM fighting you when you put content in, that it dynamically yanks it back out.
<JonathanNeal> dandclark: I think it’s also feasible we could allow developers to build these in an accessible way.
<JonathanNeal> dandclark: for instance, switching the role if it detects certain kinds of content.
<sarah_h> q+
<JonathanNeal> dandclark: for now, a soft warning does not box us in, as removing content might.
<JonathanNeal> bkardell_: we had similar discussions related to tabs. “What if I put garbage in?” Basically, we just defined a ‘garbage’ slot.
<JonathanNeal> bkardell_: This was where content that did not fit in the model went, without being removed from the DOM.
<hdv> ack bkardell_
<JonathanNeal> masonf: Can I clarify about that? It’s like a place or a comparative slot where we put stuff we don’t want to deal with?
<JonathanNeal> flackr: I would find that very confusing if certain parts of my content disappeared.
<JonathanNeal> q+
<hdv> ack flackr
<vicgutt> q+
<JonathanNeal> flackr: I think developers will want to do this (putting the content where they are)
<hdv> ack masonf
<JonathanNeal> flackr: so I want to leave the door open to that being accessible.
<bkardell_> I mean, of course they will want to :)
<JonathanNeal> masonf: it’s hard to say that I want to encourage people to say to do something that might not be possible.
<JonathanNeal> masonf: also want to +1 that parser changes will not be received well
<bkardell_> Yeah, this was ultimately my thought as well masonf
<JonathanNeal> masonf: people might even rely on that behavior (where things can be made to disappear)
<hdv> ack sarah_h
<emilio> q+
<JonathanNeal> sarah_h: outside the implementor challenges of the parser changes or the garbage slot, I would be interested in knowing how strong the pushback would be. Either stuff should be allowed or it shouldn’t.
<masonf> q+
<JonathanNeal> sarah_h: I don’t think it should be an immediate blanket, nothing interactive outside of options.
<JonathanNeal> sarah_h: But for stuff where we decide it can’t be accessible; I think it would be good to have it actively removed.
<JonathanNeal> bkardell_: actively removed or actively broken?
<JonathanNeal> sarah_h: either way
<dandclark> q?
<JonathanNeal> sarah_h: like what if I have a text input in between options?
<JonathanNeal> sarah_h: could focus end up there if that meant it would now be trapped?
<JonathanNeal> masonf: but if we break it, then we can never fix it.
<bkardell_> counterpoint maybe: If you allow it to "work" a certain way, you also cant change it?
<JonathanNeal> flackr: I could imagine the select as a “tree” of options
<masonf> counter-counterpoint - AT can change over time to get better, and if we issue console warnings only, AT can evolve to support more stuff.
<JonathanNeal> flackr: the risk is if select says it can’t do all the things, then in the future we’d need a successor to selectmen.
<JonathanNeal> flackr: /s/selectmenu
<masonf> q?
<bkardell_> masonf: like, the situation sarah_h described - someone will depend on it, I dont think you can change that after the fact either
<JonathanNeal> sarah_h: like, should it support interfaces/arrow keys for trees, calendars, etc? I think it should be an explicitly supported path or not.
<tantek> +1 sarah_h good to provide guidance on (or how to build) "tree" and similar options
<JonathanNeal> ack JonathanNeal
<hdv> ack emilio
<JonathanNeal> emilio: I also think we should also discuss removing things at a layout level.
<bkardell_> that's basically what I described, I was just doing it with slotting because that is what I had access to
<JonathanNeal> emilio: removing things feels like going against why selectmenu exists, which is to give users more control to do what they want.
<flackr> +1
<JonathanNeal> hdv: we are at time
<dandclark> I think removing at the layout level has the same problems as moving the content to a "garbage" slot: developers may come to depend on that behavior. That makes it difficult to make changes to support those scenarios in the future.
<JonathanNeal> JonathanNeal: tea time!
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been hdv, dandclark, masonf, JonathanNeal, flackr, emilio, miriam, tantek, bkardell_
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/07/21-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox (cont'd).

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Restricting interactive content in <selectmenu> listbox (cont'd)
<gregwhitworth> github: https://github.com/openui/open-ui/issues/540

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox #540.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Restricting interactive content in <selectmenu> listbox #540
<gregwhitworth> github: https://github.com/openui/open-ui/issues/540
<gregwhitworth> q?
<jhey> Weren't we going to close off #532 [popup=hint]?
<hdv> sarah_h: this is a continuation of a topic we discussed before, which is can we put arbitrary content inside options in selectmenus
<flackr> q+
<hdv> sarah_h: so what kind of content could go inside of or adjacentt to options, and if we allow it, what to do about it
<gregwhitworth> ack flackr
<dandclark> q+
<hdv> flackr: my feeling is that developers will do this, and if selectmenu doesn't let them do it, they'll choose another route like divs… so my strong preference would be to allow it and then try and come up with ways to make it accessible
<sarah_h> q+
<gregwhitworth> ack dandclark
<jhey> Cool gregwhitworth – It's quite a thread so wasn't sure if we were going to get it resolved and underlined. Most votes leaning towards "hint" currently.
<hdv> dandclark: I would like the UA to give a warning… moving the content dynamically is something not typically done by the platform
<hdv> dandclark: I wouldn't like breaking the control if it breaks, because when developers start to 'rely' on that it would be hard to then support it accessibly later, we would in that case basically have to come up with another new element to make those improvements
<scotto> q+
<hdv> dandclark: we can't really enumerate each improvement we would want to do, so would like to maintain flexibility here
<jhey> +1
<hdv> dandclark: also agree with flackr, people will build these things with divs if it breaks, and that would be at least as inaccesible, and then we won't be able to fix those things later on
<hdv> dandclark: we wouldn't be able to give developers guidance if they go down that route
<masonf> +1 to dandclark's points, very well said.
<gregwhitworth> ack sarah_h
<hdv> sarah_h: I can't say much about the parser issues… but from a developer point of view… I don't think it is a benefit to allow developers to put interactive elements in a selectmenu that is not ever going to be supported
<gregwhitworth> q+
<hdv> sarah_h: I don't think the common alternative is to coming back to divs and building it themselves, it is to take a control from a component library somewhere, an off the shelve component, and iti is likely to be more accessible than an alternative would be
<masonf> q+
<jhey> But aren't we trying to solve this problem for people? It's an edge case but we're trying to address these patterns that do pop up commonly.
<hdv> sarah_h: secondly, when we make a new HTML control that allows too many things, over time it makes developer experience worse because there is too much to learn
<hdv> sarah_h: so overall, from a developer perspective, I prefer having the control exactly what it actually supports. Which doesn't mean not allowing a filter input at the start… there is some things we should try to support… but I don't think someone should try and put a grid inside of a selectmenu or a tree… or like have no options but all buttons
<una> disagree, folks need to be able to put a grid in select items
<jhey> You might have a select list that you could tab around that was laid out like a tree though.
<sarah_h> ack me
<hdv> sarah_h: but there are various things that I think are not beneficial to developers or end users to allow
<gregwhitworth> ack scotto
<flackr> I don't think we can know that we can't ever support interactive content in selectmenu
<jhey> As Dan mentioned too. Very hard to enumerate all the edge cases for all designs.
<hdv> scotto: a lot of +1s to both sides… there could well be a way to support some additional items within a selectmenu, but there should be specific slots for those, like before the options, after the options. Those are reasonable use cases, things that people actually would do
<hdv> scotto: there is a dialog that allows other interactive elements… the use case that allows an option and a text field and another option… that's going to be incredibly messy and breaks the idea of what a listbox popup represents
<hdv> scotto: I feel the best way forward is to make sure that there are ways to allow for things people are actually doing… like making slots where people can put whatever they want, that would be great… but allowing them to do anything anywhere, that would not be better than divs and result in an awful user experience
<sarah_h> q+
<jhey> Think you should allow people to visually do what they want to do though. As long as it's still within those accessible parameters.
<jhey> We can't comprehend all the use cases and needs of people without letting them show us.
<hdv> gregwhitworth: one of the things Open UI has had as a goal is 'accessible by default'. A second principle we have always had is that we wouldn't have 'arbritrary restrictions', to allow people to be flexible
<hdv> gregwhitworth: we could end up in a scenario where people build their own… the top 100 sites we looked at have checkboxes that are inaccessible… so I agree with you sarah_h and scotto that we want to avoid problems along the way, but I don't want to introduce restrictions for things that would be normal along the way
<hdv> gregwhitworth: we will ship an element that is accessible out of the box by default… we cover 95% probably with selectmenu, then once we do combobox and multiple combobox, we may get to 99%
<una> q?
<gregwhitworth> ack gregwhitworth
<jhey> +100
<gregwhitworth> ack masonf
<hdv> masonf: +1, I think we cannot practically restrict, because it will force people out into using divs
<una> +1000 to not adding restrictions (people already break these form controls with innacessible divs)
<hdv> masonf: if people would not go to divs, but to go to frameworks, how could that be better than what we could do?
<jhey> Yep +10000!
<hdv> masonf: and if we add restrictions, it will paint our whole future, we would not be able to remove those later and basically end up with selectmenu2
<hdv> q+
<una> q+
<jhey> We can only understand what people want by letting them show us.
<gregwhitworth> ack sarah_h
<hdv> sarah_h: I think frameworks can make things more accessible because they can ship more components, like different types of pickers with different interactions and semantics
<hdv> sarah_h: whereas a browser is less flexible to do that
<gregwhitworth> I would like to timebox to 10 mins (11:40 PST)
<jhey> But these patterns are the point of OpenUI, no? To address them and make it easier for people to do it without relying on external things.
<gregwhitworth> we'll need to do a straw poll
<hdv> sarah_h: question to browser folks: if in the future we can make it accessbile by changing the semantics and keyboard semantics… is that feasible to do in the future?
<hdv> sarah_h: I think it is fairly likely that that is what the accessible solution would be?
<gregwhitworth> q?
<gregwhitworth> q+
<hdv> masonf: I wish Aaron were here to answer that question… I think he would say we should do the right thing… to do what it takes…  technically speaking… that is a lot of lines of code
<masonf> s/a lot of lines/only a handful of lines/
<gregwhitworth> hdv: listening to scott and sarah it seems to me it makes sense to have restrictions even though we don't want restrictions
<gregwhitworth> hdv: especially when you look at screenreaders, they are restricted to what is in aria; the only way to make it accessible is to restrict it
<gregwhitworth> hdv: frameworks can do the right semantics for the right things
<gregwhitworth> hdv: I think we're making it in-accessible things
<scotto> q+
<gregwhitworth> hdv: it's really hard to teach as well
<gregwhitworth> masonf: can you clarify something, the only thing that makes them more accessible in frameworks is that they're changing the roles
<gregwhitworth> hdv: they can do it quicker in a way
<jhey> This is what I wanted to say. They may move quicker but they are still using the things under the hood that we can do for them.
<gregwhitworth> hdv: they can take those particular patterns into account and move quicker
<gregwhitworth> hdv: I guess in the browser you'll need to guess more
<gregwhitworth> sarah_h: to interject it's other function reqs
<gregwhitworth> q?
<gregwhitworth> ack hdv
<gregwhitworth> ack una
<vicgutt> +q
<hdv> una: I agree with both sides… ultimately the goal here is to make it easier to do the right thing using the web platform
<jhey> This +100
<hdv> una: maybe we don't market it as accessible by default… we need to advocate building things accessibly
<hdv> una: so it is important how we talk about these things
<hdv> una: but I don't think we should do it with restrictions
<hdv> una: the current state of building components is awful, that's what we're trying to solve, and if we have too many restrictions, we're not making it easir
<hdv> s/easir/easier
<sarah_h> q+
<hdv> una: so basically, we need to teach and advocate accessibiliy, but not through limits
<hdv> gregwhitworth: when me and Nicole talked about this, we said we would not stop at one component, we won't stop at selectmenu, we will do other elements
<hdv> gregwhitworth: if we ship selectmenu, most people will just use it to do just some lines between items or some images, they won't do the advanced things
<masonf> q+
<hdv> gregwhitworth: and that makes for very accessible experiences if they do the default things
<hdv> gregwhitworth: but if we ship with restrictions, maybe all the talk will be about those restrictions and people won't use them
<gregwhitworth> ack gregwhitworth
<masonf> q-
<gregwhitworth> ack scotto
<hdv> una: we want people to use Bootstrap if they want to use Bootstrap, not because it's the only way to do accessbility… if Bootstrap would be the only way to do it, that's not great, we want to make it easy to make accessible components
<hdv> scotto: I want to clarify something… I am far more in favour of not restricting things
<una> q+
<hdv> scotto: my biggest problem is the ability to stick arbitrary things between options… maybe I can ask… if someone were to do something like this, like text inputs between option elements… how would that even work, or would it be on the author to do the necessary behavior and keyboard interactions
<hdv> scotto: what is the expectation people would have there, how does people even get from an <option> to a <button> inside of a <selectmenu>, because we use arrows between options, how would it work to get to a button or text field from there?
<hdv> scotto: some of the work sarah_h has been doing on nested interactives would solve some of these issues
<hdv> scotto: and the work masonf is doing too
<hdv> scotto: it seems like a lot of cases where allowing arbitrary content would be problematic
<hdv> scotto: it could also be done in HTML validator, console warnings, etc we would also tell authors all over the place…but what would happen if they do do it? if we're worried people don't like the restrictions, maybe we should also worry about what happens when they do do these things and the browser doesn't do the thing they're authoring anyway?
<jhey> I'll be writing! it ;D
<hdv> masonf: I can imagine a very nice blog post that can help authors to understand how to get it right… if they get a console warning referring to a blog post, that's maybe better because we can take the time to teach this
<hdv> scotto: I see the value in that
<hdv> scotto: you can do so much horrible stuff with HTML today and it's valid… and this is maybe another instance of that
<hdv> q?
<jhey> It isn't "valid" in every case but the browser lets you render them.
<gregwhitworth> ack vicgutt
<jhey> Unless it's like <img><h1></img> for example.
<hdv> vicgutt: coming from a developer point of view… I've seen developers who have done this… we shouldn't underestimate how many people aren't using React but jQuery… we shouldn't emphasise the framework side of things too much
<hdv> vicgutt: the goal is to give more power to native HTML and CSS
<gregwhitworth> ack sarah_h
<hdv> vicgutt: to answer scotto's question… if people put a button in a selectmenu they would just tab there and get a warning
<hdv> sarah_h: like scotto, I'm also curious… what would a link or button inside options would do… you can't TAB there, because that would close the list
<flackr> But should the popup close if you've moved focus to something *in* the popup?
<hdv> sarah_h: it would either involve a lot of changing the entire keyboard model for the control based on what's in there… or it would be inaccessible
<gregwhitworth> +1 to discussing concrete usecases
<hdv> sarah_h: if someone puts a tree or grid in there, or a group of checkboxes but no options… those kinds of things would be much easier to do with a popup than with a selectmenu
<hdv> sarah_h: maybe concrete examples would help
<hdv> sarah_h: the possibilities to make things accessible is a bit more dire than it comes off… it would be easier to do if it was just a button that would open a div
<gregwhitworth> ack una
<hdv> sarah_h: I agree with sarah_h that a popup would be the best option for a lot of these cases
<hdv> s/sarah_h/una
<hdv> una: this is basically a teaching problem. I think the dev tools and learning materials are the best places to address this, we can help developers get it right
<tantek> +1 una
<hdv> una: seems like it's almost two different issues we're conflating… 
<hdv> una: selectmenu is really for the majority use cases, if it is more advanced, it's up to the user to define all the interactions and that it is accessible and works
<hdv> gregwhitworth: ok, we're at time, let's move this discussion to GitHub
<una> s/teaching/HTML
<hdv> gregwhitworth: I also want to reiterate masonf's request to look at issue @@@
<gregwhitworth> issue 532
<hdv> s/@@@/532
<gregwhitworth> https://github.com/openui/open-ui/issues/532
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been tantek, dandclark, hdv, flackr, scotto, una, dbaron, masonf, Stephanie, Stimac, gregwhitworth, vicgutt, Rody, Davis, sarah_h,
<Zakim> ... StephanieStimac, RodyDavis, chrishtr
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/04-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye

[scottaohara]

To try and answer my own question from the call today, I noticed a few unexpected things when putting other interactive elements within a <selectmenu>.

1. I had asked how users would get to other nested interactive items within the listbox popup, since arrow keys are expected to navigate between options and tab key is presently expected to select the focused option and navigate away from/close the listbox popup when invoked by a select element. I found that tab key does not do this, but rather navigate to all the items within the listbox popup. It was further unexpected to me that tab key navigated between the options even if there was no other non-option interactive elements within the listbox pattern. @smhigley did some user research on combobox patterns and likely has more to say on their expectations on arrow/tab key behavior here.

2. Related to my first test where I attempted to navigate to a button and an input within a <selectmenu>

   <label>
     Name
    <selectmenu>
      <option>choice</option>
      <button>action</button>
      <label>Other<input></label>
    </selectmenu>
   </label>
   

   JAWS doesn't announce unique information for any of the non-option content within the listbox popup, even when navigated to via Tab key. The items/roles are there in the accessibility tree of the browser (chromium). But this indicates that anyone using JAWS would not be able to access this content. Assuming this is specific to how JAWS treats listboxes (as tabbing to this content does announce the name/role of the elements with NVDA/Narrator), and they were to change their code to support other elements within listboxes, any user of JAWS prior to the version of where the change was added would still not be able to access the non-option elements, as this would. This needs further investigation.

3. Another thing that came to mind, per the conversation about the HTML parser, was what would happen if someone were to put a <selectmenu> within a <p> - something that people can do with <select> inside of <p> right now and aligns with the examples for <select> in the HTML spec. I found that if I were to do the following:

   <p>
      <label for=d>choose a thing</label>
      <selectmenu>
         <option>item 1</option>
         <hr>
         <option>item 2</option>
      </selectmenu>
   </p>
   

   Everything from that <hr> element and afterwards is kicked out of the <selectmenu>.

   This is of course the HTML parser at work and kicking out the invalid <hr> from being nested within the <p> element. But this does mean that other elements like <div> or <h#> would also break in this context as well. So it does seem like there will be parsing updates to allow completely arbitrary content within <selectmenu>, to mitigate against any purposeful inclusion within <p> elements, or to mitigate against unexpected breakage due to a non-closing <p> element that precedes it.

[smhigley]

I'll try to come up with some more comments later, but just quickly responding to what @scottaohara said about tabs moving between options in a selectmenu --

In the user studies I've done on comboboxes (3 so far, and another in the works) I've found a strong user expectation that a tab from within an open combobox will select the current option and leave the popup. I don't think it would be a good idea to break that expectation in the most common/baseline use case for a selectmenu.

[mfreed7]

3. Another thing that came to mind, per the conversation about the HTML parser, was what would happen if someone were to put a <selectmenu> within a <p> - something that people can do with <select> inside of <p> right now and aligns with the examples for <select> in the HTML spec. I found that if I were to do the following:

Thanks for pointing this out. I think I agree that this sounds like an area that will actually require parser changes. I'd guess it's fairly common to put a <selectmenu> inside a <p>. I'd say we could just "copy" the parser rules for <select> but those also have their own (fairly complicated) logic, which we probably don't want to copy. Perhaps all that needs to be done (?) is to modify this section to add <selectmenu>, like this:

A start tag whose tag name is one of: "address", "article", "aside", "blockquote", "center", "details", "dialog", "dir", "div", "dl", "fieldset", "figcaption", "figure", "footer", "header", "hgroup", "main", "menu", "nav", "ol", "p", "section", "selectmenu", "summary", "ul"

• If the stack of open elements has a p element in button scope, then close a p element.

• Insert an HTML element for the token.

@dandclark will have better ideas, I'm sure.

In the user studies I've done on comboboxes (3 so far, and another in the works) I've found a strong user expectation that a tab from within an open combobox will select the current option and leave the popup. I don't think it would be a good idea to break that expectation in the most common/baseline use case for a selectmenu.

+1 - this type of expectation is definitely something we don't want to break.

[scottaohara]

@mfreed7 would that not then mean that a selectmenu would cause a p to self close?

so <p>heyo <selectmenu>... would then turn into

<p>heyo</p>
<selectmenu>...</selectmenu>

?

That's definitely a solution, but would mean that authors could not do 'mad libs' type UI (for better or worse).

e.g.,

<p>As a developer <label>I want to <select>...</select></label> so I can make cool things</p>

would turn into

<p>As a developer <label>I want to</label></p>
<selectmenu>...</selectmenu>
so i can make cool things
<p></p>

as that's what would happen if I replaced selectmenu with one of the elements from that list.

I'm quite neutral on this as a solution.

[mfreed7]

That's definitely a solution, but would mean that authors could not do 'mad libs' type UI (for better or worse).

Yeah you're right. That does sound annoying - we need to support mad libs 😄 . Perhaps the right model to follow is <button>? That allows arbitrary content, and doesn't close the <p> or kick things out, AFAICT. Reading the parser spec, I'm still not exactly sure how it achieves that, but it must be in there somewhere. We'd also have to differ from <button> in that we do allow nested <selectmenu> elements.

[scottaohara]

Another thing that may need to have special rules defined for it is per the use of <label> element with <selectmenu>

per my example of:

<label>
  Name
 <selectmenu>
   <option>choice</option>
   <button>action</button>
   <label>Other<input></label>
 </selectmenu>
</label>

I nested the <selectmenu> within the <label> element, as that is a valid way to associate the text of the <label> with its form control (thanks to @dandclark for filing a browser issue to ensure that <label> actually names the <selectmenu>.

The issue that will need to be looked into though is that a <label> is only supposed to be associated with a single labelable element, and thus must not contain more than one labelable element. However, per the above example the outer <label> contains its <selectmenu> but then also is the ancestor to a <button>, another <label> and its nested <input>.

Something will need to change here (either <selectmenu> cannot be nested within a <label> to mitigate having to change the <label> nesting rules - or there will need to be stipulations to ensure the above can be valid, and more importantly, that the parent <label> doesn't overwrite the names of the labelable elements within the <selectmenu> - e.g., "name" becoming the accessible name of the <button> which should continue to be exposed as "action".

Quickly testing, the nested button and input appear to retain their expected accessible names in Chromium - which is obviously what we want. But as the <label> doesn't actually properly name the <selectmenu> yet, and other browsers have yet to implement this, it's something to look out for with other chromium changes / browser implementations

[dandclark]

The issue that will need to be looked into though is that a <label> is only supposed to be associated with a single labelable element, and thus must not contain more than one labelable element.

I don't think we need to do anything special here; the spec has the following (link):

If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element's labeled control.

So the <label> will only apply to the <selectmenu> without digging into any of its children.

For anyone curious the bug for the <label>/<selectmenu> issue is crbug.com/1350299. It turns out that we're setting up the association with the label properly, it just isn't doing anything useful due to reasons I noted here.

[scottaohara]

@dandclark yes, the spec does say that, but webkit on macos doesn't seem to fully respect it per the following example where both buttons have the accName of 'foo a b':

<label>foo
	<button>a</button>
	<button>b</button>
</label>

So that's a webkit bug that needs filing, but I just figured it'd make sense to be mindful here to ensure unexpected behavior doesn't creep in for something that, prior to selectmenu, would have been considered invalid - per the HTML validator reporting: "The label element may contain at most one button, input, meter, output, progress, select, or textarea descendant."

[dandclark]

So that's a webkit bug that needs filing, but I just figured it'd make sense to be mindful here to ensure unexpected behavior doesn't creep in for something that

I see, I hadn't realized that WebKit treats this differently. I agree that we have to be careful that we don't introduce issues with <label> reaching into the scope of a <selectmenu>.

Re: the <p> auto-closing behavior, following <button> seems like the best option. This may be as simple as changing all references of has a p element in button scope to has a p element in button or selectmenu scope. The definition can be updated by just adding "selectmenu in the HTML namespace" as another bullet here.

[css-meeting-bot]

The Open UI Community Group just discussed (Straw Poll Only)[selectmenu] Restricting interactive content in <selectmenu> listbox (cont'd), and agreed to the following:

• RESOLVED: Allow interactive content outside of <options>, but issue strong console errors or warnings in this case.

The full IRC log of that discussion

<gregwhitworth> Topic: (Straw Poll Only)[selectmenu] Restricting interactive content in <selectmenu> listbox (cont'd)
<gregwhitworth> github: https://github.com/openui/open-ui/issues/540
<hdv> sarah_h_: this issue is about adding interactive outside of <option>s but inside of a <selectmenu>, like adding a <input> or <table> in between <option>s
<hdv> sarah_h_: things we can do about it: add a console warning, or not render the element at all.
<hdv> s/not render the element at all./completely remove the element
<scotto_> q+
<hdv> gregwhitworth: and the third one would be something like restricting what is allowed inside of <selectmenu>
<gregwhitworth> ack scotto_
<hdv> masonf: yeah there are many ways we could do this… but the two things that are mainly on the table is, when some element is in a selectmenu but shouldn't be there, do we only do a console warning, or do we not display it at all
<hdv> scotto_: the other could be that we recognise that something is in a selectmenu that shouldn't be there, would trigger it to no longer be a listbox but potentially something else, and potentially having different keyboard behavior too
<hdv> flackr: so it's a variation on A?
<hdv> scotto_: yes basically a variation where some errors would be mitigated
<hdv> masonf: so it would fix all the issues?
<hdv> scotto_: we could only mitigate some of the issues, there would still be remaining issues
<hdv> gregwhitworth: a) allow devs to do what they can, show a console warning, if they do something that would be inaccessible b) restrict what can be in the element so that we can be a lot more sure about the accessibility
<hdv> gregwhitworth: please put option a or option b in IRC or Zoom
<una> A
<jhey> a
<sarah_h_> B
<emilio> a
<vicgutt> a
<flackr> A
<hdv> B
<masonf> A
<oluOnline> b
<sana> B
<miriam> b
<dandclark> A
<vmpstr> a
<tantek> abstain (haven't considered it enough)
<hdv> gregwhitworth: so it looks like it is A got 8, B got 4
<hdv> flackr: looks like 5 for B
<hdv> gregwhitworth: ok, effectively it is resolved that we would allow people to put any element into selectmenu, we would need to update the spec
<masonf> Proposed resolution: Allow interactive content outside of <options>, but issue strong console errors or warnings in this case.
<scotto_> abstain as i still have concerns with both
<hdv> gregwhitworth: I do want to reiterate, resolutions can always be changed, as more information becomes available and more folks start to use these elements, we could still revert this decision
<masonf> RESOLVED: Allow interactive content outside of <options>, but issue strong console errors or warnings in this case.

[dandclark]

We've resolved on this issue's main topic, and I've opened bugs/issues to track the other issues that have been brought up here:

• Issue 1350299: elements don't make an association with <selectmenu>
• https://github.com/openui/open-ui/issues/599
• https://github.com/openui/open-ui/issues/598

So, I'm going to Close this one.