Categories
code css

We Don’t Need A Native .visually-hidden

Some web professionals say that The Web Needs a Native .visually-hidden. I respectfully disagree, particularly as a matter of priority.

A visually-hidden CSS class, as it’s often named, is used to visually hide textual content from sighted users but expose it to screen reader users. This is a common practice in web development, too common in my opinion. Another name for the class you’ll come across is “sr-only” (which I believe stemmed from Bootstrap but was modified in version 5). The properties of the class are complex and implemented in different ways.

So technically, this may be true—a native HTML attribute for the same functionality would be somewhat useful. But it’s not anywhere near the importance of other, more foundational needs. My point is that, in the big picture, a native visually-hidden should be much, much lower on the priority list. So low that it’s a bit discouraging to hear folks requesting it.

What the web really, greatly needs is the following:

  • Web developers who practice semantic HTML.
  • Designers who don’t want to customize every single UI element.
  • VPs who prioritize usability and accessibility.
  • Designers and VPs who prioritize usability and accessibility over the latest visual design trends (which most of the time cause accessibility problems).
  • A lot less adverts, pop-ups, notifications, and other UI shyte.

These fundamental needs will go tremendously further for usability and accessibility than any HTML attribute, ARIA attribute, automated testing tool, Figma plugin, etc.

Also, as web professionals, we don’t want to encourage the use of visually hidden text but discourage the use — in favor of universal design, creating the same design and experience for all users. This will also save a lot of time and hassle during the SDLC.

Further reading:

10 replies on “We Don’t Need A Native .visually-hidden”

The question of priority is irrelevant. Just because X is more important than Y, doesn’t have any effect on the objective importance of Y (or X).

The second point is, in my view, extremely naive. If visually-hidden text is to be discouraged then, by that reasoning, so is all ARIA. The whole point (of both) is that universal access requires case-by-case accommodation because the playing field can never be level.

I don’t get it…

Just because we need designs and developers who care more about accessibility, it’s “discouraging” that someone who DOES care about accessibility has asked for a native property that would make it easier to do a common and useful-in-certain-contexts accessibility thing?

What’s the actual point here?

The point is that the digital industry puts far too much effort into relatively minor accessibility improvements. We’re going in circles and will never make enough positive impact. To make substantial improvements, we need to focus and improve upon much larger and wider issues, such as the ones listed.

Are you saying that the people who work on HTML should put down their editors and instead spend their time, for example, trying to convince Corporate VP’s to prioritize usability and accessibility?

In what was is it “far too much effort” to standardize a widely used approach that is, frankly, a collection of hacks that’s prone to mistakes?

Why wouldn’t it be better—for both devs and users—to have a native way to do a perfectly-valid-in-certain-situations technique?

And, honestly, why not both? You can say, “Hey, having a native way to do this would make life a lot easier” AND “we should use semantic HTML, prioritize, a11y, etc.”

These are not mutually exclusive concepts.

Totally agreed. This seemed odd to me when it was first suggested. We don’t need everything to be native. Slap a bit of code in your CSS and get on with it.

I agree this post. unfortunately we still have to use a ‘sr-only’ class on specific conditions yet. But i think ‘sr-only’ and WAI-ARIA are the last resort. ‘sr-only’ doesn’t solve the origin of accessibility issues.

Semantic elements for web were poor and it’s not enough yet. But, many native semantic tags have been added on HTML5. So I don’t suggest ‘sr-only’ class when counseling with our partners. We suggest to use native tags first. If alternatives are not in native tags, we suggest to use a WAI-ARIA them.

I’m avoiding to use ‘sr-only’ class becuase of mobile devices. Many modern websites are being made with a variety of devices in mind using Media Queries. Mobile ‘sr-only’ text is too bad for screen navigating of mobile screen readers.

‘sr-only’ class distorts a touch target size of widget elements. and it make users can’t use a drag-touch to navigate screen.

In some korea website, I experienced the worst sample. All texts is graphics with empty alt attribute. They tried to make screen reader users can read them. They provided a hidden text under image but, it was ‘sr-only’ texts. beginner had to navigate them by the “Swipe one finger right or left” gesture.

‘sr-only’is a double-edged sword and WAI-ARIA is also. I won’t suggest to use a ‘sr-only’ class to my partners for compatibility with touch screen.

Leave a Reply

Your email address will not be published. Required fields are marked *