Form Validation Copy

Form validation messages are most helpful when they tell users exactly what went wrong and what the correct value should be.

Analysis:
• Option A — "valid credit card number" is vague; tells them nothing specific about the error
• Option B — too long and formal; "expected format" is developer language
• Option C ✓ — tells the rule (16 digits) AND what they entered (15 digits) — maximum specificity
• Option D — correct but missing the diagnostic ("you entered 15") that helps users understand the mistake

The gold standard for count-based validation: state the required count AND the current count.

Other examples:
• "Password must be at least 8 characters. Yours is 6."
• "Title can be up to 60 characters. You've used 63."

Key vocabulary:
• Validation message — inline feedback explaining why input was rejected
• Diagnostic copy — validation text that tells users what they actually entered vs. what was expected
• Character/digit count feedback — showing current vs. required count in validation messages
• Specific constraint — naming the exact rule being violated, not a generic error

Email validation messages should specify what's missing and show an example of the correct format.

The user typed "john@" — the at-sign is present; the domain is missing. The validation message should be as targeted as possible:
• "Invalid email" — generic; tells them nothing
• "Please enter a valid email" — same level of vagueness
• "Email format is incorrect" — slightly more diagnostic but still no example
• "Please include a domain — for example, john@gmail.com" ✓ — names what's missing, shows a concrete example

When users see their own username (john) reflected in the example, it creates a personalized, helpful moment.

Key vocabulary:
• Inline validation — validation that fires immediately when a field loses focus (on-blur)
• On-blur validation — validation triggered when the user moves to the next field
• Example-led correction — showing a correct example rather than just stating the rule
• Targeted validation — a message that diagnoses the specific error, not a generic failure

Complex password requirements need real-time, progressive validation — not a post-submit error dump.

Why each option works or fails:
• Option A ("does not meet requirements") — zero diagnostic value; most frustrating pattern
• Option B ✓ — real-time checklist lets users build the password interactively; each rule is a mini-goal with immediate feedback
• Option C — listing all 4 rules as errors after submission is overwhelming and inaccurate (they met some requirements already)
• Option D — only shows first failure; once fixed, a new error appears; this "whack-a-mole" pattern frustrates users

The checklist pattern also:
• Communicates requirements BEFORE the user attempts to submit
• Reduces anxiety with progressive ✓ marks as they go
• Makes the password field feel like a guide, not a gatekeeper

Key vocabulary:
• Real-time validation — validation feedback that updates as the user types
• Progressive validation — showing completion status incrementally, not all-or-nothing
• Requirement checklist — a list of password rules shown inline, checked off as they're met
• Whack-a-mole validation — anti-pattern where one error at a time is shown, creating repeated submission failures

Multi-field validation errors require both inline messages AND an accessible summary at the top of the form.

Why this dual approach is best:
1. The summary helps users understand the scope ("3 fields") without having to scroll through the entire form
2. Anchor links in the summary take users directly to each problem field
3. Inline messages provide context when they arrive at each field
4. Both together meet WCAG accessibility guidelines (complex forms must have accessible error summaries)

Why other options fail:
• A — "fix the errors below" provides no count; requires full-form scanning
• C — modal prevents users from seeing which fields need correction
• D — whack-a-mole pattern; frustrating for complex forms

Key vocabulary:
• Error summary — a top-of-form component listing all validation errors with links to each field
• Inline error — validation message displayed adjacent to the field it refers to
• WCAG (Web Content Accessibility Guidelines) — accessibility standard that includes form error handling requirements
• Anchor link — a link that jumps to a specific location on the page (used in error summaries)

Age-gating validation messages should state the rule AND confirm that their input was processed — not just assert a generic rule.

This is a sensitive validation scenario. The user:
• May have entered the date incorrectly
• May be genuinely under 18

A good message:
1. States the rule clearly ("18 or older")
2. Confirms the input was understood ("based on the date you entered")
3. Leaves room for the user to re-enter if they made a mistake
4. Doesn't accuse them of lying

Option B ("You must be 18 or older") states the rule but doesn't acknowledge what they entered — the user may wonder if their date wasn't processed.
Option D ("rejected", "not met") is cold and bureaucratic.

Key vocabulary:
• Age-gating — restricting access based on the user's age
• Input acknowledgment — copy that confirms the user's input was received before explaining why it failed
• Sensitive validation context — validation around personal information (age, identity) requiring careful, non-accusatory language
• Re-entry invitation — validation phrasing that implicitly invites correction without assuming bad intent