Monitoring Error Identification in Checkout and Account Forms

Red borders are not error messages. Monitoring form errors for text, association, and suggestions across checkout, login, and address forms, and why colour alone always fails.

Submit an empty checkout form on most stores and count how many of the resulting errors a screen reader actually announces. Often the answer is none. The fields turn red, a summary may appear at the top, and the programme that is supposed to read the page gets a set of empty, reddened inputs with no explanation attached to any of them.

WCAG 3.3.1 requires that an error be identified and described to the user in text. 3.3.3 asks for a suggestion when the fix is known. 4.1.3 covers getting that information announced. Monitoring those three together is the job, because a form can pass one and fail the other two on the same submit.

Test with bad data, on purpose

Monitoring that only loads a form and checks its labels will never see its errors. The check has to submit the form wrong: a postcode in the wrong format, an email missing its domain, a card field left empty. Each error state is a separate page state and each one needs its own pass. That is more work than a static scan, which is exactly why error states are where inaccessible forms hide.

Record three things per field. Is there error text, is it tied to the field with aria-describedby or an equivalent, and does it say how to fix the entry or only that something is wrong? Required field is the weakest useful message. Enter your email address in the format name@example.com is a suggestion a shopper can act on without a second attempt.

The summary at the top is not enough

Many checkouts add an error summary and consider the job done. A summary helps, provided it is announced or receives focus appropriately, lists each problem, and ideally links to the field. It does not replace the message at the field itself. A shopper working field by field should not have to return to the top of a long form to learn why the third field was rejected.

Watch for the summary that appears and then vanishes, or that lists two errors when five fields failed. Mismatch between the summary count and the field errors is its own finding, and it tends to appear when a payment widget validates separately from the rest of the form and reports on its own terms.

Errors that clear the data are a second failure

After noting the messages, look at what happened to the entries. Forms that clear a mistyped field, or the whole form, turn a one character correction into a full re entry. That is not listed as a neat criterion on its own, but it compounds every other error problem and it hits shoppers using assistive technology hardest, because re entering an address by keyboard or switch is not a small cost.

A useful monitoring note separates the two: error identification failed on these fields, and the form also discarded valid entries on submit. The second point often gets the fix prioritised, because it is lost revenue in a language a checkout owner already speaks.

Related reading: Monitoring Skip Links: The First Tab Stop Nobody Tests, Monitoring Button Names After Every App Install, Monitoring Tab Order in Drawers and Menus After Theme Updates.

Frequently asked questions

Why is a red border not an error message?

Because colour alone does not identify the error in text, which WCAG 3.3.1 requires, and it is invisible to a screen reader and unreliable for shoppers with colour vision deficiency. The text has to say what is wrong.

Does an error summary replace field level messages?

No. A summary is a useful addition, especially if it links to each field, but the message still belongs at the field so a shopper can find and fix it in place without returning to the top of the form.

What is the difference between 3.3.1 and 3.3.3?

3.3.1 requires the error to be identified and described in text. 3.3.3, at Level AA, asks for a correction suggestion when one is known, such as the expected format for a date, email, or postcode.

How should monitoring test error states?

By submitting forms with deliberately invalid data and recording, per field, whether error text exists, whether it is programmatically associated, and whether it suggests a fix. Loading the form in its clean state never exposes these failures.