- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Apr 2025 19:01:47 +0000
- To: public-css-archive@w3.org
> > 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, at least not consistently. For instance, this particular response doesn't acknowledge that CSS could be misused to make visible / unobscured content inert that isn't interactive I apologize, I never meant to imply that it was not possible to misuse, and as you have noted I have myself written examples of how the ability to inert (in the forms we have it and in the forms we may introduce it) can be misused in a way that could go overlooked. In this statement, I was only contrasting it with properties which have absolutely no effect for non AT users. In particular, making content inert means that it cannot be interacted with, the text cannot be selected or found by find in page, and the content can never be the target of any input events, meaning that it is more likely a developer or users who are not specifically using AT will catch these misuses. I fully acknowledge that it is possible to misuse in a way that could be overlooked by typical user flows. In the interest of completeness, there are also many ways for developers to misuse css properties to hide content in ways that do not remove it from the AT tree resulting in confusing extra content (e.g. opacity: 0, transform: translateX(-100%) in a clipping container, etc). > (I'm copy-pasting this comment in a few places because this conversation has been so widely distributed. I apologise for the noise.) Is this the best place to carry on this conversation? If so, shall we point the other locations to this issue? I am happy to discuss and provide relevant context related to the many points you have raised in the hopes that it may further advance the conversation. > > 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... I completely agree, and we resolved on the fix for this in #11746 and have updated the chromium implementation accordingly. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2831201400 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 25 April 2025 19:01:48 UTC