# 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 ```html
Enter an email address with an @ sign and domain.
``` 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 | Problem | Unhelpful | More useful | | --- | --- | --- | | Missing date | Invalid form | Choose a booking date | | Session expired | Failed | Your session expired. Sign in again; your draft is still here | | Network unavailable | Wrong input | We could not save the draft. Check your connection and retry | 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. --- SkillStall · 2026-10-02 W3C WAI: Forms tutorial: https://www.w3.org/WAI/tutorials/forms/