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

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

Responding to https://github.com/w3ctag/design-reviews/issues/1055#issuecomment-2725956455:
  
> 1. We echo the concerns about 'un-inerting' - that it would not be obvious to develoeprs who've purposely 'inerted' a subtree that part of that subtree has been un-inerted. [@alice](https://github.com/alice)'s [suggestion of limiting 'un-inerting' to the top layer](https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1845716939) could address this.

While it's not necessary for the particular use case of making carousels have correct accessibility, the requirement to use the top layer to escape inerting prevents non-global inert escaping scenarios. E.g. if you must show something in the top layer as the only way to escape inertness, then it means that content appears to the user (potentially disrupting the visual presentation) even if it should be currently scrolled out of view or otherwise clipped. We agree that you should not be able to escape the inertness provided by a top layer modal dialog, and are preserving this.

> 2. Being able to un-inert in CSS would be inconsistent with the HTML inert attribute - this seems to be a significant DX (confusion) issue. (Note: we _don't_ think HTML inert should be changed to match CSS - per the above concerns.)

To be clear, is the recommendation here that the HTML `inert` attribute should not be escaped by css?

> 3. We are also concerned and wondering about the use cases where it makes sense to use CSS inert over the HTML attribute? What other scenarios, besides carousels, do you envisage for CSS inert?

There are many situations where the decision of whether to do this in CSS or HTML is somewhat stylistic (e.g. as with deciding whether to set `display: none` or use the `hidden` attribute). In many use cases CSS is what is making content not readable (e.g. some transform or reduced opacity applied), by being able to apply inertness in the same definition it ensures that it is applied to the correct elements, whereas having these things decoupled risks mismatches or not applying these things together.

Some cases where being able to use CSS to control inertness is uniquely valuable:
1. Peeking UI, possibly which animates in from a zero or near-zero opacity or from a 3d transformed perspective that is not intended to be read or interacted with.
2. Component-modal UI - where you want the presence of a component dialog that blocks access to the rest of a component, without using the top layer
3. Decorative background elements (e.g. transformed image elements or text not part of the semantic content, [matrix text effect](https://web.archive.org/web/20110807080625/http://girliemac.com/sandbox/matrix.html))

> 4. Whilst the [APG carousel pattern](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/) demonstrates one way to make a carousel, we find several differnt variations in the wild that work differently. Some allow the user to move focus via the keyboard to 'out-of-view' elements - this avoids the need for the user to find navigation buttons, or learn keyboard shortcuts, such as the arrow keys. Whilst not suitable everywhere, these patterns don't seem to be encouraged by the existence of CSS inert. We recognize that substantial research was done in preparation of this proposal; we are wondering if the below (or other patterns) were analyzed?>    The following carousels either work without using any kind of inert-ness,

The ability to apply inertness, or choose not to apply it, is a very intentional one. We are encouraging developers to decide what is right for their use case. If you have a paginated experience with many focusable elements, then for that experience you probably want your users to not have to navigate through all of the focusable items that preceed it, or those that follow it, to navigate the page.

However, if you have a simple list of items, then it probably does make sense to allow using tab to get to the next / previous item.

> or provide it (via either HTML inert,

This is exactly what css interactivity is for - to apply inertness, however unlike HTML inert it can be automatically updated as the user navigates through the pages whereas HTML inert requires developer script to update it as the user navigates between pages. This script is often a footgun.

> or tabindex=-1) as an enhancement:

tabindex=-1 IMO can be harmful, as it presents an experience which might work well for non-AT users, but which forces AT users to navigate all skipped content.

> 5. In general, allowing the behaviour of elements to be changed, without altering the visual presentation, presents significant risk. Accessibility consultants often see situations where the visual and semantic go out of synch (a prime example of this is when frameworks over-use the aria-label attribute, and it doesn't get updated to reflect changing visual content/design). This happens a lot, often as a result of systemic bugs.
>    In the case of CSS inert, we would be increasing the chance that these sorts of mistakes will be made - arguably much more likely with CSS than with the HTML attribute, because people could easily be copying CSS around, and accidentally leave in some code that renders a subtree inert, and not notice this.

Unlike properties like aria-label, inertness affects non-AT users as well, rendering the content non-interactive for all users. As such we think the risk is much less here than it would be with properties that only affect AT users.

We also think that being able to pair this property in CSS with the corresponding CSS that causes some content to be obscured will in many instances be less error prone than needing to have script modify the inert attribute on the correct elements.


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

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