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.

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.)

Let me know what you think :)

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.

This was not detected automatically by Google’s algo.

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.