CODEWITHSUNDEEP
cssaccessibilityopacitywai-aria
Greg Perham
Greg Perham

Reputation: 1857

How does CSS opacity affect accessibility?

After browsing a number of Google and other SO articles, I've decided to ask my question plainly in hopes of a simple, direct answer.

To add one further step to the discussion on Does opacity:0 have exactly the same effect as visibility:hidden: I understand that display:none and visibility:hidden hide elements from screenreaders and the like, but what about opacity:0?

The table in one of the answers to the linked question notes that opacity participates in taborder, so does that necessarily mean it will be mapped to the accessibility API?

Setting a giant negative text-indent is typically offered as an alternative to display: none and visibility: hidden for dropdown menus, but I'd like to fade my menus in and out without JavaScript, while making sure I don't hide them from screen readers.

Upvotes: 27

Views: 10437

Answers (3)

angstyloop
angstyloop

Reputation: 327

How does CSS opacity affect accessibility?

It affects a11y in terms of contrast, too. WCAG2 wants a contrast ratio of at least 4.5.

To see why opacity can affects contrast, suppose you have a grey square - say (127, 127, 127) - on a black background - (0, 0, 0).

The contrast ratio of (0,0,0) and (127,127,127) is about 5.2.

If you perform alpha mixing of the foreground and background like this:

out[i] = (1-a)*bg[i] + a*fg[i]

you get the new RGB values (63,63,63).

But the contrast ratio of (63,63,63) and (0, 0, 0) is about 2.6, which is less than the required 4.5.

While the contrast ratio seems mysterious, it's actually just two esoteric definitions chained together. There are plenty of reference implementations for you to follow online, here is one picked totally randomly:

https://github.com/angstyloop/contrast-ratio

Upvotes: 0

scottohara
scottohara

Reputation: 765

While this is an older question, it was one of the first that surfaced in a Google search, so I wanted to chime in.

As of April 2017, the ChromeVox screen reader does not read content that is set to opacity 0.

Specifically, ChromeVox won't read text that has been visually hidden with opacity set to zero, unless the element is labeled by visually available text.

For example:

<!-- will not be read -->
<a href="#!" style="opacity: 0;">not read</a>

<!-- WILL be read -->
<a href="#!" style="opacity: 0.001;">is read</a>

<!-- span text will not be read -->
<a href="#!">
  Read More
  <span style="opacity: 0;">
    this will not be read
  </span>
</a>

<!-- 
  button text will not be read, 
  but aria-labelledby text will be read on button focus 
-->
<span id="test">button label</span>
<button type="button" aria-labelledby="test" style="opacity: 0;">
  This text will not be read
</button>

Upvotes: 13

FelipeAls
FelipeAls

Reputation: 22171

opacity: 0; won't hide content from screen readers, though it'll hide content from sighted users and partially sighted users.
It's like displaying a white text on a white background (or transparent, you get the idea).
It'll be mapped to the accessibility API, you should still see the pointer changing above links, edit: you can still select text /edit, and somebody should test to see if, when tabulating links and form elements, the default dotted outline will display as usual or will be transparent. Edit: the latter, just tested with Firebug on this page.

Upvotes: 3

Related Questions