Error Suggestion
When a user input error is detected and suggestions for correction are known, the suggestions must be provided unless doing so would jeopardize security.
What it requires
WCAG 2.0 SC 3.3.3 takes 3.3.1 a step further: error messages must include suggestions for fixing the error when known. Not just "Invalid date" but "Invalid date — please use the format MM/DD/YYYY".
Security exemption: password fields generally don't expose what was wrong (would help attackers). Most other fields can and should give specific guidance.
Common Shopify failure
Address form with "Postcode is invalid" and no suggestion — should be "Postcode is invalid — UK postcodes use the format SW1A 1AA". Phone field with "Invalid format" — should suggest "Use international format: +1 555 123 4567".
How to fix it
Write a correction suggestion that matches the field, locale, and actual validation rule. Avoid guessing formats from a generic library when merchant or jurisdiction context changes what a valid value looks like.
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.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 3.3.3