Error Message Quality — Learn How to Test (Junior)

1 The Hook — Why This Matters

A user tries to book a flight. They enter their credit card number wrong. The error says: "Error 0x7A3: Invalid input." The user has no idea what to fix. They call customer support.

The support agent says 30% of their calls are from users who don't understand error messages. The company pays $12 per support call. With 10,000 failed submissions per week, that's $36,000 per week in avoidable cost.

Good error messages reduce support costs. Bad ones create them.

2 The Rule — The One-Sentence Version

Every error message must answer three questions: What went wrong? Why did it happen? How do I fix it?

If your error message doesn't answer all three, the user is stuck. They'll guess, fail again, or give up and call support. A message that answers all three turns a dead end into a next step.

3 The Analogy — Think Of It Like...

Analogy

A GPS that says "You can't go here" vs. one that says "Road closed due to flooding. Turn left in 200m for detour."

One abandons you at the problem. The other guides you to the solution. Every error message is a GPS instruction. Your job is to make sure it gives the detour, not the dead end.

4 Watch Me Do It — The 5 Quality Criteria

For each criterion, I'll show you Poor → Better → Best. This is how you judge error messages during testing.

Criterion 1: Clarity

Level	Example	Why it works (or doesn't)
Poor	"Invalid input"	Tells me nothing. Which input? What's invalid about it?
Better	"Email is invalid"	Identifies the field, but still vague about what's wrong.
Best	"Please enter a valid email address (e.g., name@example.com)"	Names the field, states the requirement, and gives an example format.

Criterion 2: Specificity

Level	Example	Why it works (or doesn't)
Poor	"Error occurred"	Zero information. Can't act on this.
Better	"Password is too short"	Identifies the issue, but doesn't say how short is allowed.
Best	"Password must be at least 8 characters. Yours is 6."	Gives the rule, the current state, and the gap to close.

Criterion 3: Actionability

Level	Example	Why it works (or doesn't)
Poor	"Login failed"	States the outcome. No path forward.
Better	"Wrong password"	Tells me what was wrong, but what do I do now?
Best	"Wrong password. Try again or click 'Forgot password' to reset."	Offers two clear next steps. User is never stuck.

Criterion 4: Location

Level	Example	Why it works (or doesn't)
Poor	Error at top of page, far from the field	User must hunt for which field is wrong. Especially hard on mobile.
Better	Error next to the field	Clear association, but if there are 10 fields, the user may scroll past it.
Best	Error next to field AND summary at top with links	Local context + global overview. Screen reader users get the summary first; sighted users see inline context.

Criterion 5: Consistency

Level	Example	Why it works (or doesn't)
Poor	"Invalid!" on one field, "Please correct" on another, red on one, orange on another	Users must re-learn the UI for every error. Creates cognitive load and distrust.
Better	Same style, tone, and placement for all errors	Predictable. Users know what to expect and where to look.
Best	Same style + helpful tone + consistent vocabulary	Builds trust. Users feel guided, not scolded. "Enter" vs "Type" vs "Input" — pick one and stick to it.

WCAG 2.1 Accessibility Requirements

Error messages aren't just about words. They're about who can perceive and act on them. Here's what WCAG 2.1 requires:

3.3.1 Error Identification: Errors must be identified in text — not just colour.
3.3.2 Labels or Instructions: Fields must have clear labels before the user starts.
3.3.3 Error Suggestion: When the system knows how to fix it, it must suggest how.
3.3.4 Error Prevention: For important submissions, let the user review and confirm.
ARIA: aria-describedby links the error message to the field. aria-invalid="true" marks invalid fields for screen readers.
Focus management: After submission, focus must move to the first error so keyboard and screen-reader users know something went wrong.

Here's what accessible error markup looks like:

            <label for="email">Email address</label>

<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">

<p id="email-error" role="alert">Please enter a valid email address (e.g., name@example.com).</p>

A screen reader announces the label, then the invalid state, then the error description. The user knows exactly what field failed and why.

5 When to Use It — Decision Tool

✅ Use this when...

Testing any form (universal)
Reviewing UI copy during a bug bash
Auditing accessibility compliance
Writing or reviewing test cases for validation

❌ Don't use this when...

Never. Every form needs tested error messages.
(Seriously. There's no situation where bad error messages are acceptable.)

6 Common Mistakes — Don't Do This

🚫 Colour-only errors

Red border with no text. Fails WCAG 3.3.1. Colour-blind users can't see it. Screen readers announce nothing. Always pair visual change with text.

🚫 Generic messages for specific problems

"Invalid input" for a credit card that failed the Luhn check. The system knows the card number is malformed. It should say so.

🚫 Missing programmatic associations

Error text sits near the field but isn't linked via aria-describedby. A screen reader user tabs to the field and hears only the label. They don't know there's an error.

🚫 Validating while the user is still typing

"Email is invalid" flashes after the first three characters. This trains users to ignore errors. Validate on blur or on submit, not on every keystroke.

🚫 Auto-dismiss too fast

A toast notification disappears in 3 seconds. Slow readers, screen-reader users, and anyone who looked away misses it. Errors should persist until the user resolves them.

🚫 Error summaries without links to fields

"3 errors found" at the top with no way to jump to them. The user must manually hunt through the form. Add anchor links or move focus to each error.

🚫 Technical jargon

"NullPointerException" or "Error 0x7A3." Users don't know your stack trace. Translate errors into user language.

🚫 Blaming the user

"You entered wrong data" or "Your password is incorrect." Use neutral language: "The password doesn't match our records." This reduces user frustration.

🚫 Missing server-side error messages

Client-side validation passes, but the server returns a 500 with no message. Test server-side errors too. Turn off JavaScript and submit the form. What does the user see?

🚫 Inconsistent placement across the form

Error below the first field, above the second, inside a tooltip on the third. Pick one placement pattern and use it everywhere. Consistency is part of quality.

7 Now You Try — Rewrite These Errors

🎯 Interactive Exercise

Below are three bad error messages. Rewrite each one so it answers What? Why? How?

#	Bad message	Context	Your improved version
1	"Error 404"	Form submission fails because the user's session expired	Write your answer, then reveal.
2	"Invalid"	Next to a password field on a registration form	Write your answer, then reveal.
3	Red border only	Date of birth field rejected because user entered a future date	Write your answer, then reveal.

#	Improved message	Why it's better
1	"Your session expired. Please sign in again to continue."	Explains what (session expired), why (timed out), and how (sign in again). No error code.
2	"Password must be at least 8 characters with 1 number and 1 symbol."	States the exact rules so the user can craft a valid password on the first try.
3	"Date of birth must be in the past. Please enter a date before today."	Text + visual indicator. Explains the constraint and gives the correction direction.

How did you do? If your answers answered all three questions — what, why, how — you're thinking like a tester who cares about the user experience.

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to apply this on real forms.

Q1. What are the three questions every error message must answer?

What went wrong? (identify the problem)
Why did it happen? (explain the cause)
How do I fix it? (provide a clear next step)

Q2. Why do colour-only errors fail WCAG 2.1?

Because 3.3.1 Error Identification requires errors to be identified in text, not just colour. Colour-blind users may not see a red border. Screen readers don't announce colour changes. Without text, a significant portion of users won't know an error occurred.

Q3. What does aria-describedby do in an error message?

It programmatically links the error message to the input field. When a screen-reader user focuses the field, it reads the label, then the error description. Without this association, the error text is just orphaned text on the page that screen-reader users may never find.