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

The CSS Working Group just discussed `[css-ui] Support setting offscreen content inert`.

<details><summary>The full IRC log of that discussion</summary>
&lt;matthieud> flackr:  many website designs when creating paginated stuff or when the site provide an alternative to a long scrolling document, the recommended practice is that content outside of the viewport is inert<br>
&lt;matthieud> flackr: you dont have the content in your accessibility tree<br>
&lt;matthieud> flackr: it can be done with display:none but not very good<br>
&lt;matthieud> flackr:  you can do aria:hidden as html attribute so need a script as you progress animation<br>
&lt;matthieud> flackr: new simple way to say "content out of view is inert"<br>
&lt;matthieud> flackr:  we could either assign this on the scroller (overflow) or on the element itself  ?<br>
&lt;emilio> q+<br>
&lt;matthieud> astearns: the default value for overflow-interactivity is auto in option 2<br>
&lt;astearns> ack emilio<br>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;kizu> q+<br>
&lt;matthieud> emilio:  Is overflow the only place we want to support this use-case ?<br>
&lt;matthieud> emilio:  author might want this for stuff in the screen<br>
&lt;PaulG> q+<br>
&lt;matthieud> flackr:  similar usecases to animate to/from content not the accessibility. Option 1 would allow that because its not tight to overflow<br>
&lt;ntim> q+<br>
&lt;matthieud> Option 1 has added complexity but you cant select offscreen content with a simple selector today, so for the scrolling usecase you would have to animate the interactivity property with a view timeline or something<br>
&lt;astearns> ack kizu<br>
&lt;matthieud> kizu:  Option 2 is nice. option 1 is powerful but limited<br>
&lt;emilio> q+<br>
&lt;matthieud> kizu:  always risk to break accessiblity with all options : if we apply this to an element but cant reach it without scrolling,  accessiblity will be broken<br>
&lt;matthieud> kizu:  because it's inert you would only be able to scroll to it, cant reach it in any other way<br>
&lt;matthieud> kizu: Option 2 is safer because tight to scrollable container<br>
&lt;astearns> s/tight/tied/<br>
&lt;astearns> ack PaulG<br>
&lt;matthieud> PaulG:  Like kizu, in a listbox with item overflowed. Does the engine will give the correct number of items to the accesssiblity tree when some of them are inert ?<br>
&lt;matthieud> flackr: nice question. maybe inert is not the property we want to use then<br>
&lt;matthieud> PaulG: maybe inert is fine but not for this scenario. We need to clarify the exact use cases<br>
&lt;matthieud> flackr: we dont want to use this when user want to interact with this content<br>
&lt;TabAtkins> I'm feeling like this is indeed a "well don't do that" situation<br>
&lt;matthieud> flackr: it doesnt make sense to use this for overflowing tabs in a tab list for example<br>
&lt;matthieud> flackr: so maybe inert is not what we want<br>
&lt;astearns> ack ntim<br>
&lt;matthieud> ntim:  controlling inert from CSS was originally objected against<br>
&lt;matthieud> ntim: inert is not only about presentation but also about content<br>
&lt;matthieud> ntim: because it applies aria-hidden<br>
&lt;emilio> q<br>
&lt;matthieud> flackr: display already does stuff on aria tree even if it is a css property<br>
&lt;astearns> ack emilio<br>
&lt;matthieud> emilio: for firefox tab bar, we want tab hidden but still remain in the accessibility tree. So we dont really want inert<br>
&lt;matthieud> does this only apply to scroller ? or also to overflow-path or clip ?<br>
&lt;emilio> s/overflow-path/clip-path/<br>
&lt;matthieud> kizu: for clip it should not work<br>
&lt;matthieud> kizu:  for hidden not sure<br>
&lt;matthieud> flackr: for hidden many time people make it scrollable with other mechanism<br>
&lt;matthieud> emilio: we are not sure if we want actual inertness here<br>
&lt;matthieud> flackr: we can take it back to the issue<br>
&lt;matthieud> astearns: please comment on the issue<br>
</details>


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


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

Received on Wednesday, 21 August 2024 17:01:32 UTC