[selectmenu] Accessibility of option labels

[dandclark]

In some cases it will be useful for authors to include non-interactive content in a <selectmenu>'s listbox for the purpose of labeling groups of options. The native <select> offers this today with <optgroup> and its label attribute: MDN <optgroup>.

It is very likely that developers will want to add optgroup labels like this with <selectmenu>, and they will want them to be styleable. To meet the goal of accessibility-by-default, these labels must be accessible without depending on devs to write ARIA.

The <optgroup label="…"> approach used by <select> won't work because there is no way to target styles to these.

One way of approaching this problem is to use the <legend>* element for optgroup captions in the following way:

<selectmenu>
  <optgroup>
    <legend>Fruits</legend>
    <option>Apple</option>
    <option>Pear</option>
    <option>Banana</option>
  </optgroup>
</selectmenu>

The developer can target the <legend> element with CSS to style it in any way they choose.

The platform will apply the text content of the <legend> as the accessible label of the <optgroup>, so that the above example will be exposed to accessible tech as if it had the following ARIA:

<selectmenu>
  <optgroup role="group" aria-labelledby="fruit-legend">
    <legend role="caption" id="fruit-legend">Fruits</legend>
    <option>Apple</option>
    <option>Pear</option>
    <option>Banana</option>
  </optgroup>
</selectmenu>

"Error" cases would be handled in the following ways:

• If an <optgroup> is missing a <legend> element, this will result in a console warning. As an intervention in this case, the platform applies any non-interactive** text content inside an <optgroup> before the first <option> element as the <optgroup> label.
• If a <legend> is found in the listbox outside any <optgroup>, this will result in a console warning.
• If text content** is found in the listbox outside any <optgroup> or <option>, this will result in a console warning.
• An <optgroup> inside another <optgroup> emits a console warning. In the future we could consider adding more useful support for these and removing the warning.
• Open question: Should <optgroup>'s label attribute still do anything when used in <selectmenu>? It seems reasonable to have <optgroup label="foo"> apply foo as the accessible name of the <optgroup> when there is no <legend> element. But when both the label attribute and a <legend> are present, which one should "win"? If the label "wins", should it affect the a11y name only or also the content that is rendered?

The hope is that this approach is a good middle ground between the two extremes of leaving a11y completely up to the developer vs adding a lot of platform magic that will be difficult to specify, implement, and debug, and that may misinterpret the developer's intentions.

Does this approach sound reasonable?

*The <legend> element was chosen over <caption> because it doesn't have special HTML parser rules that need to be worked around. We could also consider adding a brand new HTML element for this possibility (<optcaption>?). This may grant more flexibility if we want to add more capabilities to these labels in the future like captions that, when clicked, automatically expand/collapse the group of corresponding options.

** There are separate considerations about how to handle interactive content discussed at #540

[mfreed7]

+1 to the proposal. It seems flexible enough to allow fairly arbitrary content while providing a straightforward way for developers to make content accessible. Plus provisions for warnings that will help them in case they don't do the right thing.

As for the question of <optgroup label=foo><legend>bar</legend>, I think it seems to make sense for the <legend> content to "win" in terms of a11y Name computation, because <legend> will be the recommended way to use the control, and it sounds like a headache if the presence of a (perhaps legacy) label attribute causes that not to work. Prioritizing <legend> will also offer some sort of fallback behavior when the same <optgroup> content can appear in both a <select> and a <selectmenu>. By providing both label and <legend>, the a11y Name can be different for the <select> vs. the <selectmenu>. That's probably a very corner case, so maybe that doesn't matter.

In either case, I do not think rendering of the <legend> should be affected by the presence of a label attribute. That seems error prone and kind of odd.

[hidde]

This sounds reasonable, the warnings seem helpful and I like the idea of repurposing legend for this more than adding a brand new element, as there are so many labelling elements in HTML already (caption, but also label).

Re: having both label attribue and <legend>, I agree with @mfreed7 that it makes sense for the <legend> to win.

[scottaohara]

agreed with <legend> content winning out over optgroup label=.... This will be different than how the option element works now, where <option label=foo>bar</option> "foo" becomes the visible label and the accName. But,.. maybe if that too changed within selectmenu then that'd be ok?

[VicGUTT]

@scottaohara

But,.. maybe if that too changed within selectmenu then that'd be ok?

I believe that would prevent <selectmenu> for being a drop-in replacement for <select> (that's one of the goals right? 🤔)

I was in agreement with <legend> content winning out over optgroup label=... until Scott's point, now I'm a little conflicted but don't have any strong argument against. My only "argument" against is consistency and avoiding confusion/unnecessary "thinking about it".

[scottaohara]

i guess what does "drop-in replacement" mean?

<button> is a better way to markup <input type=submit|reset|image|button> - and it allows for different things than those older input types. But they both still exist.

I never once thought <selectmenu> would completely replace <select>, but rather they would co-exist. I actually don't see how it would even be possible to do anything otherwise.

[VicGUTT]

Oh no I agree, both <select> and <selectmenu> should definitely co-exist.
I guess "drop-in enhancement" would be a better way to put it.

By that I mean swapping out

<select>
    <option>...</option>
</select>

With

<selectmenu>
    <option>...</option>
</selectmenu>

would yield the exact same visual, semantic, behavioral result. But allow for enhancement in customization that the regular <select> cannot.

But, if the label of an <option> comes to be determined differently depending on whether it's inside a <select> or <selectmenu> than <selectmenu> would no longer be a "drop-in enhancement" for <select>.

And all of this is based on the (possibly wrong) assumption that <selectmenu>s CAN be used in place of <select>s.

Hopefully my point is clearer :)

[scottaohara]

clearer, yes. i guess the use case you're concerned with is if someone takes

<select>
  <option label=foo>some other text</option>
</select>

where "foo" overwrites "some other text" and drops that / similar options into a <selectmenu> where instead "some other text" would win out instead.

I guess I would be wondering why that "some other text" was lingering around in the markup, since it was previously being dropped when within the <select> element anyway? Unless someone isn't testing their markup, they would likely notice the different rendering of the options when changing to <selectmenu> and then delete out what wasn't necessary.

As another example, if taking that same <option> from the above example and placing it within a <datalist> you get very different rendering results as well. In chromium browsers, both the child text of the option AND the label are displayed.

My point being that as a new parent element that allows different and expanded features, I think it's probably ok to expect developers to have to come to grips that things aren't exactly the same as the previous element, and they might need to readjust their thinking. That said, I also would be curious how many people actually remember they can use a label attribute on an option now :)

[VicGUTT]

Ahah yes, excellent points (regarding <datalist> and "how many people actually remember they can use a label attribute on an option now".

I think it's probably ok to expect developers to have to come to grips that things aren't exactly the same as the previous element

I'm totally fine with it as well, specially considering the fact I personally would move to using <selectmenu> exclusively.
BUT ideally I'd prefer less "overhead" / "less things to keep in mind", avoiding little "gotchas".

My concerne was really just that, a minor nitpicking regarding consistency :).

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Accessibility of option labels, and agreed to the following:

• RESOLVED: the `label` attribute is not supported within <selectmenu>.
• RESOLVED: Use the <legend> element for labeling <selectmenu> <optgroup>s as described in https://github.com/openui/open-ui/issues/558#issue-1289047468.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Accessibility of option labels
<gregwhitworth> github: https://github.com//issues/558
<gregwhitworth> dandclark: this one is about option labels for the selectmenu element
<gregwhitworth> dandclark: I can use an optgroup and label attr to give those groupings a name and the browser will render the group and will also group them for the AT via accessible name
<gregwhitworth> dandclark: we want to do something similar for selectmenu, however the optgroup solution won't be available since you can't style it
<gregwhitworth> dandclark: we don't want to rely on the author to write aria
<gregwhitworth> dandclark: we don't want to add too much platform magic
<gregwhitworth> dandclark: we don't want impl to push back nor do we want to mis-understand what authors intend
<gregwhitworth> dandclark: we propose to use the label element to label option groupings
<tantek> aside: you can actually (somewhat) style optgroup elements with CSS, we implemented this back in the day (1999-2000) in IE5/Mac with at least background, color etc.
<gregwhitworth> dandclark: I used optgroup in the past to label the group and and now they can use the legend element within the optgroup to apply the textcontent of this legend to the acc name
<gregwhitworth> dandclark: the approach to handling error cases is a console warning
<tantek> +1 to putting human readable text content in element contents (e.g. in a legend element) instead of an attribute (like label)
<gregwhitworth> dandclark: if I have any stray text that isn't in a option we'll put it in the console
<gregwhitworth> q?
<hdv> gregwhitworth: my question would be, are there scenarios where people are using text that isn't for group things togetehr but they are also not an option for selection, that you have seen?
<gregwhitworth> dandclark: not that I've seen no
<gregwhitworth> dandclark: a similar issue is that there is not a clear way in aria to expose that stray text content
<scotto_> q+
<gregwhitworth> dandclark: I still think it's worth warning authors that it isn't accessible
<gregwhitworth> dandclark: we can then address that in ARIA in the platform and then the console warning can go away
<gregwhitworth> ack scotto_
<gregwhitworth> scotto_: a clarifying comment, another thing to consider about listbox, popups, etc is that there are decades long patterns that they expect
<gregwhitworth> scotto_: even if the static content is there - there are years of learned behaviors
<gregwhitworth> scotto_: when you're in a listbox, you're in there to select an option
<tantek> q?
<gregwhitworth> scotto_: we could expose it - but that's the real problem statement
<gregwhitworth> scotto_: the other thing to do was what to do with the label attr
<gregwhitworth> scotto_: changing over to the legend el allows more to be done via style
<tantek> q+ to ask if decades long patterns are really relevant now since React etc. other UI frameworks are now the "new" patterns people are used to and also demonstrate devs will happily abandon "decades long patterns"
<dandclark> q+
<gregwhitworth> scotto_: the other question would be should there be a new el or pattern construct?
<gregwhitworth> scotto_: should no label attr be used within the selectmenu; how do you handle the conflicts/scenarios
<gregwhitworth> scotto_: it's solved by just saying that label attr is not supported within the selectmenu
<gregwhitworth> ack tantek
<Zakim> tantek, you wanted to ask if decades long patterns are really relevant now since React etc. other UI frameworks are now the "new" patterns people are used to and also demonstrate
<Zakim> ... devs will happily abandon "decades long patterns"
<gregwhitworth> tantek: thanks scotto_ - I appreciate when devs are used in a certain way that they're used to decades long patterns and are using other patterns in react and other frameworks not used in HTML/CSS
<gregwhitworth> tantek: the audience is broader; the inertia to moving to other paradigms is impactful but I don't think we need to consider back compat
<gregwhitworth> tantek: if there is a direct translation of one paradigm to another then I think that would be sufficient. I don't think you need to use any old patterns
<gregwhitworth> scotto_: were you replying to decade long pattern about devs as I was referring to users
<gregwhitworth> tantek: yeah those are two very different things between authors and users
<gregwhitworth> scotto_: just want to qualify that you're not talking about AT users
<gregwhitworth> tantek: yes
<gregwhitworth> scotto_: then yes we're in agreement
<gregwhitworth> ack dandclark
<tantek> my comment was scoped to developers
<gregwhitworth> dandclark: I'm agreeing with scotto_ and tantek
<gregwhitworth> dandclark: we've changed aspects from selectmenu so there is no expectation that we need to carry things forward and so we should ignore label in selectmenu
<dandclark> Proposed resolution: Use the <legend> element for labeling <selectmenu> <optgroup>s as described in https://github.com//issues/558#issue-1289047468. The `label` attribute is not used for <selectmenu> <optgroup>s/<legend>s.
<tantek> +1 let's drop 'label' attribute for any displayable content
<tantek> q+
<hdv> gregwhitworth: the way I read the proposed resolution it is that the label should not exist, right?
<gregwhitworth> tantek: yeah I think it might be helpful to seperate those two into 2 proposals
<gregwhitworth> tantek: because I think we can quickly resolve on label attr
<gregwhitworth> tantek: I want to raise an issue on legend el
<gregwhitworth> tantek: I think legend is already overloaded with parsing due to fieldset
<gregwhitworth> dandclark: good point, I did some research and found that legend did not have any special parsing rules
<gregwhitworth> tantek: it wouldn't surprise me that a legend implies that a fieldset should exist
<gregwhitworth> tantek: if you've done research and you're sure that legend is unincumbered then great
<gregwhitworth> ack tantek
<gregwhitworth> tantek: like caption is frought
<tantek> s/frought/fraught
<gregwhitworth> scotto_: legend is treated as a div
<dandclark> Proposed resolution: Use the <legend> element for labeling <selectmenu> <optgroup>s as described in https://github.com//issues/558#issue-1289047468. The `label` attribute is not supported within <selectmenu>. https://usercontent.irccloud-cdn.com/file/MAdETc2p/image.png
<gregwhitworth> q?
<dandclark> Proposed resolution: the `label` attribute is not supported within <selectmenu>.
<dandclark> Proposed resolution: Use the <legend> element for labeling <selectmenu> <optgroup>s as described in https://github.com//issues/558#issue-1289047468.
<tantek> +1
<scotto_> +1
<gregwhitworth> RESOLVED: the `label` attribute is not supported within <selectmenu>.
<gregwhitworth> RESOLVED: Use the <legend> element for labeling <selectmenu> <optgroup>s as described in https://github.com//issues/558#issue-1289047468.
<JonathanNeal> +1
<tantek> +0 on <legend> element. not going to bikeshed it
<JonathanNeal> (delayed)
<hdv> we're on top of things! \o/

[dandclark]

Since we resolved on this I'm going to close the issue. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1357869 to track the work to update the Chromium implementation.

[josepharhar]

RESOLVED: the label attribute is not supported within <selectmenu>.

Since we are going to use the <select> element instead of creating a new element, I'm not going to forbid using the label attribute in optgroups since it is already valid and used everywhere.

In order to make the rendering reasonable, I will make <optgroup> stop rendering the empty space for a label attribute when the label attribute is not present, and try adding some UA styles to make <legend> look like <optgroup label>.