Discussion:
CSS property for visually hiding an element
(too old to reply)
Oliver Joseph Ash
2017-04-03 14:21:05 UTC
Permalink
Raw Message
It is quite common for web developers to require an element to be hidden
but only visually—that is, still accessible to screen readers and keyboard
users, but not visible on the screen.

If you search for "visually hidden element CSS", you will find lots of
hacks to solve this problem. Most famously, perhaps, is the
"visuallyhidden" class that comes with the HTML5 boilerplate project:
https://github.com/h5bp/html5-boilerplate/blob/9d6176a26ca4b70ab64a51d7abb9d3ebaa197855/dist/css/main.css#L135

Could we add something to CSS to support this requirement, so authors don't
have to resort to these crazy hacks?

I fear many authors currently resort to using `display: none` instead,
which hides an element both visually and semantically. This is not good for
accessibility.
Philip Taylor
2017-04-03 14:56:49 UTC
Permalink
Raw Message
Post by Oliver Joseph Ash
It is quite common for web developers to require an element to be
hidden but only visually—that is, still accessible to screen readers
and keyboard users, but not visible on the screen.
If you search for "visually hidden element CSS", you will find lots of
hacks to solve this problem. Most famously, perhaps, is the
https://github.com/h5bp/html5-boilerplate/blob/9d6176a26ca4b70ab64a51d7abb9d3ebaa197855/dist/css/main.css#L135
Could we add something to CSS to support this requirement, so authors
don't have to resort to these crazy hacks?
I fear many authors currently resort to using `display: none` instead,
which hides an element both visually and semantically. This is not
good for accessibility.
I am almost certainly missing something obvious, but what is the reason
that "visibility: hidden" does not suffice ?
Philip Taylor
Brian Kardell
2017-04-03 15:21:26 UTC
Permalink
Raw Message
Post by Philip Taylor
I am almost certainly missing something obvious, but what is the reason
that "visibility: hidden" does not suffice ?
Philip Taylor
visibility: hidden also hides it from the accessibility tree. Undoing that
now would almost certainly cause more harm than good - as far as I can see,
it would require a new property.
--
Brian Kardell :: @briankardell
Oliver Joseph Ash
2017-04-03 15:25:27 UTC
Permalink
Raw Message
Also, `visibility: hidden` doesn't completely hide the element visually—the
element is still positioned in the layout.
Post by Philip Taylor
I am almost certainly missing something obvious, but what is the reason
that "visibility: hidden" does not suffice ?
Philip Taylor
visibility: hidden also hides it from the accessibility tree. Undoing that
now would almost certainly cause more harm than good - as far as I can see,
it would require a new property.
--
Philip Taylor
2017-04-03 15:32:10 UTC
Permalink
Raw Message
Thank you both; as I suspected, I was indeed missing something (plural)
obvious.
Philip Taylor
Una Kravets
2017-04-03 16:32:58 UTC
Permalink
Raw Message
visibility: hidden also hides it from the accessibility tree. Undoing that now would almost certainly cause more harm than good - as far as I can see, it would require a new property.
I think a display property is what you’re thinking of (akin to `display: none`, but `display: screen-reader-only`)
Nicolás J. Engler
2017-04-03 16:44:49 UTC
Permalink
Raw Message
Following something along the lines of `display: contents` can be a good start.
- https://developer.mozilla.org/en-US/docs/Web/CSS/display
- https://rachelandrew.co.uk/archives/2016/01/29/vanishing-boxes-with-display-contents/

De: Una Kravets
Enviado: lunes, 3 de abril de 2017 13:36
Para: Oliver Joseph Ash
CC: Brian Kardell; Philip Taylor; www-***@w3.org
Asunto: Re: CSS property for visually hiding an element



visibility: hidden also hides it from the accessibility tree. Undoing that now would almost certainly cause more harm than good - as far as I can see, it would require a new property.


I think a display property is what you’re thinking of (akin to `display: none`, but `display: screen-reader-only`)
Karl Brown
2017-04-03 15:16:27 UTC
Permalink
Raw Message
`visibility: hidden` still affects layout, whereas the method commonly used
that Oliver posted completely "visibly" hides the element/text from sighted
users. It's closer to making it *invisible to sighted users* than it is to
making it *hidden.*

The method Oliver mentioned is one of the first things I add to any project
I get my hands on, but it is long winded. "visibility: invisible" or
visibly-hidden might get wider acceptance from authors by being a single
line.

The only thing I'm wondering is for use cases where something's visibly
hidden and an aria state changes when the content becomes visible, such as
some sites showing "Skip to content" when the user gives it focus. Would
this method potentially make authors believe they didn't need to facilitate
a state change?
Post by Philip Taylor
Post by Oliver Joseph Ash
It is quite common for web developers to require an element to be hidden
but only visually—that is, still accessible to screen readers and keyboard
users, but not visible on the screen.
If you search for "visually hidden element CSS", you will find lots of
hacks to solve this problem. Most famously, perhaps, is the
https://github.com/h5bp/html5-boilerplate/blob/9d6176a26ca4b
70ab64a51d7abb9d3ebaa197855/dist/css/main.css#L135
Could we add something to CSS to support this requirement, so authors
don't have to resort to these crazy hacks?
I fear many authors currently resort to using `display: none` instead,
which hides an element both visually and semantically. This is not good for
accessibility.
I am almost certainly missing something obvious, but what is the reason
that "visibility: hidden" does not suffice ?
Philip Taylor
--
Karl Brown
Twitter: @kbdevelops
Skype: kbdevelopment

Professional Certificate Web Accessibility Compliance (Distinction),
University of South Australia, 2015
Post by Philip Taylor
Post by Oliver Joseph Ash
It is quite common for web developers to require an element to be hidden
but only visually—that is, still accessible to screen readers and keyboard
users, but not visible on the screen.
If you search for "visually hidden element CSS", you will find lots of
hacks to solve this problem. Most famously, perhaps, is the
https://github.com/h5bp/html5-boilerplate/blob/9d6176a26ca4b
70ab64a51d7abb9d3ebaa197855/dist/css/main.css#L135
Could we add something to CSS to support this requirement, so authors
don't have to resort to these crazy hacks?
I fear many authors currently resort to using `display: none` instead,
which hides an element both visually and semantically. This is not good for
accessibility.
I am almost certainly missing something obvious, but what is the reason
that "visibility: hidden" does not suffice ?
Philip Taylor
--
Karl Brown
Twitter: @kbdevelops
Skype: kbdevelopment

Professional Certificate Web Accessibility Compliance (Distinction),
University of South Australia, 2015
David Woolley
2017-04-04 09:33:32 UTC
Permalink
Raw Message
Post by Oliver Joseph Ash
It is quite common for web developers to require an element to be hidden
but only visually—that is, still accessible to screen readers and
keyboard users, but not visible on the screen.
In principle, hiding visually, but not from a screen reader would be
done by:

@media screen {
display: none;
}

However, I suspect that screen readers try too hard to approximate the
visual web page experience, that they will ignore hints aimed at them in
this way, simply because they are too rarely used to justify the
development effort.
François REMY
2017-04-04 17:17:07 UTC
Permalink
Raw Message
Aural stylesheets are not used for screen readers, and screen still applies.

As the name implies, a screen reader reads the screen.




-----Original Message-----
From: Patrick Dark [mailto:www-***@patrick.dark.name]
Sent: Tuesday, 4 April, 2017 04:23
To: David Woolley <***@david-woolley.me.uk>; Oliver Joseph Ash <***@gmail.com>
Cc: www-***@w3.org
Subject: Re: CSS property for visually hiding an element
Post by David Woolley
Post by Oliver Joseph Ash
It is quite common for web developers to require an element to be
hidden but only visually—that is, still accessible to screen readers
and keyboard users, but not visible on the screen.
In principle, hiding visually, but not from a screen reader would be
@media screen {
display: none;
}
However, I suspect that screen readers try too hard to approximate the
visual web page experience, that they will ignore hints aimed at them
in this way, simply because they are too rarely used to justify the
development effort.
One could also do the inverse:

@media aural {
display: revert;
}

If screen readers can't figure that out, they
François REMY
2017-04-05 21:07:20 UTC
Permalink
Raw Message
Post by François REMY
Aural stylesheets are not used for screen readers, and screen still applies.
As the name implies, a screen reader reads the screen.
That isn't the implication I get out of CSS2.2¹ and CSS1 Speech²
There isn't any browser that supports css-speech, nor the aural/speech media types. To support css-speech, a browser would have to come with its own built-in screen reader, which isn't at all what blind people desire at this point.

This specification is highly inspirational and to be honest only practical for ePub audiobooks (and maybe some cortana/echo/in-car scenarios). All mentions of blind people in these specs are inspirational but do not correspond to any reality faced by blind people when browsing the web. What blind people need is very different from what a sighted person in a car or listening to an amazon echo would need, and those use cases cannot be easily reconciled.

A screen reader cannot "get" an aural stylesheet because it does not get to deal with css at all. Can you imagine the hell it would be for screen readers if they had to implement custom logic for every application framework in a different way, especially when those frameworks can be contained in each other (a flash applet in an html page displayed in a xaml browser chrome)? It is just not practical.

Screen readers for the most part rely on a standardized model which all application frameworks in an operating system have to implement (and which is partially interfaced on the web through aria and built-in html semantics). This ui-automation model isn't sound-based in any operating system; in all honestly that is not a problem blind people even feel the need to solve right now.

Given aural stylesheets are about converting a document to a sound+markers space, they are therefore totally inapplicable to sc
Oliver Joseph Ash
2017-05-03 09:49:32 UTC
Permalink
Raw Message
The consensus seems to be that this is a sensible idea. How do I push this
forward? I'm happy to champion it, but I don't know where to start.
Post by François REMY
Post by François REMY
Aural stylesheets are not used for screen readers, and screen still
applies.
Post by François REMY
As the name implies, a screen reader reads the screen.
That isn't the implication I get out of CSS2.2¹ and CSS1 Speech²
There isn't any browser that supports css-speech, nor the aural/speech
media types. To support css-speech, a browser would have to come with its
own built-in screen reader, which isn't at all what blind people desire at
this point.
This specification is highly inspirational and to be honest only practical
for ePub audiobooks (and maybe some cortana/echo/in-car scenarios). All
mentions of blind people in these specs are inspirational but do not
correspond to any reality faced by blind people when browsing the web. What
blind people need is very different from what a sighted person in a car or
listening to an amazon echo would need, and those use cases cannot be
easily reconciled.
A screen reader cannot "get" an aural stylesheet because it does not get
to deal with css at all. Can you imagine the hell it would be for screen
readers if they had to implement custom logic for every application
framework in a different way, especially when those frameworks can be
contained in each other (a flash applet in an html page displayed in a xaml
browser chrome)? It is just not practical.
Screen readers for the most part rely on a standardized model which all
application frameworks in an operating system have to implement (and which
is partially interfaced on the web through aria and built-in html
semantics). This ui-automation model isn't sound-based in any operating
system; in all honestly that is not a problem blind people even feel the
need to solve right now.
Given aural stylesheets are about converting a document to a sound+markers
space, they are therefore totally inapplicable to screen readers.
Brian Kardell
2017-05-03 15:32:27 UTC
Permalink
Raw Message
Post by Oliver Joseph Ash
The consensus seems to be that this is a sensible idea. How do I push this
forward? I'm happy to champion it, but I don't know where to start.
While this sounds like something totally for CSSWG, I think there is an
argument to incubate this idea in the broader community... Here's why: Do
the use cases actually argue for a CSS property or an HTML attribute, maybe
just with a default UA style with gross specificity or something? I'm not
sure really. other but generally the practice of toggling a class seem to
be more or less "how we've done it" and making it a property kind of seems
to change the equation - it seems like a 'simple' way to achieve the same,
but I'm not sure it follows that it is actually paving the cowpath. Have
any preprocessors added a thing like this to shorthand it as a property,
for example? That would be interesting to know.
--
Brian Kardell :: @briankardell
fantasai
2017-05-27 01:51:40 UTC
Permalink
Raw Message
Post by Brian Kardell
Post by Oliver Joseph Ash
The consensus seems to be that this is a sensible idea.
How do I push this forward? I'm happy to champion it,
but I don't know where to start.
While this sounds like something totally for CSSWG, I think
there is an argument to incubate this idea in the broader
community... Here's why: Do the use cases actually argue
for a CSS property or an HTML attribute, maybe just with a
default UA style with gross specificity or something? I'm
not sure really. other but generally the practice of
toggling a class seem to be more or less "how we've done
it" and making it a property kind of seems to change the
equation - it seems like a 'simple' way to achieve the same,
but I'm not sure it follows that it is actually paving the
cowpath. Have any preprocessors added a thing like this to
shorthand it as a property, for example? That would be
interesting to know.
Even if this ends up with a markup switch as well, it would
still need to be implemented through a CSS mechanism. Current
hacks shove things off screen: they're why the Web platform is
unable to scroll to the top/left of the canvas origin.

The current proposal is, I think, to use the 'speak' property
for this. Doing something else would require an alternate
proposal and justifications for the difference.

Use cases would be helpful in any case. For example, there's
been a proposal to split 'display' into two longhands: one
for the box type, another for "display or not"; use cases
would help us understand how this feature needs to interact
with that proposal and/or the 'speak' property.

Further discussion is at https://github.com/w3c/csswg-drafts/issues/560 fwiw.

~fantasai

Loading...