Make Form Errors Specific Enough to Fix

A practical approach

Step 1

Give each field a persistent label and explain unusual requirements before submission. Use examples only when they reduce ambiguity.

Step 2

Associate an error with its field and provide a summary for forms with several problems. Make the path from summary to control usable with a keyboard.

Step 3

After a failed request, preserve entered values and state whether the submission was saved, rejected or not confirmed.

Worked example

A workshop enquiry requires an email address and a learning goal. ‘Please fix the form’ leaves the visitor guessing. ‘Enter an email address we can reply to’ beside the email field is actionable. If a network timeout occurs, the page should avoid claiming the enquiry definitely failed when the server may have received it.

A mistake to avoid

Placeholder-only labels disappear while people type. Colour-only errors can also be missed. Use visible text, suitable semantics and clear focus behaviour alongside styling.

Try it yourself

Submit a sample form with two invalid fields using only the keyboard. Check whether you can identify both errors, reach the controls and resubmit without re-entering correct information.

Your implementation checklist

• Labels remain visible during entry.
• Errors identify the affected field.
• Correct input survives validation failure.
• Server-side validation is still enforced.