Main Points
- Internet Explorer Tab Problem An explanation of this page and the IE problem we're addressing.
- Anchored Keyboard Navigation Demos Demos of the various inpage navigation techniques.
- Anchored Keyboard Navigation Conclusion A summary of the testing results.
- Skip to Main Points links return to the Main Points menu.
Internet Explorer Tab Problem
When using a named anchor, IE has a serious problem for keyboard users including the blind, text browser users, etc. Visually inpage links go to the target element, but if you try to tab further down the page, it starts from the top. The solution to this particular IE problem? Use a target Link. Named anchors don't work, and even using an id only tabs properly in IE if it goes to a link, like so...
Using <a href="#contactUs"> will now link to the proper target anchor and IE tabs forward from the target link instead of the top of the page.
Well, I swear it worked at the time. However, while IE and FF will both tab to an ID, IE still won't tab further but goes back to the top of the page (whether you use a link or not). So we went to inserting an explicit tab index of zero, 0, for the target attribute. This makes IE work beautifully but now FF refuses to respond to the link at all.
[chroniclemaster1, 07/08/26]
Skip to Main PointsAnchored Keyboard Navigation Demos
I'm specifically looking at trying to get several things functional. In the first place, I want to link to my contact form image. Any "Contact Us!" link should go the the contact form on the page and I want to make sure the image is visible, so I want to link to it. I've included images in each of these demos. I also want the inpage links from the main points box to go to the headings of each section so headings are included too. Finally, div tags are a great universal tool for isolating any cluster of related content. Being so generic they are quite common and easy to apply, so I'm also including them in these trials.
Using named anchors <a name="myName">
The standard way to set up inpage navigation is with named anchors. So I've set up a sample of the accepted methodology for reference. A named anchor takes the form <a name="myName">. The standard way to link to a named anchor is using the link syntax <a href="#myName">. Unless otherwise specified <a href="#myName"> is the syntax used to link in every example in this demonstration page.
This is my heading.
Mouse Results: In IE the links work marvelously when you click them. Unexpectedly, there is a problem with FF; when you click the heading link it jumps to the image. I've no idea why. This may be a random error and we'll see if it persists. One of the problems with this issue is that it is not completely stable; it does not display the same behavior every time. I would like a solution that is stable and that may be the most difficult condition of all to fill.
Keyboard Results: When using keyboard navigation only, FF displays the same behavior; everything works fine except that the heading link goes to the image. IE works beautifully at first. However, as soon as you strike the tab key it becomes obvious that the browser does not really know what it is. You tab to the first tab point of the document, in this case the first link on the page. Resolving this issue is the entire reason for the existence of the demonstrations on this page.
Using anchors with ids <a id="myId">
Next we try to alter the syntax. We continue to use the anchors but use a lone id this time. This is not a valid format, but this is a test. For validity an anchor, <a>, requires either a name or an href attribute. There is also the desire for efficiency in code, and ids are much more usable than names. Names are also being phased out in favor of the id attribute.
This is my heading.
Mouse Results: In IE the links work marvelously when you click them. The same problem occurs with FF; when you click the heading link it jumps to the image. Everything else works perfectly.
Keyboard Results: When using keyboard navigation only, FF and IE display the same behavior as when using the mouse, including that once again you can't tab properly after activating an inpage link. This behavior is also identical to when we used named anchors so at the very least <a name="myName"> and <a id="myId"> seem syntactically equivalent even though name is supposed to be present.
Using named anchors with an id <a name="myName" id="myId">
- Link to the named anchor image with an id
- Link to the named anchor heading with an id
- Link to the named anchor div with an id
This time, we combine the syntax. We try to use both the name and id attributes for the anchors. This is a valid version of the <a> with id format. The links are directed to the names, not the ids.
This is my heading.
Mouse Results: In IE the links beautifully for the mouse. FF links to the image when you click the heading. Everything else works perfectly.
Keyboard Results: IE performs links to the target anchor, but goes to the top of the page if you press tab. FF tabs like you'd expect from the mouse results. Using the heading link skips to the image. Everything else works great.
Using named anchors linking to ids <a name="myName" id="myId">
- Link to the named anchor image id
- Link to the named anchor heading id
- Link to the named anchor div id
This time we use both the name and id attributes but directed to the links to the ids, not the name.
This is my heading.
Mouse Results: In IE the links work marvelously when you click them. Clicking the heading link goes to the image in FF as in the previous examples. Everything else works perfectly.
Keyboard Results: IE performs as we've sadly become accustomed, links to the spot perfectly, but then moves to the top of the page if you press tab. FF performs identically to what we've come to expect. Using the heading link skips to the image. Everything else works great.
Using named anchors with a tab index <a name="myName" tabindex="0">
- Link to the tab indexed anchor image with name
- Link to the tab indexed anchor heading with name
- Link to the tab indexed anchor div with name
This time, we go back to the named anchor but adding a tabindex of zero. This technique was put forward by Gez Lemon. The tabindex inserts the named anchor into the tab order explicitly.
This is my heading.
Mouse Results: In IE the links work marvelously when you click them. Clicking the heading links to the image in FF, but everything else works perfectly.
Keyboard Results: FF operates as normal linking to the image when you hit return on the heading link, but otherwise works. IE works great! It tabs forward from the named anchor when the tab index is added. This is a valid solution, though it does involve using an anchor. It will be interesting to test this idea without one.
Using tab indexed anchors with ids <a id="myId" tabindex="0">
- Link to the tab indexed anchor image with id
- Link to the tab indexed anchor heading with id
- Link to the tab indexed anchor div with id
This is a variation on Gez Lemon's technique using id instead of the name attribute. The tabindex inserts the anchor into the tab order explicitly.
This is my heading.
Mouse Results: In IE the links work marvelously when you click them. Clicking the heading links to the image in FF, but everything else works perfectly.
Keyboard Results: FF operates as normal linking to the image when you hit return on the heading link, but otherwise works. IE works beautifully! It tabs forward from the anchor once the tab index is added. This is technically an invalid solution, because it does not include a name or an href attribute in the target anchor.
Skip to Main PointsAnchored Keyboard Navigation Conclusion
Firefox displayed some unexpected instability, linking to the image when the heading link was clicked. I expect that there is some browser quirk that we ran afoul of, but this is not as stable a solution as I expected. Named anchors are the standard way to link to a location on a webpage, it is curious we should have such a notable problem using them. However, there seems to be no alternative to it. We were able to find a pair of solutions that fixed the tab problem in IE, although linking to an id violates valid code. Anchors require either an href or a name attribute. So the best solution is...
This is a variation on Gez Lemon's solution. He felt that inserting the anchors into the tab order was unacceptable. However, to fix this problem he set the tabindex to negative one, and that raised problems he could only solve with Javascript. Living with anchors in the tab order seems far preferable to using a solution that depends on Javascript. Anything important enough to receive an inpage link seems appropriately important to be part of the tab order. It does create a double listing in Opera which maintains separate links and headings. However, this seems like a small element of confusion compared to resolving a major Internet Explorer keyboard navigation bug. As always, the syntax to link to the element id is...
I look forward to testing anchorless inpage navigation. It will be interesting to see if something equally effective can be found. In principle, it's more efficient to eliminate the anchor tag and link directly to the element itself. There are some instances where this works, and it will be interesting to see how stable it is. From a practical stand point, it's also easier, since a key element which serves as the target for an inpage link will frequently already have the target attributes for completely separate reasons.
Skip to Main Points