Describe the rejected value and the next action
A failed form is a decision point for the customer. The business has rejected an answer; the customer now needs to know which answer, why, and what can be entered instead. W3C's Error Identification criterion says that an automatically detected input error must identify the item and describe the error in text. Its Error Suggestion criterion adds that, when a correction is known, the suggestion is provided unless doing so would jeopardize security or the purpose of the content. These are related but distinct obligations. “There is a problem” does not identify the field. “Invalid value” names neither the allowed value nor a useful repair. A message such as “Visit date: choose an available date shown in the calendar” is much closer to an actionable response when the date no longer exists. Write error copy from the actual validation rule, not from a generic message catalog. A field that permits spaces and a plus sign in a telephone number should not instruct the customer to remove them. Keep the original entry visible where safe so the customer can spot the mistake instead of reconstructing the whole form.
Build an error inventory from actual rules
List the fields in one customer journey and the validation rule for each: missing required information, format, range, a value selected from a limited set, or a conflict discovered only when the server checks current data. For every rule, write the field name the customer sees, the error text, the acceptable choices or format, and what happens to the submitted value. Do not assume that a valid-looking input is a valid business decision. An appointment time might be correctly formatted yet already taken; the useful response is to show currently available alternatives rather than ask the person to retype the same time. A product quantity might be a positive integer yet exceed available stock; the site must explain the new limit or allow a different choice. Conversely, a name with an apostrophe or a Hong Kong phone number in a permitted international form should not be rejected by a narrow example regex. Test the rule itself with real local input patterns before polishing the message. The suggestion can be plain text, a selectable alternative, or a route to a list of options, as W3C technique G177 illustrates. The best choice depends on whether the system actually knows a safe alternative.
A booking failure, worked through
Suppose a customer booking an appliance repair enters a contact number, a district, and a preferred Tuesday afternoon visit. While they fill in the description, the last Tuesday slot disappears. On submission, the server should return the still-valid contact number and fault description, identify Preferred visit time as the affected field, state that the selected slot is no longer available, and offer current choices or a clear way to choose another date. It should not silently move the visit to Wednesday or claim the whole form is invalid. If the customer changes the district, availability may need to be recalculated; explain that relationship before showing replacement slots. If two fields fail, list both in a summary and place a field-specific message near each control, using links or focus management that help the person reach them. These are implementation choices, not a claim that W3C mandates one exact layout. The acceptance test is simple: the customer can tell what was rejected, retains unaffected work, chooses a valid alternative, and sees the final details before confirming. In Chinese and English versions, the same operational rule must be expressed in each language, not merely translated word for word.
Make feedback reachable and persistent
Place the message where people can find it after submission and keep it available long enough to act. W3C says text identification is needed but does not mandate a single presentation pattern; errors may appear at the form start, beside fields, or in another suitable pattern. A red border alone does not describe a problem. A short-lived toast can vanish before a person reads it. For a long form, a summary at the start can say how many fields need attention and link to them, while nearby messages explain the repair. Ensure the field's accessible name and relationship to the message remain clear for screen-reader navigation. When validation occurs dynamically, test whether the new message is announced at the right time without interrupting typing or repeating on every keystroke. Move focus deliberately after submission if the page stays in place; avoid unexpectedly moving it while someone is editing. Error feedback also needs to survive zoom and narrow screens. Check that fixed headers do not hide the focused field and that the person can return to the summary to verify all issues have been addressed.
Know when a specific suggestion is unsafe
The Error Suggestion criterion includes an exception where a suggestion would jeopardize security or the purpose of the content. That does not justify replacing every message with “Something went wrong.” A form can still identify the affected field and explain a safe next action. For example, a sign-in process should not disclose whether a particular account exists if that would expose account information. It can offer a neutral recovery route instead. A verification challenge should not reveal the secret answer or tell the person which digits were correct. Yet a booking date outside an allowed range or an unavailable product size ordinarily has a known, safe set of alternatives. Separate the secret from the correction. Do not show another customer's data in a suggested value, and do not let a search for near matches expose private records. Ask the security owner to document why an exception applies to a particular validation rule. Staff should be able to distinguish a genuine information disclosure risk from a generic unwillingness to write useful messages. Revisit the wording if the underlying rule changes; a correct instruction today becomes misinformation when the form accepts a new format tomorrow.
Write the message for each language and state
A bilingual form needs more than a translation of “invalid input.” Decide the label, example, instruction, and selectable choices in both languages. In English, “Mobile number: include the country code only if calling from outside Hong Kong” may be useful if it matches the actual rule. In Traditional Chinese, the natural phrasing and examples may differ, while the accepted values must remain identical. Avoid vague references such as “the box above,” because responsive layouts change position. Avoid saying “try again” when repeating the same input will fail. A dynamic rule can make a static message wrong: if a delivery option depends on district or cutoff time, the error must name the current restriction and offer available options. A server-side validation error should return through the same language the customer was using, and a browser's generic native message may not provide the necessary business detail. Keep error text in the product's content system so staff can review it alongside field labels and rule changes. This is a content governance task as well as a front-end task.
Verify the repair in the real journey
For each rule, submit an empty value, an invalid format, a boundary value, and a value that becomes invalid after another choice changes. Record the exact message, whether it names the field, whether it suggests an allowed correction, whether valid answers remain, and whether the final submission uses the corrected value. Test with keyboard, touch, zoom, and a screen reader in both site languages. Include server rejection, because a client-only test can miss the message that appears after live availability or stock changes. If an error is intentionally generic for security, document the risk and check that the safe recovery action still works. Let a support colleague read the message without knowledge of the implementation; if they cannot tell a customer how to proceed, the text probably needs more work. The release decision should be based on this evidence, not a count of error strings or a screenshot showing red fields. The goal is that a person can recover from a realistic mistake without losing accurate work or guessing the rule the business has chosen.
Before you proceed
- Does every detected error identify the affected field in text?
- Where a safe correction is known, does the message tell the customer what to do?
- Do valid answers remain after server-side rejection?
- Have both languages and assistive-technology paths been tested?
