Form error messages: best practices for wording and placement

The best practices for form error messages fit in one sentence: show the message next to the field, say in plain words what went wrong and how to fix it, show it when the person has finished with the field or pressed the button rather than while they are typing, and never clear what they already entered. Everything else is detail about wording, colour and summaries. And because every error is an instruction that arrived too late, the most effective practice happens before any message is written: put the rule in the label so the mistake never happens.

WCAG sets the floor. Success criterion 3.3.1, Error Identification, requires that a detected error is identified and described in text. Success criterion 3.3.3, Error Suggestion, adds that the message should suggest a correction when one is known. W3C’s own illustration is the difference between “Email is not valid”, which meets the first, and a message that also gives the expected format, which meets both.

When to validate

Early enough to help, late enough not to nag. Baymard Institute’s usability testing found that inline validation, which checks an answer as the person fills in the form, saves time and helps people fix mistakes while the answer is fresh, yet roughly a third of the e-commerce sites in its benchmark offer no inline validation at all. The same research also found the opposite failure: validation that fires the moment a field receives focus, or while the first characters are being typed, tells people they are wrong before they have had a chance to be right.

Baymard’s three rules are to avoid premature validation, to remove the message as soon as the field is corrected, and to confirm correct answers as well as flag wrong ones. In practice that means checking a field when the person leaves it.

A form built in this builder checks at fixed moments rather than field by field. A missing required answer is named when the person presses Submit, or Next on a paginated classic form, which checks only the fields on that step. Length limits and number ranges are checked when the whole form is sent. That makes prevention the main lever, and the payroll change form shows how far it goes: only seven of its twenty two fields are required, and every section says out loud that it can be skipped when it does not apply. Fewer required fields means fewer moments where a message can appear at all.

Where the message goes

GOV.UK puts each error message after the question text and hint, uses a red border to connect the message to its field, and refers to the specific part of the question when only one part is wrong, such as a year in a date. It also insists on keeping every answer when showing an error, the ones that passed and the ones that failed, so people can see what went wrong and edit rather than retype.

For screen reader users, GOV.UK’s component includes a visually hidden “Error:” before the message, so it is heard as an error and not as ordinary text. Whatever system you use, test with a screen reader that a message is announced when the form is sent.

On a published form built here, the message naming a missing field appears as a short notice when the button is pressed, and the answers already entered stay in place. A paginated classic form surfaces problems one step at a time, which would keep each round small on a long application such as the rental application form, where 10 of 27 fields are required.

Wording formulas

GOV.UK’s guidance is the most complete published set of rules, and most of it reduces to three.

Describe what happened and how to fix it. Plain English, positive language, straight to the point. No technical jargon, no “please”, which implies a choice, no “sorry”, which fixes nothing, and no “valid” or “invalid”, which add nothing. No “oops”.

Be specific. GOV.UK names the generic messages to avoid: “An error occurred”, “Answer the question”, “Select an option”, “Fill in the field” and “This field is required”. A text field can be empty, too long, too short, in the wrong format or using characters that are not allowed, and each needs its own message.

Use instructions for empty fields and descriptions for broken rules. “Enter your first name” for an empty field. “First name must be 35 characters or less” for one that is too long. Use both kinds, consistently.

There is one builder specific rule on top. The form builder writes its own message for a missing required field, and there is no setting for custom error text. A classic form says the label followed by “is required”. A conversational form says “Please answer:” followed by the label. So the label is the message, and it should be written to survive that sentence. On a classic form, a noun phrase works best: “Driver licence or passport number is required” reads cleanly, while a question such as “Why are you leaving?” followed by “is required” does not. On a conversational form, a question reads naturally after “Please answer:”. The rental form’s required consent field is labelled simply “Consent”, which produces a message that says what is missing but not which of its two boxes still needs a tick; a longer label would carry more.

Uploads are the one place the builder’s messages already follow the specific rule. A file that is too big produces a message naming the file and the size limit, and choosing too many files produces a message saying how many more can be added.

Colour and icons

Colour helps people who can see it and fails everyone else. Success criterion 1.4.1, Use of Color, rules out colour as the only way of conveying information, which is why GOV.UK pairs its red border with a text message rather than relying on either alone. An icon beside the message is a useful third signal, not a substitute for the words.

The same applies before an error exists. A classic form marks required fields with an asterisk after the label, a symbol that survives greyscale, and a line near the top explaining what the asterisk means removes the guesswork. The dropdown against radio buttons note covers the related choice of showing every option at once, which prevents the “Select an option” error on short lists because the choices are always visible.

A summary at the top

On a long page, a message beside the field is not enough, because the field may be off screen. GOV.UK’s error summary appears at the top of the page whenever there is a validation error, even a single one, under the heading “There is a problem”, with a link to each answer that has an error and wording identical to the message beside the field. It also recommends adding “Error:” to the start of the page title so screen readers announce it early.

A form built here names the first missing required field rather than listing them all, so a person who skipped three fields meets three messages in turn. Two things make that painless: fewer required fields, and a paginated layout on long forms so each check covers one step. The warranty claim form takes a third approach and asks for the serial number and proof of purchase before the description of the fault, with the location of the serial written into its label, “under the frame, on a silver label”.

Messages that work, row by row

The table at the end of this article lists thirteen common errors, from an empty required field to a problem on the service side, with a weak message and a stronger one for each. Field names come from the example forms on this site. Use the good messages two ways: as the wording for any validation you write yourself, and as a guide to labels and sub-labels in this builder, where the rule has to be visible before the answer rather than after it. The abstract submission form is the model for that second use: “Background, up to 700 characters” states the limit in the label, so the too long error never needs to appear.

Common mistakes

Validating on the first keystroke. People are told they are wrong before they have finished being right.

Clearing the form after an error. Keep every answer, including the ones that failed.

Generic messages. “This field is required” on ten fields tells nobody which ten.

Colour as the only signal. A red outline means nothing in greyscale or to a screen reader.

Limits nobody could see. A maximum length that only appears in an error message after the form is sent is a rule that was hidden.

Build it

Validation in the builder is set per field: a Required switch on every input, minimum and maximum length on short and long text, and minimum and maximum value on number fields. File upload adds a maximum number of files, a maximum size and two allowed type toggles, images and PDF. The form field types page lists all 41 component types and which builder offers each, and the form builder components guide shows every setting. Because there is no custom error text, put limits and formats in the label or the sub-label, and put longer rules in a paragraph component above the field, since a classic field’s description box is not shown on the published form except on file upload and photo fields. The companion article on rental application form fields covers what the embedded form asks and why.