Skip to main content
Accessibility AccessLint 0.16

Page must have a mechanism to bypass repeated blocks of content.

About this AccessLint rule

Most web pages share repeated content across multiple screens: site-wide navigation bars, search forms, branding headers, sidebars, and footer links. Sighted users can visually skip past these blocks and go straight to the content they want. Keyboard users and screen reader users cannot do this as easily. Without a bypass mechanism, a keyboard-only user may need to press Tab dozens of times through every navigation link before reaching the page's actual content. Screen reader users face a similar problem, hearing every repeated element announced on every page visit.

This rule checks that the page provides at least one way to skip past repeated blocks of content and reach the non-repeated content directly.

Why this matters

WCAG Success Criterion 2.4.1 (Bypass Blocks), a Level A requirement, exists to address this problem. It requires that a mechanism is available to bypass blocks of content that are repeated on multiple pages. Level A is the minimum conformance level, which means every accessible site must meet this requirement.

The people most affected are:

  • Keyboard-only users who must Tab through every interactive element in sequence. Repeated navigation blocks force them to press Tab many times before reaching the unique content on each page.
  • Screen reader users who hear every link, button, and heading announced in order. Although most screen readers can navigate by landmarks and headings, this only works if those landmarks and headings are present in the markup.
  • Users with motor impairments who rely on switch devices or other alternative input methods. Extra key presses or switch activations to get past repeated content cause fatigue and slow down interaction.

How to fix it

There are several accepted techniques. Any one of them is sufficient.

Add a skip link

Place a link at the very beginning of the page body that points to an anchor on the main content area. This link should be the first focusable element on the page. It can be visually hidden by default and made visible when it receives focus, so it doesn't disrupt the visual design but remains available to keyboard users.

The skip link target element should have the matching id and should also have tabindex="-1" if it is not natively focusable, so that focus moves to it correctly in all browsers.

Use a <main> landmark

Wrapping the primary content of the page in a <main> element gives screen readers a direct way to jump to it. Most screen readers have a shortcut to navigate by landmarks (for example, pressing "D" in NVDA or using the rotor in VoiceOver). A <main> element satisfies the bypass requirement for assistive technology users.

However, a <main> landmark alone does not help sighted keyboard users who are not using a screen reader. Combining a <main> element with a skip link gives the broadest coverage.

Use heading structure

If the non-repeated content starts with a heading, screen reader users can navigate by heading to reach it. This is another valid technique, though it shares the same limitation as landmarks: it does not help sighted keyboard users without assistive technology.

Make repeated blocks collapsible

If the repeated content can be collapsed or hidden by the user (and shown again), this also satisfies the requirement. This approach is less common and more complex to implement correctly.

Recommendations

The most reliable approach is to combine a visible-on-focus skip link with a <main> landmark. This covers keyboard-only users, screen reader users, and users of other assistive technologies. Any mechanism used to bypass content must itself be keyboard accessible and must have a proper accessible name. A skip link that cannot be reached by keyboard, or a landmark that is hidden from the accessibility tree, does not satisfy the requirement.

Examples

Page with no bypass mechanism (fails)

<body>
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
<a href="/products">Products</a>
<a href="/contact">Contact</a>
</nav>
<div>
<h1>Welcome to our site</h1>
<p>Page content goes here.</p>
</div>
</body>

In this example, a keyboard user must Tab through all four navigation links on every page before reaching the content. There is no skip link, no <main> element, and no heading-based navigation shortcut that reliably allows bypassing the navigation.

Fixed: skip link with <main> landmark (passes)

<body>
<a href="#main" class="skip-link">Skip to main content</a>
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
<a href="/products">Products</a>
<a href="/contact">Contact</a>
</nav>
<main id="main" tabindex="-1">
<h1>Welcome to our site</h1>
<p>Page content goes here.</p>
</main>
</body>
.skip-link {
position: absolute;
left: -9999px;
top: 0;
}
.skip-link:focus {
position: static;
left: auto;
}

The skip link is the first focusable element in the page. It is visually hidden until a keyboard user presses Tab, at which point it appears on screen. Activating it moves focus to the <main> element. Screen reader users can also jump directly to the <main> landmark using their assistive technology's landmark navigation.

Fixed: <main> landmark only (passes)

<body>
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
<a href="/products">Products</a>
<a href="/contact">Contact</a>
</nav>
<main>
<h1>Welcome to our site</h1>
<p>Page content goes here.</p>
</main>
</body>

This satisfies the rule because screen readers can jump to the <main> landmark. Keep in mind that sighted keyboard users without assistive technology will not benefit from this approach, so adding a skip link as well is a better practice.

Detect accessibility issues automatically

Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.

Help us improve our guides

Was this guide helpful?
๐ŸŒ Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial โ†’

Join teams across 40+ countries