Form error message: write a correction people can use

A form error message should help someone find and correct the relevant input without inventing rules or blaming an unknown system outcome. Use four fictional states to save a practical copy specification and the checks an implementer still needs to run.

Last updated: 18 October 2026.

What should a form error message help someone do?

A form error message should identify the relevant field and make the next correction understandable. An alert saying something went wrong may announce a problem without helping the person continue. This exercise turns four fictional failure states into a small copy-and-test handoff.

You will not build a form, submit an enquiry or change browser validation. The deliverable is editorial: a proposed message tied to a supplied rule and an expected follow-up check. Applying those words, associating them with controls and verifying the resulting behavior remain implementation work.

Imagine a workshop booking service that wants friendlier error text. Before choosing a friendly tone, establish which values the service actually accepts. A polished message with an invented limit can be more misleading than a rough message that states the right rule.

The conversion optimization guide provides a broader process for finding obstacles. Our narrower output is a four-state message specification. It is not a conversion experiment, platform configuration tutorial or prediction of increased bookings.

Capture the acceptance rule before rewriting the sentence

Validation means checking whether supplied information meets a defined rule. The copywriter should not silently decide that rule. A required field, an allowed value and an accepted file format are different constraints, even if a form currently uses the same generic warning for all three.

Our independent teaching example uses these fixed rules: an organisation name cannot be blank; delivery day must be Monday or Wednesday; an attachment must be PDF; and the result of a connection interruption is unknown. These are fictional service rules, not defaults for all forms or a claim about a named form provider.

Do not add a minimum organisation-name length, introduce Friday delivery or invent a file-size limit. If a missing condition prevents good advice, put it in the open-questions column. That is better than manufacturing a rule because the message otherwise feels incomplete.

The service-routing guide concerns branches and endings chosen from answers. Here the route already exists. The decision is what to say when a specific input cannot be accepted, and when not to blame the input at all.

Rewrite four supplied states without inventing a fifth rule

Copy the supplied states before looking at the proposed text. A useful check is whether another person could point to the field and describe a permitted correction using only that sentence and the visible choices. Keep any unresolved system condition outside the list of known input errors.

E1 concerns a blank value, not spelling or the legal status of an organisation. E2 gives the allowed choices without adding another delivery day. E3 asks for an accepted document; renaming an image with a .pdf extension does not convert its contents into a PDF.

E4 deliberately has no final retry instruction. The record does not say whether the server accepted the enquiry. A promise that retrying cannot create a duplicate would be invented. Ask the implementation owner how the outcome is checked and how repeated attempts are handled before approving a next-action sentence.

Separate identifying an error from suggesting a correction

W3C’s error-identification explanation describes identifying an automatically detected input error and describing it in text. Its separate error-suggestion explanation discusses providing known correction suggestions, with an exception where doing so would jeopardize security or the purpose of the content.

In E2, naming delivery day locates the problem. Naming Monday or Wednesday supplies a correction route. In E4, no violation of an input rule has been established, so neither a blame statement nor a made-up valid format is justified.

Those source principles do not make this document a complete accessibility implementation. A developer still needs to verify the connection between message and field, interaction behavior, announcements where relevant and the resulting form state. This exercise only specifies words, their triggering condition and questions requiring a decision.

The keyboard enquiry-path review distinguishes reaching a control from operating it. Our task begins after an input problem has been supplied. A working opening button cannot prove that an error message helps recovery, and good recovery wording cannot prove keyboard operation.

Give the implementer a condition and a follow-up check

For E1, supply a blank organisation value as the triggering condition. The proposed message asks for that field to be completed. A filled field should no longer receive this particular missing-value message, although another independently defined rule could still matter. Do not treat one corrected field as proof of a completed submission.

For E2, specify Friday as the rejected value and Monday as the correction case. The expected distinction is that the delivery-day rule rejects the first and accepts the second. Keep the exact result to be observed in a separate column rather than writing a successful test result before anyone has tested it.

For E3, specify an image and a valid PDF as future test inputs. The implementation owner must establish how document acceptance is checked. This article neither installs a file-validation mechanism nor demonstrates that a server inspected a document correctly.

The training registration walkthrough covers a broader response-collection process. Its successful setup does not establish that these new words have been applied on your own page. Ask for the page version, condition, visible message and observed result of each specific check.

Save a complete copy-and-test handoff

On Windows, search Start for Notepad, open it and create a new document headed Delivery form messages V1, fictional exercise. Copy the rule and proposed message for E1 through E4. Keep the original and revised text distinguishable so a reviewer can see what changed without reconstructing the input from memory.

E1: blank organisation → Enter an organisation name.
E2: Friday → Choose Monday or Wednesday for delivery day.
E3: JPEG → Select a PDF for the attachment field.
E4: interrupted connection → outcome unknown, no proven input error.
Open question: how is acceptance checked and repetition handled for E4?
Copy status: E1–E3 proposed; E4 continuation instruction pending.
Implementation status: none applied or tested on a live form.
Owner roles: form implementation and business-rule approval.
Future check: rejected input, corrected input, message and actual result.

Press Ctrl+S, choose Documents and save the document as delivery-errors-V1.txt. Close the editor. Open Documents in File Explorer and double-click the saved file. Confirm that the unresolved E4 question survived and that no line claims a live test passed. A saved artifact is useful only if the next person can distinguish a copy proposal from an implementation result.

A suggested fifteen-minute practice budget covers reading the supplied rules, drafting three corrections, separating the unknown system state and saving the result. It is a planning allowance, not measured participant speed. No paid service or customer data is needed.

For a real handoff, add the page identifier and the person responsible after they have accepted the work. Naming an owner role in this teaching document does not mean a colleague has already received or agreed to an assignment. Share it through your normal internal process when appropriate.

What remains before these words are ready for users?

The implementation owner should check a rejected and corrected input for each supplied rule. Does the right message appear beside the right field? Does the old error disappear when that rule is satisfied? Are unrelated entries preserved as intended? Clear copy alone cannot answer those behavior questions.

For E4, determine the acceptance state before approving continuation advice. An enquiry known to be received, one known not to be received and one whose outcome remains uncertain may require different instructions. Do not promise retry safety, response times or duplicate prevention without verifying those properties.

In earlier public writing, Anar described delaying projects by chasing perfection. The principle applied here is to finish a bounded, inspectable piece of work while keeping its unanswered question visible. It is not a claim about a personal form-redesign project, accessibility engagement or measured customer improvement.

The broader form journey still matters.

Image text-alternative review is another bounded editorial check rather than proof of the whole interface. Treat each completed artifact as evidence for its own scope, not as a shortcut around testing the final page.

Your practical outcome is a clearer work request: a known rule, a proposed sentence, a triggering condition and a correction case. That is more actionable than make the errors friendlier. Whether the implemented experience becomes easier to use must be established through subsequent observation, not inferred from the existence of this document.