More on In-page links and the IE Bug (Posted July 6,2007)
I have been writing about this problem on and off for about 2 years, first the article on
skip navigation links; then information about the hasLayout property and
how that relates to the IE bug. There is even mention of this issue in Chapter 7 of the
new Web Accessibility book.
But a couple of days ago I received an email from Andrea Fercia in Milan, Italy, and he suggested a simple approach to the problem.
For a quick review, the problem is this. Sometimes input focus does not work correctly using IE with the keyboard.
Tab to the "skip navigation" link on the Web Accessibility Initiative home
page. Follow that skip link with the Enter key (actually you may use the mouse if you have to) but now, tab again.
That's the crucial point; rather then landing on the first active element in the "main content" you are
back at the top - on the skip navigation link in this case. The solution used on these pages, and discussed in
the hasLayout article
looks like this:
Style A. <span style="position:absolute;">
<a name="inpage" id="inpage"> </a>
</span>
Andrea asked, why not just make it an empty link like this:
Style B. <a name="inpage" id="inpage" tabindex="-1" href="#inpage"></a>
That's a good question. The first answer is that when the tests were
run in 2005, this technique did not work with Opera (see the test results table).
Unfortunately, I didn't record the version of Opera that I used then - but it is no longer a problem
(Opera 8.51) - so that doesn't throw out this simplified idea. I did not discover the second answer to Andrea's question
until I followed that test
results table link.
The target is coded as an empty link (as proposed in Style B) and visual focus moves to it correctly.
But use Tab key again and focus goes to the address bar (at least on my computer!). It seems that when the target
of a link is a named anchor on a new page, this scheme doesn't work. A third reason for not using the empty link
might be that the empty link would appear in the tab order and thus be confusing. That is corrected with the tabindex attribute
set to -1, removing the anchor from the tab order. I believe that when I first wrote about this problem, JAWS didn't
respect tabindex="-1"; now (Version 8.0) it does. So with tabindex="-1",
JAWS 8.0 ignores the empty link and it is not in the JAWS links list. Oops - not so fast! It turns out that
Window-Eyes (Version 6.1) does not respect tabindex="-1" so
that the empty links are in the Window-eyes tab order and the WIndow-Eyes links list.
So it is back to the drawing board - or back to waiting for Microsoft to correct the bug in IE - or use Style A for all your in-page links.
