A recurring question on various mailing lists such as the Web Standards Group discussion list is “How can I hide content but still have it accessible?” This is usually asked in the context of image replacement techniques, where one might for example wish to display a heading in a fancy typeface, but still have the content accessible to users of assistive technologies such as screen reading software.

Two techniques, both reliant on CSS, tend to come up in these discussions: hiding the text by the use of display: none or visibility: hidden, and positioning the text off-screen, using absolute positioning and left: -9999px, or margin-left: -9999px.

Access Matters determined back in June 2005 that the display and visibility techniques appeared to be inaccessible to screen readers, whereas the offscreen positioning method was accessible. The full results go into more detail.

One thing that nobody seemed to have bothered to explain was just why this was the case. Inspired by yet another thread on the subject, I finally decided to do some digging; if I don’t know why I’m doing something, I can’t be sure that I should be doing it, which leads to the risk of Cargo Cult coding.

Ask the people who know

To my astonishment, a search of the Microsoft Developer Network Library quickly brought me to the explanation I sought. (I was astonished because the MSDN library search is notorious for returning swathes of irrelevant results for even the simplest search; I have heard anecdotal evidence that Microsoft’s own developers search the library using Google with the site:msdn.microsoft.com specifier.)

The library’s section on accessibility support in Internet Explorer is extensive, but the information about invisible objects told me all I needed to know. To quote:

With Internet Explorer 6 and later, the pvarState parameter of the IAccessible::get_accState property receives STATE_SYSTEM_OFFSCREEN when the object is invisible because of scrolling and receives STATE_SYSTEM_INVISIBLE when the object is invisible because its IHTMLStyle::visibility property is set to hidden, or its IHTMLStyle::display property is set to none.

Again, in English?

A screen reader doesn’t load an HTML page: the browser (usually Internet Explorer) does that. What the screen reader does is to ask IE about the content, using an API called Microsoft Active Accessibility (MSAA). MSAA allows the screen reader to interrogate the browser as to the contents of a page; the dialog, insofar as I understand it, would go something like:

Internet Explorer:

Hey, I’ve just loaded a page.

Screen reader:

Cool, what’s it got on it?

Internet Explorer:

There’s a heading, then some links, then a few paragraphs.

Screen reader:

OK; give us the heading.

Internet Explorer:

It says “Welcome to HyperGlobalMegaCorp”.

Screen reader:

Right, hang on a moment. (Speaks the given text to the user.)

… and so on; you get the general idea.

The key is that IE doesn’t just return content to be spoken in some way; it also returns information about that content. This includes information that goes by the snappy name of pvarState, and one of the aspects of this information is that it can tell the screen reader whether or not the content of the thing it’s asking about (for example, the heading in the above dialogue) is actually displayed on the screen - that is, whether it’s visible or invisible. (Note that these terms aren’t being used here in exactly the same way as they are in CSS.)

There are three ways that IE comes to regard something as being invisible:

1. It has the CSS property display set to the value none;
2. It has the CSS property visibility set to the value hidden;
3. It is in a position where the window would need to be scrolled for it to become visible.

IE further distinguishes these three forms of invisibility by dividing them into two kinds. The first two forms of invisibility are denoted by the pvarState value STATE_SYSTEM_INVISIBLE, and the final form is denoted by the value STATE_SYSTEM_OFFSCREEN.

So finally it all becomes clear: screen readers will treat content with the state STATE_SYSTEM_OFFSCREEN as being content that it should read, because it’s only invisible by virtue of not being within the visible region of the window: after all, a screen reader that required the user to scroll the window to read all of the content would be of very little value to anybody. The only reason that the content can’t actually be scrolled into view when using the off-left or off-top positioning technique is that Internet Explorer itself doesn’t support the concept of scrolling the window by a negative amount, although I believe this isn’t a limitation of the Windows scrolling mechanism per se.

If, however, the screen reader finds that the state of the content is STATE_SYSTEM_INVISIBLE it apparently concludes that it must have been concealed for a reason, and doesn’t speak it.

So there you go: use one of the offscreen methods and the screen reader will treat your content as being there; use the display or visibility method and the screen reader will discard it, meaning that this is a reliable way of concealing content from both a normal user and a screen reader user, should you have a reason to do so. But armed with the information above, you’ll at least know why you’re using whichever method you apply.

Last Saturday I went to the WebDD conference at Microsoft Campus, Reading. Following my standard conference procedure, I checked in, obtained coffee, and fired up my MacBook.

At this point one of the official photographers (only authorised individuals may take photos at MS) rushed over to me and asked, “Is it all right if I take a photograph of you?”

“Yeah, fine,” I replied. As he raised his camera, I asked, “Is it the Mac?” “Yes,” he said.

I’d only been at Microsoft five minutes, but the Reality Distortion Field had already cast me into a Bateman cartoon: “The Man Who Used a Macintosh on Microsoft Campus.”

(And no, I’m not a designer.)

It’s back! BarCamp London 2 will be hosted by BT on February 17th - 18th. Check out the BarCamp site (above) for signup details.

I’ve got my place, and now have to decide what subject to present about. One thing I’m certain of: I’m not going to leave it until the last minute this time. I missed a lot of good stuff at the last BCL because I was tucked away in a spare office, frantically hacking together a demo to illustrate my points about underused aspects of HTTP. This time, I’ll be ready.

Already up and running is the Backnetwork. This is the same system that Madgex developed for d.Construct 2006 (Glenn Jones of Madgex is giving a presentation on Microformats), and proved itself to be an excellent system for keeping track of contacts and following the general Flickr and blogging buzz around the event.

See you there, if my car has been healed by then. (I dread to think what the train would cost.) the car having been healed through the miracle of a few hundred pounds. (Broken trailing arm, whatever one of those is.)

Bob Holness did not play saxophone on Gerry Rafferty’s song Baker Street.

The musician responsible for the legendary riff was in fact Raphael Ravenscroft, and the whole Bob Holness thing started life as a joke by journalist and BBC presenter Stuart Maconie in the New Musical Express.

In other late-breaking news:

• The late Richard Whiteley did not play washboard with Slayer in their early days as a Doncaster skiffle band.
• Valerie Singleton and Muffin the Mule did not co-star in the series Lesbian Lavatory Lust Volumes I - XVIII.
• And, just to be positive for a change, Monkee Michael Nesmith’s mother did, in fact, invent Liquid Paper.

Thank you. You may now return to consuming your Kentucky Fried Rat, with lashings of green cola. (This means you, Gaz.)

After a tense 24 hours or so, I got bumped up from the waiting list to become the bottom of the list of attendees at BarCamp London next month. I’m not sure what I’ll be offering in the way of a presentation yet, but there’s a good chance it’ll have something to do with XSLT and/or DOM Scripting.

If you’re going to be there, I look forward to seeing you. If you’re interested in going, you can sign up to the waiting list - and then hope for a virulent plague to sweep through the UK web development community sometime in the next fortnight.

A quick and easy way to tell is to type the following snippet of JavaScript into the location bar:

javascript:alert(document.compatMode);

which will pop up a box stating either “BackCompat” for Quirks mode, or “CSS1Compat” for Strict mode.

If you’re using Firefox and have the Bookmarks toolbar visible, you can drag the following link on to it to create a handy little button you can use to check which rendering mode the browser is in on any page you visit. In Internet Explorer, right-click on the link and select “Add to Favorites…” to achieve the same thing. (You’ll get a warning that the link “may not be safe”; at that point you have to decide how much you trust me. Believe me, it’s safe.)
Rendering mode

I find this tremendously useful for doing checks on pages, particularly when editing pages by hand, where a simple typo might throw a page into Quirks mode, with resultant frustration as CSS which previously worked suddenly goes completely to pot.

(Note that the “CSS1Compat” actually means “CSS2Compat” in browsers with support for CSS 2.1.)

If only my work involved driving wherever the spirit took me, through the Rocky Mountains in the springtime - including a visit to the real South Park.