Skip Links and Bypass Blocks

The plain-language idea

Most pages put a header with a navigation menu — often a dozen or more links — before the actual content a user came for. A mouse user never notices this cost: they click wherever they want, instantly. A keyboard user pays it every time: without a bypass mechanism, reaching the main content means pressing Tab through every single navigation link first, and doing it again on every page of the site, since the same header repeats everywhere. This is a real, tedious, completely avoidable barrier — not a hypothetical edge case.

A skip link solves it. It's a link, typically the very first focusable element on the page, reading something like "Skip to main content." Its defining behavior is that it's visually hidden by default and becomes visible only when it receives keyboard focus — so it doesn't clutter the design for sighted mouse users, but it's the very first thing a keyboard user encounters when they start tabbing. Activating it jumps focus straight past the repeated navigation into the main content region.

See it in a real thing: a skip link that actually moves focus

<body>
  <a href="#main-content" class="skip-link">Skip to main content</a>

  <header>
    <nav><!-- a dozen navigation links --></nav>
  </header>

  <main id="main-content" tabindex="-1">
    <h1>Page content starts here</h1>
  </main>
</body>

.skip-link {
  position: absolute;
  top: -40px; /* off-screen by default */
  left: 0;
}

.skip-link:focus {
  top: 0; /* moves on-screen the moment it receives keyboard focus */
}

The CSS pattern here is standard and correct: absolutely position the link off-screen, then use a :focus style to bring it on-screen exactly when it's needed. But the detail people get wrong is on the <main> element itself — tabindex="-1". Without it, clicking the skip link scrolls the page down to #main-content (the browser's normal same-page anchor behavior) but doesn't actually move keyboard focus there, because <main> isn't a naturally focusable element. A user who activates the skip link and then presses Tab again would land back near the top of the page, inside the navigation they just tried to skip — the link visually "worked" but the actual keyboard-navigation problem it exists to solve is still unsolved.

What people usually miss

Watch out

• A working skip link and a "working" skip link look identical to a mouse user. Both scroll the page. The failure only shows up when you check where keyboard focus actually lands afterward — which is exactly why this bug ships unnoticed so often.
• tabindex="-1" on the target isn't there to add it to the tab order — it's specifically so that JavaScript- or anchor-driven focus-setting works on an element that isn't naturally focusable. The element still won't appear when tabbing through the page normally; it's reachable only via the skip link's jump.
• A skip link is one instance of a broader pattern: bypass blocks. Any page section that repeats identically across many pages and sits before the unique content — a header, a persistent sidebar, a cookie banner — is a candidate for a bypass mechanism, not just the top-level nav.
• Hiding a skip link with display: none or visibility: hidden instead of off-screen positioning removes it from the accessibility tree entirely, which defeats the purpose — it needs to be present and focusable at all times, just not visible until focused.

Why this matters in interviews

"This page has 40 nav links before the content — what would you add, and what's the one implementation detail people usually get wrong?" is a real, specific question, and naming tabindex="-1" on the jump target — not just "add a skip link" — is what shows you've actually tested one rather than just read about the pattern.