Make form errors easier to understand and fix

Distinguish a missing answer from an unusable one

A missing email address and an email address in an unrecognised format are different problems. The first needs an answer; the second needs a correction. During testing, trigger both. A single generic instruction can make someone repeat an answer without understanding what needs to change.

GOV.UK recommends wording that matches the question and explains the correction. Apply that idea when reviewing the form as a whole: if an error says “Project size” but the visible label says “Tell us about your team”, the person has to work out which question it refers to.

Fix the question before adding more warnings

If a range, length or number of choices matters, explain it before submission. A visitor should not have to send the form to discover a rule you already knew. Make the rule necessary for the task; an arbitrary short message limit can reject a useful explanation without improving the request.

Take one failed test answer and ask why a reasonable person might enter it. “Budget” could mean a total, a monthly amount or an amount before tax. More strict validation cannot resolve an ambiguous question. Rename the field and explain the expected amount before adjusting the rules.

Keep instructions and configuration in agreement. If help text says a visitor can choose up to three days but the field allows two, either choice will feel like a trap. Recheck explanatory copy whenever you change a limit.

Check the route back to the answer

W3C recommends understandable error feedback and links from an error list to the affected controls. Accessible Forms provides a linked summary and field-level guidance. Test this behaviour in the WordPress page where people will use it, including any sticky header or theme styling.

Send a test form containing two mistakes. Follow the first error link, correct the answer, then reach and correct the second. Check that the field and its instructions are visible at each point. Repeat the route without a mouse and with enlarged text; a useful sentence still fails if a visitor cannot find the place to act on it.

Notice whether entered answers remain available during ordinary validation recovery. If a file must be selected again, that needs separate guidance. Do not assume every failure behaves like a simple missing-field error: a server upload limit or lost connection can interrupt the request earlier.

Separate answer problems from service problems

A storage failure is not a reason to mark a visitor's email address wrong. In your test notes, distinguish an answer that needs editing from a request the service could not complete. The recovery path and the person responsible for fixing it differ.

Keep a small repeatable set of test cases for every important form: one missing required answer, one malformed answer, one limit boundary and one successful correction. Review the stored test entry separately from notification delivery. An accepted submission and a delivered notification are different outcomes, and an error review should not blur them.

Using Accessible Forms

Improve labels and rules in the builder, then test the generated errors instead of assuming the normal preview covers every state.

In Free: Free provides field validation, linked error summaries and associated inline errors. A private preview can check validation without creating a real entry or email.

With Pro: For conditional questions, file uploads and answer comparisons, test the additional failure and correction paths on a staging page.