hasLayout Property
Characterizes IE6 Bug (8/15/5 - modified 8/28/5)
The target of the skip link on this page used to look like this:
<table><tr><td>
<a name="cont" id="cont"></a>
</td></tr></table>
"Why a table?" you should ask. The answer is that there is a bug in Internet Explorer Version 6.0 which causes in-page links to not work from the keyboard. But when the target of any in-page link is placed at the top of a table cell then it will work correctly from the keyboard with IE6. What does work correctly mean? This description seems to be daunting for web developers who are so focused on and dependent on the mouse. Here is how to test any in-page link:
- Hide the mouse so you don't mess up this experiment.
- Use the TAB key to move to the in-page link that is to be tested.
- Press ENTER; that will reposition the visual focus on the page so that the target of the in-page link is at the top of the visual window (if there is enough of a page to refocus).
- Now, and this is the key, press TAB again. This time the TAB key should move to the first link below the target of the in-page link. Often this is not what happens; instead this TAB puts focus on the first link of the page, or generally some other unwanted place.
If you follow these steps with Netscape 7.2, Mozilla Firefox 1.04 or Opera 7.54 (substitute the A key for the TAB key in the process of testing the links in Opera) everything will work as one would hope and expect; not so for IE6. Mike Cherim has created a terrific set of three pages called A Focus on Focus with which you can run this experiment.
For table-based sites like CNN
and IBM (as of this writing), the skip links usually work because
it is natural for the target of the link to be at the top of a table cell (td).
For more contemporary sites like that of the Web Accessibility Initiative of the World Wide Web Consortium, for example, the in-page links do not work. Try WAI home page. TAB to the "Skip to Content" link, press ENTER and visual focus moves, but TAB again and input focus is back at the top of the page. It should work but it doesn't - at least as of this writing. This is true of many sites, and not just skip links. For example I have a short "table of contents" at the top of my comparison of Section 508 and WCAG.
Though they are fixed now, up until recently if you activated one of those from the keyboard, then tabbed again, you were back at the top of the page.
What is the solution (read work-around) for this problem? Through discussions
on various mailing lists over several months the nature of the IE6 bug
has become clearer.
In May of 2005 Becky Gibson (IBM) and
Mike Scott (MSF&W) independently recognized that when targets of in-page
links were contained in (actually at the top of) elements "with width defined" (whatever that meant) - they
generally worked from the keyboard. It was Terrence Wood who put it together
with the hasLayout
property:
IE6 places input focus on the first ancestor object of the target of the link
which is a
span or div with the property hasLayout set to true or which is one of the elements which always has hasLayout=true, including td and body. With body in the list that means that input focus always has a place to go
and also explains why input focus so often ends up on the top of the page.
With td in the list, we can understand why in-page links on table based
sites generally worked from the keyboard.
A Google search for "hasLayout property" will yield a
Microsoft
MSDN page at the top of the list that
describes this property and methods for setting it to true; setting width
and height is just one such method. There are a two of other interesting
articles about the hasLayout property from WebmasterWorld and from satzansatz.de.
With that said, here is the work-around that I use to insure that my in-page links work from the keyboard with IE6. This is the coding for a typical target.
<div style="width:0%;height:0px;">
<a name="maincontent" id="maincontent">
<img src="\images\1-pix.gif" width="0" height="0" alt="" />
</a>
</div>
The styling of the div assigns height and width which turns the hasLayout property to true.
The anchor element (a) is not empty, but contains an invisible gif.
Without that (or some other text content), it turns out
that visual focus doesn't work correctly. I hope that the next version (7.0) of Internet Explorer
will have this fixed. But of course IE6 will be around for a while and
this workaround is not too offensive.
Well, that is what I was using last week, and that is what is used on
several of my pages. But Mike Scott (MSF&W) has written
with a much simpler approach.
<span style="position:absolute;">
<a
name="content" id="content"> </a>
</span>
Here is Mike's analysis as written in an email to me.
Position:absolutehas the additional effect of removing the element from the flow, so it doesn't take up any space. This way we can use a non-breaking space instead of a 1px image. Since it uses aspan, it can be used inside elements that can't contain divs (paragraphs, headings, etc). We also don't have to worry about thedivcausing an extra line break in old/non-css browsers.
Simplification is certainly welcome. Thanks Mike.