Name the error owner and correction path
Use one state for each meaningful kind of failure:
| State | What the operator needs next |
|---|---|
| Submitting | Say the request is pending and prevent an uncontrolled second submit. |
| Field error | Identify the field in text and say the expected format or value. |
| Cross-field error | Name both fields and the relationship that conflicts. |
| Confirmed service failure | State that no effect occurred and offer a safe retry or correction path. |
| Outcome unknown | Preserve the operation identity and offer a status check or escalation, not resubmission. |
| Permission denied | Preserve the draft and offer access, copy, or exit—not a fake retry. |
| Version conflict | Preserve the draft and offer compare, copy, reload, or reviewed retry. |
W3C's error-identification guidance requires detected input errors to be identified and described in text. Color, icons, and placement can help, but they cannot be the only message. When a safe correction is known, the error-suggestion guidance calls for providing it unless that would jeopardize security or the purpose.
Preserve what is still valid
Keep the whole draft through field, cross-field, service, permission, and conflict states until the operator deliberately discards it. Do not blank a working address because a date is invalid. Do not erase a completed request's draft merely because the confirmation response failed to arrive.
While submitting, prevent an uncontrolled second submit and retain an operation identity that the service can reconcile. For a service error, say whether the service confirmed that nothing happened. If the outcome is unknown, offer a status check or an escalation path before a blind resubmission. Retrying an invoice, approval, deletion, or other consequential action can duplicate the effect.
Make the first action reachable without hiding context
Put a textual summary where it is discoverable and connect it to the affected fields or decisions. Focus the first actionable correction only when that helps the operator; a dialog or full-page summary may be better for a service or permission state. Preserve the error text long enough to read and keep a keyboard path to every correction.
The local evidence/P93/form-error-state-map.md is a technology-neutral review artifact. It records visible text, preserved data, available correction, and the backend boundary for eight states, including pending submission and an unknown outcome. It is not a screen-reader interoperability result or a claim that client validation can save or authorize data.
Keep the trusted boundary visible
The browser can help an operator find and correct input. The service must still validate the final request, enforce authorization, detect a version conflict, and report whether a consequential action completed. A permission denial is not a field-format error; a service outage is not evidence that a value is wrong.
Acceptance checklist
- Every detected input error has a textual description.
- Known safe corrections are stated with the relevant error.
- Valid values remain available until the operator decides otherwise.
- Field, cross-field, service, permission, and conflict errors have different messages and actions.
- An unknown service outcome does not invite a blind duplicate submission.
- Focus, status text, and keyboard access expose the next action.
- The backend still owns validation, authorization, persistence, and completion.
Frequently asked questions
Should every error move focus to the first field?
No. It can help for a straightforward field correction, but a service or permission state may need a visible summary and a different operator decision.
Does client-side validation make the form secure?
No. It can improve feedback. The trusted service must independently validate the request and enforce permissions.