- From: Sara Soueidan via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Apr 2025 18:12:16 +0000
- To: public-css-archive@w3.org
I opened this issue back in 2016 (wow!) and since then a lot has changed. I've been teaching accessibility for a little less than a decade now and if there's one thing I learned is that developers will resort to using `visually-hidden` utility to do things that are more often than not just bad design decisions. Yes, there are valid and important use cases. But I agree with all of @scottaohara 's points, and most importantly I agree that we need to fix the underlying issues instead of standardizing a technique that is _guaranteed_ to be overused and misused even more once it gets easier to use. Fixing underlying issues (such as translation issues with `aria-label`, for example) is far more important than standardizing a way to visually-hide labels. Naming form controls using `aria-label` is the standard, and resorting to `visually-hidden` in this case is a workaround for an issue that should be fixed so that using `aria-label` is no longer problematic. I am also reminded of [the ARIA Notifications proposal explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/AriaNotify/explainer.md) here. From the explainer: > Content authors still rely on live regions because that is the only tool available for the job. They do the best that they can, resorting to ugly "hacks", fragile coding patterns, and blatant misuse of ARIA live regions. There is a better way. I know `visually-hidden` is one of the workarounds used to create accessible screen reader-only notifications. But with the ARIA Notifications proposal, the visually-hidden hack will no longer be necessary. I imagine a similar path can be taken with other use cases of `visually-hidden` so that very few use cases remain—too few to warrant standardization. Furthermore, not all visually-hidden content is hidden equally—or _needs_ to be hidden equally. That is, not all visually-hidden content needs to be hidden using this long set of rules defined for the `visually-hidden` class. For example, interactive form controls can be hidden using a couple of lines of CSS. I have discussed this more in [an article on my blog](https://www.sarasoueidan.com/blog/inclusively-hiding-and-styling-checkboxes-and-radio-buttons/). Scott has also discussed this in more detail in [his article](https://www.scottohara.me/blog/2023/03/21/visually-hidden-hack.html) that's already been referenced in previous comments. Most of us who asked for this feature to be standardized are more experienced devs who know how and _when_ to use this utility class (and/or its alternative declarations). But once standardized, I can only imagine a whole new generation of developers who will resort to using this technique to hide things that shouldn't be hidden, either because they don't know enough about how hidden content affects assistive technology users and/or how different elements should be hidden, or simply because they work with very "stubborn" designers who make them do this because they otherwise. The teacher in me would rather teach developers and designers about usability and how to improve the underlying patterns. As an experienced dev, I do wish I had to write fewer lines of CSS to visually-hide what needs to be visually hidden. But this would come at a higher cost IMO. With all this said, I no longer encourage the creation of a CSS property/value for the `visually-hidden` utility class. -- GitHub Notification of comment by SaraSoueidan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/560#issuecomment-2810348644 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 April 2025 18:12:16 UTC