An error message should help someone finish the task, not merely announce that the form rejected them. Ask the development agency to design invalid, incomplete, and interrupted states with the same care as the successful submission.
Related service: Website and ecommerce development- 01Explain the expected input
- 02Validate at a useful moment
- 03Identify the problem
- 04Preserve other answers
- 05Confirm the corrected result
SECTION 01
Decide what actually counts as invalid
Review each field with the business team. Distinguish missing information from unsupported formats and from a service rule the visitor cannot change. Avoid rejecting valid names or international contact details because the form was tested with only one example. Explain optional fields and unusual requirements before the visitor submits.
W3C's notification guidance describes clear feedback and links between errors and controls. MDN explains browser validation and its limits. Ask the agency to specify server-side rules as well as visual messages. The backend should reject unsafe or unsupported input consistently, while the interface helps the visitor correct an ordinary mistake without exposing internal system details.
SECTION 02
Illustrative example: an international inquiry
Imagine a consulting website accepts inquiries from several countries but its phone field permits only a domestic pattern. A legitimate visitor repeatedly sees 'invalid input' and cannot continue. The problem is not solved by making the warning more prominent; the accepted data rule and business requirement need review.
If a phone number is optional for the first response, the form can let the visitor proceed with another contact method. If it is required, explain the accepted format and provide a meaningful correction path. Preserve the completed message and selected service. This hypothetical example illustrates why validation should reflect the audience rather than assumptions embedded in a copied form.
SECTION 03
Test recovery, not just rejection
Ask for examples of a blank required field, an invalid value, a server-side rejection, and a temporary submission failure. The message should distinguish these situations. An error summary can help visitors find multiple problems, while field-level messages explain each correction. Do not move focus unexpectedly while someone is still entering a value.
Acceptance should include keyboard navigation to the affected field, readable messages at increased text size, and a corrected submission that reaches the actual destination. Check that valid input remains available and that confidential data is not written into analytics. The handoff should name who changes validation rules and how those changes are tested. A form with fewer unnecessary restrictions often needs less explanation than one designed around arbitrary constraints.
SECTION 04
Frequently asked questions
Should validation happen while the visitor types?
Only where it helps rather than interrupts. Avoid announcing a field as invalid before the person has had a fair chance to complete it.
Can an error use only a red border?
No. Explain the problem in text and connect the message to the relevant control.
Should a failed request clear the form?
Usually not when the visitor can retry or correct it safely. Preserve appropriate input and explain the current state.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Form User NotificationsW3C WAI
- Client-side form validationMDN Web Docs
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy