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?

Some feedback from @fantasai

• Only <div> should be allowed instead of <span> outside of <option> because the elements wrapping <option> should be block level
• Elements like <em> and <bdo> should be allowed inside <option>s

I'll remove explicit references to <span> so that only <div> remains.

As for em, bdo, ruby, and other tags for doing things to text, I'm not sure there is an existing category that represents this, so I'll say "palpable content except for interactive content" inside options. If anyone has a better idea, I'm all ears!

Here is an updated overview of the new content model (to replace #10317 (comment)):

Within <select> these nodes are allowed:

• <option>, <optgroup>, and <hr>
• <div>
• <noscript> and script-supporting elements

Within <optgroup> these nodes are allowed:

• <option>
• <legend>
• <div>
• <noscript> and script-supporting elements

Within <option> these nodes are allowed:

• Text
• Palpable content except for interactive content
  • This is intended to be elements which support rendering text, like <ruby> and <bdo>
• <svg> and <img>
• <span>
• <noscript> and script-supporting elements

understand the feedback about no span outside of options - but not sure why it wouldn't be allowed within options? Or is that a miss that it's not listed along with div within option?

any other feedback needed to remove img/svg from being direct allowances of select (e.g., are they really necessary between options?), vs just allowed within options?

understand the feedback about no span outside of options - but not sure why it wouldn't be allowed within options? Or is that a miss that it's not listed along with div within option?

any other feedback needed to remove img/svg from being direct allowances of select (e.g., are they really necessary between options?), vs just allowed within options?

After looking through una's demos:

• I agree about span inside option, that is what is present in the demos. I'll update the PR and my comment to replace div with span when inside options.
• Unas demos don't use images outside of options, so yeah I think it is reasonable to remove that. I'll do so until we find a reason to re-add them.

In my last comment I said that I didn't have any evidence that authors use divs inside options, but @brechtDR was just showing me a demo which uses div inside options: https://codepen.io/utilitybend/pen/PoMbYRg/f7ceec6bf1b0153e77928e014ef210ba

Maybe we should allow divs and spans inside options?

In my last comment I said that I didn't have any evidence that authors use divs inside options, but @brechtDR was just showing me a demo which uses div inside options:

To elaborate a bit. One of the reasons i'd like to use at least <div> elements inside an option is the "lazy developer syndrome". Because I want to set 2 items inside my option block without having to specify the following in my css:

option span {display: block;}

I just want to quickly add 2 items below each other.

If it's possible, why not allow it as it is just one little task that is less tedious and speeds up development a bit?
Another quick draft of why: https://codepen.io/utilitybend/pen/VwobyNw

Yes, i know, you could just add two spans and set them to display block... question as a developer is: Why? Do I really have to? Why is this restricted? This feels like an unnecessary rule (especially since div is generic, in contrast to video or paragraphs).

i don't see any reason not to allow either of those elements within options. there are plenty of examples of developers doing this if you look at custom listboxes containing role=option elements. if you look for them using this within the actual option element, you likely won't find much if any, since those elements would be ignored right now.

The proposed content model seems overly strict.

I have a strong bias towards being more expressive and less restrictive overall. The focus here seems to be mostly on styling/display and not considering the potential for extended functionality or future innovation. Disallowing custom elements inside <select> is a limiting case in point.

I definitely acknowledge the large trade off between providing a more expressive API and maintaining base functional guarantees and accessibility. In general, I favor trusting the developer and giving them more power.

Disallowing custom elements inside <select> is a limiting case in point.

Custom elements seems fine to me as long as their content doesn't go against the content model. I'm not sure if there is any prior art to be able to do this in the HTML spec's content model though.

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

I think I would expect it to influence the text getter and therefore both the "label" and "value". (Although we should probably not define the latter two by directly invoking the text getter as we do today as that's kinda bogus.)

I'd prefer not to calculate alt text and incorporate that into these getters/attributes. Would it just be for the alt attribute on img elements? Didn't scott recommend that imgs used in select shouldn't even have any alt text in the first place?

i was/am not keen on the idea of informative images being used outside of options.

but an img element inside of an option, that could be decorative to sibling text. Or it could be the only content of the option, and so long as it has alt text, then that's the text fallback / value of the option.

With an svg, it looks like if actual text is defined in the SVG (title, desc or text elements, for example) then that could serve as the fallback text. https://codepen.io/scottohara/pen/rNXXJVd

so alt and text from within an svg seem like maybe they'd be in scope?

I'm not sure about ARIA attributes though - even though people will absolutely want/expect to use these, since they can with custom ARIA versions of selects (combobox / popup listboxes with options)

but anything that fully relied on ARIA or CSS to be accessible / render... maybe to Anne's earlier comment

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.

such things shouldn't be considered conforming - at least not without a fallback that would be able to render in browsers that didn't support customizable select?

I'd prefer not to calculate alt text and incorporate that into these getters/attributes.

Why not?

Would it just be for the alt attribute on img elements?

I think so.

SVG is an interesting case I hadn't thought about. I don't think SVG defines an algorithm we can use, but using the text contents of the first desc element, falling back to text contents of the entire SVG, could be reasonable?

(ARIA attributes are out-of-scope as they shouldn't influence core HTML semantics.)

From WHATNOT discussion: We should add alt text to display label, but maybe not submitted value. SVG elements also have a title element that we could use as a text representation for svgs.

For SVG elements, we can use the SVG <title> element which sets an accessible name: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title

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.