[select] rendering elements which don't fit the content model

[josepharhar]

I was just talking to @jcsteh, @mcking65, and @aleventhal about customizable select, and they were suggesting that we should make the browser not render content which doesn't fit the proposed content model. This opposes and older resolution which was made here, where it was decided to render all content but use DevTools to push authors towards the standardized content model.

The justification is that we can always add more things to the content model as we discover new use cases that we can make accessible, but once we choose to render everything we can't go back. I'm hoping that we would also get feedback from developers about which use cases they can't address if we choose not to render "bad" content.

What do yall think about this?

[lukewarlow]

My gut is that hiding stuff is probably fine. But I have a few questions.

Might be dumb but what does a custom element count as for the content model would they still render?

If we blocked interactive content how is that defined? Would this potentially encourage people to do entirely the wrong thing (make an input from a div?) rather than mostly the wrong thing?

Does this present a forward compat issue if we don't render stuff currently but want to support it in future?

[scottaohara]

Very glad you talked to others about this. Definitely makes me feel a lot better about preventing author misuse / creating patterns that aren't supported (yet)

[josepharhar]

Thanks for the feedback Luke!

Might be dumb but what does a custom element count as for the content model would they still render?

Perhaps it would make the most sense to allow the custom element itself, and apply the rendering restrictions to all of its flat tree descendants?

If we blocked interactive content how is that defined?

I suppose that in the rendering section of the select element we could add a paragraph which says that nodes which don't follow the content model should not be included in layout or something...? I'm not aware of great precedent for precisely defining this though.

In terms of implementation, I was thinking at first of having a carefully crafted UA style rule which puts display:none!important on the "bad" elements, but it might also make sense to do this all during building of the layout tree.

Doing it while building the layout tree is probably more powerful and allows us to really look at the flat tree, but might also be challenging to do performantly.

Would this potentially encourage people to do entirely the wrong thing (make an input from a div?) rather than mostly the wrong thing?

Huh, yeah I guess you could make a contenteditable div to get around the restriction on input elements 👀. We could probably work around that too by considering whether elements have contenteditable when choosing whether to render them or not.

Does this present a forward compat issue if we don't render stuff currently but want to support it in future?

Yes, but the parser change feels a lot more dangerous and if that goes well then I'd be surprised if we couldn't start adding new things to the content model and render them.

[josepharhar]

I'm thinking some more about this, and I remember @jcsteh saying that we should not make something that works for sighted users but doesn't work for screenreader users. I think this is very compelling, but I also feel like @aleventhal's current plan of changing the role to dialog when authors break the content model solves this - or so I think, because I don't actually use a screenreader. I wonder if we could get more feedback from @jcsteh and @mcking65 about this, and/or have people try out the dialog fallback mode?

[aleventhal]

Joey, maybe they will provide more context, but here's my understanding. The dynamic change to role "dialog" should help when there is extra content at the beginning or end of the list of options. There was concern about authors putting unexpected things in between options. In that case, "breaking it for everyone" as in visually not rendering it, would prevent it from becoming a problem only for assistive tech users.

…

On Tue, Oct 1, 2024 at 5:44 PM Joey Arhar ***@***.***> wrote: I'm thinking some more about this, and I remember @jcsteh <https://github.com/jcsteh> saying that we should not make something that works for sighted users but doesn't work for screenreader users. I think this is very compelling, but I also feel like @aleventhal <https://github.com/aleventhal>'s current plan of changing the role to dialog when authors break the content model solves this - or so I think, because I don't actually use a screenreader. I wonder if we could get more feedback from @jcsteh <https://github.com/jcsteh> and @mcking65 <https://github.com/mcking65> about this, and/or have people try out the dialog fallback mode? — Reply to this email directly, view it on GitHub <#1099 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZQ4AFFVAY3ZAPF63MLZZMJUTAVCNFSM6AAAAABO6BMXE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBXGEZTAOBUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mfreed7]

If we blocked interactive content how is that defined? Would this potentially encourage people to do entirely the wrong thing (make an input from a div?) rather than mostly the wrong thing?

Does this present a forward compat issue if we don't render stuff currently but want to support it in future?

These two questions represent why I do not think we should go down this road. We've had this discussion before, mostly on #540 but also elsewhere. Here are the issues, as I see them:

1. If we go this route, things are fixed, permanently. Whatever the content model is for "v1" customizable-<select>, it can never change, since that won't be web compatible. So this will require very careful thought to get it exactly right. If there's something we decide (today) can't be used within <select>, then it never can be, even if there's a way to make it perfectly accessible, now or later.
2. For developers who "want" to do one of these prohibited things, they will be forced to go back to <div>s and <span>s to build their select. Those developers won't get any benefit from the browser developer tools, since the browser doesn't know that's "really" a <select>. So whatever they build will almost surely be non-accessible. (And it won't work with autofill, and it won't have all the other nice things that <select> provides.)
3. Small side point, but no other element (that I know of?) refuses to render content that violates the content model. (For example, buttons within buttons.) This would be a first.

On the other hand, if we continue to render content that doesn't fit the content model, a) we might later figure out a way to make that use case accessible, especially if it becomes popular, and b) developers who really violate the rules will always get helpful devtools guidance that they're doing something bad, and hopefully how to fix it.

[josepharhar]

If we go this route, things are fixed, permanently. Whatever the content model is for "v1" customizable-select, it can never change, since that won't be web compatible. So this will require very careful thought to get it exactly right. If there's something we decide (today) can't be used within select, then it never can be, even if there's a way to make it perfectly accessible, now or later.

I'm guessing this is because we shouldn't change the rendering of "bad" content after shipping? James was saying that we can always add more to the content model but once we start rendering the bad stuff then we can't take it back. Kind of the same point but the other way around?

• For developers who "want" to do one of these prohibited things, they will be forced to go back to <div>s and <span>s to build their select. Those developers won't get any benefit from the browser developer tools, since the browser doesn't know that's "really" a <select>. So whatever they build will almost surely be non-accessible. (And it won't work with autofill, and it won't have all the other nice things that <select> provides.)

Yeah this makes sense. I wonder how accessible things like this are and how much better we could do.

3. Small side point, but no other element (that I know of?) refuses to render content that violates the content model. (For example, buttons within buttons.) This would be a first.

Yeah this sounds similar to something that @domenic told me. I also think that we could extend our tooling to try to help people improve what they're doing in those situations.

Joey, maybe they will provide more context, but here's my understanding. The dynamic change to role "dialog" should help when there is extra content at the beginning or end of the list of options. There was concern about authors putting unexpected things in between options. In that case, "breaking it for everyone" as in visually not rendering it, would prevent it from becoming a problem only for assistive tech users.

Ah ok, this is good to know. I wonder how often people will want to put interactive elements between options, I haven't seen a use case like that before.

[css-meeting-bot]

The Open UI Community Group just discussed [select] rendering elements which don't fit the content model.

The full IRC log of that discussion

<bkardell_> jarhar: at tpac I was talking to several people about the content model for select
<masonf> q+
<bkardell_> jarhar: James said a few things that were really compelling... "I don't want to make it possible to make stuff that works for sighted users but not assistive tech users"... I agree. Mason also made a comment that we should render everything. There's been a decent amount of disucssion
<bkardell_> jarhar: I also found it interesting what Aaron said about people putting interactive elements _around_ the elements
<bkardell_> masonf: I have fairly strong opinions on this. Generally: If developers want to build something they are going to build it - look around. so if you restrict so that people can't build it, they will build it anyway and it will be inaccessible and the browser will have no way to help
<bkardell_> masonf: we have options if it marked as a select - and we can improve it over time, making it more and more accessible. But if they use divs and spans we can't
<bkardell_> masonf: if we fix the content and say if you don't render this content, then we will be stuck with that forever. If you can't put a button in a select, we never will be able to
<bkardell_> q+
<bkardell_> masonf: the third point is - it also would be new precedent - you can build all kinds of content today that still renders - we can warn people about that so that they stop
<masonf> ack mason
<masonf> ack bkardell
<masonf> bkardell_: if we prevent that, we'll be stuck. This is new precedent. Are there not other places where we drop content?
<masonf> q+
<keithamus> q+
<bkardell_> masonf: it might be an overstatement that "we can't" - it will definitely be very unlikely. You are right there are a few specific parser only limitations - I don't know what % of the web uses react, but there none of the limitations apply
<masonf> ack mason
<masonf> ack keith
<bkardell_> keithamus: I was going to say pretty much the same thing - the limitations on the parser should be lifted - there are so many things you can do with DOM that you can't do with the parser
<jamesn> q+
<bkardell_> keithamus: I think there is a bigger question/thing at play here... I think we could do a lot more to educate people on a11y - we could integrate something like axe into devtools. That would probably do more to alleviate this issue
<bkardell_> q+
<masonf> ack james
<bkardell_> jamesn: I wonder if we can throw developer console errors if there is stuff we don't know how to render accessibly
<keithamus> q+
<bkardell_> masonf: that is part of the resolution we had - to get that in your face if you get it wrong
<masonf> ack bkardel
<bkardell_> masonf: putting squiggly lines in the element pane
<masonf> bkardell_: I'm curious what would happen if we lifted all these things from the parser?
<jarhar> q?
<jarhar> i am lifting almost all the restrictions on the HTML parser for the select element
<masonf> bkardell_: markup on web almanac, there was weird but somehow functional stuff in even very big systems.
<bkardell_> jarhar: Yeah, I am planning on lifting as many on the select element as possible - I've looked at a lot of data. The only thing I've found that I believe is going to break is input tags inside of select tags - there are sites that put that there accidentally and somehow it works, and that will change
<bkardell_> jarhar: hopefully people will start seeing the console errors and start changing that. I want to relax the parser on that as much as possible - I've been running it and it's been ok
<masonf> q?
<bkardell_> masonf: I think we should talk about this as rendering, not parsing. If we're talking about the parser question as independent of what we are talking about now which is about rendering. Should that thing act as if it is display none. Or maybe the whole select should. That's probably more draconian than some want
<masonf> ack keith
<bkardell_> keithamus: on the topic of console reports, I think I've mentioned it before but I'd like to see some kinds of insights reports, like CSP reports that can send a request to a well known url that browsers can feed into a system. In the abstract we are not browsing the web with devtools open - what a lot of site do/want is aggregate reporting where it will tell you like "here are 1k users that have seen this issue"
<bkardell_> keithamus: here are the egregious pieces and the impact on your customers - hard to do today, but it could be really useful if browsers do that
<bkardell_> masonf: good idea, some things do get reported to that API already
<masonf> q?
<bkardell_> which ones?
<jarhar> keithamus: some exceptions that devtools reports go to window.onerror. we see things like you called showpopover on an already visible popover. there are other things that show up as warnings in chrome devtools and they don't make it to our error reporting software, like link prefetch or src attribute is missing on an image. theres also two
<jarhar> categories of errors. some sites will paginate their errors as server errors vs client errors. often times these are different teams.
<jarhar> keithamus: I spent a lot of time looking at our sentry thing for js errors and didn't look at the backend
<jarhar> keithamus: there's a signal to noise ratio there, there's a lot of stuff that isn't visible to frontend devs because its in the console it disappears
<jarhar> keithamus: there's also satiation. for GitHub the average page has 10 or 15 console errors.
<jarhar> bkardell_: those things are not - there's no way to send a header that says aggregate and report these errors. with csp I think what you mean is that with trusted types, pretend that this is on and don't enforce it and tell me what would break if it was enforced
<jarhar> keithamus: I want a feature like csp where the browser sends a bunch of these messages over the network. the best we have is exceptions right now. those do get aggregated because they go on window.onerror and we can report them with tooling. but if you have here's an endpoint and tell us about issues
<jarhar> bkardell_: aggregation and stuff is you doing it
<jarhar> keithamus: if anyone wants firsthand experience with this, I'd be more than happy to show examples of this
<jarhar> keithamus: it would be more of a 1v1 session
<jarhar> keithamus: sentry is a common error reporting tool
<jarhar> masonf: you're asking for a specific API. its like a new event that gets fired when a console warning or error gets fired by the browser. have you or anyone raised an issue about this?
<jarhar> keithamus: no
<jarhar> bkardell_: theres two things: there's that thing and then can you build into the browser a thing to do that, aggregate all the errors and here's where you should send the reports to. here's a URL that's every once in a while is going to get hit that says here's a bunch of errors
<jarhar> masonf: that sounds huge and controversial - but its not possible right now. people don't have devtools open right now, so if there are accessibility issues they cant find out
<jarhar> keithamus: the developer flow for acccessibility issues is that we try running ax in dev mode. its very slow. it tells you about errors, but we never see the aggregate cost of that. 1000 users are seeing this error. there's only so much that these tools can reason about. if there was an equivalent of csp that would be good, like contrast ratio
<jarhar> errors
<jarhar> q+
<jarhar> keithamus: spam that endpoint with all that stuff, and we can label it and organize it. here is our error event, but instead of error event, etc
<masonf> ack jarhar
<jarhar> masonf: your performance numbers are going to suffer if you turn that on
<bkardell_> jarhar: my idea of how to do that in the easiest way possible would be to ... maybe this is a security violations, but devtools messages are stored even when the devtools window is closed - if we just plugged into that...
<bkardell_> keithamus: I think there is a new category of things here - something new like CSP needs to be invented to say "I am interested in violations of... stuff..." here is the policy - we care about contrast issues, tell us about violations. I presume you could enable violations with csp reporting?
<bkardell_> masonf: we've gone down a road that is like reporting things to the console because we're going to keep rendering things - are we on the same page with that
<bkardell_> naman: I agree with you masonf but I also am scared about breaking old websites - so what I would support srendering everything except inputs
<bkardell_> masonf: out of curiosity are you worried about that because you know of issues
<bkardell_> naman: If all of the browsers can show that that is not an issue, I like it - but if that is the one thing that would become a big blocker - I would be ok with keeping inputs out
<masonf> q?
<bkardell_> jamesn: I'd like to hear directly from Aaron and jaime because they were the ones voicing this opionion - it wasn't me... I think we need to hear directly from those people who raised this
<bkardell_> scotto: I also think that unfortunately I would also want to have Jamie and Aaron and Matt king on this too... Aaron was on the other side of this before TPAC I think, but then it changed along the way.
<jarhar> q+
<bkardell_> Scott: seeing the swing - I wasn't at tpac, but something seems to have convinced him -- I'dl ike to hear what that was
<masonf> q+
<bkardell_> s/Scott/scotto
<bkardell_> jarhar: I did mention Aaron at the talk, he was at the table when we were talking, but I'm not sure he was convinced. He wasn't talking a whole lot. I don't necessarily think we was convinced one way or the other, but I do think they had some really compelling things to say - as I said at the start of the topic
<bkardell_> jarhar: "I don't want this new thing to be usable for everyone but me and Matt" - it is compelling if we cause it to break... by the way I do think it will be very difficult to prune the layout tree. Maybe if we don't render it, people will stop using it and go back to the old thing which is accessible... If we render the content, hopefully they have devtools open and they see one of the million things we're shoving at you and they'll
<bkardell_> learn about why and redo it to make it more accessible
<bkardell_> masonf: I definitely agree it's a good point the people who raised this aren't here... maybe we should leave it on the agenda for next week and specifically go look for those people to join
<bkardell_> keithamus: we could go to aria
<bkardell_> jamesn: Jamie won't be at either... I'm not sure the overlap in people is that different
<bkardell_> masonf: The initial post says "rendering elements that don't fit the content model" - it's an allow list inside an element and things that aren't listed aren't shown -- maybe there is a different twist here... Maybe it should be a disallow list of really problematic things that never in a hundred years we figure we'll ever want to change it.... that feels a little more tractable to me
<bkardell_> masonf: I don't know why you shouldn't put a section in there, for example... maybe you should or shouldn't, but I think we can say "You should not put an iframe in there" or something... specific things
<masonf> q?
<bkardell_> masonf: maybe we want to reword the issue
<masonf> ack jarhar
<masonf> ack mason
<jarhar> q+
<masonf> qq+
<bkardell_> scotto: I don't know if that is something that can get into the spec "what is not allowed" but I'd be happy to work on that - I already did kind of do this work when we created the content model from the previous resolution... we would need implicit aria actions for some of the things we eventually want to do - but there probably is a short list of things that should be absolute no's... I could write that and I am volunteering jamesn to
<bkardell_> help
<masonf> ack mason
<Zakim> masonf, you wanted to react to masonf
<bkardell_> masonf: we would have to put something like that in the HTML spec... anything that we do to not render content would have to get added to HTML. It would have to be a very specific section of the spec
<masonf> ack jarhar
<bkardell_> jarhar: the content model is an allow list, and I don't want to try to rearchitect it as a deny list. I don't want to limit us based on how the spec works right now. thinking back to what Aaron said, maybe putting an input in there is exceptionally bad - we can not render or have extra strong warnings or something...

[flackr]

I wonder how often people will want to put interactive elements between options, I haven't seen a use case like that before.

Maybe collapsible groups of options? Or a tree-like hierarchy where only the leaves are selectable options? Or delete buttons that are for some reason not in the option they're deleting..

[josepharhar]

I just talked with @aleventhal and it seems that we have different takes on the discussion from TPAC. He suggested that we should have a denylist that looks like this:

• Interactive content inside options except for links and buttons.
• Interactive content in between options (before or after all the options is OK if we change the role to dialog)

This seems pretty narrowly scoped and safe to me.

[jcsteh]

1. If we go this route, things are fixed, permanently. Whatever the content model is for "v1" customizable-, it can never change, since that won't be web compatible. I guess this is the reverse of my argument, as @josepharhar pointed out. I don't quite follow the argument this way though. If something is allowed now and then disallowed later because it is found to be fundamentally inaccessible in a way which can't be resolved, we break existing implementations because they depend on something working which we break. On the other hand, if we disallow something now and then allow it later, we don't break any existing implementations because those implementations won't be using the disallowed things in the first place. Is your concern that actually, some implementations might be using disallowed things (even though they don't render) and then suddenly they will render something later that they didn't previously? If there's something we decide (today) can't be used within , then it never can be, even if there's a way to make it perfectly accessible, now or later.

On the flip side, if we allow all the things and we later discover cases that just can't ever be made accessible, we now have a new shiny widget that will work for "most people" but be inaccessible to some. This is the crux of my argument: start with a clear set of well understood use cases and then widen the use cases as we discover new ones we know we can make work for everyone.

2. For developers who "want" to do one of these prohibited things, they will be forced to go back to <div>s and <span>s to build their select. Those developers won't get any benefit from the browser developer tools

But the browser developer tools would be telling them that they're doing one of those prohibited things, so either way, the developer is "knowingly" doing something prohibited and likely inaccessible. The situation is still bad for users. At least if we truly prohibit (instead of just dev tools prohibit), a developer has a reasonable guarantee of accessibility because the web platform promises that it will be accessible if it renders visually.

On the other hand, if we continue to render content that doesn't fit the content model, a) we might later figure out a way to make that use case accessible, especially if it becomes popular, and b) developers who really violate the rules will always get helpful devtools guidance that they're doing something bad, and hopefully how to fix it.

I guess the question is: how much weight do these rules carry if they're only really enforced by dev tools? You can certainly already create non-compliant web content in a myriad of ways; that's nothing new. Will these rules still be normative, even if browsers don't enforce them by not rendering things? I was just hoping not to create an entirely new way to make the web inaccessible. :) Still, I guess I can live with this if content that violates the content model is considered non-compliant, even if it renders. It doesn't give us the guarantee that "any custom select will be accessible", which is unfortunate, but at least we can still say that any "compliant" custom select will be accessible, which is still far better than divs/spans.

I also feel like @aleventhal's current plan of changing the role to dialog when authors break the content model solves this - or so I think, because I don't actually use a screenreader. I wonder if we could get more feedback from @jcsteh and @mcking65 about this, and/or have people try out the dialog fallback mode?

Part of the challenge here is that we just don't know what wild, obscure things authors will try, so it's hard to know what to test. And that's the worry: allowing all the things means that we'll only really discover this once it's out in the wild, at which point accessibility problems will be actively harming users.

I just talked with @aleventhal and it seems that we have different takes on the discussion from TPAC. He suggested that we should have a denylist that looks like this:

• Interactive content ...

Both of these rules only exclude interactive content, but what about non-interactive content? That might be equally important, but potentially impossible for users to access if we do this wrong.

[mfreed7]

So I spoke to @jcsteh and @aleventhal about this issue, and I think that at least the three of us have reached some sort of consensus. I’ll try to summarize that, and then we can continue the discussion from there.

Some points of clarification:

1. The HTML content model dictates what conforming content must look like. It is normative according to the spec, and can be validated via various tools including the W3C validation service.

2. Content that violates the content model is generally still rendered by browsers. (E.g. here’s a button containing a link containing a button containing…) There are no other examples of elements that “break” the rendering in cases that violate the content model, so it’d be a departure to do so for this specific element.

On this issue, an understandable desire has been expressed to depart from the existing behavior, and implement some kind of “don’t render” behavior for particular kinds of content, to “guarantee” accessibility. The pro of doing that is that developers will definitely notice, and won’t be able to build non-accessible content. The con is that the list of forbidden elements (defining what is accessible) is relatively fixed at the beginning, and can’t easily be changed over time.

The problem from my (@mfreed7) point of view is mainly that we don’t get to change the list of “bad” elements over time. Any such change would represent a web compat problem, and a fairly large engineering effort to verify compatibility, roll out slowly, triage bugs, etc. At Chromium, we’ve made a number of such changes, and they are always a ton of work. We’d therefore be loath to change these restrictions over time. I.e. we can’t start out with a ton of restrictions and move toward fewer limitations over time, or vice-versa. We need to get the list pretty close to “right”, at the get go. And that’s why I’m afraid of this approach - it doesn’t allow us enough flexibility to get this right.

As a quick aside, I mentioned that we’re afraid of compat risk if we were to “break” the rendering, and “unbreak” it later. We’ve seen a number of such examples, where developers take dependencies on a thing not having an effect, and then break when the thing starts having an effect. One great example is the width and height of checkboxes. I was interested in expanding the stylability of checkboxes in one specific way: allowing them to be rectangular instead of always square. So I ran a study to see how many checkboxes on the open web were styled with width != height, because any of those would break if both dimensions began to be respected. The result was that a whopping 10.9% of all checkboxes on the web fell into this category. The conclusion: it’s very hard to make changes like this without breaking things.

In contrast to the “break the rendering” approach, our prior plan (render invalid content, but provide strong/visible devtools errors plus failing conformance checkers) can be adapted relatively easily over time. Restrictions can be added and subtracted as we learn more about how developers use this new control. Warnings can become increasingly “visible”, e.g. by lowering lighthouse scores, having big red warnings on the Elements panel for broken components, etc. This kind of pressure can itself be ratcheted up over time.

Part of the challenge here is that we just don't know what wild, obscure things authors will try, so it's hard to know what to test. And that's the worry: allowing all the things means that we'll only really discover this once it's out in the wild, at which point accessibility problems will be actively harming users.

We agree on this - we’re definitely going to discover new ways that folks use <select> in inaccessible ways, as this feature rolls out. That’s why I’m in favor of a solution that is flexible, and can easily adapt to this new content, adding or subtracting restrictions as we go. The “break the rendering” approach is not very amenable to these rapid adjustments.

—--

So our general conclusion (among the three of us) was that the best option moving forward was to keep rendering content that violates the content model, but provide strong devtools guidance/errors for out-of-compliance content. We’ll also include informative notes within the HTML spec and perhaps on MDN also, to make sure authors are aware of what they should and shouldn’t do with this element.

Side note: we’d love it if folks could review the proposed, updated content model for <select>, to make sure it sounds right and makes sense.

[mfreed7]

As a quick aside, I mentioned that we’re afraid of compat risk if we were to “break” the rendering, and “unbreak” it later. We’ve seen a number of such examples, where developers take dependencies on a thing not having an effect, and then break when the thing starts having an effect.

As if to underscore this point, a bug like this was reported to us this morning: we changed the <details> element to allow the display property to have an effect, and it broke a site that was setting it to display:flex but relying on it still being display:block. You might think that is a fluke, but it was the second such bug. The first such bug also relied on a similar assumption.

[scottaohara]

i'm struggling to think up how an iframe, or an object element setup to behave as an iframe wouldn't cause problems for users, particularly those using assistive technology, who thought they were navigating a list of options, but now are somehow interacting with the content of a nested web page.

those elements are two that i just keep thinking about how they could harm the user experience, and i can't think of a good use case for why someone might need them in this context.

[domenic]

iframes are pretty commonly used to display anything controlled by a third-party. E.g. imagine a payment method selection dropdown where each payment method represents themselves as an iframe. The iframe probably only contains a single image, or maybe some text, or maybe an SVG. But those elements being in an iframe doesn't disqualify them from being valid options.

[scottaohara]

if this weren't in the context of an interactive element, thus making the use of an iframe already invalid, i would have no argument against what you're saying.

but if someone were to use an iframe within an option, for example, even if that iframe only contained an image or text, then that author would likely have to prevent clicks to the iframe, so that it wouldn't get in the way of the option being selected. And, they'd have to duplicate the important content of that iframe into the primary doc/option, as nothing rendered in the iframe would contribute to the naming of that option.
So, at the very least, <option> <iframe src=... title="the text displayed in the iframe" style="pointer-events: none"></iframe></option>

and this is just for a simple example. outside of already being invalid (iframe being categorized as interactive and thus already invalid within a select), and more complex iframe content having various other hurdles that would need to be accounted for by browsers and AT alike, I again acknowledge the use case - but am not sure the LOE for browsers/authors is really worth it.