Form error messages best practices: the wording

Error text is often written by the person who built the validation, who knows the rule by name. The message says Invalid input, Field required or Something went wrong, and that is all the visitor gets. A stranger scanning a long form cannot tell which of six boxes holds the problem, so they retype everything or press Send again. The wording is accurate for the developer and no use to the person holding the phone.

• Does the message name the field, in the same words as its label?
• Does it say the fix, such as the format to use, and not only that a value is wrong?
• Does the message sit beside its field, not only at the top of the form?
• Do the typed values survive the error, or does the form clear them?
• After an error, does the focus move to the first field that needs a fix?

Take one failure, a phone number with a space in it, and compare three messages. The wrong one says Invalid phone, which names the field and gives no way out. The better one says Phone number is not valid, which is accurate but still asks the visitor to guess the rule. The right one says Use digits only, with no spaces or dashes, which names the rule in the visitor's terms and the change to make. Write each message as the change the visitor must make, and add the reason only when the change is not obvious.

A message at the top of a long form is read once, if at all, and then the visitor has to find the box it refers to. Put each message directly under the field it describes, in the same style as that field's hint text, so it reads as part of the field. Link the message to its field so a screen reader announces it when the visitor reaches that box. A red outline on the box helps, but color alone does not reach a visitor who cannot tell the shades apart, so the words must carry the meaning.

A form that clears its fields after an error makes the visitor do the work twice. Keep every valid value in place, including the long address they typed and the company name that was correct. Move the focus to the first field that needs a fix, so the visitor does not have to scroll back up to find it. A form that reloads the whole page after a failed submit can lose input the visitor never saw go, and the loss is easy to miss on a laptop, where the reload looks instant. Test it on a phone over a slow connection, where the reload takes long enough to notice.

Forms change after launch: a new password rule, a country list, a required tax field, a second step. Each new rule adds a message, and the old copy may not describe it. After each change, submit the form with each failure on purpose, one at a time, and read the message each time. Compare the wording with the last run, and check that the field named in the message is the one that is wrong.