Closed dandclark closed 1 year ago
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:
<selectmenu>
fully inoperable when interactive content is present, remove the prohibited tags, similar to what happens with <select>
and other elements todayRegarding 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.
The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox #540
.
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:
<summary>
/<details>
, or even something like a button that opens a nested popup with info.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.
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!
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.
The Open UI Community Group just discussed Restricting interactive content in <selectmenu> listbox
.
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. , / ,
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.
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?
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 listbox
s. I might totally be wrong though. I haven't done extensive research on the matter.
The Open UI Community Group just discussed [selectmenu] Restricting interactive content in listbox #540
.
The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox (cont'd)
.
The Open UI Community Group just discussed [selectmenu] Restricting interactive content in <selectmenu> listbox #540
.
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>
.
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. <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.
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.
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.
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.
@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.
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.
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
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.
@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."
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.
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.
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:
So, I'm going to Close this one.
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 likearia-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:<a href>
,<summary>
/<details>
,<video>
, others...<iframe>
<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.