Re: [w3ctag/design-reviews] CSS inert (Issue #1055)

jcsteh left a comment (w3ctag/design-reviews#1055)

> Outside of uninerting, some other situations for inerting visible content (i.e. use cases that wouldn't be supported by an offscreen is inert api) are when content is technically visible, but either:
> 1. Not fully visible (e.g. peeking at next / previous content),
> 2. Obscured (e.g. tabs that animate opacity in/out or z-index forwards / backwards) or transformed such that it's not readable or intended to be interacted with e.g. via a 3d transform on previous / next items in a scrolling list. A card stacking UI is a common use case of this where the subsequent or previous elements are arranged as if below the current in a stack.
> 3. Low to zero opacity.

The major problem is that inert *semantically* enforces that such content is not perceivable to the user, but there is potentially no *visual* impact (unless the content is interactive). That is a footgun at best, a potentially catastrophic accessibility failure at worst. History would suggest that a significant number of developers aren't going to heed accessibility warnings (or even requirements) in the spec, let alone test with accessibility tools.

Of course, all of this is true for the HTML inert attribute as well and it can be just as harmful if misused. I'd argue the risk is even more severe in CSS, though:

1. The inert HTML attribute is more clearly tied to semantics precisely because it is associated with an HTML element.
2. It's less clear with CSS, especially given that the majority of CSS is visual. Authors are likely to think even less about semantics with CSS (if they think about semantics at all) with CSS than they are with HTML.
3. Because it's in a style sheet, it can apply in more complex ways than HTML.
4. The ability to undo inertness makes things more complex and means that authors could potentially make something broadly inert, realise it causes problems for interactivity on some descendant and undo inertness on that descendant, potentially leaving large areas of non-interactive content visible but completely inaccessible.

If authors make these mistakes, they'll likely be none the wiser (assuming they even care), since there's no visual indication that this is happening. In contrast, the original overflow-interactivity proposal was much less risky from an accessibility perspective because impacted content would also be invisible; i.e. everyone has an equivalent experience.

If we really wanted an off-screen/obscured, non-interactive state, I'd suggest that this should be a new property which does both or at least has some obscuring visual impact. This way, it's impossible to accidentally mess up the semantics without breaking it visually too; the two are intertwined. I realise this isn't how CSS normally does things, but CSS also doesn't normally mess with semantics. Once CSS starts tweaking semantics, it needs to consider the semantic implications more carefully.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1055#issuecomment-2756592149
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1055/2756592149@github.com>