Bypass Blocks
A mechanism must be available to bypass blocks of content that are repeated on multiple web pages — typically the header, navigation, and announcement bar. The dominant pattern is a "Skip to main content" link as the first focusable element.
What it requires
WCAG 2.0 SC 2.4.1 protects keyboard and screen-reader users from having to traverse the same site-chrome (50-100 focusable nav items) on every page load. The skip link is the canonical implementation: positioned off-screen by default, visible on focus, jumps focus to the page's `<main>` content on activation.
Equivalent mechanisms include proper landmark structure (so screen-reader users can jump to main via the landmarks navigation), and heading-level navigation. Most sites combine all three.
Common Shopify failure
Theme has a skip link defined but its target (`#main-content` or similar) does not exist on the page. Or the skip link itself is positioned with `display: none` instead of off-screen, removing it from the focusable order entirely.
How to fix it
Provide a working bypass mechanism such as a visible-on-focus skip link with a valid target and appropriate main landmark. Verify it on each template and with keyboard navigation.
Merchant QA checklist
- Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
- Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 2.4.1 failure after a theme edit.
- Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.
How AccessComply handles it
AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a pattern that may have a supported suggested fix. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.
Primary source: W3C — WCAG 2.0 Understanding 2.4.1