Inspired by a discussion over at HTML5 Boilerplate, I want to lift the accessibility issue of providing a mechanism to bypass blocks of content to another level.

One of the sufficient techniques provided within WCAG 2.0 to meet the requirement is the so-called skip link. Contrary to popular belief, this is not the only valid technique to meet the requirements. 

You can simply use ARIA landmarks to identify regions of a page to meet the same requirement, or provide headings at the beginning of each content section.

However, the skip link provides a solution that the other techniques don't: a way for keyboard-only users without a screen reader to skip to the main content of a page.

The skip link doesn't come without caveats though. WebAIM wrote the following about the concept a while ago:

The truth is that "skip navigation" links are a rather clumsy and obtrusive solution to a real world problem. They work. They're useful, but they're a bit of a hack. They will continue to be useful until a more standardized method of designating the difference between navigation and main content evolves and is fully supported.

The reason the pattern is a "hack" is the following issues:

Are we solving a problem, or creating a solution that makes us feel like we're solving it? This sounds familiar.

Remember the font size widget?

One of the accessibility patterns that had its peak during the days of Internet Explorer 6 was a widget to change the font size on a web page.

(A notable modern example is the London 2012 web site, which also has an equally problematic contrast widget…)

The idea behind this was to give users a way to increase the font size to make it more legible for them, in case they didn't know how to do so in their browser.

This pattern is on its way to becoming extinct because it was attempting to solve a problem that was already solved natively by browsers.

Every web site that implemented this pattern did it differently, with a different design, placement and/or functionality, violating a primary accessibility tenet: consistency.

Instead of a different way to size text on every site, the user should always have been setting this globally in their browser settings, or using the browser's built-in features for resizing the text – which works the same for any web page! 


So how are skip links any different? We're back to implementing custom controls on web pages that should be solved at the user interface level.

Elle Waters at Simply Accessible summarized five reasons to leave text resizing widgets in the historical dustbin; don't most of them apply to skip links?

Another frustrating battle

Let's revisit what WebAIM wrote about the problem with navigating to the main content of a web page:

With ARIA landmarks and the HTML5 <main> element, this is closer to becoming a reality. Unfortunately, no browsers yet fully support keyboard navigation via these elements. 

We were blessed with the main element in HTML5. Alternately, we have the ARIA role "main" in case we want to place it somewhere else in the document. Yet they're not being used to their full potential.

Screen readers can navigate via landmarks/roles or headings to find the main content – why isn't there a keyboard shortcut implemented by browsers to do the same thing?

With the text resizing widget, the reality was that lots of users didn't know how to resize the text with their browser – but most if not all users didn't use or understand the widgets implemented on web sites, either!

Skip links are the same battle.

The user doesn't know they're there, until they randomly might see it. Does this sound like a winning usability pattern?

Are we still not done creating custom controls on every site to accomplish basic browsing tasks that should be solved by the user's interface?

We might as well implement our own "back" buttons. (I'm going to pretend that no one still does that…)

Save us, browser vendors! Give keyboard-only users a shortcut to navigate directly to the main content on the page!

We already have the solution: <main>.