Validation errors must explain the expected format

What it is

An actionable validation error says more than “invalid.” It identifies the field and tells the person how to recover: which structure the selected region accepts, what characters or range are allowed, and a localized example made from non-real data. The guidance follows the data jurisdiction, not an interface-language default. Disclosing a repairable input contract does not require revealing every decision rule. Sensitive results such as account existence, risk thresholds, challenge details, or document authenticity should not become queryable oracles.

Why it happens

“Wrong format” transfers diagnosis to the person. When familiar notation differs from the system's internal form, this produces repeated guessing, abandonment, or invented placeholder values. Useful guidance narrows the problem and keeps the visible label, example, constraint, and actual parser consistent. Yet an error is also system output: distinctions such as “account exists,” “valid credential but not yours,” or the exact anti-abuse condition let an attacker enumerate records or tune input. A layered error model is therefore needed. Publish enough of the format contract for ordinary completion, collapse sensitive decisions into results that do not reveal internal state, and retain diagnostics only in controlled logs.

Studying it

In usability sessions, observe whether people can repair the first failure without outside help. Measure first-attempt recovery, consecutive failures, time, abandonment, and correct localization of the fault. Include familiar notations from several regions, keyboard and screen-reader use, paste, simultaneous errors, and server-returned failures; verify that language, text direction, and examples remain intelligible. Security review treats enumeration, response differentiation, and rule probing as threat cases, comparing copy, status codes, timing, and retry behavior. Both forms of evidence should determine disclosure granularity.

Where it stops holding

An example is not the full contract and must not resemble a real identity or account. For ambiguous dates, numbers valid in multiple regions, or missing jurisdiction context, one example can steer the person toward the wrong interpretation; request the missing context first. A sensitive workflow may use a less specific submission result, but should still state public format requirements before input and offer a legitimate recovery route. Assistive-technology users cannot depend on color, placeholder text, or a top-of-page summary alone to discover the problem.

Applying it

• Show a persistent label and concise format guidance before input. After failure, programmatically associate the error with its field, preserve the entry, and direct focus or an error summary to the repairable location.
• Use a non-real example for the current data jurisdiction and state accepted characters, grouping, or range. Version client guidance with server acceptance rules, mapping server failures to stable, localizable error codes.
• Separate public syntax failures from sensitive decisions. Explain how to repair the former; word the latter without confirming account, document, or internal risk state. Put detailed reasons only in access-controlled, redacted logs.
• Verify discovery, announcement, and repair with keyboard, screen reader, zoom, and multiple-error cases. Then test enumeration and differential responses so copy, status codes, and timing do not expose security rules.

Related

• Same group: S2.09.1 Regular-expression validation usually embeds a single-region assumption · S2.09.2 Identity-document numbers vary by format and length · S2.09.4 Be permissive at input and strict at output
• Adjacent: L2.04 Form error handling · N2.02 Error messages and recovery
• Search terms: actionable validation error · inline error message · account enumeration