Your form says “error” — but not how to continue
Unclear validation errors lose qualified leads and exclude users. Learn how to audit forms for understandable, accessible error recovery.
A contact form can work technically and still lose people.
The submit button responds. The backend is available. The message could be delivered. Yet after submission, the page shows only a red outline, a message such as “Invalid input,” or no visible explanation near the field that caused the problem.
To the website, this is a validation error. To the person using it, it may be the point where they leave.
The quiet conversion blocker
Forms often sit at the end of a valuable journey: an enquiry, registration, appointment, application, purchase, or support request. Anyone who reaches that point has already shown intent. Poor error handling therefore does not merely lose random traffic; it often loses a qualified lead.
Common consequences include:
- repeated unsuccessful submission attempts,
- correcting the wrong field,
- losing entered data after a reload,
- abandoning the process on mobile,
- avoidable support requests,
- excluding people who use keyboards, screen readers, zoom, or speech input.
The failure is rarely dramatic. That is exactly why it can remain unnoticed for months.
Five red flags you can test quickly
1. Errors are communicated by colour alone
A red border does not explain which field is wrong or how to correct it. Errors should also be described in clear text.
“Invalid input” is only marginally better. A useful message would be: “Enter a complete email address, for example name@company.com.”
2. The message is not connected to the field
Text placed visually beneath an input may look obvious to a sighted user. Assistive technology does not automatically understand that relationship.
A robust implementation programmatically connects the message to the control, for example with aria-describedby. When an error is present, aria-invalid="true" can communicate the state. The goal is not to collect ARIA attributes; it is to ensure the field name, error state, and explanation are announced together meaningfully.
3. Focus stays on the submit button
In a long form, the first error may be far above the visible viewport. If keyboard focus remains on the submit button, users may not realise that the submission failed.
A clear error summary at the start of the form can name the affected fields and provide links to them. After a failed submission, moving focus to that summary can make the recovery path immediately understandable.
4. Instructions exist only as placeholders
Placeholder text often disappears during input and does not replace a persistent label. Required status, expected formats, and examples should remain available after the user starts typing.
When a date must use a specific format, explain that format before or beside the field — not after the third failed attempt.
5. Validation is unnecessarily strict
Phone numbers, names, postal codes, and addresses have more valid forms than many regular expressions allow. Rigid rules create avoidable failures.
Validation should reject invalid or dangerous input while accepting legitimate variation. Client-side validation improves usability, but security-relevant checks still need to happen on the server.
A practical audit flow
A form audit should test more than the happy path. A compact error matrix is more revealing:
- Submit with every required field empty.
- Test each field with an invalid format.
- Navigate the entire form using only a keyboard.
- Test at 200 to 400 percent zoom.
- Test in a narrow mobile viewport.
- Confirm that valid entries remain after another field fails.
- Use a screen reader or accessibility tree to inspect labels, error states, and descriptions.
- Simulate a server failure and check whether the page offers a clear, repeatable next step.
Success feedback matters too. After submission, users need to know whether the request was received and what happens next.
What Website-Pflichtencheck inspects
A technical form review should not stop at confirming that a request was sent. We can inspect:
- visible and programmatic labels,
- required-field and format instructions,
- the clarity of error messages,
- focus management after failed submissions,
- keyboard operation,
- preservation of entered data,
- behaviour during slow or failed server responses,
- mobile layout and zoom,
- technical relationships between controls and errors,
- success messages and actual delivery where safe to test.
The result is not a generic WCAG checklist. It is a prioritised view of what blocks completion, what makes the form harder to use, and what should be fixed first.
Good error handling feels uneventful
A good form does not force people to reverse-engineer its rules. It explains expectations early, describes errors precisely, and returns users to the right place without destroying their work.
That is a useful measure of mature website quality: not whether nothing ever goes wrong, but whether people can recover reliably when it does.
When an important form is responsible for enquiries, bookings, or registrations, test its failure path deliberately — before real prospects are forced to do it for you.