Checkout marks an error only with color

Identify the rejected input without inferring a payment result

Start from a genuine report or an error state already observed on the checkout. Record the public page, checkout step, field label, time and action immediately preceding the indicator. Keep the field value out of the record. The first question is which input the page says needs attention, not whether the buyer’s card or the merchant account was declined.

A red border, changed background or icon may draw attention to a field while leaving the reason unclear. Note any words beside the field and in any page-level message. If the form simply reappears or the only instruction is a generic failure sentence, record whether a reader can connect it to the particular input.

Do not submit a payment or create a new order to produce an error for this worksheet. If the reported error is no longer visible, preserve the report as reported rather than confirmed. A maintainer can investigate the actual validation rule and component from those facts; the worksheet does not need sensitive payment values.

Separate an indicator from an explanation

W3C’s understanding page for WCAG 2.2 criterion 3.3.1 says that an automatically detected input error must identify the item in error and describe the error in text. It explains that redisplaying the form without a hint is insufficient. The requirement is about communicating the detected error, not merely changing the field’s appearance.

Assess identification and description separately. Text can name the affected field yet leave the problem unexplained. A message can describe a format problem while failing to show which of several similar fields it concerns. Record both findings. The purpose label, error description and entered value are different parts of the buyer’s understanding.

The text does not have to be judged solely by whether it sits beside the input. Record the relationship between an error summary and the field it names, including whether the wording is understandable at the point of correction. Do not assume a colored border becomes sufficient because text exists elsewhere on the page but cannot be matched to this input.

Request wording that matches the real validation rule

Have the component owner establish what the checkout actually rejected before drafting a repair. A required value that is absent and a present value that does not meet an accepted format need different explanations. Tie the description to the configured rule; do not invent a postal, phone or address format that the form does not actually require.

Where the owner knows a safe corrective action, ask for useful guidance that helps the buyer make that correction. Keep this practical copy request separate from the cited criterion’s requirement to identify and describe the error. Do not imply that criterion 3.3.1 alone specifies every error-suggestion behavior or a complete accessible interaction.

Keep messages limited to what the system established. A local field error does not justify wording that blames an issuer or declares an account ineligible. Conversely, a real provider decision needs that provider’s supported explanation; it should not be rewritten as a made-up field-format problem. Route each message to the owner of the component that produces it.

No error description needs to repeat card numbers, authentication codes, private payment-link tokens or secrets into a support record. Use the field’s purpose and the validation category to explain the issue. Omit sensitive values from screenshots and from any public inquiry.

Close the finding with the corrected message

Define the requested result before editing: the affected field is named unambiguously, the actual input problem is described in readable text, and any correction instruction agrees with the field’s real rule. Retain color as an additional cue if appropriate; the decision here is whether the words provide the missing explanation.

When the corrected behavior is available to review, compare the same affected step and error condition with the original observation. Record the actual text and whether it identifies that field. Leave other error states and unobserved devices unassessed. A readable message does not establish that order creation, payment processing or every accessibility criterion works.

For a Prism checkout consultation, describe the checkout component, rejected field and missing explanation without entering private records in the form. Confirm the scope, responsibilities, fees and terms of the requested review or implementation before work. The merchant’s payment-provider eligibility remains a separate decision.

Error-message coverage

Complete one copy for each observed input error. Record exact public-facing wording, field purpose and the observation conditions, excluding entered values. Mark a reported or unobserved state explicitly. A finding closes only when text both identifies the affected input and explains its actual error.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.