Error Identification
When a user input error is detected, the field in error must be identified and the error described to the user in text.
What it requires
WCAG 2.0 SC 3.3.1 requires that form errors be identified specifically — not "Some fields are invalid" but "Email field is invalid: please enter a valid email address". Errors must be available as text (not color-only or icon-only) so screen readers can announce them.
The accessibility-correct pattern: associate the error with the input via `aria-describedby` pointing at the error-message element, set `aria-invalid="true"` on the input, and announce errors in an `aria-live="assertive"` region.
Common Shopify failure
Checkout form turns invalid fields red but provides no text error message — screen-reader users have no idea what failed. Newsletter signup that says only "Error" with no detail. Custom shipping calculator that flashes a red border and silently exits.
How to fix it
Render specific text for each error, associate it with the field using `aria-describedby`, and set `aria-invalid` when appropriate. Choose live-region behavior carefully so validation feedback is announced without creating repetitive interruptions.
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.1 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.1