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

+1 to @alice's post.

Some responses to @flackr's comment.

First regarding the 3 points raised:
1. Peaking UI remains a strong case for a _version_ of this feature. (emphasis added because I continue to believe there are use cases that need to be solved, but not at the expense of the larger concerns being raised)
2. I doubt the strength of this second use case. As I understand it you're talking about something like <a href="https://html.spec.whatwg.org/multipage/interaction.html#the-inert-attribute">this HTML inert example</a>.  Often the reason for needing such UI is because the underlying content is temporarily blocked, or is in a loading state. Revealing that content would often require a user action, or for content to finish loading, and the DOM be modified.  Using the HTML inert attribute would likely be the better call here since the DOM would have to be modified, if not entirely replaced, anyway. I'd be open to understanding this use case more, particularly if a compelling example could be provided to demonstrate why CSS would be the preferred option.  But right now, I struggle to imagine a scenario where doing this with CSS (but also likely still needing JS) would be better for the developer. 
3. For the last point, I have little doubt in saying CSS would be the _wrong_ choice, or if inert (css or html) is even needed or appropriate at all (e.g., background images which are already not in the a11y tree, or img elements which can already be set to presentational with an empty `alt`).  Just taking the linked 'matrix' example at face value, if that was used for decorative purposes, then using `aria-hidden=true` or `inert` attributes would be far more logical.  If it was meant to be conveyed as a demonstration, like it is on that page, then marking it up as a graphic (role=image w/ accName) would be the more appropriate choice.  If someone is going to add text to their interface/page that is meant to be incidental - then they should be using markup to make that so.  If they are using CSS to add the text, then there's already the alt text feature for CSS `content`. 



Next, regarding:
> 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 precede it, or those that follow it, to navigate the page.

I can follow this rational for the carousel use case - not wanting to have a user have access to content that is obscured/off screen.  That's where the idea of off-screen inert makes sense to me. But where this response lost me was specifically with "to navigate the page" - as this seems like it's opening up the use case for making visible focusable elements of the page inert, beyond the carousel use case.  
While I believe the mention of "`tabindex=-1` being a footgun" was in the context of simply using it and it alone to mark off-screen content as problematic (because yes, that content would still be available to people using screen readers) I've already had a couple of conversations with people who assumed `interactivity` could be used as a means to remove _any_ focusable element from the tab order.  And that's a problematic interpretation. `tabindex=-1` or the `disabled` attribute can often be far more appropriate for scenarios where content can still be seen, but may not presently be interactive, or at least not meant to be interactive via keyboard (as other ways to achieve the same function may be present). This is a far more nuanced topic though, and I want to avoid a tangent, so I'll leave this here for now...

The part that really stands out to me as needing stronger guardrails and understanding for appropriate use is this comment:
>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.

I think this speaks to @alice's point that some of the concerns being raised aren't being fully appreciated. For instance, this response doesn't acknowledge that CSS could be misused to make visible / unobscured content inert that _isn't interactive_.  An author could erroneously mark static content as inert and never realize the full impact of that - much in the way people have commonly misused `aria-hidden=true` and similarly unintentionally hid content that shouldn't have been marked hidden. In these cases, _only_ people using assistive technology are impacted, because those who can see can still read the content.  

For some more context, `aria-hidden=true` used to be a lot more powerful - completely removing content from the a11y tree with no recourse for the user to mitigate unless they knew how to manipulate markup. Over the years, browsers have had to chipped away at this 'power' due to the constant misuse.  As a result, the attribute is no longer allowed to be used or even function if specified on the `html` or `body` elements. If focus is found to enter an `aria-hidden` container, the browser might now undo the hidden state for all the content in that container... which wouldn't be possible with this feature to correct for author error.  I mention all of this because it's not clear to me what mitigation for author error a browser could reasonably do, or if this has even been a topic of discussion up to this point.  I would hate to see misuse that can't be corrected for - and for a feature like this to need to be whittled down to a safer version - scoped to specific use cases, but it can't be because it's been shipped and changing it could "break the web".


Finally, briefly touching on adam's comment:
>Being able to "un-inert" the interactivity is paramount so that the offscreen content (cards or whatever) is marked as not being interactive (this allows the keyboard to flyover a long list of interactive items), but the ::scroll-marker generated for it inherits the non-interactivity thus becoming a dot that can't be clicked or interacted with.

To me this seems more like something the browser should be able to do automatically - rather than leaving it up to the author to have to know to do this.  That really seems like an unnecessary requirement for authors, especially since the browser is already performing some magic in generating / slotting these markers, anyway... 

That's all I can muster for now.... there are far more points to raise - and even going back and forth on individual use cases isn't really acknowledging all the other use cases none of us have even thought to talk about yet.  There is potential to make something really useful here - at least for specific use cases where misuse can be prevented.  I just don't want to see this become the `aria-hidden` of CSS.  An incredibly powerful and well-meaning feature that has led to so many problems.

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


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

Received on Thursday, 3 April 2025 22:19:49 UTC