W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2005

How to make in-page links work.

From: Jim Thatcher <jim@jimthatcher.com>
Date: Sun, 7 Aug 2005 21:31:51 -0500
To: "'WAI-IG'" <w3c-wai-ig@w3.org>
Message-ID: <000201c59bc1$58812820$6501a8c0@jtcom2400>

I have been harping on this for months and have written about it at
http://jimthatcher.com/skipnav.htm. It is the fact that in-page links often
don't work when using the keyboard. And it is absolutely crucial for
keyboard navigation that in-page links work. After something like 6 months I
think there is answer to the question: "how can you get in-page links to
consistently work with the keyboard without resorting to either table cells
(when the target is in a table cell the link usually works) or making the
target a link (always works)?  Remember this is all IE - the other browsers
do not have a problem.

This concept of an in-page link working or not seems to be a little hard to
get across. Here it is. First of all, do not use the mouse. Now tab to the
in-page link; press enter. The visual focus will change if it should. Now,
and this is the key. Tab again. The link "works" if that tab took you to the
first link after the target.

Example 1: Put your mouse out of reach. Open http://webaim.org. Tab to the
skip Navigation link, the first link on the page. Press enter. There
probably was no change in the visual point of regard. Now tab again. The
first link in the "main content" is "Notice of proposed Rulemaking". That
link got focus. This in-page link works.
The target of this link is coded:  
<div style="width:0%;height:0px;">
<a name="maincontentlink" id="maincontentlink"></a></div>

Example 2: Open http://webaim.org/techniques/forms/. Tab all the way down to
"Introduction", the 16th link. Press enter. Note the visual focus shifts
this time. The first link after the target of the "Introduction" link is
http://sports.espn.go.com/ncb/index. Now Tab. Input focus moved to the top.
This link does not work. Input focus moved back to the top.
The target of this link is coded like this: <a name="Intro" id="Intro"></a>
with no special div around it.

Example 3: Open http://gawds.org. Tab to "Jump to Diary Archive" (the second
link). Press enter. The visual looks good. The next link is "Automated
Testing how Useful is IT?" (hmmm). Go ahead and Tab. Focus lands back up on
the search field. The link fails to "work" in that it doesn't bring input
focus with it.
This target that doesn't work is coded like this:
<h2 id="diaryarchive"><a name="diaryarchive">Diary archive</a></h2>.

Example 4: Open http://www.w3.org/WAI/. Tab to "Skip to Content." Press
enter. Visual focus moves as expected. Next link is "WCAG 2.0 Call for
Review". Tab. Ooops! Back to the top "Skip to content".  This link (and
every in-page link on the WAI site that I have tried) does not work from the
The target of this link is not an anchor, just a div with ID: <div

It probably is the case that <div id="main"> is supposed to work but it
doesn't if you are using IE only with the keyboard. So here's a workaround
that seems to work with the keyboard and with JAWS and Window-eyes.

Example 5: Open http://jimthatcher.com/sidebyside4.htm (this is a test page.
Tab to the in-page link, "Overview". Press enter. Tab again and you are on
"The WCAG View." This is the first link after the target. The link works
from the keyboard. It is also an in-page link. Hit enter again and you can
check that that one works too.
These targets are coded like this: 

<div style="width:0%;height:0px;">
<a name="Overview" id="Overview">
<img "src=\images\1-pix.gif" width="0" height="0" alt="" />

This combines the WebAIM technique (Example 1) with one Liam McGee has been
suggesting to me. I have just added an invisible gif as contents of the
named anchor. Without putting something as the contents of the anchor, the
WebAIM technique doesn't work for visual focus. It seems to work in Example
1 only because no visual focus shift was needed. Becky Gibson and Mike Scott
were the first to notice that when targets of in-page links were contained
in elements "with width defined" (whatever that means) - they generally
worked from the keyboard.  

Accessibility Consulting: http://jimthatcher.com/
Received on Monday, 8 August 2005 02:32:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:26 UTC