When should a form show errors?

Problem

People keep getting stuck while filling in a form.

Choose timing for the task

W3C illustrates several useful moments for feedback. It does not prescribe submission-first validation for every form.

• During typing: show useful feedback such as username availability or password strength while someone chooses a value. Avoid treating a partially entered value as a finished answer.
• After leaving a field: check values that need a complete format, such as an expiry date, once the user moves on.
• On submission: check the submitted values and explain remaining errors. Keep valid input so the user can correct the problem without starting again.

Which checks need the server?

Check simple requirements in the browser without a request, such as whether required fields are filled in, values fit a length limit or an email address has the expected format. Use the server for checks that depend on permissions or current data, such as whether a username is taken.

You do not need a separate API call for every rule. The request that submits the form can check permissions, required values and duplicates before saving anything. A separate validation request is an optional way to give earlier feedback, not a requirement for each check.

For example, when creating a relation between two records, the browser can check that both records have been selected. The server must check whether the user is allowed to create that relation. A permission failure means the action is not allowed; it does not mean a field has the wrong format.

W3C and MDN explain that browser checks can be bypassed, so the server must also enforce the rules when accepting the submission, including requirements already checked in the browser. OWASP requires permission checks on every request. An earlier permission or availability result does not replace those checks.

When should a server check run?

W3C describes feedback after submission, during typing and when leaving a field. Its username example shows how earlier feedback can avoid repeated submissions; it does not prescribe an API design or one timing rule for every form.

Our recommendation: add an early server check when it helps someone choose a valid value. Check after a pause or when they leave the field, once there is enough input to evaluate. Otherwise, check on submission.

• Show a pending message such as “Checking availability…” rather than success before a response arrives.
• If the input changes, remove the previous result and only show a response that matches the current value.
• If the request fails, say “Could not check availability. Try again.” Do not mark the value invalid because the connection failed.
• For an actual input error, identify the field and explain the problem in text. Suggest a correction when known, unless doing so would compromise security or the purpose of the form.

Example

Implementation

1. Use visible labels, identify required fields, and explain unusual formats before input.
2. On failed submission, preserve values and describe each error in text with a useful correction.
3. Use a linked error summary when errors may be missed. Move focus to the summary, or to the first invalid field in a short form.
4. For custom validation, associate inline errors using aria-describedby and set aria-invalid after detecting an error. Clear each error when its failing rule has been checked again and passes.

Tradeoffs

Earlier feedback can prevent wasted effort, but interruptions can make typing harder. Server checks need pending and failure states; a network failure is not invalid input.

References

• W3C · Form notifications and validation timing
• W3C · Validating input
• W3C · Error identification requirements
• W3C · Error correction suggestions and exceptions
• MDN · Browser validation and server enforcement
• OWASP · Permission checks on every request

Related patterns