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 – you can read more about that here: The search for the perfect skip link (on the old Communis blog) 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…
- 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
- 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?
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!
More examples and tutorials
Want more from Refined Practice?
For all the latest updates, follow us on Twitter:
Or like us on Facebook: