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

Thanks for the very well thought out response @alice!

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

Agreed! @emilio had concerns that while this solved the particular use case, it wasn't generic enough to help with situations where the content was not accessible for other reasons, e.g. I believe being obscured by a foreground tab was the case in their UI. There is something nice about how inerting content outside of the scrollport still allows it to be accessed by scrolling mechanisms, and for this specific use case it is ergonomically much simpler.

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

It doesn't need to be a specificity battle, I suspect even if we did allow authors to escape inert, we would only want to allow it to escape the author applied inertness and not extend to cases such as modal dialogs.

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

This was pursuing @scottaohara's suggestion https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2310950905 to see if this made sense. However, it does prevent us from explaining how the `inert` attribute works in any other way than computed magic, whereas if we use a new property we can easily explain it by a UA stylesheet

```css
[inert] {
  interactivity: inert;
}
```

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

Right, I think I've heard the argument construed as only the DOM should affect the tree, so I drew the parallel to these other properties to show that there is at least precedent for CSS affecting it as well. I agree that this doesn't mean it necessarily should. However, as in the OP i'm trying to make it easier for authors to do the right thing in some of these interactive use cases without needing to resort to careful scripting.

Would it make sense for `pointer-events: none;` to affect the accessibility tree since this content cannot normally be interacted with, at least not directly? I'm not sure if there are use cases where you want to make interactive content that can't be interacted with / targeted by the mouse / touch - it seems like this would be bad practice.

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


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

Received on Friday, 27 September 2024 04:14:34 UTC