WCAG 3.3.7Level AWCAG 2.2Guided or hands-on fix

Redundant Entry

What it requires

WCAG 2.2 SC 3.3.7 reduces the burden on cognitive-disability users by eliminating "type your address again" steps in checkout. If a user has entered their email at step 1, the email cannot be required again at step 2 unless re-entry is essential (e.g., for security).

Standard exceptions: passwords, security questions, and information whose accuracy must be re-confirmed (e.g., a verification step before payment). For everything else, auto-fill from the previous step or offer a "use the same as billing" toggle.

Common Shopify failure

Custom checkout extension that requires the customer to re-enter shipping address even after they entered it at the address step. Multi-step signup form that asks for first name on step 1 and again on step 3.

How to fix it

Review custom checkout and signup flows for information that has already been provided and offer selection or automatic population where the criterion applies. Do not remove fields without validating business, security, and legal requirements.

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 3.3.7 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, nothing is written until the merchant says yes (one confirmation for the run, or change by change), 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, Understanding WCAG 2.2 3.3.7

Scan your storefront free

AccessComply checks the automated rules it supports on the pages it reaches and shows each fix before anything is written. Some criteria still need hands-on testing.