WCAG Bypass Blocks (Skip to content) – improve user interaction speed and even prevent pain

Number of words: 769.

(Loaded 2325 times)

Stumbled upon a e-commerce that required hundreds of key-presses to get below the navigation. Reminded me, again, about the importance of skip links…

Speed is important. How fast can we get (to) the information, how fast can we buy a product. It is the same for people with disabilities. Maybe even more important.

And sometimes speed actually prevents pain!

Some people can only use their devices with keyboard (or keyboard-like alternative devices).

They can reach interactive elements like buttons, links and form elements with pressing the Tab key and activate them by pressing Enter key (I am simplifying it, it’s a bit more complex, but it basically drills down to this).

Now – imagine an online store selling thousands of products, sorted by hundreds of categories. And imagine they have all these categories in their navigation (mega)menu. And a keyboard user needs to tab through each and every one of them before reaching the content on the page – because the navigation is at the top and content follows it.

I just found an example where I needed to press the tab key for 350 times to get pass navigation and to the content. The navigation was implemented in a way that I didn’t even see all the items that I needed to tab through. It was obvious that nobody thought of keyboard users and accessibility. Tabbing 350 times through all available categories and subcategories is extreme!

Here is the video to demonstrate it visually, the page is in Slovenian language, but that does not matter, what it matters is that keyboard user needs to press the tab key 350 times to reach to the content.

Now – imagine that every key-press (or similar interaction with other assistive technologies that emulate the keyboard) hurts a bit. This basically means that inaccessibility causes physical pain to some people.

And there is such a simple solution for this – “Skip to content” link, that is the first interactive element on a webpage, when we activate it the focus is moved under repetitive top elements on the page (basically skip the navigation and jump directly to the content).

Such “skip” links can save both time and pain for people. Give them the possibility for speed and quick way to reach the desired content. Give them freedom. They can still tab through the whole navigation if they want to. Sometimes they will go through it, especially if they are not familiar with the content. Sometimes they won’t. It’s about efficiency and freedom of choice.

All sites should have skip to content links. Even if you only have 4 items in navigation, before main content – you should have it.

It can be hidden until focused, or it can be visible at all times. But it should be there and it should work. On all pages!

Skip to content link implementation

Code-wise it can be just a anchor link to an id that is set on the main container (or main heading in main container,…), like this:

<header>
    <a href="#main">Skip to main content</a>
    <!-- other header items  -->
</header>

<nav>
    <!-- navigation -->
</nav>

<main id="main" tabindex="-1"><!-- crucial with id and tabindex! -->
    <!-- main content -->
</main>

<footer>
    <!-- footer content -->
</footer>

Things to keep in mind:

  1. Skip to content needs to be the first interactive element on the page. Best practice is that it is inside one of the landmarks (if header is the first one, then it should be in the header).
  2. It needs to be visible (at least on focus), it is not screen-reader users that benefit from it, so it needs to be seen to be used.
  3. It can point to main container or main heading (h1), if heading is the first item in the main container. Never forget to use correct id and add tabindex=”-1″ to this target. Only id is not enough for focus to actually move in all browsers and it will also not show where the new focus is, which can be very confusing…
  4. You can add multiple skip links if your page has a lot of links. But use them wisely, otherwise you are only adding more “Tab stops” and making it even worse.

Simple demo of anchor link with and without tabindex=”-1″

Just to make it more clear – please check out my simple demo of anchor links with and without tabindex=”-1″ on the target. The difference in most modern browsers is that focus is visible also on non-interactive targets when they use tabindex=”-1″.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me:

3 thoughts on “WCAG Bypass Blocks (Skip to content) – improve user interaction speed and even prevent pain”

  1. Can you expand on tabindex=”-1″? I have seen sites where almost every content element had this attribute, and didn’t understand why. I thought “overriding” tab behavior was generally not the right thing to do. Thank you!

    1. Thank you for your comment, Nora.

      Sure, happy to elaborate: tabindex="-1" is used to make non-interactive elements focusable, but only by JavaScript or via anchor links (this is the scenario of skip to content links that I wrote about).

      Using tabindex="-1" on anchor link targets makes the focus visible (by default, if somebody didn’t intentionally remove the focus outline etc.), which makes it easier for keyboard-only users. I have updated the post and added a simple demo to expose the difference…

      Adding tabindex="-1" to non-interactive elements doesn’t actually do anything by itself, so in theory it can be added all over the place (on non-interactive elements), but I don’t know why one would need that.

      Adding tabindex="-1" to interactive elements removes them from keyboard tab order and is only used in special cases (for example when we need to intentionally disable tabbing to them (check “Roving tabindex” for example)).

      And yes – it is generally not the right thing to “override” tabindex values with positive numbers as it often leads to wrong focus order and confusion (and with that also fails WCAG Success Criterion 2.4.3: Focus Order (Level A)).

      Hope this will help.

Comments are closed.