People should not have to solve the interface
Imagine a website-project enquiry form. A visitor describes the task, adds a contact and presses submit, only to see a red outline. Is a phone number missing, has the connection failed, or has the enquiry already been sent? That uncertainty is a design problem, not a failure of attention. A useful mockup should cover unfinished input, multiple errors, waiting and success, not just a perfectly completed form. These small states determine whether the whole journey makes sense.
Explain what the field needs
Each field needs an understandable label; WAI recommends associating it with its control. A format example does not replace the label. In our imaginary brief, the phone number could be marked optional when email is enough. A full business address should not be demanded merely out of habit when it serves no purpose in the first conversation. Before drawing the form, list its fields and explain why each exists. If a field has no clear purpose, reconsider it. W3C WAI: Labeling Controls
Name the actual problem
Detected errors need a textual description identifying the affected field; colour alone is insufficient. Instead of a vague invalid-data message, a missing contact field might say “Add your email address”. For our enquiry form, prepare separate wording for an empty contact, an incomplete description and an unavailable service. Combining them into one red banner hides an important distinction: correcting input and recovering from a submission failure require different actions. W3C: Error Identification
Offer a route to recovery
When a correction is known and safe to suggest, explain it. If a field has a specific length restriction, describe that restriction rather than asking people to try again. In a longer form, an error summary linking to affected fields can complement nearby guidance. Avoid messages that cover the entered text. Walk through the process with a keyboard: a person should be able to find the problem, correct it and continue without rewriting the entire project brief. W3C: Error Suggestion
Validation is not delivery
Browser-side validation does not replace validation on the server. A correctly formatted address also does not prove that a message was delivered. Outcome text should match the system’s actual response. In our example, an enquiry being saved is different from a failed submission. Do not promise a callback in five minutes unless that process actually exists. Consider repeated clicks, a slow connection and reopening the page as separate situations rather than assuming every request follows the happy path. MDN: Client-side form validation
Test more than success
WAI recommends feedback for both successful and unsuccessful submissions. Before launch, try an empty form, one incorrect contact, a long description, correction, success and a service failure. Check enlarged text, a phone and keyboard navigation; accessibility also requires testing with assistive technology. This short checklist is not a certification. It is a practical way to discover whether the form helps people move forward instead of leaving them to interpret an unexplained red border. W3C WAI: User Notifications