[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.