A visitor finishes a booking form, presses the button, and receives “Something went wrong.” The page clears their details. Even if the server correctly rejected an invalid date, the interface has created a second problem: the visitor must reconstruct their work without knowing what to change.
Good error handling begins with a practical question: what does this person need in order to finish? The answer usually includes their existing input, a specific explanation, and an obvious route to the relevant field.
Keep the work that is still useful
When a form fails validation, return the values the person entered wherever it is appropriate to do so. Validation means checking whether submitted information meets the form’s requirements. An error in one field should not routinely erase unrelated fields.
Suppose a booking form asks for a name, email address, arrival date, and departure date. If the departure date is earlier than the arrival date, retain the name and email address and show the two entered dates. The visitor can then correct the actual mistake instead of filling out the form again.
Handle sensitive information deliberately. Do not put passwords, payment details, or other secrets into URLs, logs, or persistent browser storage simply to preserve a form. Decide what can remain in the current interface and what must be entered again, then explain any necessary repetition.
Describe the correction in the field’s language
“Invalid input” describes the software’s opinion. “Choose a departure date after your arrival date” describes the action the visitor needs to take. Prefer messages that identify the affected item and the requirement it failed.
Match the wording to the field label. If the form says “Arrival date,” an error about a “start timestamp” adds unnecessary translation. Keep internal variable names and technical exception messages out of the user-facing response.
Be accurate about what you know. An email field can reject a clearly malformed address, but that does not prove whether a plausible address belongs to the visitor. Likewise, a network failure does not automatically mean that their input is wrong. Distinguish an entry problem from a service problem.
Make the error discoverable
A red border alone is insufficient. Add a visible text explanation, and connect it programmatically to the field so assistive technology can convey the relationship. In HTML, aria-describedby can associate explanatory text with an input, while aria-invalid can indicate that its value has failed validation.
Keep the ordinary label in place. Placeholder text that disappears during typing is not a dependable substitute for a label, especially when someone returns to an erroneous field after reading a summary.
For a form with several errors, provide an error summary near the beginning of the form. Its entries can link to the affected fields. Manage keyboard focus deliberately after submission so a keyboard or screen-reader user can discover the result and reach the corrections without searching the entire page.
Test the complete interaction rather than assuming that adding an accessibility attribute solves it. Focus changes and live announcements can become confusing if they duplicate each other or interrupt the user unnecessarily.
Choose the right moment to interrupt
A date is often incomplete while someone is typing it. Announcing an error after each character can punish normal entry. In many cases, checking when the person submits or moves to the next step provides a clearer experience.
Some immediate feedback is useful, such as showing whether a chosen username is available. Even then, account for unfinished input, delayed responses, and rapid edits. Do not allow an older response to overwrite feedback for a newer value.
Browser-side checks can offer fast guidance, but they are not a security boundary. Validate submitted data on the server as well, because browser checks can be bypassed. Where both layers enforce a requirement, their explanations should lead to the same correction.
Test the recovery path as a real task
Give a tester a small booking task and deliberately create a recoverable error. Ask them to correct it and finish without explaining where to click. Include keyboard-only use and an appropriate screen-reader check.
- Submit with an essential field empty.
- Enter a date combination the service cannot accept.
- Correct one error while another remains.
- Confirm that previously valid entries survive.
- Simulate a service failure and check that it is not blamed on the visitor.
For the service-failure case, consider whether a submission might already have succeeded before showing a retry action. The appropriate recovery depends on the operation; blindly repeating a booking or payment can create a different problem.
The final check is simple to state: can someone understand what happened, retain their useful work, make the correction, and recognize success? Treat that path as part of the form’s core design, and the error message becomes a way forward instead of the point where the task ends.