CSS 'display: none' causes problems for screenreaders

Mike, I'll put a post in the WebAIM forum to ask the same question. There we can get definitive answers from world-class experts on accessibility. In fact, you might want to join that forum so you can get quick answers to questions just like these.

Hi Cliff and Mike,

The issue is that using CSS 'display:none', will actually hide the content contained in the <div> that the declaration is attached to from the screen reader completely. The content is just not rendered to the screen at all and therefore not detectable by the screen reader. Use of 'display:hidden' will generate a content box but not the content. This is not always desireable however, As Gez points out in the Juicy Studio article, this hiding/not diplaying is not always entirely the case but it seemed to be a bug, if an background URL has been added to the a parent of the CSS declaration, sometimes the content will be picked up by the screen reader. Depending on what you wish to achieve, a solution may be to have the content displayed with in the source code but use a simple IR technique to move it off the screen. The kind of show/hide feature that is in vogue today, is sometimes more than just eye candy as it is useful for showing and hiding things that are only needed within different contexts.

Maybe a user defined preference for certain menu types would be good? I am not totally familiar with this issue as it relates to Drupal, it seems to relate to form elements embedded in a collapsible menu? Is this correct?

Anyway, the combination of both the 'display:none' and 'display:hidden' seems to be a workaround that sits well with the two most used screen readers, JAWS and Window eyes. You may find some useful pointers on this part of the Juicy Studio thread. [1]

Cheers

Josh

[1] http://juicystudio.com/article/screen-readers-display-none.php#comment3

Hi Mike, John and Kathy,

It's then just a question of going through each of the elements to determine if there is any they should be visible to screen readers. Sound good?

@Mike, looks fine to me.
@John, will using the .offscreen class essentially achieve the same thing?

Either way using these kind of offscreen methods is perfectly fine to keep vital content discoverable for screen reader users and hiding them from sighted users or for aesthetic reasons. As long as the underlying markup is semantically solid and available either on screen of off - all is well.

@Kathy,
Next question: I'm concerned with the edit node "collapsible fieldsets" in that we have content creators who are screen reader users and expert HTML editors. I've been asked to make the interface as simple as possible, but don't want to remove options permanently (comment, url, attachment, etc).

Would some kind of simple JS show/hide functionality work here? FWIW if the user could select the kind of interface elements that they needed in a preference section that would really help. It may also make your lives easier when trying to design an interface that properly serves the the broadest range of user needs. Some functionality and UI styles may suit one user group better than others. For example, using a drag and drop API is not great for non-visual users so a simple user preference section where a user can choose to globally remove any of this kind of functionality when they don't wish it would be great. As I say it may make your implementations easier.

Question: If the fieldset link is clicked even though the choices are there from the DOM and would be read, the page is refreshed and focus is lost. Are you talking about handling this with 'display: none;' on the 'html.js fieldset.collapsed *' or is this a case for ARIA?

Could this be done asynchronously? It may be possible to use scripting combined with wrapping the next desired object/element that you wish to user to have focus in a negative tabindex? I actually don't know if ARIA would help in this case. ARIA describes the role, states and properties of complex widgets and components of the interface. It may be a case that even with elements of the page using ARIA components, for the sake of backwards compatibility if nothing else, you may still need to use some tricks like the scripting/negative tabindex value for focus issues as currently there are a limited number of elements that a user agent such as a screen reader can actually focus on.

Gez Lemon has written extensively about this so you may find the following useful, though the first one will be more relevant.[1] [2]

Cheers

Josh

[1] http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
[2] http://juicystudio.com/article/wai-aria-live-regions.php

Two things always bug the heck out of people using assistive technology and, to at least that extent, interfere with accessibility:

• when an img tag has no alt attribute
• when an img tag has a useless alt attribute

Unfortunately, there are lots of borderline cases that introduce widespread disagreement regarding the definition of “useless.”

Whatever the solution, it would have to:

1. Ensure that <img src="source_url.ext" /> never happens.
2. Get the author to consider whether the best answer is <img src="source_url.ext" alt="" /> or <img src="source_url.ext" alt="brief explanation" />.
3. Perhaps link to a place where authors who need more information could get it.

But we will never ensure that all alt attributes satisfy everyone. In many cases, I'm not sure we could even satisfy a majority. For instance, in one forum I recently witnessed a week-long — um — discussion that focused on the issue of the appropriate treatment of a photo next to the name of the same person, much like the photos that appear as avatars on this page.

Roughly equal camps insisted that the alt attribute should be:

• alt="" (that is, empty)
• alt="[name]" , (that is, the name of that person, but nothing more)
• alt="photo of [name]"
• alt="[name] - photo as [format]" (for example, "Cliff - photo as jpg file")

Smaller groups insisted on other variants as well. (A very few even thought that the filename would be a useful alt attribute. Most strongly disagreed with that position, though.)

So what goes between the quotes after alt= is truly a judgment call. We just need to be sure that the software makes it possible to put something there. From that point, authors will have to think about it and do their best.

1) As written, it only works on block level elements. If you just want to hide a single link, or a form label (for example), then you'll have to add display: block; to the CSS, or else wrap your inline element in another block-level element and hide that.

actually, it only doesn't work on inline elements. it works on <p>, <li>, <h#> etc.

-

2) The technique doesn't affect any margins of the targeted element might have. So if you do use it on a block level element, you'll need to add margin: 0; as well, otherwise some space remains visible on screen.

This is partially true, dependant on how your theme is set-up, (and which browser you're using)
1) If you're using any kind of "reset CSS" it'll always work properly.
2) margins are mergable, and will also show this behavior here.
3) afaik, no element you might wish to hide has (bottom-/top-)padding by default.
therefor, the only time this problem possibly shows, is when a padding has been explicitly or when an element has a padding by default.

-

Also, placing it above the top or beyond the sides still suffers from some problems:

webAIM: http://webaim.org/techniques/css/invisiblecontent/

Placing the content above the viewport is preferable to placing it to the left or right of the viewport because both of these other directions cause display irregularities in some browsers.

Accessibility Tips: http://www.accessibilitytips.com/2008/03/04/positioning-content-offscreen/ (linked from WebAIM Forums)

Avoid offscreen using top
[...]
[...]if the content you are hiding is originally below the fold on the screen, when a focusable element in the off-screen styled content receives focus, the page scrolls right to the top of the document trying to bring this content into view. This jump in content creates confusion for keyboard users, and screen magnifier users.

What is just as bad is when the user tabs again, the page again jumps, this time downward to the next focusable element. [...]

-

this method doesn't touch width, thereby allowing this to adhere to it's context.

I don't understand what that means. In a screen reader, the context is based on HTML source order. CSS doesn't affect that. Does anyone know what he was referring to here?

meaning if you want to make it visible again, you don't have to worry about width, because it is not overridden.

That's a good link about keyboard focus scrolling the browser window when following tab order with absolutely positioned elements above the top of the viewport. I just tried it out, and it does screw up, exactly as advertised.

Regarding this:

Placing the content above the viewport is preferable to placing it to the left or right of the viewport because both of these other directions cause display irregularities in some browsers.

Archive.org's Wayback Machine has listings for WebAIM's invisible content page back to August 15th 2006, and that text has been there from the beginning. I'm inclined to wonder -- what display irregularities, exactly? Affecting which browsers? Is this still an issue? I think I'll try and get in touch with WebAIM and ask them.

After hearing about problems for accessibility with jQuery at the 2nd accessibility BoF at DrupalConDC I ran across the following page with a work around for the display:none problem we've been having with Drupal.

Seems like it works well enough simply to switch the default implementation so that jquery inserts display:none rather than removes it which seems to be better for screen readers. Would like to know how this works in the demo from someone who actually uses one.

Also interesting to know about the jQuery accessibility group.

Looks like this is a good place to find best practices within the jQuery community that we can implement in Drupal.

Mike

OpenConcept | CLF 2.0 | Podcasting