No Keyboard Trap
Keyboard focus must be able to move away from any component using only the keyboard — there must be no "trap" where Tab stops moving focus.
What it requires
WCAG 2.0 SC 2.1.2 requires that any component receiving keyboard focus also has a keyboard mechanism for focus to leave it. The most common offenders: modal dialogs that trap focus permanently, custom date pickers with no escape, and embedded videos that capture focus and don't release.
The fix pattern for modals: trap focus inside while open, return focus to the triggering button on close, and listen for the Escape key to close.
Common Shopify failure
Cart drawer that traps Tab focus indefinitely once opened — Escape does nothing, clicking the close X is the only way out (impossible for keyboard-only users). Newsletter modal with no close button reachable by Tab.
How to fix it
Provide an operable close path, support Escape where appropriate, keep focus within an open modal without trapping the user permanently, and return focus to the trigger on close. Test the full component behavior manually.
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.1.2 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.1.2