Form error messages are inline and descriptive
Why it matters
A top-of-form banner saying "There was an error" forces visitors to re-scan every field to find what went wrong, and many simply abandon instead. Inline errors rendered directly under the offending field tell the visitor exactly what to fix and where — a fundamental usability affordance that is also a WCAG 2.2 SC 3.3.1 (Error Identification) requirement for accessible form validation, meaning the absence of inline errors creates both a conversion drag and a compliance gap.
Severity rationale
Medium because non-inline error feedback increases abandonment and fails WCAG 2.2 SC 3.3.1 but does not block submission outright.
Remediation
Render validation errors inline, adjacent to the specific field that caused them, with a descriptive message ("Email address is invalid") rather than a generic toast. Adopt react-hook-form with zod resolvers and the shadcn Form primitives in components/ui/form.tsx:
<FormField
name="email"
render={({ field }) => (
<FormItem>
<FormLabel>Email</FormLabel>
<FormControl>
<Input {...field} />
</FormControl>
<FormMessage />
</FormItem>
)}
/>
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Conversion Optimization Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- wcag:2.2 · 3.3.1 — Error Identification
Taxons
History
- 2026-04-18·v1.0.0·Initial import from marketing-conversion·automated