When something goes wrong, a good error message is the difference between a user who recovers in seconds and one who abandons the task. Yet error copy is usually written last, under pressure, and ships as “Error” or “Invalid input”. This tool scores each of your messages against WCAG 3.3.1 (Error Identification), 3.3.3 (Error Suggestion) and plain-language best practice, and tells you exactly what to fix.
How it works
Each pasted message is evaluated against seven signals, and the share that pass produces a Good / Fair / Poor grade:
- Identifies the specific problem — it is not a generic “error” / “something went wrong” (3.3.1).
- Names the field or item affected, so the user knows where to look.
- Suggests how to fix it — contains an actionable next step (3.3.3).
- No leaked codes or jargon — no exception names, stack traces, HTTP codes or
nullreaching the user. - Not blaming — describes the issue without accusing the user.
- Clear length — roughly 3 to 30 words, neither a single word nor an essay.
- Calm punctuation and casing — no shouting or multiple exclamation marks.
These are heuristics: they catch the patterns that most often make error copy unhelpful, but you should still read each message in its real UI context.
Example
| Message | Grade | Why |
|---|---|---|
Error | Poor | Generic, no field, no fix, no detail. |
Invalid input | Poor | Says nothing specific or actionable. |
Your email address is missing an @ symbol — please enter it as [email protected] | Good | Identifies the problem, names the field, suggests the fix. |
Tips
- Lead with the problem, then the fix: “Password must contain at least one number.” beats “Please try again.”
- Put the message next to the field it concerns, not only in a banner at the top — proximity is part of identifying the error.
- Keep machine detail (codes, stack traces) in your logs, never in the user-facing string.
- Write in the user’s language about their goal, not your system’s internals. Everything here is scored locally in your browser.