There is a bug in Internet Explorer that can prevent same-page link from working as expected when used from the keyboard. Specifically, when a same-page link is clicked, the page may visually scroll to the desired location, but the keyboard focus can jump to the top of the section, the top of the page, or another unexpected location. Jim Thatcher first reported this bug in detail at http://www.jimthatcher.com/skipnav.htm.
The effects of this bug can be extremely confusing for people who rely on keyboard devices. And worse, it often prevents the use of "skip navigation" links, which can otherwise be of tremendous help to keyboard users.
The good news? There seem to be workarounds...
Try the following links using the keyboard, pressing Tab to move between links and Enter to activate them. Press Tab once after following a link to see where keyboard focus has gone. Use Shift+Tab to return to these links:
Example 1 | Example 2 | Example 3 | Example 4 (the workaround) | Example 5 (the alternative)
Dummy Link 1.1 | Dummy Link 1.2 | Dummy Link 1.3
Note that the link to Example 1 doesn't work as expected. Its target (<a id="example1"></a>) is immediately before the Example 1 heading, but keyboard focus moves to the top of the page instead.
Dummy Link 2.1 | Dummy Link 2.2 | Dummy Link 2.3
The Example 2 link works as expected: keyboard focus moves to the top of the Example 2 section, and pressing Tab again moves focus to Dummy Link 2.1.
Interestingly, Example 2 is the same as Example 1 except that the whole section is wrapped in a <div> with style="width:100%". Assigning any width other than "inherit" or "auto" has the same effect, as does placing the entire section within a table cell. (This is why this bug only sometimes appears, and why we didn't face this problem when tables were used for layout.)
Internet Explorer treats Example 2 differently because it sees the containing div as having a special property called "hasLayout". (See On Having Layout for all the painful details.) Internet Explorer actually moves keyboard focus to the top of the target's closest ancestor element that "hasLayout", which, in this case, is the top of the div containing Example 2.
Dummy Link 3.1 | Dummy Link 3.2 | Dummy Link 3.3
Unfortunately, it isn't always possible to find a parent element that "hasLayout", and in some cases, doing so still doesn't solve the problem:
Example 3 is the same as Example 2, but the target is placed immediately before Dummy Link 3.3. The intent is that focus should move directly to that link, bypassing Dummy Links 3.1 & 3.2. Unfortunately, Example 3 works just like Example 2, and keyboard focus moves to the top of the section regardless of where the target is placed.
Dummy Link 4.1 | Dummy Link 4.2 | Dummy Link 4.3
Example 4 repeats Example 3, with the target positioned immediately before Dummy Link 4.3. However, this time, everything works as expected.
The workaround is the addition of a parent element that "hasLayout" and contains only the target. As a result, the containing div no longer needs to have its width set, and the target works no matter where it is placed within the section.
Specifically, we use a <span> around the anchor and set its style="position:absolute" to trigger "hasLayout". To complete the workaround, a non-breaking space ( ) is added inside the anchor so that Internet Explorer will still visually scroll the screen. With position:absolute, neither the target nor the non-breaking space take up any visible space.
The code for the workaround looks like this:
<span style="position:absolute;"><a id="example4"> </a></span>
Dummy Link 5.1 | Dummy Link 5.2 | Dummy Link 5.3
Gez Lemon of Juicy Studios has identified an alternative workaround: Setting tabindex=-1 on the target causes Internet Explorer to move keyboard focus as expected. This example uses that approach, with the target placed before Dummy Link 5.3 using the following code:
<a id="example5" tabindex="-1"></a>
This approach is cleaner and simpler, and its only obvious drawback is that "-1" is not an officially valid value for tabindex. It will, however, pass the W3C Markup Validation Service as long as an XHTML doctype is used. See Gez's article and comments at http://juicystudio.com/article/ie-keyboard-navigation.php.
This issue appears to be unique to Internet Explorer for Windows, and it affects versions 5, 6, and 7.
Firefox 2 and Netscape 9 handle same-page links as expected, and the use of this workaround does not interfere with that behavior. Opera 9 and Safari 3 for Windows don't appear to move keyboard focus to same-page links with or without this workaround.
If you have questions or suggestions, please email accessibility@msfw.com.