Re: [csswg-drafts] [css-ui] Support setting offscreen content inert (#10711)

I came across this issue more or less by chance, but nevertheless I have some thoughts, having been involved in the resurrection of the `inert` attribute.

I think (at least) two things have become conflated here that I'd like to argue should be kept separate:
1) Should it be possible to make content inert using CSS properties?
2) Should it be possible to escape inert? And/or how should inert-ness be inherited?

I do think there is probably a good argument to be made for being able to make content inert using CSS properties, and I think the example in the issue description is somewhat compelling. I'm not personally sold on the idea of being able to do things purely in CSS as a good _in itself_, having seen more that one well-intentioned attempt to implement things without javascript which resulted in an inaccessible experience. I do think, however, that making it more convenient to do the "right thing" makes it more likely that developers will... do that. I like the example in the issue description because it seems like the type of case where applying the attribute might be fragile if done in script, but is a couple of lines of CSS which should be easy to test and maintain. I think the "option 2" proposal seems to be the most convenient way to solve the specific problem laid out here, to that end.

I'm hesitant on the question of whether it should be possible to "un-inert" content. We went back and forth on this with the attribute as well, I think, and landed on the current behaviour partly for HTML boolean attribute reasons, but also partly because we didn't want to have authors accidentally or deliberately escaping inert and degrading the user experience.

I have a hunch that the main (and possibly _only_) use case for escaping inertness is to create modal UI. I think that if that is indeed the case, we should be talking about modal UI specifically (for example: does all modal UI belong in the top layer?), and I don't think that having a CSS property which can get into specificity battles (especially when the property in question doesn't necessarily have a visual impact, making it harder to perceive when it's applying) is the right approach.

On that note, I'm also not clear after reading through this issue why this is being prototyped as an extension to `visbility`. It seems like that has potential for unintended consequences as it interacts with `visibility` rules with different specificities, plus it seems semantically confusing given inertness _isn't_ a visibility.

---

Aside: I'm sceptical of arguments along the lines of "CSS already affects interactivity/the accessibility tree, therefore it's invalid to argue this doesn't belong in CSS". CSS affects interactivity and the accessibility tree _because it affects presentation_. Content in a `display: none` subtree can't be interacted with because it's essentially not there for anyone: there's nothing there to be a click target, there's nothing to draw a focus ring a round, there's nothing to direct a screen magnifier to. The change to that content's interactivity is a _result of_ the change to its appearance. There's a common misconception that the accessibility tree should theoretically be based purely on the DOM tree. In fact, the accessibility tree is intended to be as faithful a representation as possible of the visible experience, with exceptions as necessary to improve the user experience for AT users. This is because, firstly, AT users (including screen reader users) may well be able to at least partly see the visible experience; and, secondly, because the visible experience is the experience which will almost certainly have been given the most attention by the web page authors.

-- 
GitHub Notification of comment by alice
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2359573310 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 September 2024 22:40:08 UTC