An error message should help the visitor recover. Color or an icon can support the message, but the problem and correction must also be available as understandable text.
Name the affected field and the correction
Write Email address must contain an @ sign rather than Invalid input. Keep the wording close to the field label and describe the expected format when it is not obvious.
Connect inline errors to their controls
Give the error an id and reference it from the control with aria-describedby. Set aria-invalid when the value is known to be invalid, then remove it after correction.
<label for="contact-email">Email address</label>
<input id="contact-email" name="email" type="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter an address such as [email protected].</p>Provide a useful error summary
For several errors, place a short summary before the form and link each item to its field. A dynamically inserted summary can use role alert, but it should not produce repeated announcements on every keystroke.
Preserve progress and move focus deliberately
Do not erase valid answers after a failed submission. Put focus on the summary or first invalid field only when that movement helps the visitor understand what changed.
Frequently asked questions
Can I show errors only with a red border?
No. The error also needs text that identifies the problem and can be understood without relying on color.
Should every keystroke trigger an alert?
Usually not. Continuous announcements can be distracting; validate at a predictable time and announce meaningful changes.
What happens to valid fields after an error?
Keep their values whenever it is safe so the visitor only corrects the affected fields.
Primary sources
Turn the guide into a working form
Start from a template, change the fields and take the code with you.
Open the free builder