Form Errors and Recovery Paths

Working case

A case intake form accepts location, inspection date, severity, and notes. Reviewer 29 submits an impossible date and a location reserved by another team. The client catches the date; the server returns a conflict for location. If the page wipes the notes and says only 'Invalid submission', the reviewer must reconstruct work and cannot tell what to change. Retain values, attach separate messages, summarize failures, and permit resubmission after clear correction.

Implementation boundary

<label for="inspection-date">Inspection date</label><input id="inspection-date" name="inspectionDate" aria-invalid="true" aria-describedby="inspection-date-error" value="31 April"><p id="inspection-date-error">Enter a real calendar date.</p>

The visible label supplies a stable name, while the referenced message describes the correction. The error state belongs only to a field that currently failed. A full implementation preserves other values, builds a summary linking to invalid fields, and focuses that summary after a rejected submission when several errors need scanning. Server responses should carry stable error codes; English prose is display content, not a machine identifier. Treat conflicts and permission failures separately from syntax validation.

Cost and boundaries

Field errors require a mapping from server codes to controls and translated messages. That mapping adds maintenance whenever fields change, but prevents vague global errors from driving repeated attempts. Validation on every keystroke can create noise or network load; validate at meaningful points such as submit or completed field edits. Preserve entered values through a slow round trip and server-rendered return. Test recovery from a failed input, not only a pristine form.

Failure trace

The server rejects an unassigned case ID, but the client maps every failure to the date field. A reviewer changes the date three times, receives the same error, and abandons the task. The interface has lied about the failure class. Keep transport, validation, conflict, and permission results distinct. Show a field message only when that field can be corrected. If access is missing, explain the boundary without exposing another team's private record.

Verification

• Submit two invalid fields and verify summary, field descriptions, and retained notes.
• Simulate a timeout and verify the page does not blame a field value.
• Correct one field, resubmit, and confirm stale error state clears only after a new result.

Practice drill

Test a rejected submission with a long note and an uploaded-file selection. The browser may not permit restoring a file input after navigation, so explain that limitation and keep other values. Test a translated error whose length wraps across lines, then use keyboard focus to reach the summary and each field. Finally simulate a retry that succeeds and confirm that stale errors disappear when the server accepts the corrected data.

Decision note

Represent error types at the API boundary. Correct a value, retry a temporary failure, and request access are different paths and need different copy.

Common Mistakes

• Showing error color without text.
• Replacing all input with an empty form after rejection.
• Mapping permission and transport failures to arbitrary fields.

Connected lessons

Inclusive Interface Engineering; Accessible Names and Native Controls; Dialog Focus and Interruption Boundary; Reflow, Zoom, and Motion Preferences; Form submission: validate on the server and return field errors; API Evolution and Compatibility Windows; Accessible forms: connect labels, errors, and focus.

Apply and check

Build Project: inclusive case review and review Web Development: inclusive and global delivery quiz.

Further connections

Optimistic Mutations and Rollback; Autosave, Draft Recovery, and Conflicts.