Error message does not explain how to fix input

What is this issue?

A form field fails validation, an error is shown, and the error is even correctly associated with the right field, but the message itself states only that something is wrong, not what a valid value would look like. “Invalid entry,” “This field has an error,” and “Invalid password” are all real error messages that correctly flag a problem while providing zero information about how to resolve it.

This is a distinct failure from error identification. A field can be perfectly identified (announced clearly, associated with a specific error, everything working exactly as it should structurally) and still fail this criterion if the words themselves don’t explain the fix.

Why does this matter?

Whenever the correct format or acceptable range for a field is knowable in advance (a password’s minimum length, a date’s expected format, a required number of digits in a phone number), withholding that information forces every user into guesswork. Someone gets “Invalid password,” tries a slightly different password, gets the same generic message again, and has no growing understanding of what’s actually required after each attempt.

This burden falls hardest on anyone who can’t quickly scan the whole page for other contextual clues, such as a hint in fine print elsewhere or a tooltip that only appears on hover, that a sighted user skimming the page might eventually notice even without a specific error message spelling it out. A generic error message treats every user as capable of that kind of exploratory scanning, which is exactly the assumption this criterion exists to remove.

Who is affected?

• Screen reader users: hear only that an error exists with no indication of the fix, and have no equivalent of a sighted user’s ability to glance around the page for a stray hint that might explain the requirement.
• Cognitive disabilities: users who benefit most from being told directly and specifically what to do, rather than being expected to infer a pattern from repeated failed attempts, face the most friction from a vague message repeated on every retry.
• Low vision: using significant magnification see only a small part of the form at a time, making it especially costly if the actual format requirement is only stated elsewhere on the page rather than directly in the error text itself.

What users experience

Diego has dyslexia and finds trial-and-error form corrections especially frustrating, since re-reading and re-parsing the same vague message repeatedly adds cognitive load on top of the original task. He’s creating an account on a service whose password field rejects his first attempt with only “Invalid password” shown beneath it, no further detail anywhere on the page. He tries three more passwords, each rejected with the identical unhelpful message, before he finally guesses correctly that the requirement was a minimum length of twelve characters, a fact the form knew the entire time and never stated once.

How do I fix it?

State the specific requirement the input failed to meet, directly in the error text, whenever that requirement is knowable ahead of time. This works because it replaces guesswork with direct information: the user doesn’t need multiple attempts to discover a rule the system already knows and could have stated on the first try.

Write the message around the actual constraint: a length requirement, a required character type, an expected format, a valid range. If the field’s correct value genuinely can’t be predicted in advance (an email address already registered to another account, a username that’s taken), explain the constraint as clearly as possible without the specificity a knowable format requirement allows, rather than defaulting to a fully generic message in every case.

Code Examples

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-error">
<p id="password-error">Invalid password.</p>

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-error">
<p id="password-error">Password must be at least 12 characters and include a number.</p>

The field-to-error association through aria-describedby doesn’t change; that part was already working. Only the message text changes, from a bare statement that something is wrong to a specific, actionable description of exactly what the field requires, so the very next attempt can succeed instead of repeating the same guess.

Common Mistakes

Mistake: “Telling the user the exact requirement makes the form feel like it’s lecturing them.” A specific requirement stated once, upfront, prevents far more friction than it creates: the alternative is the same user re-reading a vague message after every failed guess, which is a worse experience by any measure than being told the rule directly the first time.

Mistake: “The password requirements are listed elsewhere on the signup page, so the error doesn’t need to repeat them.” Requirements listed once, elsewhere, are easy to have scrolled past, forgotten, or never seen at all by the time an error actually occurs. The error message is exactly the moment the user needs that information most, and it should be self-contained rather than relying on the user to remember or relocate a separate note.

Mistake: “For security fields like passwords, being vague about requirements is safer.” Stating a password’s format requirements (length, character types) reveals nothing that helps an attacker guess a specific password; it’s the same information a strength-meter or password-creation hint already shows. What genuinely creates risk is confirming whether a specific guessed value is close to correct, which is a different, narrower thing to avoid than withholding the format rules entirely.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s coverage model records zero automated detection for this criterion, for the same underlying reason as the related error-identification check: evaluating whether error message wording is sufficiently specific requires simulating form submission and then judging natural-language content quality, neither of which RedFlag’s static DOM scan performs.

False negative: every case, since no automated check runs against error message wording: a form full of “Invalid input” messages with zero actionable detail passes every scan with nothing flagged. False positive: not applicable, since no automated flag is ever raised. Manual step: the Manual Testing steps below are the only current way to catch this; deliberately trigger validation errors and judge whether the resulting message would actually let you fix the problem on your next attempt.

Manual Testing

1. Open a form in Chrome or Firefox with NVDA or JAWS running, or simply read the page visually.
2. Deliberately submit a value you know will fail validation for a field with a knowable format requirement, such as a short password, a badly formatted date, or a phone number missing digits.
3. Read the resulting error message and ask: could you correct the input on your very next attempt using only this message, with no other context from the page?
4. If the message only states that something is wrong (“Invalid password,” “This field has an error”) without stating what a valid value looks like, the check fails.

Related WCAG Success Criteria

3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, those suggestions must be provided to the user, unless doing so would jeopardize security or the content’s purpose. A message stating only that an error exists, with a known fix withheld, fails this criterion at its core requirement.

Related Issues

Form error is not clearly identified is the prerequisite this rule builds on: a user has to be able to find and understand which field has an error before the quality of that error’s wording matters at all.

Form field autocomplete attribute is missing or invalid reduces how often users need to read error messages in the first place, by letting the browser fill common fields correctly instead of relying on manual entry that’s more prone to mistakes.

Form field has more than one label shares this rule’s broader theme: a form’s announced text becoming unreliable or unclear at precisely the moment a user most needs it to be dependable.

User must re-enter information already provided in the same process is a related form-friction issue under the same broader theme of forms making recovery from a stumble harder than necessary.

Form input has no label is the foundational naming requirement every field in this rule’s scope still depends on; a well-written error suggestion on an unlabeled field only solves half the problem.

References

• W3C Understanding 3.3.3: Error Suggestion
• W3C Technique G177: Providing suggested correction text
• MDN: Form data validation