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

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

The Accessible Platform Architectures (APA) WG has reviewed this proposal too, and has some concerns and questions. (To be clear: this is from APA WG, and is not a TAG comment.)

We're very supportive of the trend of moving widgets/features into CSS and HTML, and away from depending on JS. There have been lots of accessibility wins because of this. We appreciate this carousel (and foundational) work has similar goals. Though carousels present several significant usability and accessibility challenges, they are widely used, so the goal of making them more consistent, accessible, and efficient is laudable. That being said, these are APA WG's questions and concerns...

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's [suggestion of limiting 'un-inerting' to the top layer](https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1845716939) could address 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.)

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?

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, or provide it (via either HTML inert, or tabindex=-1) as an enhancement:
   
   - [BBC's carousel](https://bbc.github.io/gel/components/carousels/)
   
   - [Heydon Pickering's "Content slider"](https://inclusive-components.design/a-content-slider/)
   
   Here are some carousels that work differently:
   
   - [Deque's carousel, based on tab panels](https://dequeuniversity.com/library/aria/carousel)
   
   - [Web Experience Toolkit's carousel](https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html)
   
   - [Every Layout has a "Reel"](https://every-layout.dev/layouts/reel/) - this requires purchase, but the tl;dr from APA WG members is that this is essentially just a horizontal scroll container, with no buttons.
   
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.

There's the [upcoming TAG call](https://www.w3.org/events/meetings/3f225b9b-3562-45ed-8922-e7a89be0b890/20250318T150000/) (organised on the thread for #1037) on which we we'd like to learn more about the motivations behind this - and the overall - proposal, and also how you expect both CSS inert, and the scrolling primitives (#1054), to be used outside of carousels, in future.

*[APA WG call where this was discussed](https://www.w3.org/2025/03/12-apa-minutes.html#5307)*

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

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