Hi @flackr, the TAG just discussed this and we weren't able to work out how the accessibility of something that uses this property would be handled, specifically in this new carousel model examples.

Consider that you have a carousel with all the scrolling business set up (using the new features you are defining, a new scrollable container with linked buttons, etc...). If you focus the content in that carousel, I'd assume that you could then scroll it to see stuff that was not within the visible space. As a concrete example, you might have an image carousel with three images shown and a number more offscreen. Maybe each item has a link or interactive controls.

Someone using a keyboard (arrow keys, tab) might focus the first and then use keys to move to the second and third. If the fourth is offscreen and therefore inert, would having it be inert make it not possible to focus it with keys? Obviously, someone clever could avoid the problem by avoiding use of inert for the items that are next up. But that would seem to defeat the point of having the content be inert.

In general, if we are viewing this as a specialized scroll container, if you look at a regular iframe or overflow: auto; visibility: hidden elements, the things that are not in view are not made inert in any way, they just aren't shown. Accessibility tools know how to handle that. If this work is providing new scrolling affordances in line with ordinary scrollable content, does the accessibility advice you refer to still apply?

Having only the in view items be in the tab order is the recommended design by the ARIA Authoring Practice Guidelines, https://www.w3.org/WAI/ARIA/apg/patterns/carousel/.

For instance, the screen reader experience can be confusing and disorienting if slides that are not visible on screen are incorrectly hidden, e.g., displayed off-screen.

The ARIA APG buttons example and tabs example do this by having the not yet reached items be display: none. The Web accessibility initiative example sets aria-hidden=true on the offscreen items.

Just as with those accessibility examples, we are encouraging developers creating a slides style experience to make offscreen items inert and use ::scroll-marker and/or ::scroll-button pseudo-elements as slide controls to access that content. Making all of the content (or even just the next item) available in the tab order creates an accessibility anti-pattern where a user needs to tab through all of the items before they can get to content or controls which follow it.

In general, if we are viewing this as a specialized scroll container, if you look at a regular iframe or overflow: auto; visibility: hidden elements, the things that are not in view are not made inert in any way, they just aren't shown. Accessibility tools know how to handle that.

visibility: hidden does remove items from the accessibility tree, however toggling this is likely to result in flickering and doesn't support use cases where you want to peek into the next item. If you don't hide the content, it provides a suboptimal experience for these use cases, which is why the accessibility guidelines actually recommend making offscreen content hidden in some way.

If this work is providing new scrolling affordances in line with ordinary scrollable content, does the accessibility advice you refer to still apply?

This property is useful for non-scrolling cases as well. Since it is inherited this enables a long desired goal of being able to author component modal dialogs which are more challenging to create with the inert HTML attribute as you cannot undo it within the subtree. E.g.

<style>
#my-component:has(.modal) {
  interactivity: inert;
  & .modal {
    interactivity: auto;
  }
}
</style>
<div id=my-component>
  <button>Controls</button>
  <div class=modal>
    <p>You must choose X before you can continue</p>
    <button>Option 1</button>
    <button>Option 2</button>
  </div>
</div>

For generic scrolling experiences where the user does not have specific scroll navigation controls, I would not recommend they inert offscreen content. However, even if they did, many of the assistive tech I've experimented with has mechanisms for scrolling.

OK, I think that you mostly answered my question. This was not really about whether inertness could be useful (your example clearly demonstrates that), but about the accessibility properties you get.

Consider my budget vertical carousel:

  <style> div { height: 1.2em; margin: 0; padding: 0; } </style>
  <div style="overflow-y: auto">
    <div><a href="#">One</a></div>
    <div><a href="#">Two</a></div>
    <div><a href="#">Three</a></div>
  </div>

Right now, I can tab through the items and they each show in turn. When I have any of the items focused, the arrow keys scroll the box. If item three is inert because it is not visible, would that continue to work? Does it require some additional, special action on the part of the developer to have that work?

If item three is inert because it is not visible, would that continue to work?

If item three is inert, tab will go to the next focusable after the overflow div. However, arrow keys will still scroll the box, making it visible (and thus focusable).

Since it is inherited this enables a long desired goal of being able to author component modal dialogs which are more challenging to create with the inert HTML attribute as you cannot undo it within the subtree.

Once again: this was a deliberate choice when we were specifying the inert attribute, and I'm still opposed to adding this mechanism via the CSS attribute (even when it's "only" undoing inertness added via the CSS property). I have argued that this mechanism should be instead provided only in conjunction with top-layer mechanisms.

I have argued that this mechanism should be instead provided only in conjunction with top-layer mechanisms.

@alice, just to make sure I understand from a process perspective, this means you believe the CSS WG came to the incorrect decision in the debate they had on this back in September, right?

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

   • Heydon Pickering's "Content slider"

   Here are some carousels that work differently:

   • Deque's carousel, based on tab panels

   • Web Experience Toolkit's carousel

   • Every Layout has a "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 (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

@matatk Thanks for sharing the APA group's thoughts; it's really reassuring that I'm not alone in having concerns.

Since you'll be meeting to discuss this tomorrow, I'd like to try one more time to make sense of this proposal and where I would prefer to see things go. Obviously I'm not the person who has to be accountable for getting things specced or shipped, but I really have spent a great deal of time over the last decade or so thinking about these issues.

I think that the shape of the proposal here, when presented as a solution to the problems of carousels specifically, represents a fairly severe scope creep. There was a solution proposed in https://github.com/w3c/csswg-drafts/issues/10711 which is not mentioned as a considered alternative in the explainer linked in this issue, but which I think fits nicely on to the problem as described:

2. Adding a CSS property specifically for making offscreen content inert, e.g. overflow-interactivity: auto | inert. This would make content that does not intersect the optimal viewing region of the scrolling container inert as it would be if it were display: none.

In particular, I noticed in the BBC carousel guidance:

As the user scrolls by mouse, touch, gesture, or by using the auxiliary buttons, browsers that support IntersectionObserver add the inert attribute to items that go out of view and remove it from items that come into view.

Much of the early discussion on https://github.com/w3c/csswg-drafts/issues/10711 favoured this proposal, and even notes that it doesn't rule out a more general inert property in CSS.

However, in the course of the discussion, several adjacent problems were drawn in:

1. On-screen content which also needs to be inert (and, presumably, needs to be made so without using JavaScript to set the inert attribute).
   • This is vaguely mentioned in the 22 August IRC log but without a specific use case; Rob elaborated in a later reply to my comment in the issue that the specific use case was "being obscured by a foreground tab". (I'm not sure whether it wasn't minuted in the earlier discussion, or whether this was from a separate discussion, but I can't find any more details on that scenario.)
2. Content which needs to "undo" inertness.
   • Much later in the discussion, @scottaohara elaborated on scenarios where this would be necessary.

I don't have enough information about the scenario envisaged in (1) to understand how the proposal here applies to it; at a guess, it's an implementation of a tabbed interface where tabpanel contents are stacked on top of one another so that only the front panel is visually accessible, but the rest can't be visibility: hidden or display: none for some unspecified reason.

For 2/3 of the scenarios Scott lists for (2), I don't think this proposal even actually helps directly, except inasmuch as it allows authors to give up on modal <dialog> by providing a (IMO) fairly bad alternative:

• Since it doesn't (and probably shouldn't) allow escaping inertness caused by a modal <dialog> showing, it can't help with live regions outside of the dialog being made inert;
• Likewise, it can't help with popovers showing on top of a modal <dialog> being erroneously made inert.

The reason I believe it's a fairly bad alternative to modal <dialog> is that it still requires authors to draw the rest of the owl (i.e. implement all the behaviour of <dialog> from scratch), and that it doesn't even have <dialog>'s ability to really make the rest of the page inert; whether something is inert or not is based purely on what rule ends up applying on that element.

Edit: oh, apparently the inert attribute can also be overridden now? https://github.com/whatwg/html/pull/10956#issuecomment-2704345559

Even for the "UI tour" example Scott gives, I think the same risk applies without the strong inertness provided by <dialog> or inert: you have to trust all the developers directly or indirectly working on a given page not to author styles which cause an element to become un-inert when you don't intend it to be, and unlike with the majority of CSS properties you don't even get any visual indication that your styles have inadvertently become broken.

What would I prefer?

I think the problem stated in the explainer is well worth solving, and I think the option mentioned above which @flackr originally proposed is a nice solution, without the problems inherent in the current proposal.

I think that the current proposal would be less problematic at least if it worked more like the inert attribute, and didn't allow any undoing of inert by using the property (including when content is made inert by the property). This is what I had initially misunderstood was being proposed, based on @emilio's comment.

Regarding undoing inertness, I linked earlier to my comment on the PR arguing that the situations where authors want to be able to "undo" inert would probably be better addressed using a mechanism based on the top layer primitive. Mason even filed an issue to at least address the "popover on top of a modal dialog shouldn't be inert by default" problem. In a comment on that issue, I fleshed out a little more my ideal scenario for how this should function:

I think if I could wave a magic wand, I would make the dialog "blocking" behaviour instead a function of the top layer under certain circumstances. Then, everything above the "blocking" top layer would be excluded from the inerting behaviour, and everything below it would be included. That would remain consistent with the current behaviour of <dialog> and fullscreen elements, other than the undesirable behaviour described in this issue. It would also be consistent with the visual appearance of relevant top layer elements. Dialogs' blocking behaviour is visually indicated by positioning them such that they visually block other other content, often with a backdrop. Likewise for fullscreen elements, which obscure literally all other content other than higher top layers.

I think a full exploration of inert-escaping scenarios would also be highly worthwhile: the fact that developers were so eager to add it to the scope of this issue shows that there is a very real and urgent need there. However, I don't think they've been done justice here.

just to make sure I understand from a process perspective, this means you believe the CSS WG came to the incorrect decision in the debate they had on this back in September, right?

Sure.

I have argued that this mechanism should be instead provided only in conjunction with top-layer mechanisms.

Component-modal dialogs are a use case where putting something in the top layer is not appropriate as doing so would make it effectively globally modal preventing interaction with the rest of the page and visible even if the component wasn't visible. However, doing this correctly does require careful coordination within the components on your page - e.g. the author may have to combine with a count to determine whether the thing should really be interactivity: auto or not because it's inside the inert portion of an ancestor component, e.g.

<my-component id=c1>
  <div>
    <button>This is made inert because it's covered by #i1</button>

    <component-modal id=i1>
      This modal element obscures the component only and blocks interaction with the rest of the component.
      It may be associated with a nearby control and thus near it in the dom to facilitate positioning near the associated element.
     </component-modal>
    <my-nested-component id=c2>
      <component-modal id=i2>
        <!--
        This should still be inert since it is covered by #i1,
        css libraries would need to conditionally remove inertness based on an inherited count of inerting ancestors
        -->
      </component-modal>
      <button>This is made inert because it's covered by #i2</button>
    </my-nested-component>
  </div>
</my-component>

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.

That said, the semantics of offscreen is inert is nice in that it could empower the UA to make offscreen content discoverable, see https://github.com/w3c/csswg-drafts/issues/11553

I think that the current proposal would be less problematic at least if it worked more like the inert attribute, and didn't allow any undoing of inert by using the property (including when content is made inert by the property). This is what I had initially misunderstood was being proposed, based on https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1843685422.

This was the original proposal for the interactivity property, that it could not be undone and was roughly equivalent to adding the inert attribute, however @emilio and @nt1m https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2338876054 expressed the desire to be able to explain the underlying model we have for uninerting - as well as @scottaohara bringing up the use cases which I acknowledge you've considered in detail. I think the component-modal use case is one that wasn't discussed yet. Allowing it to be undone makes the property behave similar to visibility (which also applies / inertness when hidden and can undo itself) and pointer-events (not inert, but not also interactable with by pointing devices).

I'm going to repeat my two main points:

I think that the shape of the proposal here, when presented as a solution to the problems of carousels specifically, represents a fairly severe scope creep.

I think a full exploration of inert-escaping scenarios would also be highly worthwhile: the fact that developers were so eager to add it to the scope of this issue shows that there is a very real and urgent need there. However, I don't think they've been done justice here.

A full exploration would carefully consider use cases including component-modal UI, as well as considering the downsides of any particular solution.

The coordination problem you mention proves my point: if authors get that wrong, especially if page authors are using multiple components which all use the interactivity property, most users - and thus most authors - won't notice there's a problem, but assistive technology users will be left with a broken experience.

Allowing it to be undone makes the property behave similar to visibility (which also applies / inertness when hidden and can undo itself) and pointer-events (not inert, but not also interactable with by pointing devices).

This is not a justification. visibility is easily debuggable: content will either be visible or it won't. Properties which disproportionately affect assistive technology users have different considerations.

pointer-events also doesn't disproportionately affect assistive technology users.

We have a responsibility when making changes to the web to carefully consider the impact on all users, and (in my opinion) especially the impact on assistive technology users, since those impacts are less likely to be considered by authors, for all sorts of reasons. It doesn't seem like that care has been taken here.

TAG reviewers may also like to catch up on the comments on the HTML PR:

• @scottaohara calling out an issue this creates with customizable select
• @smhigley warning of potential pitfalls

some quick things here as a comment of mine is being cited a bit.

1. for the most recent reference in alice's previous comment - i'm happy to see that an update to the UA stylesheet for customizable select would help prevent authors from undoing the inertness of the custom select's button part - which was made inert very much on purpose and should not be able to be undone by authors.
2. i want to call out that the use cases I mentioned / have been cited also have me stating "I am also totally fine with CSS not being the way to do that" - and so that makes sense out of context: I did not and do not strongly believe CSS is the only way to solve these use cases. I will acknowledge that at the time, it was a way that seemed worth considering. I say this because I want to make it clear that while I would like a solution for these use cases - I would be perfectly fine with alternatives (even if they weren't all immediately available). Per the very real concerns of misuse / pitfalls, I feel it's important I state that I am much more on the side of not wanting to introduce a feature that could potentially be problematic and misused. Especially since it would be unlikely to walk back once it was release into the wild.

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.

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's suggestion of limiting 'un-inerting' to the top layer 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)

4. Whilst the APG carousel pattern 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.

I just mentioned some library and developer feedback on https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2762007667 that I feel are meaningful use cases that CSS inert is best suited to support:

• Crawling a tree with JS to be picky about which nodes are inert or not? CSS does that with selectors
• Adapting a tree crawl or UI to various screen sizes to manage whether or not items are offscreen inert or on screen and interactive? CSS does that with media queries
• Knowledge of whether or not the inert item is actually off screen or just obscured in other UI layering creative design ways? CSS is already orchestrating those moments and knows best when to change it

It's very meaningful to use conditional inert strategies to guide users to focusable content. Applications balance this very complex task these days, and developers are reporting that inert is a bit too rigid. CSS can pick up these moments, enhance and guide user experiences.

I need to step away from this for a bit; it's been exceptionally stressful trying to engage on this topic when there doesn't appear to be a genuine effort made to understand and engage with (not just rebut) the feedback others and I are giving on accessibility.

Some brief thoughts, however:

• HTML inert was never meant to be a one size fits all solution.
• However, it was designed carefully to try and mitigate the worst accessibility risks.
• A one size fits all solution is most likely not a good idea; solutions more tailored to specific problems are going to be easier to reason about regarding trade-offs, easier to design in such a way that they match up with the desired visual appearance in each case, and less likely to come with the type of accessibility risks we're seeing here.
• Anything which impacts the accessibility tree without impacting visual appearance needs to be very, very carefully approached, and that care has absolutely been and continues to be absent here.
• This is doubly true in the context of CSS, which is a truly brilliant system which was specifically designed for changing the visual appearance of HTML content.
• Yes, this is still true even when the property in questions impacts interactivity.
• The name interactivity doesn't even make clear that it will affect the accessibility tree, just for starters.
• Just because content isn't interactive doesn't mean it isn't critical, and an author might even deliberately make critical content non-interactive for similar reasons to why authors make content user-select: none.
• Consider how this may be misused by authors who aren't "well intentioned" or who are even "well intentioned but in a hurry/ignorant/misguided" and/or lack accessibility testing resources.
• Consider the unintended use cases as well as the intended ones. What might authors use this for "off-label" without fully understanding the implications?
• Consider how this may be misused in AI-generated code.
• A note in the CSS spec can and likely will be ignored by the vast majority of authors.
• This is likewise true for the best written CSS Tricks or web.dev article.
• Authors will learn primarily through trial and error, and their trial will absolutely not, in the majority of cases, include testing with assistive technology or, in all likelihood, the keyboard.
• Actively pushing authors away from rather than towards carefully designed native options like <dialog> and popover seems like a regressive move, especially for accessibility.
• Please, please, please slow down and listen to what others are saying about the accessibility risks.

(I'm copy-pasting this comment in a few places because this conversation has been so widely distributed. I apologise for the noise.)

We posted a TAG comment on the overall carousels proposals last week. It contains our concerns regarding interactivity (as well as questions on a couple of other parts of the overall proposal).

Closing this sub-issue. Please refer to the response in the parent issue: https://github.com/w3ctag/design-reviews/issues/1037#issuecomment-2754205037