Just a Coder - nickfitz.co.uk

(Update: Thierry Koblentz points out in the comments that either technique may be appropriate, depending on circumstances. I mention this in the last pargraph, but just to be clear, there should have been a “usually” or “often” or some such word in front of the “better” of the title. That, or a different title.)

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.

The IEBlog has announced the release of the Beta Preview of IE7. Unfortunately, you need to overwrite your existing system to use it, or shell out hard cash for Virtual PC, sold by… Microsoft.

Oh, and it only works on XPSP2; bet you wish you hadn’t shelled out for Windows Server 2003 now.

Zen gardener Dave Shea’s post Bye Bye Tan Hack attracted a number of comments from people claiming that Internet Explorer’s conditional comments (CCs) were ungeneratable if you are using XSLT to produce your pages. “Strange,” I thought, “I’ve done that before.”

I’ve been working with XSLT for several years, and the project I’m currently working on uses it intensively; getting CCs working was simmering somewhere down my todo list. (I couldn’t recycle any previous efforts for boring, legal IP reasons.) So I set to work, and am happy to present an XSLT template which will build your conditional comments for you. I’ve tested it with Xalan 2.2, Saxon 6.5.3, MSXML 3 and MSXML 4 (those being the only XSLT processors I had to hand), and it worked perfectly with all of them.

In addition, I’ve created a demonstration for Firefox, Internet Explorer and Safari (2.0.1 on Tiger, anyway). This XML file uses an XSL stylesheet which generates a conditional comment. Using Firefox’s DOM Inspector you can see that the comment is created correctly. Using Internet Explorer, a stylesheet is linked which modifies the appearance of the page’s heading. This demonstrates that the technique I’m describing can be used client-side as well as in server-side transformations.

First, the template:

<xsl:template name="conditionalComment">
   <xsl:param name="qualifier" select="'IE'"/>
   <xsl:param name="contentRTF" select="''" />
   <xsl:comment>[if <xsl:value-of select="$qualifier"/>]<![CDATA[>]]>
      <xsl:copy-of select="$contentRTF" />
   <![CDATA[<![endif]]]></xsl:comment>
</xsl:template>

Easy, yes? Well, maybe not; let’s look at it one step at a time.

The template takes two parameters:

qualifier

The qualifier for the “if” clause of the comment. Defaults to “IE”, which targets any version of Internet Explorer that recognises conditional comments.

contentRTF

The body of the comment: the stuff that IE gets to see (depending on the qualifier). This is passed as a result tree fragment; if you’re not sure what that means, you may want to go and read the relevant section of the XSLT spec. Defaults to an empty string.

We can invoke the template using the following code:

<xsl:call-template name="conditionalComment">
   <xsl:with-param name="qualifier" select="'lte IE 6'"/>
   <xsl:with-param name="contentRTF">
      &lt;link rel="stylesheet" type="text/css" href="ie-win-fixup.css" /&gt;
   </xsl:with-param>
</xsl:call-template>

That will give us a conditional comment targeting Internet Explorer versions 6 and below (”lte IE 6″). NOTE: I haven’t messed up my character entities there; the HTML we want to output really is expressed as you see above in the XSLT code.

So how does it work?

The comment is generated using the <xsl:comment> element. Note that we want to keep tight control of our whitespace here, making the rest of the template pretty unreadable. Split into its component parts, we have:

<xsl:comment>

Starts outputting our comment to the result tree. Output so far: <!--

[if <xsl:value-of select="$qualifier"/>]

Starts adding on the bits needed to make IE parse this as a conditional comment, using the value of the qualifier parameter. In the example case, our output is now up to <!--[if lte IE 6]

<![CDATA[>]]>

This CDATA section is treated as raw characters to copy to the result tree by the XSLT processor. So our output becomes:
<!--[if lte IE 6]> which is the start of our conditional comment.

<xsl:copy-of select="$contentRTF" />

This just copies the contents of our result tree fragment to the result tree. Our output is now:

<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" xhref="ie-win-fixup.css" mce_href="ie-win-fixup.css"    />

Notice that the character entity references we passed in in contentRTF (< and >) have now been turned into the actual characters we wanted, through the magic of result tree fragments. (In fact, this technique can be abused to allow invalid XML output from an XSLT processor, which is why it isn’t likely to survive into XSLT 2.0.)

<![CDATA[<![endif]]]></xsl:comment>

Our final line uses another CDATA section to provide the markup IE needs to recognise the end of the comment, and then the </xsl:comment> closes our comment. Note again that there is no whitespace between the CDATA section and the closing-comment element: this is where IE’s CC parser might trip up, so we make do with a little unreadability for the sake of getting the result we want which, in all its refulgent splendour, now looks like:

<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" href="ie-win-fixup.css" />
<![endif]-->

So there you have it: an XSLT template for creating Internet Explorer conditional comments. Hopefully re-targeting your CSS hacks in readiness for the new age just got a little easier.

The Web Standards Group presented ten questions to Tommy Olsson, one of which addresses the thorny issue of the abbr and acronym elements in HTML.

Tommy’s discussion of this was informative, and I was particularly entertained by his assertion that

Netscape invented ABBR, while Microsoft invented ACRONYM, and both types meant the same thing. Then the W3C incorporated both in HTML 3, but with subtly different semantics. Microsoft’s meaning of ACRONYM was replaced by something different, which made the people at Microsoft so furious that to this day they still don’t support the ABBR element type!

as I came across a manifestation of this (possibly imaginary) dislike for the abbr element in Internet Explorer quite recently.

Consider the following markup fragment:


<p>An example of an abbreviation might be <abbr title="Limited Liability Company">Ltd.</abbr>, used in the UK to denote a private company with limited liability.</p>


One would expect a browser which supports HTML 4 (which IE is claimed to have done since version 4) to produce a DOM structure as follows:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
    • Text: Ltd.
  • Text: , used in the UK to denote a private company with limited liability.

Whereas IE actually produces the following:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
  • Text: Ltd.
  • Element: /abbr
  • Text: , used in the UK to denote a private company with limited liability.

Yes, that’s correct: the initial abbr is parsed into an element, the text within remains as a childNode of the paragraph, and an element with the name /abbr is created.

If you try to use the createElement method of the document to create such an element, you naturally get an exception. But internally, IE manages to create an element whose name begins with a slash.

I don’t have a PC at home, so I can’t check right now whether or not spurious markup like <goat>Hello</goat> produces the same result, but I’ll check at work tomorrow and report back.

Long-delayed update: The <goat> example above does indeed produce the same results.