Error messages are the moments when a website admits something did not work, and they are usually written last, by default, by software. The visitor reading one has been interrupted in the middle of a task. What they need is brief and practical: what happened, where, and what to do next. This checklist covers the two places small business sites most often leave visitors stranded: form submissions that fail and addresses that lead nowhere.
The anatomy of a useful message
Accessibility guidance describes three duties. The message should identify that an error occurred and describe it in text, not only through color or an icon. It should show which field or item is affected. And where the system knows how to correct the problem, it should suggest the fix. ‘Invalid input’ fails all three. ‘Enter a phone number with the area code, for example 555-0100’ succeeds, and it reads clearly for a person using a screen reader as well as someone glancing at the screen on a phone.
Review by situation
| Situation | Weak message | What a better message does |
|---|---|---|
| Required field left blank | ‘Error’ | Names the field and says it is needed |
| Email entered without the expected form | ‘Invalid’ | States what an email address looks like and where to fix it |
| Message too long for the field | Silent cutoff | Says the limit before or when it is reached |
| Submission fails on the server | A blank page or technical code | Says the message was not sent, keeps the entries, and offers another route such as a phone number |
| Address not found | Bare technical status text | Says the page is missing and links to the main menu, search and contact page |
| Page was retired on purpose | Generic not-found page | Explains the change and points to the closest topic |
Protect what the visitor already typed
The cruelest form behavior is to clear every field because one was wrong. Check that a failed submission keeps the valid entries in place and moves attention to the first problem. MDN’s material on form validation explains how browsers can flag incomplete or mismatched entries, but built-in prompts differ between browsers and do not replace your own wording. If your site uses custom messages, confirm they appear near the field they concern and are announced to assistive technology, not merely painted in red.
Do not blame the visitor
Tone matters. ‘You entered an incorrect address’ puts the failure on the person; ‘We could not find that address. Check the spelling or choose an option below’ puts it on the situation. Avoid jokes on error pages that could land badly with someone who is already frustrated, and avoid language that exposes technical internals or file locations. A visitor does not need a stack trace, and including one can reveal information the business would rather keep private.
Hypothetical worked example
Hypothetical example: picture an invented landscaping supplier whose quote form turns the whole page red and clears every field when the visitor leaves out a delivery postcode. During the owner’s review, the form’s message says only ‘Please correct the errors below,’ while nothing below says which error. The owner asks the developer for three changes. Name the missing field in the message and place the text beside the field. Keep every other entry after a failed attempt. Add a sentence under the submit button with the office phone number for anyone who cannot complete the form. The owner then sends a deliberately incomplete test entry and reads the result aloud as a screen reader might. The example carries no claim about completion rates; it shows a review that turns a vague prompt into a recoverable one.
Walk-through checklist
- Submit each form empty, then with one deliberate mistake, and read every message that appears.
- Confirm each message names the field and states the expected form of the answer.
- Verify that nothing relies on color alone to signal a problem.
- Open an address with a mistyped ending and check the not-found page offers a route onward.
- Ask the developer how a server failure appears to the visitor, and who is notified when it happens.
- Record the wording of every message in one document so changes are deliberate.
Make the wording part of ownership
Messages tend to be set by plugins and templates, so they drift when software updates. Keep the approved text in your records, and recheck it after updates to the form tool or theme. Having one person own the wording keeps the voice consistent and gives the vendor a reference when something changes.
Write for readers with different needs
Short sentences help everyone, and they matter most for people using translation tools or reading in a second language. Avoid abbreviations and internal jargon. Place the instruction beside the field it concerns, not only in a banner at the top of the page, because a visitor who has scrolled down to the field may never see a message far above it.
