C and D may cause problems with Google, from what I’ve been reading — although they may object equally to B, so I’m not sure if there’s much help there at any rate.

I’d probably use option C, unless I were extremely concerned about my pagerank, in which case I’d experiment with B.

B: have never tried that one.

C and D should work, but ems are a bit unpredictable across browser-land. Some browsers may get the calculations wrong, and end up affecting the visible part. Pixels are better here.

Off-screen by use of absolute-positioning with pixels is reliable in all browsers I’ve tested in (win / Mac), with a top and left value of max -30000px.

Other methods, like negative text-indent, are less reliable.

My typical, safe, ‘off-screen’ will look like this:
.offscreen {position: absolute; left: -9000; top: -9000;}

* http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=565
* http://juicystudio.com/invisible-form-prompts.asp

of course, in an ideal world, there wouldn’t be a need for this dual approach: you’d be able to define element display/visibility on a per-medium basis, therefore making things like skip links not display on screen but be available through media-specific stylesheets aimed at “speech”…

http://www.webaim.org/techniques/articles/hiddentext

I have used this successfully on some sites without noticing any loss in page ranks.

I’d go with C, or the unlisted option E which uses text-indent: -9999px

C and D may cause problems with Google, from what I’ve been reading…

Does anyone know if this is true? Yes, we know that Google looks for text hidden by making color and background the same, but that is a relatively trivial test of inline styling information.

Is Google now testing for techniques such as C and D? That’s sort of hard to imagine for a site that doesn’t use web-standards techniques in its own presentation.

Fact, rumor, or paranoia?

If these techniques become known as being used for valid reasons then hopefully this will never be an issue.

If the rumours are true I’d say B was just as bad…

The only one I’d avoid like the plague is A) which has well-documented issues w/ screen readers. [2]

NOTES:
[1] http://css-discuss.incutio.com/?page=ScreenreaderVisibility
[2] http://www.alistapart.com/articles/fir/

@media screen, print {
#divtohide {
display: none;
}
}

@media speech {
#divtohide {
display: block;
}
}

or, even better, just import different style sheets for different media:

@import url(”/path/to/screen.css”) screen;
@import url(”/path/to/speech.css”) speech;

B or C. Guess B.

Bah, I’d probably go with C, but I think A should work in an ideal world.

Opera 8 does indeed handle media-dependent stylesheets.

I’d go for option F: Push creators of other screenreaders into supporting media-dependent CSS. Broken tools should be fixed, not worked around.

I agree — broken tools should be fixed. But I don’t want to penalize users who use them (often with no real option to change) in the meantime. So you code around it while trying to get it fixed at the same time.

And, no, I haven’t seen anything official saying that Google penalizes for negative text indents.

I’m going to quote at length from an Eric Meyer post from December[1]:

* A lot of things that we take for granted as being good, like image-replacement techniques and Flash replacement techniques, are technologically indistinguishable from search-engine spamming techniques. (Mostly because these things are often used for the purpose of spamming search engines.) Things like throwing the text offscreen in order to show a background image, hiding layers of text for dynamic display, and so forth are all grouped together under the SEO-industry term “cloaking”. As the Yahoo! guy put it, 95% of cloaking is done for the specific purpose of spamming or otherwise rigging search engine results. So the 5% of it that isn’t… is us. And we’re taking a tiny risk of search-engine banishment because our “make this look pretty” tools are so often used for evil.

Reading that last point, you might be wondering: how much of a risk are you taking? Very little, as it turns out. Search engine indexers do not try to detect cloaking and then slam you into a blacklist—at least, they don’t do that right now. To get booted from a search engine, someone needs to have reported your site as trying to scam search engines. If that happens, then extra detection and evaluation measures kick in. That’s when you’re at risk of being blacklisted. Note that it takes, in effect, a tattletale to make this even a possibility. It’s also the case that if you find you’ve been booted and you think the booting unfair, you can appeal for a human review of your site.

That sounds, to me, like it *could* hurt you but won’t, necessarily.

Notes:
[1] http://meyerweb.com/eric/thoughts/2004/12/18/ses-chicago-report/

Fact, rumor, or paranoia?

I haven’t seen any evidence about Google spidering my stylesheets. Possibly, if someone complains, then Google will look it up manually.

That said, I’ve gone for option C for a long while, adding an option to render the text visible to keyboard users (skip links using :focus). Using B sounds good as well, although some browsers (that one) have a bit of a problem with the overflow:hidden. Nothing that can’t be worked around.

This was not detected automatically by Google’s algo.

Choice A does have issues. Those issues are dependent on how the display:none is delivered. For example, JAWS will obey display:none if it is inline or part of a LINKed style sheet, but will not obey it if it is part of an IMPORTed style sheet.

Two or three questions from now, we will explore all the possibilities.

Let me know what you think :)

It sounds like it’s worth experimentation, though. Or has somebody already looked into it?

(In other news, Bob, can we get a “preview” option for our comments? I’d like to be able to proof mine outside of the textarea. Thanks.)

Essentially none-displayed content is neither guaranteed to be accessible, nor guaranteed not to be .. so it’s best not to use it at all, except for things that are generated from events that only a mouse-user would generate (such as onmousedown - assuming it’s safe to assume that a screenreader-user is using a keyboard, not a mouse or other tracking device …?)

To the question I’d say C, but I agree with Georg - offleft “em” positioning sometimes causes horizontal scrollbars, in Safari and Opera; I generally go with “position:absolute;left:-10000px;” and confirmed that that works in all modern (5+)browsers, JAWS 4.5, 5 and HPR 3

I’ve never seen any evidence that SE ratings are affect by offleft positioning - but if it is true - it’s their problem; if SE’s are doing this then they’re broken and will have to stop it - I’m not gonna drop a useful accessible technique to suit their relevance-filtering problems. SE optimisation is a vicious circle anyway … but that’s another story ;)

Anyway.. it isn’t just display and overflow that’s a problem - any of “display:none”, “visibility:hidden”, “overflow” or “clip” will make the element (or the affected region) inaccessible to most browser-based readers. And I actually *don’t* think that’s wrong - screen readers are *screen* readers, they’re not aural or speech browsers - I think it’s right that they should read essentially what you would see.

But do be careful with what content is hidden using this technique. Skip links we’re talking about elsewhere, but I also don’t like to hide the text in FIR constructs either - the “images off / css on” situation is real, not to be dismissed as exreme minority (and even it is - numbers are beside the point ;))

But there are many things where it’s useful - I use it a lot for “meta headings” - things like an H2 “Site navigation” just before the navbar list - where it’s useful to a serial browser because it aids spatial comprehension, but arguably superfluous for graphical browsers, who can tell what it is by looking at it.