[css-display] create a display property value for visually hiding an element while making it available for AT

[SaraSoueidan]

While giving a talk at CSSConf last week, I mentioned how we should provide text for AT to be able to read when we are using only icons to represent that text visually. Basically: provide text in the DOM that screen readers can read, and then hide it visually by using one of several visually-hidden techniques/hacks that we currently use for this purpose.

After the talk, an attendee asked why we don't have a CSS property whose sole purpose would be to hide content visually while keeping it readable by screen readers, for example.

We know display: none and visibility: hidden both hide content visually but they also make it inaccessible by AT. Any chance we could get a display value that would hide text similar to the way display: none does but that also keeps the text accessible underneath?

Thanks!

[AmeliaBR]

There isn't a CSS proposal, but there is an ARIA property, at least in theory. aria-hidden: false is supposed to expose content to assistive technology even if it would normally be considered hidden because of display: none or visibility: hidden or width/height of 0.

However, because browsers did not support aria-hidden: false consistently, accessibility best practice has developed to use a combination of properties (overflow/clip plus absolute positioning, and/or positioning off-screen) that none of the browsers use in their heuristics for deciding whether something is hidden or not.

That said, this is definitely something that should be discussed as part of the new CSS Accessibility project.

[dauwhe]

See also #427

[pepelsbey]

But isn’t there the box-suppress proposed property with show, discard, and hide values? Quoting Rachel Andrew’s explanation:

• show: the element would be visible and use whichever display method was used to display itself and any child elements.
• discard: the element would generate no boxes at all
• hide: the element and any children would still be present but would not participate in layout and would be completely hidden.

The hide value should solve this issue, just like we solve it today with visuallyhidden pattern today.

[thierryk]

I think we already have the "clip technique" for this. To me, the problem is not how we can visually hide content but rather how to deal with focusable elements inside boxes styled this way. Because sighted keyboard users access these elements without any context. They know they are on a focusable element on the page but they have no clue where and what it is (unless it's a link for which the href value may appear at the bottom of the browser).

[AmeliaBR]

The problem with keyboard users and hidden content, brought up by @thierryk, is actually a good argument for having an easy declarative way of hiding content. Too many devs copy & paste the "screen reader only" CSS without actually thinking about whether it should be screen reader only (a label for an icon or a heading for a sidebar) or whether it should be hide-until-focused (like a skip-to-content link).

A semantic, declarative method of hiding content would make it easier for browsers to override the hiding when content receives focus, or based on user settings (such as when images are turned off).

[noahblon]

I agree @AmeliaBR. We do have the wonderful clip technique. However, we are currently in limbo with clip, considering that it has been deprecated and Edge hasn't yet picked up support for clip-path. In my opinion this is reason alone to move away from "hacks" towards a standard method of dealing with a very common need.

In regards to focusable elements within visually hidden elements, my understanding of the Focus Visible Success Criterion of WCAG 2.0 says that an element must be visible when focused. When focused, and in this particular use case, such as for skip links, I would expect the browser to give the element a display, such as block or flex. If the developer needs to disable keyboards from focusing the elements, they should disable tabbing to the focusable elements.

[fantasai]

This feature already exists as speak in CSS Speech Level 1, fwiw. Just hasn't received much interest.

Possible ways forward:

• Trim down the Speech module to be just speak and possibly speak-as.
• Move this property to the Display module so more people notice it exists.

[ianthedev]

Maybe absolute positioning, like the following example, can serve the purpose.

.hidden-visually {
    position: absolute;
    left: -5000px;
}

[thierryk]

@Ian-Y this approach works for focusable elements (i.e. skip links) but it does not work on hidden elements that contain focusable elements.

[ianthedev]

@thierryk I see. Then @media not speech is also needed:

.hidden-visually {
    position: absolute;
    left: -5000px;
}

@media not speech {
    .hidden-visually {
        display: none;
    }
}

But in such a case, I would agree with @AmeliaBR that it is too many devs copy & paste for a "screen reader only" purpose. A simpler way would be preferable.

[caduvieira]

Why aria-hidden do not resolve this besides the lack of support? Does aria-hidden=true disable focus on focusable elements?

[4thel00z]

Doesn't this part of @Ian-Y proposal already does the job ?

@media not speech {
    .hidden-visually {
        display: none;
    }
}

[ianthedev]

I personally still hope to see a "CSS declaration" solution such as aria-hidden: true; because using media query can be inconvenient. For example, if I have a long media query for responsiveness like the following one (each CSS rule is being represented by ...... for the purpose of this example):

@media (max-width: 1024px) {
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
	......
}

And if I need to hide one of the CSS rules from assistive technologies and also want to preserve the order of those CSS rules, I would then have to break the original media query into three parts like this:

@media (max-width: 1024px) {
	......
	......
	......
	......
	......
	......
	......
}
@media not speech and (max-width: 1024px) {
	......
}
@media (max-width: 1024px) {
	......
	......
	......
	......
	......
	......
	......
}

And if I need to hide more non-adjacent CSS rules from assistive technologies, I would then have to break the original media query into more parts. So that is inconvenient sometimes.

[Malvoz]

@AmeliaBR

this is definitely something that should be discussed as part of the new CSS Accessibility project.

w3c/css-a11y#13

[nigelmegitt]

An additional use case for this feature is described at w3c/imsc#484 (comment) and further up that thread in more wordy fashion.

[css-meeting-bot]

The CSS Working Group just discussed create a display property value for visually hiding an element while making it available for AT.

The full IRC log of that discussion

<birtles> topic: create a display property value for visually hiding an element while making it available for AT
<birtles> github: https://github.com//issues/560
<birtles> nigel: this comes up a lot in subtitles and captions
<birtles> ... the desire to be able to make text available to the screenreader while not visually displaying it
<birtles> ... this is particularly important for subtitles because there is a video behind it which might be showing text, for example
<birtles> ... so we don't need a subtitle necessarily but we want to expose it to a screenreader
<birtles> ... there are hacks to do this
<birtles> ... perhaps a display property value
<birtles> fantasai: this exists in the speech module level 1
<birtles> ... property is speak
<birtles> ... initial is 'auto' which defers to display
<birtles> ... but not implemented it
<birtles> ... 'never' and 'always'
<birtles> AmeliaBR: display: none has so many other affects other than just hiding
<birtles> fantasai: we have a spec but no one is interested in implementing it
<birtles> nigel: the request is not to speak it
<birtles> ... it is to make it visible to the screenreader
<birtles> ... it might be presenting it in some other way
<birtles> AmeliaBR: braille display etc.
<birtles> Rossen__: you can use visibility: hidden
<birtles> ... and refer to it via aria-description etc.
<birtles> AmeliaBR: as the label of a different element
<birtles> nigel: if you're just labeling an element then the screenreader might just read that once
<birtles> ... but this is an element whose contents is live
<birtles> ... it needs to read it when it changes
<birtles> AmeliaBR: there are many demands this feature beyond the captioning use case
<birtles> ... I'm sure the accessibility people who come in after the break would be happy to talk about it
<birtles> nigel: perhaps we can cover it in that session
<birtles> github: end topic

[cookiecrook]

Leonie, Amelia, Brian K, and Ian P, are going to draft something.

[css-meeting-bot]

The CSS Working Group just discussed Display property value for visually hiding element while making available to assistive tech.

The full IRC log of that discussion

<fantasai> Topic: Display property value for visually hiding element while making available to assistive tech
<fantasai> astearns: brought up by TTML also
<jcraig> https://github.com//issues/3708
<fantasai> astearns: question is how to move forward on this capability
<heycam> github: https://github.com//issues/3708
<fantasai> AmeliaBR: The general use case is when you have text that adds a little extra information for assitive technology but either repeats something already visually on the page
<astearns> github: https://github.com//issues/560
<fantasai> AmeliaBR: or is text that is already obvious because of other visual cuse
<fantasai> s/cuse/cues/
<fantasai> AmeliaBR: so don't want to print the text, but want available to a11y
<fantasai> AmeliaBR: there are methods used by authors using absolute positioning or clip
<fantasai> AmeliaBR: intentionally picked by authors because not currently used as cues to screen readers to hide the text
<fantasai> AmeliaBR: so feature requests coming to ARIA and CSS
<fantasai> AmeliaBR: is to have a simple one property one attribute way to do this
<fantasai> AmeliaBR: there are ways in specs defined to do this
<jcraig> Example of what AmeliaBR is referencing: <p>Read <a href=“#”>more <span class=“a11y”>About widgets</span></a></p>
<fantasai> AmeliaBR: there's aria-hidden=false, originally specified to do this
<astearns> q?
<fantasai> AmeliaBR: there is the 'speak' property in CSS Speech module
<fantasai> https://www.w3.org/TR/css-speech/#speaking-props-speak
<jcraig> hidden=true aria-hidden=false
<fantasai> AmeliaBR: neither of these is implemented because in reality the visual display property has all sorts of side-effects in how elements are processed
<jcraig> aria-hidden=true was problematic for a variety of reasons
<fantasai> AmeliaBR: and saying 'display: none' or visually hidden but still available to AT
<fantasai> AmeliaBR: has never happened in borwsers
<jcraig> s/=true/=false/
<fantasai> AmeliaBR: so feature request is for specific way to do things
<fantasai> AmeliaBR: in ARIA yesterday had a talk about, is this really use case pattern we want to encourage by making it easier to do?
<fantasai> AmeliaBR: visually-hidden styles can be misused by developers
<fantasai> AmeliaBR: who are only thinking about visually-able vs. blind users
<fantasai> AmeliaBR: missing a huge swath of people usign both AT and visual rendering
<fantasai> AmeliaBR: so argument that this is a hacky approach for a reason, shouldn't make it easier
<fantasai> AmeliaBR: but it is widely-used on the Web anyway, so argument for paving that cowpath
<fantasai> AmeliaBR: my recommendation is to go ahead with this
<fantasai> AmeliaBR: and do it in CSS
<fantasai> AmeliaBR: because sometimes visually-hidden content depends on MQ
<jcraig> q+ to remind the group that many (most?) screen reader users are not completely blind...
<fantasai> AmeliaBR: e.g. button might have icon and text on big screen
<fantasai> AmeliaBR: but on small screen only the icon
<fantasai> AmeliaBR: but want AT to be able to see that text
<florian> q+
<astearns> ack jcraig
<Zakim> jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind...
<fantasai> jcraig: I think this is valuable and needed
<fantasai> jcraig: but remind group that most screen reader users are not blind
<fantasai> jcraig: there are a lot of low-vision users
<fantasai> jcraig: ~ 1/5 are actually blind
<nigel> q+ to point out that for text to describe media content the solution has to work in an ARIA live context
<astearns> ack florian
<fantasai> astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage
<tink> Q+
<fantasai> florian: the reason why neither ARIA attr or speak has been easy to implement
<fantasai> florian: is because AT works by reading plain text off the render tree
<fantasai> florian: this is the reality today
<fantasai> florian: can't ignore it
<fantasai> florian: but causes many problems
<fantasai> florian: exposing info to AT
<fantasai> florian: I hope this is merely current reality
<fantasai> florian: and not long-term goal we want to maintain
<fantasai> florian: because in that case many limitations
<fantasai> florian: there are many cases where we would want to work from DOM, not render tree
<fantasai> florian: because render tree has lost information that's in the DOM\
<fantasai> florian: I think we will see that problem in a number of use cases
<fantasai> florian: I would like us to not abandon idea that aria / display proposals
<astearns> ack nigel
<Zakim> nigel, you wanted to point out that for text to describe media content the solution has to work in an ARIA live context
<fantasai> florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved
<fantasai> nigel: Some of the proposed solutions/hacks might not work for ARIA live environment
<fantasai> nigel: for ? put forward this morning, want something that describes content in a video
<jcraig> q+ to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details
<fantasai> nigel: gets read out during playback of video
<fantasai> nigel: want to use ARIA live region approach
<fantasai> nigel: and have AT notice that
<jcraig> s/live environment/live regions/
<florian> s$that aria / display proposals$that aria / speak proposals$
<fantasai> nigel: biggest gap we have is something that, following from florian's point, here is some text from render tree
<fantasai> nigel: don't actually paint pixesl for it, leave layout alone
<fantasai> nigel: atm visibility: hidden has effect that some screen readers don't read it out
<fantasai> nigel: I would separate visibilty from display
<fantasai> nigel: I would expect display: none to never feature in a display
<fantasai> nigel: but visibilty is not rich enough
<florian> fantasai: visibility hidden currently leave things in the layout tree
<florian> fantasai: so they take up space
<ZoeBijl> q+ to say that there are more assistive technologies than screen readers
<florian> fantasai: we probably want variant that doesn't
<fantasai> jcraig: technique used is positionign off-screen and clipping
<fantasai> nigel: want something more proper
<florian> s/variant/a variant/
<fantasai> astearns: and more simple
<astearns> ack tink
<fantasai> tink: I'm really strongly in favor of this proposal
<fantasai> tink: than existing methods, which cause alls orts of problems
<fantasai> tink: can confirm that visibility: hidden does get hidden from screen readers
<fantasai> tink: if we go ahead with an idea like this attribute
<fantasai> tink: what will we do with tab focus?
<fantasai> tink: techniqe that jcraig describes
<fantasai> tink: tab focus disappears off screen
<fantasai> tink: some renderers will screw up rendering as a result
<fantasai> tink: would there be some mechanism to get around that problem?
<fantasai> AmeliaBR: that's a very good argument for a proper bult-in feature
<fantasai> AmeliaBR: then browser knows to override hiding and make things visible
<fantasai> AmeliaBR: with current techniques, up to author to have a special focus rule
<fantasai> AmeliaBR: to handle that case
<fantasai> AmeliaBR: strong argument to have dedicated feature so browser knows why this style is being set, and to override
<fantasai> tink: so if was focusable content hidden, once it got focus would become visible
<fantasai> tink: makes visible, but if contents appear from off-screen, that would be quite disruptive
<fantasai> tink: is there a possibility to do it the other way around, take things outside of focusability?
<fantasai> AmeliaBR: that wouldn't help with skip links
<fantasai> tink: screenreaders have much better ways to navigate content
<fantasai> tink: skip links are mainly useful for sighted suers
<fantasai> s/sighted suers/sighted keyboard users/
<fantasai> florian: would be problem to make things visible without author expecting it
<fantasai> florian: likely to break things
<jamesn> q+
<fantasai> florian: would rather make it not visible, invoke HTML inert behavior
<fantasai> florian: author can pop things into visual space if they want
<fantasai> AmeliaBR: or maybe two different values of a property, recognize different use cases
<fantasai> AmeliaBR: standard skip link that should become visible
<fantasai> AmeliaBR: and extra information for screen readers
<jcraig> q?
<jcraig> ack me
<Zakim> jcraig, you wanted to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details
<astearns> ack jcraig
<fantasai> jcraig: couple techniques mentioned, one seemed reasonable was HTML hidden=false
<fantasai> jcraig: aria-hidden=true
<fantasai> jcraig: or reverse of that rather
<nigel> q+ to reply
<fantasai> jcraig: webkit was the only browser to implement
<fantasai> jcraig: was very tricky, because webkit builds accessibiltiy tree off of render tree
<fantasai> jcraig: this was after fork from blink, so blink doesn't have
<fantasai> jcraig: firefox same thing
<fantasai> jcraig: so very challenging
<fantasai> jcraig: after noticing bugs
<fantasai> jcraig: decided to only allow this if every ancestor above was displayed
<fantasai> jcraig: so child node could be hidden, but not descendant
<fantasai> jcraig: not sure that's the right path, but is the one available atm
<fantasai> jcraig: technique in the ARIA spec, aria-hidden=false not recommended
<astearns> ack nigel
<Zakim> nigel, you wanted to reply
<fantasai> jcraig: hidden=true aria-hidden=false
<fantasai> nigel: interaction between attributes and CSS properties not clear in spec, and varies in implementations
<fantasai> nigel: there some weird stuff going on there
<fantasai> nigel: my conclusion was to ignore HTML hidden
<fantasai> jcraig: on WebKit side, implementation was hidden=true { display: none; }
<fantasai> Rossen__: Edge actually supports everything you said about computing aria and various permutations
<fantasai> Rossen__: there is an effort that was in EdgeHTML
<fantasai> Rossen__: have ongoing work in Chromium to add additional capabilities to handle that n Chromium-based browsers
<fantasai> Rossen__: not sure where Mozilla is
<fantasai> jcraig: no plans last I heard
<astearns> ack ZoeBijl
<Zakim> ZoeBijl, you wanted to say that there are more assistive technologies than screen readers
<fantasai> ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff
<astearns> ack jamesn
<fantasai> ?: displaying something ...
<fantasai> ?: Issue of deliberately making things visible
<astearns> s/?/jamesn/
<fantasai> jamesn: another use case is when you have native HTML control that you do not want to display but you want to use all of the properties that you get for free
<fantasai> jamesn: e.g. range control, can't increment/decrement unless native
<fantasai> jamesn: but can't sytle it properly
<fantasai> jamesn: so hide it, and display your own control over it
<fantasai> jamesn: common authoring technique right now, because can't make controls accessible on moble
<fantasai> jamesn: is one custom control for visual, and one hiden native control for interaction
<fantasai> jamesn: hidden using very low opacity so stll there
<fantasai> jamesn: you wnat it to not be inert in this case
<nigel> scribe: nigel
<nigel> fantasai: we've heard a lot of new info in this meeting
<florian> fantasai: we've heard a lot of new information
<nigel> .. next step is someone to draft a proposal for a new CSS property or value
<nigel> .. probably a property
<jcraig> display value?
<nigel> .. that takes into account the use cases here and the various limitations
<nigel> .. I haven't heard a proposal yet.
<fantasai> astearns: https://github.com//issues/560
<nigel> astearns: Is there a specific CSS spec for this?
<nigel> s/spec/issue
<nigel> fantasai: We definitely don't want to use the display property for this.
<nigel> .. too many other effects.
<nigel> .. There is an existing property in the speech module called speak
<jcraig> q+
<nigel> .. which was intended for this use case but it doesn't address the issues of the render tree and focusability
<nigel> jcraig: I've evidence that it was never intended to address this
<nigel> .. it's well specced for DAISY
<fantasai> jcraig: css-speech is very well-specced for DAISY use case, not for screenreader
<nigel> scribe: fantasai
<astearns> ack jcraig
<jcraig> ack me
<fantasai> astearns: need a volunteer
<fantasai> astearns: lacking a volunteer, keep the issue open and periodically ping people
<fantasai> tink: can try to put words together but need someone on CSS side
<fantasai> AmeliaBR: I can help
<fantasai> ACTION: Amelia and tink to draft a proposal
<trackbot> Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24].
<IanPouncey> I can also help.
<fantasai> astearns: and bkardell_

[JesusTheHun]

This is stale for a while now, but I want to build upon what has been said.
In my case I'm building a Pills input field. Like your email client Send to field.

Selected items are visible
To add an item you use a combobox and select the desired item.
To remove an item you click on the pill.

Selected items are not included in the combobox/listbox, that would make them appear twice.

For someone visually impaired whom have to use screen reader it is to change the selected items using this component. You have two navigation trees, one for selected items, one for available items. So I would like to make the selected items non-focusable and the listbox include the selected items, but only for screen readers.

<ul role="listbox">
  <li role="option">Option 1</li>
  <li role="option" aria-selected="true">Option 2</li> <!-- This should be not focusable/selectable by a non-screen-reader -->
</ul>

This goes further than just visibility ; current visibility hacks such as sr-only won't do the trick, the element will still be focusable and when using keyboard navigation we would meet a "dead" position.

[josepharhar]

Multiple speakers at CSS day mentioned this lacking capability. I skimmed the meeting notes in this thread and it sounds like setting aria-hidden=false on a display:none element is the closest thing we have...? Is that what we should recommend? Or a new css property/value or a new HTML attribute/value?

@scottaohara @cookiecrook @frivoal

[josepharhar]

I also saw an article with opinions here: https://benmyers.dev/blog/native-visually-hidden/

[scottaohara]

@josepharhar re: aria-hidden=false on a display:none element - that's off the table. The ARIA spec actually has a pending update to specifically note that aria-hidden=false needs to be treated the same as aria-hidden=undefined / e.g., as if the attribute wasn't even there, as there are many instances of where authors misused the false value and making that re-reveal hidden content to the accessibility tree would actually break intended experiences.

As a counter point to the article you found - https://www.scottohara.me/blog/2023/03/21/visually-hidden-hack.html

[scottaohara]

and by pending update, i mean it's landed in the latest ARIA 1.3 draft:

Note
As of ARIA 1.3, aria-hidden="false" is now synonymous with aria-hidden="undefined".
Note

Note
The original intent for aria-hidden="false" was to allow user agents to expose content that was otherwise hidden from the accessibility tree. However, due to ambiguity in the specification and inconsistent browser support for the false value, the original intent is no longer supported.

[SaraSoueidan]

Seeing this thread being revived a few years later, I have an additional comment on my own "wish".

As a developer who kind of know what she's doing when she uses the .visually-hidden utility class, I appreciate having a native alternative. Sure. And I know other accessibility practitioners who would also appreciate not having to use a utility class so often.

BUT as a teacher, I can't but understand and kinda agree with @scottaohara 's points.

Unfortunately, I think that by standardizing the utility class into a property, it would encourage more devs to misuse it and end up with more broken experiences.

The utility class is already being misused sometimes, and we already have a lot of work to do to teach (and learn) about all the nuances. It will be a lot harder to do when this is standardized.

[josepharhar]

Thanks Scott and Sara! It sounds like we should not add a CSS capability like .visually-hidden and perhaps should instead focus on the items in Scott's blog post:

We should be able to navigate to landmarks (e.g., skip to main content) by default browser commands.
We should be able to send dynamic messages to assistive technology, without having to rely on fragile, invisible, live regions.
We should be able to use aria-label (and also aria-description) without having to worry about translation services.
We should be able to fully and easily style common form controls.
And we shouldn’t need to introduce a native way to do all these things, which covers various use cases for visually hidden content, but not all of them.

[alkorlos]

Read this thread and @scottaohara's article https://www.scottohara.me/blog/2023/03/21/visually-hidden-hack.html.

I agree with most of the points — it's better to fix specific issues rather than adding a hack to the specification.

However, there are cases where visually-hidden is used today and aren't fix in future specifications. For example, headings that don't fit into the design are often visually hidden, and the same goes for form elements without a label. The developer doesn't have the final say on how the product will look, so if the designer or client decide that a section shouldn't have a heading or a form element shouldn't have a label, they are implemented using visually-hidden.

What solution do you see as better than the standard display: visually-hidden for addressing designs without headings or form elements without labels?

[pepelsbey]

the same goes for form elements without a label

That’s a good example: when I try to solve this case with aria-label, accessibility experts usually say “it’s better to use visually hidden pattern” (not always auto-translatable, easy to miss in development, etc.) But this pattern is a hack on top of the missing feature that I’d rather use instead.

[scottaohara]

form controls w/out a label sounds like an aria-label use case. so nothing really to discuss there. (re: mention of translation issue as to why people advocate the hack - fix the issue, don't enshrine the hack).

headings that don't exist in the design sounds like a use case for standardizing a feature to mitigating poor design - and that seems wrong to me.

Or, the heading isn't actually necessary and properly labeling landmark containers might be the right solution - if the UI somehow makes it clear the purpose of the section of the content. hard to tell exactly we're both imagining the same scenario - but having come across many scenarios that seem like they'd fit this - that's my take at least until given more information to determine otherwise.

again, standardizing what might work for visually hiding a heading (the standard ruleset that essentially creates an invisible 1x1px container) would be rubbish to use on a visually hidden control that may or may not need to remain visually hidden when focused (button, checkbox, etc.) for the reasons i've already written about.

since there are a variety of ways one should/could be visually hiding content, i continue to fail to see a way this can get standardized that doesn't require it essentially boil down to only handling the position absolute, opacity 0 aspects of the classic ruleset...

or, if something does get standardized that handles more than that, then a bunch of usage caveats need to be introduced, and then people will complain the thing they need to do isn't a single property for them to declare.

i still question why some instances of the big visually hidden ruleset can't just be written as the following (so long as people don't need to handle legacy browser support - which, any new standardized property wouldn't be useful for anyway...so...)

.example:not(:focus) {   /* remove :not(:focus) if needed */
	scale: 0;
	position: absolute;
}

other instances of needing to visually hide something but still having it discoverable if searching by touch, or screen readers that announce what's being hovered, then something like the below would be more appropriate.

.example2 {   
	opacity: 0;
	position: absolute;
  /* it would not always be appropriate - if at all - to show on hover/focus.  e.g., visually hidden controls
      replaced by more robust design controls would not be expected to unhide.  but other controls that
      are meant to be hidden by default but overlay other content would become full opacity on hover/focus.
}

[travisvalerius]

I originally came here to propose display: visually-hidden, and I’m disheartened to see that this idea has been discussed for nearly nine years without significant traction. While there are workarounds to achieve this effect, if we truly prioritize accessibility, there should be a dedicated property/value for this purpose.

	Hidden from A11y Tree	Visible to A11y Tree
Occupies Space	visibility: hidden;	opacity: 0
Collapses Space	display: none	display: visually-hidden (ideally)

Having a standardized way to visually hide content while keeping it available to assistive technologies would reduce reliance on custom CSS utility classes and improve accessibility consistency across the web.

[SaraSoueidan]

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 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. Scott has also discussed this in more detail in his article 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 want things done a certain way regardless of how it affects implementation and/or usability. 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.