To be clear, #10310 was to discuss a specific subset of #9799. What ends up getting rendered is really a function of the appearance property and is already tracked by its own issue over in the CSS WG: w3c/csswg-drafts#10028 & w3c/csswg-drafts#5998.

I think an accessible select will always need to have text-based options, essentially. Not just for accessibility, but also for platforms that opt not to support the custom rendering. When you create a tree that one cannot derive text-based options from (and thus doesn't render anything with appearance:auto instead of appearance:base-select) that should essentially be a non-conforming.

My draft spec has a proposed updated content model here: #10548

The gist of the changes:

<select>

• Either one of the following:
  • Zero or more <option>s, <optgroup>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.
  • One <datalist>
• Zero or one <button>

<datalist>

• Either: phrasing content if not the child of a select element.
• Or: zero or more <option>s, <optgroup>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.

<optgroup>

• Zero or more <option>s, <hr>s, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.
• Zero or one <legend>.

<option>

• If the element has a label attribute and a value attribute: Nothing
• If the element has a label attribute but no value attribute: Text
• If the element has no label attribute: Text, script-supporting elements, <noscript>s, <div>s, <span>s, and “decorative images”.

Decorative images:

• <img> with alt=””
• <svg> with aria-hidden

Why would we only allow decorative images? I think we should make alt="something" work. People will want to be able to replace option text with images.

we had discussed images with alternative text being allowed. i think that might just be a miss. We had talked about how it could be problematic if people used images without alternative text or visible text in the option - and how that'd be an issue.

but i know there was also discussion about needing to potentially address your previous comment.

I think an accessible select will always need to have text-based options, essentially. Not just for accessibility, but also for platforms that opt not to support the custom rendering.

with your latest comment, are you implying it might be ok if image has alternative text, then such platforms could render the alt text instead of the image? if so that'd be great. i was worried that if a platform decided not to render the image, that the whole image, including alt text, would be dropped.

Relatedly, I think having authoring conformance requirements depend on ARIA seems a bit sketchy? ARIA is supposed to be used as a means of interfacing with AT, and not affect semantics or document conformance.

@scottaohara right, it's called "replacement text" for a reason. I don't see why we couldn't use that.

@annevk excellent, seems we're on the same page then. again, i think that's a mistake in relaying what had been discussed. an option should absolutely be able to contain non-decorative images. The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

the mention of decorative images was supposed to be in regard to if the graphic was a direct child of a select element (used outside of an option), not if it was a child of an option. cc @josepharhar

@domenic that's fair, and if not for the fact that aria-hidden=true is the primary author guidance for how to mark svgs as decorative, then the use of aria would have been avoided. but maybe it makes sense to reverse the way this is being talked about. lean more into where there would be author requirements to provide alternative text for graphics, rather than requirements about marking graphics as decorative/presentational.

Thanks for the discussion!

So it sounds like I should keep the content model the way it is but also remove the requirement of having alt='' or aria-hidden=true, and then add another requirement for this:

The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

Anything I'm missing? If not then I can go update the content model in the draft spec.

The only requirement with graphics being that if they are the only content of an option, they must have alternative text.

I don't think we need a specific requirement for this. There are many elements in the spec which don't make very much sense if they're empty (e.g., only whitespace, or only a non-alt image, or only <audio>). For example <p> or <em>. I don't believe we call out such restrictions on their contents.

For the title element we do call out non-whitespace text as content model, but for the option element without label attribute we only say text. But then we define text as potentially being nothing. We might not be as good about this as we should be?

We have "palpable content", but it might not be correct for option (for example an img with empty alt counts as palpable content).

Right now https://html.spec.whatwg.org/#the-option-element has

If the element has no label attribute and is not a child of a datalist element: Text that is not inter-element whitespace.

I think the intent is to catch the mistake where the contents of option is used as its value.

Should alt text be included in the submitted value? That would be a normative change, but maybe it's not a web compat problem (since you can't easily use images in option and they are ignored today). If so, https://html.spec.whatwg.org/#dom-option-text needs to be changed, and maybe the content model can just say that https://html.spec.whatwg.org/#concept-option-value must be non-empty (when in a select and no label attribute)

Should alt text be included in the submitted value? That would be a normative change, but maybe it's not a web compat problem (since you can't easily use images in option and they are ignored today).

I feel like the only case where making alt text the submitted value make sense is if there is no other text in the option element and the option element also doesn't have the value attribute. Wouldn't it make more sense to put a value attribute on the option as well?

For the title element we do call out non-whitespace text as content model, but for the option element without label attribute we only say text. But then we define text as potentially being nothing. We might not be as good about this as we should be?

This sounds in favor of including the "if they are the only content of an option, they must have alternative text" requirement. Do you think we should have that requirement?

i don't see the downside of calling this out. Even if just briefly and cross linking over to https://html.spec.whatwg.org/multipage/images.html#alt for the more detailed requirements for when an alt is necessary.

Wouldn't it make more sense to put a value attribute on the option as well?

It seems cumbersome if you would otherwise not have to do that. Since we already have a custom iterator to determine the text content we might as well handle img elements explicitly going forward.

Additionally, we have environments where we need to display the pure text version and that pure text version should be roughly the same as what AT sees I think and not necessarily reflect the submitted value (which can be nonsensical as far as an end user is concerned).

It seems cumbersome if you would otherwise not have to do that

that pure text version should be roughly the same as what AT sees I think and not necessarily reflect the submitted value (which can be nonsensical as far as an end user is concerned).

It sounds like you're in favor of including alt text in the submitted value. Is that correct?

the mention of decorative images was supposed to be in regard to if the graphic was a direct child of a select element (used outside of an option), not if it was a child of an option.

This sounds in favor of including the "if they are the only content of an option, they must have alternative text" requirement. Do you think we should have that requirement?

i don't see the downside of calling this out.

So it sounds like if the image it outside of the option it must not have alt text, and if its inside the image it must have alt text. I'm going to add this to the spec.

Relatedly, I think having authoring conformance requirements depend on ARIA seems a bit sketchy? ARIA is supposed to be used as a means of interfacing with AT, and not affect semantics or document conformance.

if not for the fact that aria-hidden=true is the primary author guidance for how to mark svgs as decorative, then the use of aria would have been avoided

For svgs, can we just make aria-hidden get applied automatically as part of the accessibility mappings when needed? Also, how is alt text supposed to be put on svgs in order to follow the requirement that it must have alt text when used inside an option element?

just talked with @josepharhar about this, and per the feedback in this thread we are instead thinking to drop the explicit mention of decorative images from the content model entirely.

Rather, author guidance can be provided in examples and notes, referencing back to existing spec content about the alt attribute, and explaining why it is important to mark graphics as either decorative or informative. Per Domenic's point, there is no special author requirements for other elements, like hyperlinks or the button element, that if you use only an <img src=... alt=""> as their contents then that would make non-conforming HTML. But a11y-specific checkers and WCAG success criteria exist and can catch these sorts of problems.

The only way I could still see graphics being mentioned in the content model, is in regard to needing a value to submit - so that an option like <option><img src=# alt></option> would return something. but again, very happy to just make that into an example if people think this scenario would be covered by the existing content model allowances?

I was very surprised at the idea that alt="" text, or SVG <title>, or generally any ARIA information, would be used for the submitted value.

Those accessibility strings are human-facing, whereas the submitted value is computer-facing. I worry that this will cause people to start writing their accessibility strings as computer-facing instead.

I agree with domenic and I think that we can include <img> alt text (and <svg> titles) in the option's label without changing the option's value.

I have a clarifying question though - should we use img alt text in the case that there is only an img with alt text and no other text in the option, or in all cases? If we're going to use img alt text in the case that there is also DOM text nodes, how should we concatenate the alt text with the adjacent DOM text nodes?

Here's an example:

<option>
  <img alt="hello world" src=...>option one
</option>

What should the label be? "hello worldoption one"? "hello world option one"? If we want to add spaces, does that not make sense in some languages? Should we account for whitespace and make it different if there is a space at the start of the text node like " option one"?

This would be easier if we only include alt text in the label when there is no DOM text nodes. @scottaohara

What should the label be?

all browsers handle this now per the accName algorithm. a space is added between the img element and the text in the calculation of the name.

i think it would be a mistake to allow authors to use images in options, but throw a curve ball and tell them that setting an alt wouldn't do anything. it already works in the name calculation for the option, so this would effectively break something that already works fine.

this seems more a problem with how to calculate the submitted value than what to expose to users visually / via the a11y tree.

as far as that is concerned, i agree with Domenic that I would not expect ARIA to contribute to that at all. I would, however, expect an image's alt to be included as part of the text idl if an explicit value wasn't specified for the option. that seems to be where the gap is.

if for some reason that's something that can't be solved, then it seems like there would need to be author guidance to state that if people are using images within their options, then they MUST also specify a value attribute with the string they want submitted. We're likely going to need that guidance to inform authors that ARIA should also not be expected to be considered for the submitted value of the option. Making a very clear distinction between the value someone perceives from an option's visible label or a11y name VS what would be the computed value that participates in form submission.

I would, however, expect an image's alt to be included as part of the text idl if an explicit value wasn't specified for the option. that seems to be where the gap is.

What do you think the value IDL is used for? In my experience, it's used for developers trying to determine or set what value is sent to the server. From that perspective, including alt="" values there seems problematic.

I am aware of the value IDL. Yes. thanks....

in my experience devs use the specified value, OR they expect the value to be calculated by the text content of the option - which given Anne's prior response, I would have thought the image's fallback text could have been made to take part of thta text calculation - so then per the HTML spec:

The value of an option element is the value of the value content attribute, if there is one, or, if there is not, the value of the element's text IDL attribute.

a developer could expect whatever they set as the option's text / label (including alt text) as to then become the value to send to the server.

working with developers who work with javascript frameworks and component libraries that have custom selects built with JS / ARIA - they similarly either grab the computed text of an option (which might then need to include image’s alts), or they use a custom attribute / data- attribute to provide a value - or they just have it all setup in their scripting and the actual value of an option isn't included in what's sent to the DOM.

all that said - i'm more concerned with the human facing label/value. if there is some reason that alt text can't be considered part of this computation, then i'm not trying to say "this must be done". far from it actually. I'm saying that if this can't be done, then developers need to be made aware of that.

but i'm against the idea of not including an image's alt in the computed name/label of an option - per joey's comment "This would be easier if we only include alt text in the label when there is no DOM text nodes".

Doing that would make something like <option>im from <img src=… alt=“country name”></option get exposed in the a11y tree as just “I’m from”.

But this is already a solved problem where the accname is properly computed for that situation. let's not break that because there seems to be hesitation about including an image's alt in the submitted value. If that won’t be done, then devs need to be informed that they must also set a value for instances where an image that serves as more than decoration is used. That might be inconvenient in some cases but shouldn’t be a huge problem for a dev.

For sure, the human-facing name/label should include those things. I just think that does not need to have any connection the developer-facing value (or the developer-facing text property).

then we agree on the part that's the most important to what i'm concerned with.

While I have my preference, as long as its clear in the spec what will / won't be used to calculate an option's value if a value attribute is not set, then that's all that really matters to me on that topic.

Thanks for the discussion! It sounds like alt text should be included for everything but the value attribute, and that alt text should be concatenated with other text by adding spaces. I will make these changes to chromium and the spec PR.

Those accessibility strings are human-facing, whereas the submitted value is computer-facing.

Today an option element consists of a "label" and a "value", which both can be initialized from the same string, the contents of the element. And all three of those have an API. label for the label, value for the value, and text for the contents. I think it would be weird if the introduction of the img element forced us to introduce a fourth kind of string belonging to option elements. Why would we want that?

It also seems inconsistent that <option>Blah initializes both the "label" and "value" but <option><img alt=Blah> would initialize neither (or perhaps just "label"? though @domenic seemed to argue for no developer-facing API).

Ok, I can make option.value include alt text to match option.label. Does that address your concern @annevk? Does that sound ok @domenic?

No, that goes directly against what I suggested above.

Again, I think the accessibility string should include the image alt text, but this should not be exposed anywhere besides to accessibility tech. It should not show up in option.label (basically label="" attribute reflection), nor in option.value (server-seen value), nor in option.text (basically a specialized textContent).

This is the same as how even though alt text impacts accessibility, it does not show up in node.textContent or node.innerText. In fact it shows up in zero current DOM APIs.

I don't really understand why you'd want web developers to write <option label=Norway alt=Norway><img alt="Norway"> over <option><img alt=Norway>. That seems extremely cumbersome. img elements are not part of any other element API so we haven't really considered this before.

The following are the kinds of cases I'm concerned about

<option>
  <img alt="A fjord">Norway
</option>

<option>
  <img alt="A Norweigan flag">
</option>

<!-- maybe in a game where you're selecting which country's army to send in -->
<option>
  <img alt="A viking warrior, representing Norway">
</option>

I don't think these are suitable values to submit to the server. The web developer should instead write specific value=""s. Likely, those values should not be Norway, if the backend works like most backends do! They should instead be sending NO or NOR or 578.

I worry that your proposal would steer developers toward doing alt="NO".

I don't see how those are materially different from <option>A Norwegian flag today. (The lack of space in the first example is presumably an error?)

I don't like making the model of option elements even more complex for this. I could maybe see not defaulting "value", but also excluding "label" seems plain wrong.

The image forming a part of the contents (and thus influencing both "label" and "value" (and text I guess)) is also what @scottaohara argued for above, but getting more input from @whatwg/a11y on the tradeoff would probably be good.

I don't see how those are materially different from <option>A Norwegian flag today. (The lack of space in the first example is presumably an error?)

The difference is that today, people know that images never form part of text in DOM APIs, like textContent and text and innerText. Breaking that expectation will likely lead to them writing broken code.

I don't like making the model of option elements even more complex for this. I could maybe see not defaulting "value", but also excluding "label" seems plain wrong.

What is more complex? The model I'm arguing for is the model we use for option elements today: use the text content. You're the one arguing for adding an unprecedented step that starts treating alt attributes as text content.

Today option elements only contain text.

I was asked to weigh in on this thread, and after reading it all I have to say I'm pretty happy with the model we've arrived on in #10317 (comment), #10317 (comment), and #10317 (comment).

It seems like myself, @scottaohara, @domenic, and @josepharhar are all satisfied with this direction of not including img alt text in label, value, and text API return values. I'm pretty sympathetic to the argument (#10317 (comment)) that including img alt text in these values would encourage developers to write their alt text in a more machine-readable way, instead of with accessibility and visual appearance in mind, thus undercutting the value of alt text. I also see no accessibility downside with this path (folks like @aleventhal might have more thoughts on this), nor do I find it "extremely cumbersone" for developers.

I'd love to hear from more people too, but I feel like we're just inches away from being able to resolve this issue in that direction.

It seems like myself, @scottaohara, @domenic, and @josepharhar are all satisfied with this direction of not including img alt text in label, value, and text API return values. I'm pretty sympathetic to the argument (#10317 (comment)) that including img alt text in these values would encourage developers to write their alt text in a more machine-readable way, instead of with accessibility and visual appearance in mind, thus undercutting the value of alt text. I also see no accessibility downside with this path (folks like @aleventhal might have more thoughts on this), nor do I find it "extremely cumbersone" for developers.

From an a11y perspective, I'm also supportive of the direction of not including image alt-text in the computed value property. I do agree that alt-text should (continue to) be used for accessible name/description computation, and display to the user when appropriate. However, adding this new behavior (unprecedented as well AIUI) of copying alt-text into server-submitted, and JS-visible values might have a detrimental effect on accessibility in general. Developers might find "odd" values in their value property, track them down to alt-text on contained images, and remove the alt-text to fix it. Perhaps they might even learn the lesson that alt-text breaks things, and stop using it elsewhere :(

I was very surprised at the idea that alt="" text, or SVG <title>, or generally any ARIA information, would be used for the submitted value.

Those accessibility strings are human-facing, whereas the submitted value is computer-facing. I worry that this will cause people to start writing their accessibility strings as computer-facing instead.

+1