A visitor writes a careful enquiry, presses send and receives “Something went wrong.” The message disappears from the form. The website has turned a willing customer into someone deciding whether to start again.
Error handling is part of the contact experience. It deserves the same care as the success screen and the design of the send button.
Distinguish a field problem from a service failure
If an email address is incomplete, identify that field and explain the correction. If the server cannot accept the submission, do not blame the visitor’s input. The message should reflect what the system actually knows.
W3C WAI’s form-notification guidance explains the value of clear errors and appropriate associations between messages and controls. Colour alone is not enough to communicate which field needs attention.
Preserve the work where it is appropriate
Keep entered text available when a correction is needed, subject to sensible privacy and security handling. Avoid making a person retype a long message because one required field was missing.
A practical field message might say “Enter an email address in the format [email protected].” A service message might say that sending failed and offer a retry or a verified alternative contact route. Do not say the message was received unless the system has actually accepted it.
Make recovery accessible
Help keyboard and screen-reader users locate the problem. Use visible labels, meaningful instructions and programmatic relationships between fields and errors. After submission, focus management and announcements should fit the form’s implementation and be tested with assistive technology.
Do not expose stack traces or internal infrastructure details to visitors. Useful language can explain the next action without leaking technical information or making a promise the support team cannot keep.
Test the unhappy paths
Try an empty required field, an invalid address, a long message and a simulated server failure in an authorised test environment. Verify that the user can recover and that a retry does not silently create multiple submissions.
Then check the receiving side: does a successful test message reach the intended workflow? A polished confirmation screen can conceal a delivery problem. The complete contact journey ends with a received enquiry and an understandable expectation about what happens next, not merely a button that animates when clicked.