Write form errors that help people recover

A useful form error identifies the problem and tells the person how to fix it. Preserve entered data when possible and connect the message to the affected field. “Something went wrong” may be unavoidable for a system failure, but it is poor feedback for a specific input problem.

Separate input errors from system errors

An invalid email, a required field, a declined operation, and a network failure need different recovery paths. Do not ask the person to correct their information when the system failed to save it. Likewise, retrying a request will not fix a missing required field.

A field-level example

<label for="email">Email address</label>
<input id="email" name="email" type="email"
       aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter an email address with an @ sign and domain.</p>

Show the error only when that problem has actually been detected. This fragment is not a complete validation system. Your server should validate submitted data as well as any client-side checks.

Compare fictional messages

The recovery promise must match the implementation. Do not say a draft is preserved unless it is.

Test the recovery, not just the message

Trigger the error, correct it, and submit again. Confirm that the message clears at the right time and that focus or an error summary helps the person find the relevant field. Keep repeated status announcements from overwhelming assistive technology.

Use W3C’s forms guidance as a reference for labels and notifications, then inspect your actual flow. A reassuring error message cannot fix lost data or a button that retries the wrong operation. The copy and the behavior need to agree.