The shelf life of a skip link

Most things have a shelf life and technology on the web is no different. Tricks and hacks that once seemed to save the day sometimes need to be retired as newer technologies or techniques get implemented.

I can think of plenty of accessibility solutions that have found their way into the archives such as using an asterisk (*) for a bullet image, text versions of websites and verbose title text around links – to mention just a few.

So what about the skip link? Firstly Gez Lemon describes Skip links as follows:

Skip links are links to another part of the page that allow visitors to navigate their way around a web document, without having to cycle through a huge list of links.

Ability Net's skip link

On todays web skip links are a good thing. They’ve played their part in improving the usability of the web for users with disabilities and mobile devices. Screen readers, voice input software, keyboard only users and those browsing on mobile devices all benefit.

Skip links are becoming increasingly mainstream despite them not being an explicit requirement of WCAG 1.0, the defacto standard up until December 2008. Much of what was implied in WCAG 1.0 however has become explicit in 2.0 and the skip link finds itself as a sufficient technique in for Success Criteria 2.4.1: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages securing itself a place in Level A no less.

So why am I suggesting – given the skip link’s new found status –  that they may have a shelf life? Well here goes…

Document structure

Having a well constructed document that marks up headings, paragraphs and lists, and has well written and grouped links already goes a long way to supporting the user orientate and navigate within a page.

Access technologies such as voice input and screen readers hook into these so that users can use keyboard commands to jump from heading to heading, paragraph to paragraph and so on. Having these in place means users are not forced to tab laboriously through numerous page elements but instead  “scan” a page in much the same way a sighted user can.

Shift F7 lists headings for a Jaws screen reader users that can be navigated using the arrow and enter keys.

Of course this is nothing new. There has always been a question mark over the need for skip links when your documents are well constructed but what has changed is that there is a larger critical mass of websites now following web standards than before – ever the optimist – be it through a desire to be accessible, searchable or findable.

HTML5 elements

HTML5 introduces new elements designed, in part, to replace the divs in HTML4. These include header, nav, section, article, aside, and footer. This immediately gives pages a structure by identifying content areas within a page.

Image courtesy of A List Apart - An introduction to HTML 5 by Lachlan Hunt

Image courtesy of A List Apart - An introduction to HTML 5 by Lachlan Hunt

The idea is that a screen reader can inform the user of where they are in the page as well as provide a means for the user to jump to sections, much like you can jump between headings with a screen reader. For example I might want to read each blog post on the home page of this blog by jumping from section to section then jump to an aside to browse through the categories or recommended links.

This doesn’t mean that heading levels (h1 to h6) become redundant but rather they are now presented within related container blocks. Using the new elements may well also impact how you structure your headings and put to rest ongoing debates about repeated h1’s in a page and using the website name as the h1.

What will be particularly useful on complex, content heavy sites is that you wont need hacks such as hidden headings for content that is otherwise visually obvious. For example many sites will code a hidden heading at the top of sub navigation, such as “Sub-navigation”, in order to orientate a screen reader user.

Another example of “too much accessibility thank you very much” is when developers get a little over eager with skip links and add in what seems like a whole new set of navigation such as “Skip to main content”, “Skip to sub navigation”, “Skip to search”, “Skip to footer” and so on.

You really don’t need more than “Skip to main content” and possibly “Skip to sub-navigation”. A “Skip to search link” is especially redundant as users can do a search for it by looking for the text “search” or using keyboard shortcuts. Adding these new HTML5 elements should remove the temptation to overdo skip links which can add to the complexity of site navigation as well as reduce the number of headings used in a page.

You can start using these new HTML5 elements now in your markup as most browsers are able to handle them however what level of support is being built into screen readers for new elements and attributes in HTML5 is hazy. The vendors are not participating in the HTML5 Working group despite repeated invitations from the web developer community. That said, while the specification wont be finished until 2022 you can start using HTML5 now.

WAI-ARIA landmark roles

Just as HTML5 introduces section elements so WAI-ARIA introduces landmark roles. Landmark roles allow screen reader users to orientate themselves in a page by informing them if they are in the article, banner, complementary, contentinfo, navigation, main or search. You can read more about this in Gez Lemon’s excellent article Introducing WAI-ARIA.

A web page with landmark roles displayed

Landmark roles are intended to allow screen reader users to orientate and navigate around the page thereby doing away with the need for skip links. Questions have been asked about how adding both landmark roles and HTML5 section elements may work together with Steve Faulkner recommending that landmark roles be used now and removed once support for HTML5 becomes more robust.

The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority of of cases there is no equivalent for the ARIA landmark roles in HTML5. It is suggested that where there is a similarity the ARIA roles can be used to provide semantic identification that has a practical use now, for example if you want to use the HTML5 nav element, add role="navigation" to it, so supporting Assistive Technology (AT) can convey the semantic information to users. When HTML5 elements such as nav are supported by AT, you can then remove the role as it will no longer be required.

Current support for WAI-ARIA is shaping up with all browsers working on it as well as the main screen reader vendors. The specification is also likely to be completed 2009 and is becoming more and more mainstream.


Browsers are getting better and better at helping users access content. The Web Accessibility Initiative publishes guidance not just for content in the form of Web Content Accessibility Guidelines (WCAG) but also user agent developers in the from of the User Agent Accessibility Guidelines (UAAG). The relationship between UAAG and WCAG means that browser should offer options to help users navigate around the page via the browser and not just the content.

Opera – where I work – provide spatial navigation and single key shortcuts.  Spatial navigation allows you to use your Shift + arrow keys to go up, down, left or right within a page which gives much more flexibility than tabbing in a page in a linear fashion which is the main barrier that skip links address.  Single key shortcuts allow you to jump between headings, links, page elements as well as customise your shortcuts. Again allowing the user quick access to content areas within a page.

Opera Mobile and Mini also offer spatial navigation to make browsing easier. This is a huge improvement on the WAP style pages where you’re forced to navigate through the page linearly. In addition to this every numeric key (0-9) has a pre-programmed function that you can customise. Within this context skip links seem less necessary however they do still have a huge benefit on WAP style pages.

Knowing enhancements such as spatial navigation and single key shortcuts are available in desktop and mobile browsers decreases the need for skip links however this does assume that all users know how to use their browser and many do not. While that is not your problem as a developer it equally can’t be ignored and I don’t think can be considered a full alternative just yet.

That aside it would be interesting to review the browsers and versions that you support and see what the baseline of navigational aids there are in the browsers and assess whether skip links are indeed necessary.

So is that it for skip links?

No, not yet. If you have skip links there’s no reason to remove them. Adding enhancements are never a bad thing and skip links are unobtrusive when implemented properly. It is however worth reviewing your content to ensure you have a logical document structure that can be read by access technology: good headings, lists, well worded links and so on. My personal take is that on a simple site such as this blog this is sufficient, on a more complex site you still may want to implement skip links. Opinion however, will always be divided so you need to think what suits your site best.

Adding in WAI-ARIA landmark roles and HTML5 can do no harm at this point but can’t be relied on in full. Apart from anything else – browser and access technology support – there is a learning curve with any new technology on the web that the user has to go through. We can’t assume that screen reader users will immediately be familiar with the benefits that HTML5 and WAI-ARIA bring, as with navigating Flash when it became more accessible users had to become comfortable with it.

So has the skip link passed it’s best before date? No. Does it have a shelf life? Yes, I think it does. Keep your document structure logical and gradually implement WAI-ARIA and HTML5 and you may just find skip links become redundant.

14 thoughts on “The shelf life of a skip link

  1. I don’t understand why there isn’t an HTML 5 element called “content” that you wrap the main content in. (You can mark up secondary stuff like nav, footer, etc but not the main meat of the page).

    Then browsers could have a key that jumps straight to the main content and skip links would be completely redundant.

  2. Skip links considered a temporary hack: Agreed.

    However, the time to loose them is not quite yet in Sweden. JAWS is ruling the market almost like a monopoly, and Swedish versions always lags behind teh English a year or two…

  3. Hey Lars, I don’t think it’s time to lose them just yet here in the UK either, especially just when they are becoming more mainstream.

    The good news is that they’re backwards compatible so as better nav mechanisms are introduced with WAR-ARIA and HTML5 we wont have any clashes.

  4. I’m not sure where this fits in, but to my understanding the XHTML Access module provides a standardized method to add skip links as well. Alas the last call standard is very vague what exactly it is good for (enables a more robust accessibility model – why and to what extent?), and since it is an XHTML 2 extension while all the cool people focus on HTML 5, it is little known and feedback on browser or screenreader support is missing.

  5. Excellent summary Henny! Thanks for sharing your research on skip links.

    Sound advise to continue using skip links, while incorporating the ARIA roles and HTML 5 elements into our markup as we wait for the expected support from assistive technology.

    I know a lot of web workers who haven’t explored learning about WAI-ARIA roles or HTML 5, and will direct them to this article.

  6. Awesome summary of ALL of the issues. In my opinion, if browsers (except Opera) would have implemented and followed the User Agent Accessibility Guidelines a few years ago and provided more robust keyboard navigation natively, then “skip” links could have gone away before they were ever considered mainstream.

    The issue is centrally around sighted keyboard-only users. If we only had to worry about screen reader users, it would be prime time to have “skip” links go away.

  7. Bruce, having a special content element would be unnecessary. In general, the main content of a page is typically made up of one or more sections or articles, and being able to access each of those individually is more useful than being able to jump to a main content container that contains them all. So jumping to the first such article or section after the header and nav would be effectively the same as jumping to the main content.

  8. Lachy, the first section after the header might be the content, if the nav is on the right.

    I guess you mean the first block level element after the header that’s not a nav element (as the main content won’t necessarily be inside a section or article element)?

  9. Very nice article.

    I agree with you that it is not time yet to throw those skip links away, but they have created lot’s of unnecessary frustration. Skip links are not my favorite way of getting the user to the main content, and I’m happier to use something else. However, when it comes to Section 508, it is not that easy not to implement them at this point.

    While Section 508 does not specifically require a skip navigation link, I know that many government agencies use it as a minimum requirement. So, I cannot just tell my client to use a different method if that pleases them, because they will have a hard time selling it to the government agency. And in all honesty, sometimes it is easier to give the whole agency a cooke cutter solution and implement it as an agency standard. Especially, if they already use skipnav links but hide them, to benefit screen reader users only. But that’s another fight, if a solution should benefit all people who need it, or only a select few.

    The other problem I was facing around the skipnav links was that many of the more accessible content management systems did not support them, or it was quite a procedure to set it up. It could have been much easier to say that there is really a great way to skip to the content without the skipnav link.

  10. So it looks like we’re all thinking along similar lines which is interesting. This is really making me think about spec development (particularly HTML5) and how we can develop it so we can do away with as many of these hacks as possible. The less people have to learn about accessibility because it is reinforced in the spec the better. Nothing new there I guess…

    Martin, thanks for pointing out your post on the XHTML Access module. I’d not thought about this and will do some digging. Good post BTW.

  11. Hi Heni, I Just wanted to chirp in and say I’m with Bruce on the main content identifier. I’m not up on HTML5, but it certainly seems to make sense to be able to identify the start of the main content it explicitly and seems a bit strange to me that this isn’t already the case.

    I think skip to content will be with us for a good while yet as there are many, many, things that need to happen before they become redundant.

  12. Hi Grant, I’m with you on the main content identifier too. It’ll be interesting to see how HTML5 and it’s development pans out and how it affect skip links. It will take a long time for them to become redundant (if at all) especially as they are becoming increasingly common on sites. That said I’m looking forward to HTML itself having a solution to help page navigability without these additional hacks. It will hopefully mean that better accessibility even if the developer is less aware.

    Let’s hope anyway!

  13. Hi Heni

    Excellent read, though a bit dispirited by this snippet:

    “That said, while the specification wont be finished until 2022 you can start using HTML5 now.”
    That must rival WCAG 2.0 for gestation periods…

  14. Paul, don’t be dispirited, in fact the emphasis on that sentence is on the “ can start using HTML5 now”.
    Yes the spec is evolving and changing and yes they are yet to write all the test cases necessary but this doesn’t mean that HTML5 can’t be touched until all this work is 100% complete.
    Many people are using HTML5 now (see and are troubleshooting their way using it (see

    HTML5 is commonly referred to as ‘paving the cowpathes” and if we want to draw parallels to WCAG 2.0 I’d say that much of what went into WCAG 2.0 was what responsible developers were already doing to make their sites accessible.
    So don;t feel you cant start working with it now, in fact now is a great time to get started so you can get familiar with what’s happening and how to advance your own websites.

Comments are closed.