New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
SaraSoueidan opened this Issue Oct 1, 2016 · 14 comments

Comments

Projects
None yet
@SaraSoueidan
Copy link

SaraSoueidan commented Oct 1, 2016

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

This comment has been minimized.

Copy link

AmeliaBR commented Oct 1, 2016

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

This comment has been minimized.

Copy link
Contributor

dauwhe commented Oct 1, 2016

See also #427

@dauwhe dauwhe added the css-display-3 label Oct 1, 2016

@pepelsbey

This comment has been minimized.

Copy link

pepelsbey commented Oct 2, 2016

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

This comment has been minimized.

Copy link
Contributor

thierryk commented Oct 2, 2016

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

This comment has been minimized.

Copy link

AmeliaBR commented Oct 2, 2016

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

This comment has been minimized.

Copy link

noahblon commented Oct 11, 2016

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 comment has been minimized.

Copy link
Contributor

fantasai commented Jan 3, 2017

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.

@fantasai fantasai added the Agenda+ label Jan 24, 2017

@Ian-Y

This comment has been minimized.

Copy link

Ian-Y commented Feb 1, 2017

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

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

This comment has been minimized.

Copy link
Contributor

thierryk commented Feb 1, 2017

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

@Ian-Y

This comment has been minimized.

Copy link

Ian-Y commented Feb 1, 2017

@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

This comment has been minimized.

Copy link

caduvieira commented Feb 7, 2017

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

@astearns astearns removed the Agenda+ label Feb 15, 2017

@4thel00z

This comment has been minimized.

Copy link

4thel00z commented Jun 8, 2017

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

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

This comment has been minimized.

Copy link

Ian-Y commented Jun 8, 2017

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

This comment has been minimized.

Copy link

Malvoz commented May 15, 2018

@AmeliaBR

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

w3c/css-a11y#13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment