Can keyboard users get past your repeated navigation?

Find the repeated journey before choosing a control

A shopper who opens several product pages should not have to tab through the same header links, search controls, category menu and promotional strip before reaching each product. W3C's WCAG 2.2 success criterion 2.4.1 asks for a mechanism to bypass blocks of content repeated across pages. It does not prescribe one mandatory visual design or require a skip link for every repeated word. The business decision is to identify genuine repeated blocks on its own page templates and give people a usable route past them. A simple link near the start of the page that goes to main content is a common solution. Landmarks and headings can help some assistive-technology users, but they do not automatically prove that a sighted keyboard user has an efficient visible route.

List the templates that customers actually encounter: home, category, product, search results, account and checkout. Count the focusable items before each page's main task from the browser's first tab stop. The number is a local observation, not a WCAG threshold. Its value is to expose where an unusually long header or filter panel consumes effort on every visit. Include mobile layouts, because an expanded menu or cookie panel can change which elements appear first. Also identify whether the repeated block starts before or after the primary navigation; a link that skips only the menu but lands inside another repeated promotion may save very little work. The goal is to reach the point where the page's unique content or task begins.

Make the destination real and visible

W3C's G1 technique describes a link at the top of the page that goes directly to the beginning of main content. Put it early enough in the focus order that a keyboard user can find it before traversing the repeated navigation. Its label should say what it does in the current page language, such as a direct route to main content. It can be persistently visible or reveal itself when focused, but it must be visible while a sighted keyboard user is deciding whether to activate it. Give the destination a stable identifier and ensure that it marks the real start of the page's unique content. A link whose target is missing, duplicated or hidden behind a sticky header is merely decorative.

Use semantic page structure so that the destination also makes sense to assistive technology. A main region should contain the central content rather than the repeated site header, and its beginning should give the visitor orientation through a meaningful page heading or task name. W3C treats bypassing repeated blocks and preserving meaningful focus order as related but separate criteria. Moving the visual viewport alone can be misleading if the next Tab key returns to the header or jumps unpredictably. Test where keyboard focus goes after activating the link, not just whether the browser scrolls. Depending on implementation, the target may need to be focusable programmatically; avoid adding unnecessary permanent tab stops to static text. The expected outcome is a coherent next action from the destination.

Test with a keyboard from a fresh page load

Open a representative page, reload it, put the pointer aside and press Tab. The bypass link should be encountered before the repeated navigation. Confirm that its focus style is visible against the actual page background and is not covered by a sticky banner. Activate it with Enter. Check the new viewport position, the programmatic focus if applicable, the next Tab destination and the page heading a screen reader announces. Then navigate to a second page of the same template and repeat; a control that works only on the home page does not solve the repeated-page problem. Repeat with zoom and a narrow viewport, because responsive layouts can move the navigation and alter sticky offsets. Record the page, browser, viewport and observed result rather than writing a vague pass.

Do not limit testing to the link itself. On a catalogue page, a long filter panel may precede product results even after the global header is skipped. W3C's bypass-blocks guidance gives a filter-before-results example: a route directly to results can be useful when that panel becomes another repeated obstacle. The right destination depends on the page's purpose. A shopper who came to refine filters may want those controls, while someone opening successive result pages may need quick access to products. Consider a clear route to each area when the page structure warrants it, rather than using one ambiguous jump. Test both paths with keyboard and assistive technology, and make sure the labels distinguish them. Keep the first route to main content predictable across templates.

A worked product-page review

Consider a local shop whose product pages share a header with account links, search, several category links and a seasonal promotion. A keyboard user arriving from search results opens three products to compare specifications. The first Tab on each page reaches a visible 'Skip to main content' link. Activating it places the user at the product title, with the next interactive control in a logical product sequence. The tester verifies this on two different products, not just one. On the mobile layout, however, a sticky promotion hides the title after the jump. The team changes the destination's scroll offset or layout and retests rather than declaring success because the URL fragment changed. This is an illustrative test, not an observation of an actual client's site.

The shop also checks an account page where a temporary message appears above the main content. It decides whether the message belongs in the main task flow or is a repeated banner that should be bypassed. The choice is based on whether skipping it would hide information needed to complete the account task. A warning about an action the user must take should not be silently lost. The team reviews both English and Traditional Chinese labels, because the link text and heading must orient readers in the language of the page. It records the destination ID, page templates covered and regression checks in its release notes. The completed work saves repeated keystrokes while preserving access to navigation for users who choose to use it.

Keep the route working as templates change

A site-wide header redesign can quietly break a previously good bypass mechanism. New cookie panels, campaign banners, in-page tabs and client-side route changes can alter the first focus stop or remove the destination after navigation. Add the bypass route to the acceptance checks for shared layout changes. Test the rendered pages, not only the component in isolation, including one page from each important template and both site languages. If client-side navigation moves to a new page without a full reload, check how users are told where they are and where focus begins; that is a wider navigation problem, not solved by a skip link alone. Make the owner of the shared template responsible for the regression check, and preserve a short record of actual keyboard observations.

When a test fails, describe the exact failure before choosing a repair. If the link is absent from the first focus stops, inspect document order and whether another overlay captured focus. If the link appears but cannot be seen, inspect its focus styling at the actual zoom level and against both language layouts. If activation scrolls correctly but the next Tab returns to the navigation, inspect the target's focus behaviour and the following controls. If the target is right but hidden behind a fixed header, adjust the layout or scroll positioning and retest on narrow screens. These are different defects with different fixes. A useful ticket includes the page template, steps from a fresh load, expected destination, actual focus position and a short keyboard recording or observation note. That makes repair reviewable without claiming that an automated audit alone has tested the human journey.

Decide who accepts the result, because a screenshot of the link is weak evidence. The page owner should confirm that the route reaches the promised content; a keyboard tester should confirm visible focus and the next action; someone familiar with the site's languages should check that both labels make sense to readers. They can use a compact acceptance record: page URL, template, language, first focus stop, activated destination, next Tab target and any overlay present. The record is a test plan for future changes, not a claim that every combination of device and assistive technology has been covered. Where a page has exceptional structure, such as a full-screen checkout step, document the reason for its destination and test that step directly. Consistency is helpful, but the destination should still reflect the task on the page the customer opened.