Screenreader Visibility

From CSS Discuss

Jump to: navigation, search



When you hide material from visual display on a PC screen, you almost always hide it from screen readers too. See also Speech Stylesheets . Test results from testing in 2003 are shown further down in this article. More recent test results, from June 2005, are available on Bob Easton's .


As we move from tag soup to CSS governed design, we throw out the layout tables and we throw out the spacer images. Great! It feels wonderful to do that kind of house cleaning. So, what do we do with those "skip navigation" links that used to be attached to the invisible spacer images? A few famous web designers have begun using regular text links for skip navigation and then hiding them from visual display with CSS display:none.

This technique has a certain appeal. If it would work as we hope, accessibility links can be made to be heard but not seen. We could even add more expanded information targeted directly to people using assistive technology. Further, we could place that information in elements, like headings or lists, that have strong semantic value and are easily found by screen readers, especially those that have hot keys for reading headings and lists. The promise is very alluring, and I am certain the designers who have used this technique have the best of intentions.

The results are in:

The technique does not work as expected. With rare exceptions, the three most used screen reader programs do not discover, and do not speak the material hidden with display:none. The people you are trying to reach with this technique will never hear it, nor see it. If you threw out the previous technique (images with links), you have actually regressed.

How do we know?

I turned to accessibility gurus and to people who use screen readers everyday, asking them to try my Screen Reader Visibility Test. Summary results are below. While we wait to hear about more screen readers, the evidence is very clear. The display:none technique fails in the most used screen readers.

How did we get here?

First and foremost, the difficulty is with the screen reader products, none of which honor aural style sheets, and few of which pay any attention at all to CSS standards. Many of the screen readers appear to use Internet Explorer's DOM api to let IE tell them what it sees. Talk about listening to the blind men describe an elephant! Now we know.

Open memo to screen reader publishers: It is long past time to start building products that comply with W3C standards. The first of you who honors CSS, and especially aural media style sheets, will win the hearts, minds, and vocal support of designers who want to optimize accessibility in their designs.

What next?

What would we really like, and how can we accomplish it? From what we see at a few of the major CSS governed sites, it is clear that the designers would like accessibility conveniences to be heard but not seen. Perhaps the ideal way of achieving that is to:

  1. hide from visual display as is currently being done, with display:none in the style sheet intended for screen media, and
  2. speak with speak:normal; in the style sheet intended for aural media. The hope here is that the aural style sheet will have a higher precedence for the part of assistive technology that speaks.

The downfall, of course, is that the screen reader publishers don't yet pay attention to media="aural". We need to help them become aware. If you have contacts at those places, point them here or to the tests.

Late Breaking Breakthrough


Henry, the Old Actor, directs Mortimer in Abduction Ballet, "No no no, OFF LEFT, damm it!" (The Fantastiks). The off-left technique looks like a fine replacement for display:none. This came to me originally from Choan Gálvez on the css-discuss list. I extended it. Then, Dave Shea reduced it. The result works with Jaws 4.51, Window-Eyes 4.5 (beta), IBM Home Page Reader 3.02. Visually, it works as expected (content hidden, no extra whitespace) in Safari 1.0, Camino 0.7, Mozilla 1.3, Mozilla 1.4, Firebird 0.6, Opera 6 Mac, Opera 6 Win, Opera 7 Win, IE 6 Win, IE 5.2 Mac, NN4(!!!).

.off-left { position: absolute; left: -999px; width: 990px; }

The beauty of this technique is that it enables using as much text as we feel appropriate, and the elements we feel appropriate. Imagine placing instructive text about the accessibility features of the page off left (as well as on the site's accessibility statement). Imagine interspersing "start of..." landmarks through a page with heading tags. Or, imagine parking full lists off left, lists of access keys, for example. Screen readers can easily collect all headings and read complete lists. Now, we have a made for screen reader technique that really works!

However, this technique does not negate the need to consider other assistive features that cater to other disabilities, such as keyboard assistance for the mobility impaired. Be careful when using off-left to avoid causing other accessibility problems.

You may have to adjust the width so that your page element's bounding box appears on screen, even if the text is far offscreen. 990px width may not work with all elements.

The next best ways to leverage CSS and standards based thinking include:

  • Use good structural markup. All screen readers have fast ways of reading headings and lists.
  • If at all possible, place main content high up in the html source.
  • Joe Clark reminds us to not hide the SKIPNAV link because it is useful to others, not just the blind.

If you have other ideas of how to be heard but not seen, let me know and I will add them to the test suite.

Screen Reader or user agentlinkedimportedauralempty linkoff-leftnotes
Jaws 4.51 with IE6no/nono/noyes/noyes/nono/noyes/noyes/no3
Jaws 5.00.297 (beta)no/nono/noyes/noyes/nono/noyes/no?/?3
Jaws 6 no/nono/nono/nono/nono/noyes/?yes/?
Window Eyes 4.211no/nono/nono/nono/nono/nono/noyes/no
IBM Home Page Reader 3.01no/nono/nono/nono/nono/nono/noyes/no
IBM Home Page Reader 3.02no/nono/nono/nono/nono/nono/noyes/no
pw Web Speak yes/yesyes/yesyes/yesyes/yesyes/yesyes/noyes/yes6
Connect Out Loud 2.0yes/noyes/noyes/noyes/noyes/noyes/noyes/no7
HT Reader 3.5yes/?yes/?yes/?yes/?yes/??/??/?6
Start Speaking - Mac OSX w/Safariyes/noyes/noyes/noyes/noyes/nono/noyes/no
Microsoft Narrator- Win2k w/IE6no/nono/noyes/noyes/nono/noyes/noyes/no
Opera's accessibility layoutna/yesna/yesna/yesna/yesna/yesna/nona/yes5
Opera's small screen pda emulationna/yesna/yesna/yesna/yesna/yesna/nona/yes5
MSN TVna/yesna/nona/yesna/nona/yesna/no?/?
MAGic Screen Magnifier & IE6no/nono/nono/nono/nono/nono/no?/?

A very special "thank you" to all who took time to contribute their observations to these results!


  1. Styles coded as embedded or inline in the html behave identical to having the styles within linked style sheets.
  2. @import occurring within a linked style sheet produces results identical to having the @import directive in the <style> element of the html.
  3. Jaws speaks these only because it does not heed imported style sheets. When Jaws does learn to import style sheets, it will not speak these either.
  4. Sometimes used with screen readers.
  5. Not a screen reader, but indicative in some ways.
  6. I am *guessing* that these products do not read CSS.
  7. Almost too good to believe! Aimed specifically at Internet users, maybe this Freedom Scientific product is paying attention to standards?

Bob Easton , September 26, 2003

Come to that, there is some value in having a visible link to the main part of the page (or wherever it is that the link *skips to* - the next navigation point. It is a pity that the use of the link element to build an internal table of contents isn't implemented by IE, or it would be a sensible alternative, it is implemented in a lot of other browsers. --chaals

Tom Gilder's technique seems to solve the problem for me - and works nicely for people without mice - but it would be good to be know the results of exhaustive testing on that, too. -- Graham Seaman

Update: no, this technique kills all other links on IE5 on Mac. All links become effectively dead. :-(

The screenreader or/and tool webformator has an option to show invisible content or not, which is important if you try to use that software for testing purposes. The position%absolute method like described here is a little risky, information about the problems can be found here position error and with a alternative here K.Lipfert-Barrierefrei. Display or screen errors may happen at Gecko by using larger "em" instead of "px". IE 4 and NC 4 may need other methods too. Geckos behaviour at Windows 98 may be a bug and is reported here Bugzilla. -- K.Lipfert

A reference is made here to "three most used screen reader programs". What are they? A bigger question is, what are the best demos or free screen readers developers can use to test things like speak:spell-out? Connect Outloud 2 demo (basically the internet version of JAWS, demo lasts for 24 total hours of use) and Window-Eyes demo (30-minute timeout). Are their free, demo, and/or popular apps for Linux and Mac? -- Rock Of Victory (2005Jun1)

  • As a small followup, apparently Emacs/W3 (multiplatform) and Emacspeak (Linux) are two of the few browsers that actually provide aural CSS support; seem to be for the major techno dweebs, though.
  • Firevox ( provides some speech synthesis support for Mozilla Firefox and is multi-platform (Linux, Windows etc.), but it uses very non-standard keys.
  • We have also created Text browser tool for website accessibility tests. This could support speech synthesis in future using one of the open source engines.

I'm very glad people are thinking about accessibility, but I believe that your reading of the CSS standard is incorrect. Here is CSS2, section 9.2.4, the display property

This value causes an element to not appear in the formatting structure (i.e., in visual media the element generates no boxes and has no effect on layout). Descendant elements do not generate any boxes either; the element and its content are removed from the formatting structure entirely. This behavior cannot be overridden by setting the 'display' property on the descendants. Please note that a display of 'none' does not create an invisible box; it creates no box at all. CSS includes mechanisms that enable an element to generate boxes in the formatting structure that affect formatting but are not visible themselves.

Failing to speak display:none elements is therefore correct behaviour, and using display:none to hide things from sighted users is incorrect. I've checked CSS3 and it says the same thing: "The element is not rendered. The rendering is the same as if the element had been removed from the document tree" CSS3 The Box Model

I develop the WebbIE web browser for blind people so I'm particularly interested in this. At present I follow the standards as I understand them: however, if the use of display:none becomes dominant to hide navigation links I will be forced to break the standards to improve usability. -- Alasdair King

  • A follow-up: Isn't the point of CSS that you can render the page independently of its structure? So you can put the title and the main content at the top of the HTML document, and you don't even need the skip-nav link! -- Alasdair King
    • Not so. If your content comes first, you should then provide a link to skip to the navigation instead of a skip to the content link. -- Zoe Gillenwater

Alasdair has a definite point here and I'm surprised people even THINK of using [display:none] for this (and then complain when stuff disappears from DOM). What's wrong with using [visibility:hidden]? I know that using [visibility] would leave something visibly on the page (namely whitespace) but that can be circumvented with positioning/scaling, just as one would position and scale those spacer images. Consider:

  width:0px; height:0px;

this would effectively render the link as if it had [display:none] but it would still be available within the DOM. Using [z-index] would even enable one to hide it behind the real content stack, with the screenreader none the wiser.. --Patrick Kanne

@Alasdair: Isn't one of the main points of the article that these screen readers lack standards, by not interpreting the "media" link? If they respect the standard, the CSS code should be completely 'invisible' (no pun intended) to the screen reader. And about what's wrong with visibility:hidden: I think the example code looks more like some ugly hack than it would be with display:none. With display:none the object is not inserted into the tree, and that's exactly what the developer wants for those clients for whom the stylesheet is intended (not the aural media). -- Allard Naber

@Patrick Kanne: I tested it with NVDA (an open-source screenreader) and for that, at least, it doesn't work. I don't expect others to do better. Screen readers read the screen, even with some integration. To them, "visibility:hidden" has the same effect as "display:none". The obvious argument is that if nothing is displayed on the screen, nothing should be read. The counterargument would be that the designer intended for it to be invisible, but still audible when read -- the problem is that there's no way to tell that that was the designer's intent. Getting it wrong for the most common case (that the designer wasn't considering accessibility) would be undesirable.

@Allard Naber: the problem is, again, that screen readers read the screen. What you're saying would apply to aural browsers, but those are a slim, slim minority. Most screen reader solutions just hook into a visual browser and thus try to render content exactly as a screen browser would, just read out loud.

What might be the easiest compromise for now is for browsers to offer the option of turning off CSS altogether. To non-blind users with accessibility needs this may make sites look decidedly less attractive, but it's better than nothing. In Firefox, this can be done with View -> Page Style -> No Style for individual pages, and there's probably some obscure about:config setting to do it globally. For other browsers, no idea.

As an aside, I find it both funny and tragic that this wiki uses an ASCII-art captcha that renders it inaccessible. And is that a "U" or a "V"? Sigh. --JM

Speaking of the z-index attribute, couldn't this also be accomplished by setting the z-index to -1 (or one lower than the rest of the block-level elements) to effectively hide it, though retain its position and dimensions? -- Matthew Washington

Personal tools