Accessible form validation errors: messages and a working example

Write the correction the person needs

“Invalid input” leaves the visitor guessing. “Enter an email address in the format name@example.com” gives a concrete next action. Say what is required before submission and keep error wording specific to the failed condition.

Connect the message to the field

The demo uses visible labels, aria-invalid on affected fields, and aria-describedby for hints and errors. After an unsuccessful submit, focus moves to an error summary whose links focus the inputs. Text identifies the error without relying on color. Success is announced separately. These patterns follow W3C’s form-notification guidance; they are not a certification of a complete site.

Try both paths below

Submit the empty example to see two errors. Follow the email link, enter a malformed address, and resubmit. Then enter a valid example address and a project goal. The confirmation explicitly says that nothing was sent or saved. Your text stays in the page during correction; this demo has no server submission or persistence.

Before using the pattern in production

Repeat validation on the server, wait for confirmed server success before saying a response was received, and handle network failures without clearing answers. Test with keyboard-only navigation and the screen readers your audience uses. Review zoom, contrast, touch targets and error recovery across the complete form, including any custom widgets.

Sources and reproducibility

• W3C WAI — form user notifications

Continue your task

• Completed client intake example
• Likert scale generator