Try this right now: load your homepage and press Tab once. If the very next thing you land on isn't your navigation menu, congratulations — you've already found the fix this article is about. If it is your navigation menu, keep pressing Tab. Ten presses later, are you still stuck in the header?
That little exercise takes about eight seconds, and it's the single fastest way to diagnose one of the most common accessibility gaps on the web: the missing skip link. It's an invisible piece of UI — sighted mouse users will never see it, never miss it, never know it's gone. But for anyone navigating by keyboard, it's the difference between reaching your content in one keystroke and reaching it in twenty.
The Stat: WCAG Success Criterion 2.4.1 (Bypass Blocks), a Level A requirement, mandates a mechanism to let users skip repeated blocks of content — like navigation menus — that repeat across pages. (Source: W3C WCAG 2.4.1)
What a skip link actually is
A skip link — sometimes called a "skip to content" or "skip to main content" link — is the very first focusable element on a page. It's usually visually hidden until it receives keyboard focus, at which point it pops into view as a small, clearly labeled link. Activate it, and focus jumps straight past the header, logo, and navigation menu, landing on the main content region.
That's it. No JavaScript framework, no third-party widget, no redesign. It's a handful of lines of HTML and CSS that solves a very specific, very real problem: repeated navigation.
Why "repeated" is the key word
Sighted mouse users never notice your nav menu twice in a row, because their eyes jump directly to whatever they're looking for on the page. Keyboard users don't get that shortcut. Every single Tab press moves focus to the next focusable element in the DOM — one at a time, in order. If your header has a logo link, a search icon, a "sign in" button, and a five-item nav menu, that's eight or nine tab presses before a keyboard-only visitor even reaches your headline.
Now multiply that by every page on your site. A user reading a five-page article series, or clicking through a multi-step checkout flow, re-tabs through the identical header block every time. It's not a one-time cost — it's a tax paid on every page load, forever, unless there's a bypass mechanism.
That's precisely the gap WCAG 2.4.1 Bypass Blocks exists to close. It's a Level A criterion — meaning it sits at the most basic tier of conformance, not an advanced nice-to-have — and it requires that repeated blocks of content have some mechanism for users to skip past them. A skip link is the most common, most battle-tested way to satisfy it.
How to build one correctly
The failure mode here isn't usually "we have no skip link." It's "we built a skip link, and it's broken in one of three predictable ways." Here's the checklist:
- The skip link is the first focusable element in the page's DOM order — before the logo, before the nav, before anything else.
- It's visually hidden by default but becomes visible on keyboard focus (never
display: none, which also hides it from assistive tech and prevents focus entirely). - Its
hrefpoints to a real, valid target — typically a<main>element or a heading with a matchingid. - The target element is actually focusable when jumped to (in most browsers this means giving it
tabindex="-1"if it isn't a naturally focusable element). - The link text is clear and specific — "Skip to main content," not just "Skip."
- It's tested with an actual keyboard, not just eyeballed in dev tools.
That fifth point deserves emphasis: skip links are one of those features that look fine in code review and quietly don't work at all in production, because the target element was never actually reachable by focus. WebAIM's Skip Navigation Links guide walks through the CSS pattern for the "hidden until focused" behavior in detail, along with common implementation mistakes — it's worth bookmarking as the canonical reference.
What about pages with more than one thing to skip?
A single "skip to main content" link handles the most common case, but some page layouts have more than one repeated block worth bypassing. Think of an e-commerce category page with a long filter sidebar between the header and the product grid, or a documentation site with a persistent table-of-contents rail on every article. A keyboard user who's already skipped past the header still has to tab through the entire filter panel before reaching a single product.
The fix is the same pattern, just applied more than once: a short list of skip targets at the very top of the page — "Skip to main content," "Skip to filters," "Skip to search results" — each jumping to a different landmark. You don't need this on every site; a simple blog or brochure page is fine with one skip link. But if you've got a genuinely long, repeated interactive block standing between your header and your actual content, a second skip target is a legitimate, low-effort way to shorten that path further, and it satisfies the same WCAG 2.4.1 requirement, just more thoroughly.
One caution: don't go overboard. A page with eight different skip links defeats the purpose — now the keyboard user has to tab through those to find the one they want. Two or three well-chosen targets, clearly labeled, covers nearly every real layout.
A quick reference: common implementations
| Pattern | How it works | Watch out for |
|---|---|---|
| Visually-hidden-until-focus link | CSS moves the link off-screen by default, repositions it on :focus |
Must not use display: none or visibility: hidden |
| Always-visible skip link | Link sits visibly at the top of the page for all users | Can look out of place in some visual designs, but never breaks |
| Landmark-based navigation | Screen reader users jump by ARIA landmark (<nav>, <main>) instead of a literal link |
Doesn't help keyboard-only, non-screen-reader users — landmarks and skip links solve overlapping but different problems |
That last row matters. A skip link and semantic landmarks aren't interchangeable — they serve overlapping but distinct audiences. Screen reader users can often jump between regions using landmark navigation commands, which is why the ARIA Authoring Practices Guide's landmark regions documentation is worth pairing with your skip link work — marking up <nav>, <main>, and <header> correctly gives screen reader users a second, complementary way to bypass repeated content, while the visible skip link covers sighted keyboard users who don't use a screen reader at all. You want both, not one instead of the other.
The eight-second test, revisited
Here's the thing about skip links: they cost almost nothing to build, and testing whether one exists costs almost nothing either. Load any page, press Tab once, and look. If a small link appears announcing itself as a way to skip to content, you're covered. If focus lands silently on the logo or the first nav item with no visible indicator at all, you've found a gap — and now you know exactly what's missing and why it matters.
It's a small fix, but it's rarely the only keyboard issue on a site — tab order problems, invisible focus indicators, and unreachable interactive elements tend to travel together. If you want a clearer picture of how your own site's tab order actually behaves beyond this one check, get a free scan and see what else a keyboard-only visit would actually look like.