How should a form guide visitors to the fields they need to fix?
A visitor can reach the bottom of a long enquiry form, press Submit and miss an error displayed near the top. The design decision is not only how to announce a problem, but how to help the visitor reach the input that needs attention. An error summary, local explanations and preserved answers should be considered together. The enquiry form below is a hypothetical implementation example.
Describe the problem rather than just colouring a field
W3C's error-identification guidance addresses identifying an automatically detected input error and describing it in text. A differently coloured box does not explain what went wrong. In our hypothetical enquiry form, a specific message about the email entry is more useful than a generic failure label. Reflect the actual validation rule, and review rules that reject legitimate formats unnecessarily. The error message must not tell the visitor to make a correction that the application does not actually require.
Connect the summary and local message to the same action
The GOV.UK Design System combines an error summary with messages beside the affected inputs and links from the summary to the relevant answer. When adapting that concrete interface pattern, use a short heading and a clear list. The summary and local message should describe the same problem. An email-format warning in the list should not become an unrelated required-field warning beside the input. Check that activating the link allows the visitor to continue with the correct field, rather than merely scrolling nearby.
Review focus and preservation of answers together
After an unsuccessful submission, design a focus sequence that makes the new state noticeable to keyboard users; the GOV.UK pattern moves focus to the summary. Check your implementation with actual keyboard and screen-reader use. In the hypothetical form, an invalid email should not erase the project description, selected service or other valid answers. Visitors should not need to re-enter everything. If an uploaded file must be selected again, explain that separately and clearly instead of leaving the field's state ambiguous.
Distinguish an input error from a system failure
A missing email and an unreachable server are different problems. Asking visitors to correct valid answers after a connection failure is misleading. Do not announce success if it is unknown whether the request was saved. Explain what is known and what safe next action is available. Once an input error is corrected, the visitor should be able to continue through the same form. If repeating the action could create duplicate submissions, that needs a separate technical check rather than a more colourful validation message.
Try several error paths before accepting the form
Leave one required answer empty, make another invalid and submit at a narrow phone width. Does the summary list the right fields, do its links work, is keyboard focus visible, and are the other answers preserved? Correct one error and try again; the old warning should no longer remain beside a valid answer. Do not judge the form only by its ideal success path. Include these error scenarios in web design acceptance checks and review them alongside the real enquiry workflow. Passing these checks is not proof of complete accessibility or a measured conversion increase.
Frequently asked questions
Is a summary unnecessary for a single error?
GOV.UK uses the summary for a single validation error too. Evaluate both noticing the error and reaching its correction in your own form.
Is the browser's built-in warning enough?
That depends on the actual form. Test whether client and server validation provide a consistent, understandable correction route.