Focus Not Obscured (Minimum)
When a user-interface component receives keyboard focus, it must not be entirely hidden by author-created sticky content (sticky headers, footers, drawers).
What it requires
Sticky headers and announcement bars often cover the upper portion of the viewport. When a keyboard user tabs to a link in the navigation, that link is sometimes scrolled into the area now covered by the sticky header — the focus indicator is hidden, the user is lost.
2.4.11 is "Minimum" — it requires the focused element to be at least partially visible. 2.4.12 (Enhanced, AAA) requires the entire focused element to be visible.
Common Shopify failure
Cart drawer overlay covers the entire viewport, but Tab still moves focus through links underneath the drawer. Sticky announcement bar covers the top 60px, hiding the first row of newly-focused header links.
How to fix it
Use an appropriate `scroll-margin-top` or `scroll-padding-top`, or change overlay behavior, so focused controls remain visible. Test the actual sticky heights and drawers at each breakpoint rather than assuming one offset works everywhere.
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.11 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.2 Understanding 2.4.11