Your skip links are broken

Many websites have an accessibility feature called skip links that help some users navigate the site. However, there’s a problem with basically all skip links on mobile devices, which hurts your site’s accessibility instead of improving it.

Button with text "Skip to content" broken in two pieces.

Skip links are a common accessibility feature on websites. They are simply shortcuts to important parts of the webpage that makes it easier and quicker for some users – especially users with disabilities – to find their way around.

Skip links are usually hidden visually by default and appear when users navigate to them using the tab key on their keyboard. “Who would ever use a keyboard to navigate?” you may ask yourself. Well, lots of people actually! For instance many users with motor or sight impairments will rely on keyboard navigation. But more on the use cases under the next heading.

If you want to try out a skip link using your laptop, go to Starbuck’s website and press the tab key after you have entered the site.

Here’s an attempt at illustrating what happens. 

Starbucks page with and without skip link showing. Press of tab key necessary.

So when you “tab into” the site the skip link appears, and you can activate it with the Enter key to skip to where it points. On Starbuck’s site you can (in theory) skip to either the main navigation, content or footer.

Skip links work well on desktop. Here’s a short video where I’m using them on a few sites with the VoiceOver screen reader on Mac. It might be a bit difficult to follow along if you’re unused to hearing a screen reader in action, and to make things worse mine switches between Swedish and English. But the important thing to notice is how the focus indicator jumps into the content area after I press the skip links:

Skip links are great when they work, and this type of functionality is recommended in the Web Content Accessibility Guidelines (WCAG):

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

– WCAG 2.1

Skip links are mainly used by:

  • Users with motor impairments who navigate with a keyboard instead of a mouse.
  • Users with motor impairments who navigate with switches.
  • Users with severe visual impairments who use screen readers on desktop or mobile devices.
  • Users with low vision who use screen magnification software in combination with keyboard navigation.

Instead of having to spend time tabbing through the logotype, links in the header, menu, etcetera, on each page you visit, skip links provide a handy shortcut to jump straight to what you’re after.

They’re also quite popular among users. In the latest Web AIM screen reader user survey – which almost 1800 people responded to – over 30% said they always or often use skip links when they are present.

We’ve seen in user tests that skip links are even more used by novice screen reader users. Tech savvy users tend to use shortcuts on their keyboard or special gestures to skip between different parts of the page. But less “techy” users are not always aware of those features, and will instead often use the skip link to find their way to the main content.

Update april 2020

The problems we describe below have been fixed by many (all?) of the browsers/assistive tech/operating systems. So skip links seem to work as intended in most devices right now.

The problem

We became aware of a major issue with skip links after seeing it in two user tests a few months apart, where two different screen reader users struggled with the same type of problem on two different websites.

One of our clients was kind enough to let us share a video clip from their user test in this article. So thanks, Council of the European Union, for that ❤️. The user in the test has also given us her consent to spread this video.

So take a look at this clip (sorry for the blurry start), then we’ll tear apart exactly what’s happening.

So in the clip we see a screen reader user trying to use the skip link with her iPhone. This is what happens:

  1. She activates the skip link.
  2. The page scrolls down visually – which she and other blind user will not be helped by.
  3. She swipes right to go to the next object – you can think of it like pressing the tab key on a desktop.
  4. The screen reader puts focus on the cookie message, not the main content.
  5. She naturally gets quite confused and annoyed.

We started investigating the problem and found the same issue on every single skip link we tested. You can try it yourself if you know how to use the screen reader on your smartphone at these sites:

Or just check out this video where we try to use skip links with VoiceOver on an iPhone on the sites above. You’ll see the sites scrolling, but as soon as we swipe the screen to go to the next item, we’re back at the top of the page.

Skip links are almost always constructed in the same way. They are simply anchor links pointing to a part of the page.

Something like this:


<a href="#skip-here">Skip to main content</a>

//Menu and other stuff users might want to skip..

<main id="skip-here">...</main>

For some reason, these simple anchor links don’t work as intended on iOS. We tried in Safari, Firefox and Chrome – all have the same issue.

To be clear, this problem exist on mobile when the user navigates by swiping to go from one object to the next. There is another way of navigating (explore by touch – moving your finger over objects on the screen), and then it works fine on iOS. 

Affects Android as well, but in a different way

Regular skip links don’t work with VoiceOver on iOS as shown above. Sadly they don’t work with Android’s screen reader TalkBack either, but this time it’s not the anchor link that’s causing the problems.

In Talkback, skip links don’t even show up when the screen reader focuses on them. Here’s a video where you’ll hear the skip link being announced, but it’s not showing on the screen like in iOS. We try to activate the link when it’s announced, but nothing happens.

This is caused by a bug in Android that stops the focus event from being triggered. It’s probably easiest to understand if you look at this video comparing what happens when tabbing on desktop, using VoiceOver on iOS and using TalkBack on Android. You’ll see that when tabbing on desktop or using an iOS screen reader, the focused links turn orange. On Android, you never see the orange focus style.

For some reason, Android doesn’t trigger the CSS focus event with TalkBack. This is the reason skip links never show up visually on Android, since they are programmed to show up when they receive focus. This is a bug reported to Google, so hopefully they’ll fix it soon.

But shouldn’t it still be possible to use the link, even though it’s visually hidden? Sadly, that’s not possible. If you click on a hidden link with TalkBack, the link will not be activated. So, we guess that Google will need to fix this focus issue before skip links will work at all on Android.

Interesting enough, some Android phones have a version of TalkBack called VoiceAssistant. With VoiceAssistant, skip links work exactly as intended!

What can you do?

Solving this bug is mostly up to browser and screen reader vendors. So we hope you’re listening Google, Apple, Mozilla and the rest.

But there are some things you as a site owner can do while we wait for a more robust solution.

We created and played around with this codepen where you can test skip links that reference different types of elements like headings, &lt;main&gt; ,&lt;div&gt;, and more. We found cases where including the attribute tabindex="-1" on the element you reference would solve the issue, but unfortunately only for iOS users. Here’s how:


<a href="#skip-here">Skip to main content</a>

//Menu and other stuff users might want to skip
...
<main id="skip-here" tabindex="-1">...</main>

So simply adding tabindex="-1" to the element you’re skip link points to is the best solution we can offer at the moment. It won’t make your skip links work for all your screen reader users, but at least you’ll have catered the needs of the majority of them.

See update 3 below for problems with this solution and other, better ways to solve this

Update 1 – a better solution!

A lot of clever people read our articles, and it turns out that there’s an even better solution. Paul J. Adam (@pauljadam) uses javascript to move focus to the first heading. Like this with jQuery:


$('#skip-link').click(function(e) {
e.preventDefault();
$(':header:first').attr('tabindex', '-1').focus();
});

It works splendidly! Check it out on Paul’s website.

Update 2 – Vanilla javascript solution

Ben Buchanan made a regular “vanilla” javascript solution from Paul Adam’s solution above, since many people don’t use jQuery. And he was also kind enough to share it with us and the world, so here it is:

Codepen – Working skip links using vanilla JS

Mike Foskett also made a really nice Codepen:

Mike Foskett’s skip links codepen

Update 3 – A comment from gov.uk

Anika Henke e-mailed us some great input:

I’m a developer working in the accessibility team at GDS (the people behind gov.uk).

I was made aware of your article about skip links and that it mentions gov.uk.

We investigated the very same issue on gov.uk last year and I created a bug report for the iOS issue as it’s clearly a browser or screen reader bug.

Your suggested solution introduces worse barriers, though. See our Pull Request about removing tabindex from main to understand why. To quote:

“When clicking anywhere in the page focus will return back to the top. Consider a user interacting with an input field who clicks away from it to remove the focus style. Should they then hit tab they will be taken to the top of the page.”

The JavaScript solutions are a bit better because they focus on a smaller element. But it is too specific. It is dependent on certain elements or IDs being present.

Since ages I’ve been using a better fix in my personal projects which fixes all in-pages links, not just skip links, and removes the tabindex the moment the focus moves away.

Thanks for that great input Anika!

Get notified when we write new stuff

About once a month we write an article about accessibility or usability, that's just as awesome as this one! #HumbleBrag

Simply drop your email below.

We work world wide, if you need help send us an email!
hello@axesslab.com