New editorial guide, published 17 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
An error message is often written after the rest of a form is finished. That makes it easy to describe a technical failure while leaving the reader unsure what to do. Something went wrong may be true, but it does not distinguish an incomplete field from an unavailable service or an uncertain submission. Useful form copy begins with the whole task: what information is needed, why it is needed and what happens after submission. The examples here describe a fictional enquiry form. They are writing exercises, not an operating form on this site or a complete accessibility conformance audit.
Prevent avoidable confusion before validation
Start with the label and any instruction needed to answer correctly. If a date must use a particular format, explain that before the reader submits it. If a field is optional, do not make the person discover that by deliberately leaving it blank and testing the form. Ask whether the requested precision is necessary. A form that needs only a month should not demand a full date merely because a component supports it. The easiest error to recover from is sometimes the one removed by asking a clearer, smaller question.
Keep examples distinct from prefilled answers. An example should show the expected structure without becoming submitted data when someone overlooks it. Avoid relying on placeholder text as the only explanation of a field’s purpose. On a narrow screen, inspect how instructions relate to the relevant control rather than reviewing a desktop mock-up alone. The copywriter should ask the implementer how the label, hint and error are associated in the interface. Good words can still fail if they are visually or programmatically attached to the wrong field.
Describe the problem and the available correction
A helpful field error names the issue and suggests a repair when the system knows one. For the fictional enquiry form, enter an email address in the format shown is more actionable than invalid input. But the wording must match the actual validation rule. Do not tell someone that an address does not exist when the system has only checked its syntax. W3C’s form notification tutorial explains the value of clear error identification, corrective guidance and a programmatic association between a control and its message. Wording and implementation need to be checked together.
Be precise without exposing unnecessary internal details. An attachment that exceeds the accepted size needs the limit and a way to choose another file, not a database error. A service outage should not be blamed on a field the reader completed correctly. If the system cannot identify the cause, state that uncertainty and give the known next step. Avoid cheerfulness that minimises lost work. A calm statement of what happened, what remains saved and what the reader can do is more useful than a playful apology followed by an unexplained retry button.
Make multiple errors navigable
A long form can contain several independent problems. An error summary should help the reader find them rather than forcing a repeated cycle of submit, discover one problem and start again. Use consistent names between the summary and the fields. If the field is labelled project date, the summary should not call it commencement timestamp. Ask the implementation team how focus and navigation behave after submission. A message can be technically present on the page while remaining difficult to locate for someone using a keyboard, magnification or a screen reader.
Do not use colour alone to explain whether information is acceptable. Text should communicate the state and the required action. Preserve correctly entered information when that is appropriate and technically supported; if information cannot be retained, explain the consequence before a retry. The writer needs the actual behaviour from the implementer rather than assuming every field survives a failed submission. Test a realistic multi-error example. Can a person identify each issue, move to it, make the correction and tell which problems remain? That sequence matters more than how attractive a single red message looks.
Distinguish a rejected submission from an uncertain one
Imagine that the enquiry form times out after the person selects Send. There are at least two different possibilities: the request never reached the service, or the service received it but its response did not reach the browser. The interface should not claim that nothing was submitted unless the system can establish that. Ask the technical owner which states can be distinguished and whether duplicate submissions can be recognised. This is not a problem a writer can solve by choosing a friendlier synonym for failure. The copy depends on the transaction’s real boundaries.
Where the system cannot confirm the outcome, say so and provide the approved next step. A useful design might offer a reference number or an existing enquiry-status route, if those capabilities genuinely exist. Do not invent either in the copy. If retrying can create a duplicate, the product needs a considered behaviour for that situation rather than an instruction to click repeatedly. Record this as an implementation question during review. It is better to leave a clearly identified unresolved state in the specification than to publish confident wording that describes a capability the service does not have.
Give success messages a bounded promise
A success message should identify what was completed and what comes next. Your enquiry was received is not the same as your request was approved. If the workflow includes a response expectation, use the timeframe the responsible team has actually approved and can maintain. Avoid promising immediate contact because it sounds welcoming. Where a confirmation email is part of the design, say what it contains and what to do if it does not arrive, using a real supported path. If no email is sent, do not suggest the reader should wait for one.
Keep a record the person can use where the task calls for it. A visible reference, submitted summary or downloadable receipt may help, but only if the system provides it securely and accessibly. Consider shared devices and sensitive content before exposing a full submission. The copy should explain the next decision, not repeat every field for decoration. Test the success state separately from the form’s happy-path screenshot. Can the reader distinguish receipt from approval, understand whether they need to act again and return to a sensible location without accidentally submitting the same request twice?
Review the state map, not isolated strings
Create a small state map covering empty fields, invalid formats, rejected files, service unavailability, uncertain submission and confirmed receipt. For each state, record the trigger, displayed text, available action and technical owner. Use realistic sample content while keeping personal details fictional. Review the map with the implementer and whoever handles resulting enquiries. They can identify promises the workflow cannot fulfil. Keep source strings connected to their states so a later translation or redesign does not reuse the wrong message simply because two failures both contain the word error.
Finally, exercise the complete task on a narrow screen and with keyboard navigation. Correct several fields, submit again, follow the success path and inspect whether messages remain understandable in context. This does not replace a full accessibility review, but it can expose broken assumptions early. Record failures in terms of the reader’s task: could not locate the second error is more informative than copy needs improvement. Revise the behaviour or wording at the boundary that failed, then repeat the affected path. Form copy succeeds when the person can continue with a truthful understanding of the current state.
References & further reading
From the recovered archive
- Customer Service in a Home Business · captured 20 February 2021
- How To Create A Blog From Scratch And Make Money From It: The New Blogger's Guide · captured 25 May 2021