Page has no skip navigation link

What is this issue?

The page provides no bypass mechanism: no skip link, no landmark structure, and no other way for a keyboard user to jump directly from the top of the page to its main content. The first focusable element on the page is the first item inside the repeated navigation, not a shortcut past it.

This rule covers the whole page, not one element. It fails when none of the recognized bypass techniques are present: a skip link as the first focusable element, a <main> (or role="main") landmark that assistive technology can jump to directly, or a full set of ARIA landmarks (<nav>, <header>, <main>) that give screen readers a navigation shortcut even without an explicit skip link.

Why does this matter?

A keyboard user reaches every focusable element on a page in order, one Tab press at a time, with no way to jump ahead visually the way a mouse user’s eye does. On a page with a header, a primary navigation menu, and a secondary navigation menu (20 or more links combined), that’s 20 or more Tab presses before the first Tab press that actually reaches the page’s content, repeated on every single page of the site.

This isn’t a one-time cost. A sighted mouse user’s eye jumps straight to the article they came for; a keyboard user pays the full navigation-traversal cost again and again, page after page, for as long as they use the site. A skip link collapses that cost to one keystroke, which is why WCAG treats it as a baseline requirement rather than an enhancement.

Who is affected?

• Keyboard users, including people with motor disabilities who cannot use a mouse, must Tab through every repeated navigation link before reaching new content, on every page.
• Screen reader users: without landmarks or a skip link, they hear the full navigation read aloud (or must manually arrow past it) before reaching the content region on every page load.
• Motor impairments: anyone using a switch device or head pointer pays a much higher physical cost per Tab press than a standard keyboard, so unnecessary repeated Tabbing is a bigger burden than it is for most keyboard users.
• Cognitive disabilities: repeatedly having to re-scan and re-traverse the same navigation block adds task load and makes it easy to lose track of where the main content actually starts.

What users experience

Marcus is a keyboard-only user with a repetitive strain injury that makes a mouse painful to use. He opens a client’s product page and starts pressing Tab, moving through the logo link, seven primary navigation items, a search icon, and a “Sign in” link (twelve Tab presses) before he reaches the first link inside the actual product description. He does this again on every product page he visits during his session, because there is no skip link to shortcut past the header.

How do I fix it?

Add a link as the very first focusable element in the page’s HTML, pointing at an id on the main content region, with visible text like “Skip to main content.” This works because keyboard focus always starts at the top of the DOM’s focus order, so placing the link first guarantees it’s the very first thing a keyboard user encounters, before the navigation they want to skip.

Keep the link visually hidden by default using an off-screen CSS technique (not display: none, which also removes it from the accessibility tree), and reveal it visually the moment it receives keyboard focus. This way sighted keyboard users see the link exactly when they need it, and it stays out of the way of everyone else. Give the destination, typically <main>, a tabindex="-1" so it can actually receive programmatic focus when the link is activated, since <main> isn’t natively focusable on its own.

As a secondary, complementary fix, use real landmark elements (<nav>, <header>, <main>) throughout the page. A skip link and landmarks solve overlapping but distinct problems: landmarks help screen reader users navigate directly by region at any point, while a skip link is the one mechanism that also helps sighted keyboard users who don’t have a landmark-navigation shortcut available.

Code Examples

<header>
  <nav><!-- 20 links --></nav>
</header>
<main><!-- content --></main>

<a href="#main-content" class="skip-link">
  Skip to main content
</a>
<header>
  <nav><!-- 20 links --></nav>
</header>
<main id="main-content" tabindex="-1">
  <!-- content -->
</main>

.skip-link {
  position: absolute;
  transform: translateY(-100%);
  transition: transform 0.2s;
}
.skip-link:focus {
  transform: translateY(0);
}

The link is placed before <header> in the DOM so it’s the first focusable element, and transform: translateY(-100%) moves it off-screen without removing it from the accessibility tree or the focus order. The :focus rule brings it into view the instant it’s reached by keyboard, and tabindex="-1" on <main> lets the browser move focus there once the link is activated, even though a <main> element has no focusable behavior by default.

Common Mistakes

Mistake: “A skip link is only useful on very long pages.” Length isn’t the relevant factor; repetition is. A short page with a 15-link navigation menu costs a keyboard user the same 15 Tab presses on every visit regardless of how little content follows, so the fix matters most where navigation is large relative to unique content, not where the page happens to be long.

Mistake: “Adding a <main> landmark is enough on its own.” A <main> landmark helps screen reader users, who can jump to it with a dedicated navigation shortcut, but it does nothing for sighted keyboard users, who have no equivalent shortcut and still rely on Tab order. The two fixes are complementary, not interchangeable; this rule specifically requires a mechanism that also serves keyboard-only users.

Mistake: “Hiding the skip link with display: none and showing it via JavaScript on Tab is the same thing.” display: none removes an element from the accessibility tree entirely, so a screen reader has no way to discover it exists, focus or no focus. Use an off-screen positioning technique (like the transform example above) that keeps the element in the tree and in the Tab order at all times.

Mistake: “The skip link only needs to work visually, since keyboard users can see where focus lands.” A skip link that scrolls the page to <main> visually but never actually moves keyboard focus there leaves the very next Tab press starting back at the top of the page. The link’s href and the target’s tabindex="-1" need to genuinely move DOM focus, not just scroll position.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s bypass rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The check looks for at least one recognized bypass mechanism on the page: a link to an in-page anchor as an early focusable element, a <main> or role="main" landmark, or a full complement of ARIA landmark roles that together let assistive technology skip the repeated regions.

False negative: axe-core confirms a bypass mechanism exists somewhere on the page; it can’t confirm the mechanism actually skips past the navigation a real user wants to skip: a skip link that jumps to an empty anchor two lines below the header instead of past the whole nav block can pass the automated check while still leaving most of the navigation in the Tab path. False positive: none typical for this check, since the presence of a recognized bypass mechanism is close to binary for axe-core’s heuristic. Manual step: Tab through the page from the very top and confirm the skip link (or landmark jump) actually lands past the full repeated navigation block, not partway through it.

Manual Testing

1. Load the page fresh in Chrome or Firefox and press Tab once, before clicking anywhere.
2. Confirm a skip link becomes visible and reads something specific, like “Skip to main content,” not a generic “Link.”
3. Press Enter to activate it, then press Tab again.
4. Confirm the next Tab press moves focus to content genuinely past the navigation, not back to the top of the page and not to an empty anchor with nothing after it.
5. Repeat with NVDA or VoiceOver running, and additionally try each screen reader’s landmark-navigation shortcut (NVDA/JAWS: D key for landmarks in browse mode; VoiceOver: Rotor set to Landmarks) to confirm a <main> landmark is also reachable directly.

Related WCAG Success Criteria

2.4.1 Bypass Blocks: Pages must provide a mechanism to bypass blocks of content repeated across multiple pages, such as navigation menus. This rule maps directly to 2.4.1: it’s the specific, checkable failure of that criterion when no skip link, landmark structure, or equivalent mechanism exists anywhere on the page.

Related Issues

Skip link target is missing or not focusable covers the companion failure: a skip link exists but its destination is broken, which produces the same end-user experience as having no skip link at all.

Navigation order is inconsistent across pages affects the same repeated-navigation block this rule is designed to help users bypass; inconsistent ordering makes even a working skip link’s surrounding context harder to predict.

Content in a scrollable region is not keyboard-focusable shares this rule’s underlying concern with keyboard focus reaching content that a mouse user could otherwise access directly.

Links with the same accessible name go to different places commonly co-occurs in the same repeated navigation blocks this rule targets, since large nav menus are a frequent source of both problems.

Button or link has no accessible name is worth checking alongside this rule specifically for the skip link itself: a skip link with no real accessible name defeats the fix even when the mechanism is technically present.

References

• W3C Understanding 2.4.1: Bypass Blocks
• W3C Technique G1: Adding a link at the top of each page that goes directly to the main content area
• WebAIM: “Skip Navigation” Links