Here are the main parts (with some headers and the body omitted) of the response to a broken request for Raymond Chen’s blog – I deliberately misspelled “default” as “defult” to trigger a 404:

HTTP/1.1 302 Found
Date: Wed, 10 Dec 2008 17:46:51 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Location: /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx
Content-Type: text/html; charset=utf-8
Content-Length: 176

So, a request for something that is not found returns 302 Found. Nice.

What happens when the browser follows the redirection to /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx? This happens:

HTTP/1.1 404 Not Found
Date: Wed, 10 Dec 2008 17:46:52 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Content-Type: text/html; charset=utf-8
Content-Length: 11769

So, just to get this straight: when something is not found, ASP.NET returns a 302 Found response redirecting the client elsewhere. Then, when the redirect is followed, it returns a 404 Not Found response, despite the fact that this page clearly has been found, and it was the page that redirected us here that was not found.

Weird. Just plain weird.

Update: an online acquaintance (I don’t have a URL for him) has pointed me to a page on MSDN where the rationale for this behaviour is presented:

Redirect creates a new Context, Transfer does not. Redirect requires a round-trip to the browser, Transfer does not. As a result of this round-trip, Redirect rewrites the URL to reflect the location of the error page, Transfer does not.

If this seems to be an argument in favor of Transfer, it isn’t. The rationale of the ASP.NET development team is that Redirect accurately displays the URL of the custom error page…

However, at no point is it explained why displaying such an implementation detail to clients is preferable. Given that the article starts with the words:

The quality of a site should be measured not only by how well it works, but by how gracefully it fails.

it seems strange that it then recommends a technique which causes sites to fail in a singularly graceless manner.

My suggestion would be to modify your ASP.NET application configurations so that the customError capability uses the Transfer technique instead of Redirect. If that

…breaks a tenet of the design philosophy of ASP.NET…

then so be it.

Update 2, December 2008: It is now accepted that it is better to use top: -9999px;, as using left: would cause a scroll bar on a page with right-to-left text.

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.

This post is now available in Belorussian provided by http://www.fatcow.com/ – many thanks for that!

A designer?

Originally uploaded by writerus drivelus.

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