Error Message Quality
Bad error messages create support tickets. Good ones guide users to fix their own mistakes. Learn the 5 criteria, WCAG 2.1, and ARIA patterns that make error messages truly accessible.
1 The Hook — Why This Matters
In 2013, a major UK bank launched an online mortgage application. A 34% drop-off at the "income details" step baffled the team for two weeks. The cause? A single error message.
When users typed their salary with a comma ("45,000"), the system replied: "Error: invalid data format." Nobody realised the comma was the problem. The fix was one sentence: "Please enter your salary without commas, e.g. 45000." Drop-off fell to 6%.
One bad sentence cost millions. One better sentence fixed it. That is why error message quality matters.
2 The Rule — The One-Sentence Version
A good error message tells the user what went wrong, where it went wrong, and exactly how to fix it — in language a stranger would understand.
Run every error message through this filter. If any piece is missing, it's a bug — not a nice-to-have, but a real defect that blocks users.
3 The Analogy — Think Of It Like...
A road sign that reads "No Entry" with no detour arrow versus one that reads "Bridge closed — follow yellow diversion signs to City Centre."
The first abandons you at the problem. The second guides you to the solution. Bad error messages are "No Entry" signs. Good ones are the diversion. Your job as a tester is to make sure every error sign has a detour arrow.
4 Watch Me Do It — Step by Step
Here are three real error messages rated Poor → Better → Best against the five quality criteria and WCAG 2.1.
- Evaluate against the 5 criteria Every error message is scored on Clarity, Specificity, Actionability, Location, and Consistency. A message that scores well on all five is a pass. Any missing criterion is a defect.
- Check WCAG 2.1 compliance Errors must be identified in text (3.3.1), suggest a fix when the system knows one (3.3.3), and be announced to assistive technology (4.1.3).
-
Verify ARIA programmatic associations
Visual proximity is not enough. The error text must be linked to the input via
aria-describedby, and the input needsaria-invalid="true". Without these, screen-reader users hear only the label.
Example 1: Login failure
| Level | Message | Evaluation |
|---|---|---|
| Poor | "Login failed" | No indication of what failed or what to do. Fails WCAG 3.3.3 Error Suggestion. |
| Better | "Incorrect password" | Tells the user what is wrong, but offers no path forward. Still fails 3.3.3. |
| Best | "Incorrect password. Try again or click 'Forgot password' to reset." | Answers what, where, and how. Passes 3.3.3 and 3.3.1 Error Identification. |
Example 2: Email validation
| Level | Message | Evaluation |
|---|---|---|
| Poor | Red border only, no text | Fails WCAG 3.3.1 outright. Colour-blind users may miss it. Screen readers announce nothing. |
| Better | "Email is invalid" | Text present, so 3.3.1 is met. But the user must guess what's wrong. Lacks specificity. |
| Best | "Email must contain @ and a domain (e.g., name@example.com)" | Names the field, states the rule, and gives a correct format. Linked with aria-describedby, it passes 4.1.2 Name, Role, Value too. |
Example 3: NZ postcode
| Level | Message | Evaluation |
|---|---|---|
| Poor | "Please enter a valid zip code" | Wrong locale. New Zealand uses postcodes, not zip codes. Breaks Consistency and confuses users. |
| Better | "Postcode is invalid" | Correct term, but no guidance on what a valid NZ postcode looks like. |
| Best | "Please enter a valid NZ postcode, e.g. 6011 or 8011" | Locale-correct, specific, and gives examples. Passes all 5 criteria and WCAG 3.3.3. |
WCAG 2.1 Criteria at a Glance
- 3.3.1 Error Identification (Level A): Errors in text, not colour alone.
- 3.3.2 Labels or Instructions (Level A): Clear labels before the user starts.
- 3.3.3 Error Suggestion (Level AA): Suggest a fix when the system knows one.
- 3.3.4 Error Prevention (Level AA): Let users review important submissions.
- 4.1.2 Name, Role, Value: Link errors to fields via ARIA.
- 4.1.3 Status Messages: Assistive tech must announce dynamic errors.
<label for="email">Email address</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" role="alert">Email must contain @ and a domain (e.g. name@example.com).</p>
A screen reader announces the label, the invalid state, and the error description. The user knows exactly what failed and why.
5 The Decision Tool — When to Use It
✅ Use error message quality testing when...
- Testing any form with validation
- Running an accessibility or WCAG review
- Writing negative-path test cases
- Reviewing UI copy in a bug bash
- Testing server-side errors with JavaScript disabled
- Localising a product for the NZ market
❌ Don't skip this when...
- The stakeholder says "just test the happy path"
- You are short on time
- The form is "just internal"
- The error text was "already signed off by UX"
Before you accept an error message, ask:
- Do you have access to the actual error messages displayed in the product?
- Have you tested errors with accessibility tools (colour contrast, screen readers)?
- Does the error message tell the user HOW to fix it, not just that it's broken?
6 Common Mistakes — Don't Do This
🚫 Colour-only errors
I used to think: A red border was enough because users notice colour.
Actually: Red border with no text fails WCAG 3.3.1. Colour-blind users may miss it. Screen readers announce nothing. Always pair visuals with clear text. The error must be perceivable by everyone, not just sighted users with normal colour vision.
🚫 Generic messages for specific problems
I used to think: Generic messages were safer because they don't reveal system details.
Actually: "Invalid input" is never good enough. The system knows what is wrong. A credit card field that fails a Luhn check should say so. An email missing an @ should say so. Security through obscurity hurts usability. If the system can detect the problem, it should describe the problem.
🚫 Missing programmatic associations
I used to think: If the error text was near the field, screen reader users would find it.
Actually: Visual proximity is not enough. Without aria-describedby, a screen reader user tabs to the field and hears only the label. They may never discover the error text below the input. This fails WCAG 4.1.2 Name, Role, Value. Always verify in a screen reader, not just by looking.
When error message testing fails
Error messages that don't match actual system errors confuse users. A field shows "invalid format" but the actual validation rule is "must be 8-20 characters." Users cannot fix what they don't understand. Also, error messages that fail accessibility (colour-only, no programmatic association) exclude disabled users entirely.
7 Now You Try — Rewrite These Bad Messages
Rewrite each message so it answers What? Where? How? Write your answers mentally, then reveal the improved versions.
| # | Bad message | Context |
|---|---|---|
| 1 | "Error 404" | Form submission fails because the user's session expired after 30 minutes of inactivity |
| 2 | "Invalid" | Next to a password field on a registration form that requires 8+ characters, 1 number, and 1 symbol |
| 3 | Red border only | Date of birth field rejected because the user entered a future date |
| # | Improved message | Why it's better |
|---|---|---|
| 1 | "Your session expired. Please sign in again to continue." | Explains what, why, and how. No error code. Neutral tone. |
| 2 | "Password must be at least 8 characters with 1 number and 1 symbol." | States the exact rules so the user can succeed on the first try. |
| 3 | "Date of birth must be in the past. Please enter a date before today." | Text plus visual indicator. Explains the constraint. Meets WCAG 3.3.1 and 3.3.3. |
How did you do? If your answers covered what, where, and how, you are thinking like a user advocate.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you get all three right in your head, you are ready to evaluate error messages on real forms.
Q1. What are the three questions every error message must answer?
What went wrong? (identify the problem clearly)
Where did it go wrong? (name the field or area)
How do I fix it? (provide a clear, actionable next step)
Q2. Why do colour-only errors fail WCAG 2.1, and which success criterion do they violate?
They violate 3.3.1 Error Identification (Level A). Errors must be identified in text, not just colour. Colour-blind users may not perceive a red border. Screen readers do not announce visual changes. Without text, a significant portion of users will not know an error occurred at all.
Q3. A developer says the error message is visible right under the field, so it's accessible. What is missing?
Visual proximity is not programmatic association. The error text must be linked to the input via aria-describedby, and the input needs aria-invalid="true". Without these ARIA attributes, a screen-reader user tabs to the field and hears only the label, not the error. This fails WCAG 4.1.2 Name, Role, Value.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. What makes a good error message?
A good error message is Clear (plain language, no jargon), Specific (names the exact problem), Actionable (tells the user how to fix it), Located near the field (not at the top of the page), and Consistent (same tone and format across the product). It must also pass WCAG 2.1: text not colour alone, with programmatic ARIA associations.
Q2. What WCAG 2.1 criteria apply to error messages?
3.3.1 Error Identification (A) requires errors to be identified in text, not just colour. 3.3.3 Error Suggestion (AA) requires the system to suggest a fix when it knows one. 4.1.3 Status Messages requires assistive technology to be notified of dynamic errors. 4.1.2 Name, Role, Value requires ARIA attributes like aria-describedby and aria-invalid.
Q3. What is wrong with saying "Please enter a valid zip code" in a New Zealand form?
New Zealand does not use "zip codes." We use postcodes. Using American terminology breaks the Consistency criterion and confuses local users. A good NZ message says: "Please enter a valid NZ postcode, e.g. 6011 or 8011." This is locale-appropriate, specific, and gives examples.
10 Link to Reference
Want the full theory, WCAG deep-dive, and ARIA implementation guide?
→ Error Message Quality — Full Library Reference
Includes the formal ISTQB definition, WCAG 2.1 success criteria mapping, and ARIA code patterns for React, Vue, and plain HTML.
11 Next Step
You now know how to evaluate any error message against the 5 criteria and WCAG 2.1. The next skill is learning to find bugs without a script — using your intuition and experience.