Focus Order
When users navigate with the keyboard, focus must move through the page in an order that preserves meaning and operability.
What it requires
WCAG 2.0 SC 2.4.3 requires the keyboard tab order to follow the visual reading order — left-to-right, top-to-bottom in LTR languages — and to traverse interactive components in a sensible sequence.
Common failures: positive `tabindex` values that yank focus out of natural order; CSS `order` declarations on flex/grid items that visually reorder content without updating the DOM order; modal dialogs that don't move focus to the modal on open.
Common Shopify failure
Theme uses `tabindex="1"` on the search box to "make it focus first" — pulls focus before the skip-nav and breaks every other interactive element's order. CSS `order: -1` on a "promoted" product card so it appears first visually but tabs last.
How to fix it
Prefer natural DOM order, remove unnecessary positive `tabindex` values, and make modal focus behavior follow an established accessible pattern. Reordering DOM or adding a focus trap requires component-specific testing and should not be applied mechanically.
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.3 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 guided or hands-on fix pattern. 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.3