How does CSS opacity affect accessibility?

25
votes

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.

2
cssaccessibilityopacitywai-aria

2 Answers

12
votes

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>
3
votes

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.