Reviewed November 7, 2026
Checkout Errors Need Words, Not Just Red Borders
A customer types their card number wrong, the field turns red, and nothing else happens. A sighted user who can see red gets a hint. A colorblind user gets nothing. A screen reader user hears nothing at all, because a border color is not text and a screen reader does not announce colors.
WCAG 2.2 Success Criterion 3.3.1, Error Identification, exists for exactly this failure. When an input error is automatically detected, the field in error must be identified and the error described to the user in text. A red border is not a description.
What the criterion actually requires
Three things have to happen together. The invalid field gets aria-invalid set to true, so assistive technology knows the field is in error. A text message describes what is wrong, in the page, not in a tooltip and not only in color. And the message is connected to the field with aria-describedby, so a screen reader announces it when the field receives focus.
The message itself has to be useful. Invalid input fails the criterion in spirit even if it passes the letter, because it does not describe the error. An email address must include an @ symbol, for example name@company.com, passes, because it names the field, the problem, and the fix. WCAG 3.3.3, Error Suggestion, goes further at Level AA: when the system knows the correction, it must suggest it.
On a failed submit, focus has to move. Either the first invalid field receives focus, or an error summary at the top of the form receives it, with each item linked to the field it describes. A customer who submits a form and hears nothing has no way to know the page changed, which is how checkouts lose sales that look like abandonment in the analytics.
The failures hiding in Shopify checkouts
The most common failure is the color-only error, which fails 3.3.1 and also 1.4.1, Use of Color, at the same time. A theme that turns a field border red and adds no text has failed two criteria with one design decision, and it is the first thing a demand letter cites, because it is trivially demonstrable.
The second failure is the unassociated message. The text exists, sitting visually next to the field, but it is not connected with aria-describedby, so a screen reader user tabbing through the form never hears it. Visual proximity is not programmatic association, and the distinction is the whole point of the criterion.
The third failure is timing. Errors announced on every keystroke punish the user while they are still typing, and errors announced only after three failed submits punish them for trying. Validate on blur or on submit, never on keystroke, and announce the error once, with role alert or an aria-live region, so it is heard the moment it appears.
The audit you can run this afternoon
Open your checkout with a keyboard only, submit it empty, and count what happens. Every field that turns red without a text message is a 3.3.1 failure. Every message that appears without being announced is a 4.1.3 failure. Then turn on a screen reader, submit an invalid email, and listen for whether the error is announced and whether the field is reachable. The fixes are small: a text element per field, an aria-describedby connection, and a focus move on submit. The demand letters that cite this criterion are not citing a hard problem. They are citing an untested one.
Related reading
Related reading: Checkout Form Errors: Naming the Field Is Only Half the Job, Autocomplete on Checkout Fields: The WCAG 1.3.5 Fix That Fills the Form for You, and Session Timeouts at Checkout: WCAG 2.2.1 and the Cart That Empties Itself.
Frequently asked questions
Is a red border enough for a checkout error?
No. WCAG 3.3.1 requires the error to be described in text, and 1.4.1 forbids using color as the only way to convey information. A red border with no text fails both.
What does aria-describedby do for error messages?
It connects the error text to the input, so a screen reader announces the message when the field receives focus. Without it, a visually adjacent message is invisible to assistive technology.
Should errors appear while the user is typing?
No. Validate on blur or on submit. Announcing errors on every keystroke interrupts the user mid-entry, and WCAG guidance treats it as a poor practice even when it technically passes.
What is the difference between 3.3.1 and 3.3.3?
3.3.1, Level A, requires the error to be identified and described in text. 3.3.3, Level AA, requires a suggestion for fixing it when the system knows the correction. An invalid email needs a description; a mistyped email domain can earn a suggestion.