Skip links: Chrome, Safari and Added WAI-ARIA

Posted on June 2, 2009 by Paul Ratcliffe

This article was written in 2009. For up-to-date advice on skip links please refer to the latest article on our [RPress] site.

Skip links are a way to allow a keyboard user to get to the main content on a web page quickly, without having to read through or tab through a whole bunch of menu items every time that they load that page. Given current technology, they are a level A requirement of WCAG v2 (Success Criterion 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages).

Creating a skiplink that works across a number of browsers and is actually usable to the end user is not a simple task as outlined in [The search for the perfect skip link on the old Communis blog is sadly no longer available] and Skip links: the saga continues. Spurred on by new functionality in some later browsers, the launch of Google’s Chrome browser and some feedback we had regarding using skip links on a Mac, we thought we would re-examine skiplinks and present you with our latest thoughts.

The impatient amongst you can go and look at the example skip link code straight away. Those who want a bit more background, read on…

The requirements

Skip links need to be ‘visible’ to all keyboard users (not just screenreader users) (see )
Skip links should not confuse a fully sighted mouse user
Skip links need to provide enough information to the keyboard user to explain what they do
The skip link needs to work on a wide a range of current browsers as possible

Some issues

WebKit browsers (Safari and Chrome) deal with page fragments in a very odd way. If you follow an in-page link on one of the browsers (one that ends in #somethingorother) the viewport of the browser moves, but the keyboard focus doesn’t
Earlier versions of Internet Explorer will only move the keyboard focus is certain circumstances (to do with hasLayout), otherwise it behaves in a manner similar to WebKit.
Making the skiplink visible to keyboard users but hidden from mouse users can be difficult to acheive cross-browser

So what did we do?

Our latest version of the skip link code targets WebKit browsers using javascript (not ideal, but the best solution currently available) and uses a specific combination of HTML and CSS to ensure that it works for Internet Explorer 5.5, 6 and 7. IE 8 thankfully seems to be a bit more sensible than its predecessors and behaves somewhat more like a proper browser.

The result can be found on the example skip link code page – take a look and let us know what you think!

A word about WAI-ARIA

WAI-ARIA is an upcoming standard that specifies a bunch of ways to make rich internet content accessible. Part of the standard defines something called Landmark Roles, and although this is only a draft support for this is already implemented in a number of modern browsers. Landmark roles provide a way of marking what each part of your webpage is about (e.g. which bit is main content, which bit is navigation, which bit is complementary content, etc.). The Pacielleo Group has a great blog post on landmark roles that explains what they are and how they work. Where supported (e.g. in the screenreader JAWS 10), these roles provide a fantastic way of navigating around the page, far superior to using skip links. Hence we now recommend that WAI-ARIA roles are implemented on your page as well as skip links, to provide the best possible experience for as many users as possible. And before you tell us, we know they don’t validate, but in line with WCAG 2 we take a flexible view on such matters… (see Success Criterion 4.1.1: Parsing)

Anyway, that’s enough waffle from us. If you haven’t got bored and gone there already then head on over to the example skip link code page and have a look. Post any comments back here, we’d love to hear from you!

11 thoughts on “Skip links: Chrome, Safari and Added WAI-ARIA”

Liam McGee says:

June 2, 2009 at 2:32 pm

Note that by allowing a mechanism for meeting WCAG2.0 success criterion 2.4.1 [Bypass Blocks] in Chrome and Safari, it stops WCAG2.0 being impossible to implement for that SC… which is a relief 🙂

It does bring up an interesting question – if a browser simply doesn’t support an accessibility feature required in the WCAG 2 guidelines… does this make it impossible to pass? Or does a conformance claim need to reference the browsers for which it is known to conform? Hmmm.

Reply
Wayne Dick says:

June 2, 2009 at 7:20 pm

A naive question.

Why are skip links necessary? The page can satisfy SC 2.4.1 using headers and other grouping elements. See, How To Meet 2.4.1 in Understanding WCAG 2.0. The second sufficient technique gives 4 alternative ways to meet 2.4.1 and none require skip links.

Why use a JavaScript work-around when there are perfectly fine HTML elements that require no WAI-ARIA for interpretation?

I am really interested in an answer to this because, I’m curious why developers are so committed to skip links when visually impaired users have effective element navigation available? Most users with visual impairments that I know, including myself, prefer element navigation.

Reply
1. Paul Ratcliffe says:
  
  June 2, 2009 at 8:20 pm
  
  There is a great discussion on the need (or not) for skip links on Iheni’s blog at http://www.iheni.com/the-shelf-life-of-a-skip-link/. In short, our feelings here at Communis pretty much match those of Iheni. Skip links provide an extra level of usability for certain user groups – especially keyboard only users without visual impairments who often aren’t using a browser/assistive tech that offers element navigation. As browsers and the web evolve (especially with WAI-ARIA and HTML 5) the skip link will eventually become redundant, but skip links fill a gap in the meantime.
  
  Re: use of the javascript work around. This was born out of a desire to make the skip link work on WebKit browsers (no javascript necessary for the others tested) as it would be frustrating for a WebKit user to see a skip link but not be able to use it. The choice seemed to be either use CSS hacks or javascript to hide the skip link from these users or make it work for them, so we went for making it work!
  
  Reply
2. Liam McGee says:
  
  June 3, 2009 at 12:05 pm
  
  Hi Wayne – I agree that effective use of heading mark-up combined with use of element navigation in e.g. JAWS removes the need for skip links for some screen-reader users.
  
  However, in our experience of testing users with disabilities, many screen reader users simply do not use the full range of facilities that their software places at their disposal. ‘Power users’ have several navigational strategies they will throw at a page, but less confident users do not – I have watched too many users patiently (and impatiently) sit through yet another repetition of a long list of navigation link – and seen too many praise a site to the skies for implementing a skip link – to feel that they are redundant yet. As a skip link adds greatly to the usability for less confident users, and does not detract from usability for power users, we feel that skip links – well implemented – is the best practice.
  
  Note that the technique does not require any WAI-ARIA techniques (we put ARIA roles in for the sake of perfection).
  
  For sighted, non-mouse users, skip links are a real boon, as Paul mentions in the earlier reply.
  
  Reply
Shelagh says:

June 8, 2009 at 3:01 pm

Thank you for this post. May I ask a couple of questions please?

Is there any way to use the javascript in Opera also?

I have read many articles that explain how to make skip links work for keyboard users, but none of the methods work for me except in Firefox and IE. I’ve started to think I’m going mad and that internal links work in these browsers for other people! Am I really going mad, or is there genuinely no html/css way to make internal links work outside FF/IE? If that is the case, how come nobody else seems to be aware of the issue?

Reply
1. Paul Ratcliffe says:
  
  June 9, 2009 at 4:22 pm
  
  Good point on Opera! Opera has a great set of keyboard shortcuts that effectively make skip links redundant (take a look at http://www.opera.com/browser/tutorials/nomouse/). Our old approach was to make the skip link invisible to Opera. However, this relied on CSS hacks, which can lead to problems when new versions of browsers are released. This new method makes the skip link visible to all browsers, so I’ve tweaked the javascript on the demo so that should an Opera user want to use the skip link it works for them (provided javascript is enabled).
  
  In general, you are right though – of the current ‘big 5’ browsers (IE,FF,Chrome,Safari,Opera) internal links only work in IE and FF unless you augment it with javascript like we have in our example.
  
  Hope this helps, Shelagh!
  
  Reply
  1. Shelagh says:
    
    June 11, 2009 at 11:30 am
    
    Indeed it does, thank you. I was also wondering why you have enabled the javascript for Opera, Safari and Chrome, instead of for “anything that isn’t IE or Firefox”. Are there situations where the javascript might cause a problem?
    
    Reply
    1. Paul Ratcliffe says:
      
      June 17, 2009 at 9:09 am
      
      We like to design using straight (X)HTML and CSS where possible, and only use javascript when it is the only way to achieve something. So, we’ve only enabled the javascript for those browsers where we know that the HTML/CSS approach doesn’t work.
      
      Reply
Robert M. V. Gaines says:

January 8, 2014 at 4:24 am

Two Questions:
1. Should the height/width of #skiplinkholder be set with inline CSS in case the user turns off external style sheets or substitute there own?

2. I have read that some screen readers ignore a target anchor unless it contains content. Does this not apply to your solution, or should #skiptarget surround some sort of content?

Thank you for your work!

Reply
1. Paul Ratcliffe says:
  
  January 8, 2014 at 3:55 pm
  
  Hi Robert, here’s our thinking on your questions:
  1) No, we always recommend using external stylesheets. As well as helping the designer to separate style from content, you can never tell exactly why a user has turned off external stylesheets (there are a number of accessibility reasons why they may have chosen to do so), so it’s best to honour that request completely if they have made it so they don’t suffer from any unexpected effects. E.g. you would not want to hinder someone from increasing the size of the skip link holder if they require a larger text size.
  2) Based on our testing at time of writing, this was the most effective way of managing the skip link and we haven’t come across any problems with the screen readers we’ve tested this on up until now. If you do find a system it doesn’t work on we’d love to know so that we can test and update the code.
  
  Reply
John Green says:

April 9, 2014 at 4:42 am

It appears that Chrome’s behavior has changed, now that it has switched from the Webkit to Blink rendering engine. Using the javascript as shown in the demo allows Chrome (which still reports “Webkit” as part of its User Agent string) to tab to the #skiptarget link, despite the desire to bypass this as it is not an actual link. Any suggestions?

Reply

The requirements

Some issues

So what did we do?

A word about WAI-ARIA

More examples and tutorials