The decision that matters
Place field-specific guidance near the field and provide a useful overall status for submission failures. Distinguish invalid input from a temporary service problem. Do not clear a message or attachment when the server rejects the request. Keep labels visible instead of relying on placeholders, and ensure error states are communicated in text rather than color alone.
A practical scenario
If a contact form cannot reach the email service, “Invalid form” is misleading. Explain that the inquiry could not be sent, keep the entered message and offer the contact email as an alternative. If the email address itself is malformed, point to that field. These are different recovery paths and deserve different language.
Before you ship
- Keep entered values after a failed submission.
- Associate labels and error text with their controls.
- Prevent repeated submission while showing a clear in-progress state.
A useful next step
Test a missing required field, an invalid email and a server failure. Use keyboard navigation to find and correct each issue. The form is ready when a person can recover without re-entering unrelated information or wondering whether they accidentally sent the request twice.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.