Accessibility and Access Keys

Skip to Content

The search for the perfect skip link

18th August 2005

We are now fairly certain that we have the perfect skip link implementation, after much discussion and testing. There are several problems that may be found in skip link implementations.

The skip links themselves

Most problems here derive from the fact that many designers like to hide their skip links. Problematic implementations of this include:

  1. Hidden too well. Use of display: none or visibility: hidden, both of which hide the links from all users, including screen reader users.
  2. Completely non-visual implementation. Any method that doesn’t show the skip link itself when it has keyboard focus. Skip links are meant to be for keyboard users, both sighted and non-sighted. Hiding a skip link from all but screen reader users is therefore a no-no.
  3. CSS relative movement vertically. This is where a developer styles the skiplink with CSS such that it is moved upwards by a large number of pixels sufficient to take it off-screen, and move it back down when it receives keyboard focus (defined using :focus and :action pseudoclasses, the latter for IE) so that sighted keyboard users get the benefit. All very well, but some versions of Window Eyes just lose track of it completely. Stick to horizontal movement.
  4. NS7.1 crash. Combining absolute AND relative horizontal movement AND moving the link off-screen. This mysteriously crashes Netscape 7.1. Use any two of the three.

Hitting the Target

So that’s a few no-nos for the link itself, but the next set of hassles surround the target.

  1. Link targets with no content. Contentless anchor elements are ignored by JAWS and several other browsers and screenreaders. Still some aesthetic debate about whoat to put in the target anchor. A header? Yes, if there is a suitable one and you’re happy to style around confusions of coloring it as a link rather than text, and your fix of the IE focus bug (see below) allows it. A single pixel gif? Ick. OK, what about the text ‘Main content begins:’? Hmmm, rather redundant for a screenreader user who has just clicked a skip link of ’skip to main content’. This is a question best answered by user testing, I think.
  2. The IE keyboard focus bug. Nasty one this. If you are a regular keboard user with IE, you will have noticed that many in-page links will move the viewport, but the keyboard focus remains on the skiplink rather than moving to the target. This means that as soon as you press the tab key after skipping, you are popped back up the to the link that immediately follows the skip link. Deeply annoying. Jim solved it by using a target in a table. Not great mark-up, however, so we kept going. I realised that we could also fix the bug by putting the target in a div with an explicit, positive width or height (e.g. 100%, 1px, 20em but NOT auto or 0). This means that you can stick your target (e.g. the text ‘Main Page Content’) in a div with a width or 1px, a height of 1px, a float of right and an overflow of hidden, you have a target that works with pretty much everything (or, at least, everything we tested it on, which was a pretty good cross section of browsers and screen readers old and new). Terrence Wood suggested a formal explanation, that

    Using the keyboard IE6 will focus to the closest div or span element that is the parent of a target - either an element with an id, or a named anchor - where the div or span ‘hasLayout’ property is set to true. The div or span may itself contain the id being targeted. It appears that div and span are the only elements that receive focus via this method.

    Authors can set ‘hasLayout’ to true a number of ways (see MS’s
    documentation
    ). The most common method, used by CSS authors to clear floats, is to set the element height at 1%, or by setting the width to any value as already noted.

    As a final note, in IE6 with a strict DTD, width and height do not apply to inline elements. Thus, if you want to use a span instead of a div, make sure that it is displaying as a block either by setting the display explicitly to block or inline-block or by floating it left or right.

Thanks are due to Jim Thatcher, Terrence Wood, Steve Faulkner, Mike Cherim for valuable discussion and testing.

One Response to “The search for the perfect skip link”

  1. strottrot.com » Blog Archive » skip to content-ment Says:

    […] I did not realize that content-less anchor tags are “ignored by JAWS and several other browsers and screenreaders .” In this article, Communis mentions the difficulty in deciding what to put in the anchor (or rather put the anchor around, like some header). I looked at the W3C’s XHTML 1.0 specs and found a few interesting things: […]

Leave a Reply

You must be logged in to post a comment.