Short answer: Form validation checks what people type before the form is accepted. Check in the browser for fast feedback and again on the server for security. Show each error in text next to its field, after the person finishes it, and mark it with aria-invalid for screen readers.
What form validation does
Validation catches empty required fields and data in the wrong format before they reach you. MDN lists the browser’s own messages, such as “This field is required” and “Please enter a valid email address”.
WCAG criterion 3.3.1, at Level A, covers input errors that are detected automatically. The field in error has to be identified, and the error described to the user in text. Our contact form guide covers which fields to make required.
Browser, script and server
| Where the check runs | What it does | Worth knowing |
|---|---|---|
| In the browser | required and type="email" stop the send with the browser’s own message | Fast, but MDN warns it is too easy to bypass |
| In your own script | Shows your messages by the fields and sets aria-invalid | Add styling and a message on how to fix it |
| On the server | Checks the data again before it is stored | Browser checks alone don’t ensure security, the W3C says |
From MDN’s pages on client-side form validation and aria-invalid and the W3C forms tutorial, read November 4, 2026.
MDN warns that malicious users can still send bad data to your server, because checks in the browser are too easy to bypass.
How to write error messages
NN/g recommends showing each message below or next to the field in error. The message should be explicit, human-readable, polite and precise, and give constructive advice.
Criterion 3.3.3, at Level AA, asks you to suggest a fix when you know one, unless that would put the security or purpose of the content at risk. “Enter an email such as name [at] example.com” helps more than “Invalid input”.
NN/g notes that red is the color most associated with errors, and that an icon helps people who are colorblind. The W3C accepts color or an image in addition to the text, never in its place.
When to show the error
NN/g recommends inline validation: as soon as someone finishes a field, an indicator appears nearby if the field has an error. It also advises against showing an error before the person has finished with the field.
Some checks can only run after the form is sent. In that case, show each message next to its field and make the fields in error easy to find.
Errors and screen readers
A red border means nothing to someone who can’t see it. MDN asks your own validation scripts to set aria-invalid on fields in error, together with visible styling and a message that explains how to fix the mistake.
MDN also says not to set aria-invalid on an empty required field until the person tries to send the form. It suggests linking the message with aria-errormessage. Our aria-label guide shows how fields get their names.
How to add validation to a form
- Mark required fields in their visible labels and with the required attribute.
- Use input types such as type="email" so the browser runs basic checks.
- Check the same data again on the server before you store it.
- Show each error in text next to its field, once the person finishes the field.
- Say how to fix the problem, with an example when it helps.
- Set aria-invalid on fields in error and link each one to its message; wait for a send before marking empty required fields.
- Remove the marks when the field is fixed, and test the whole form with a keyboard.
How our own form reports errors
On November 4, 2026, we tried our contact form in both languages, at computer and phone widths. No message left the test browser. We pressed “Send message” with the name, phone and email empty.
Each of those fields showed its message underneath, and the focus moved to the first one. With the earlier version of our form, nothing told a screen reader which fields were wrong. When a send failed, the keyboard focus also fell back to the page.
After the change we made that day, each field with an error carries aria-invalid and points to its message with aria-describedby. Typing a valid email cleared that field’s marks, and the other two kept theirs. When a send fails, the focus stays on the button, and a line says “Could not send. Please try again.”
Before you publish
- Required fields say so in their labels.
- Every error appears in text next to its field.
- No error shows while someone is still typing.
- Fields in error carry aria-invalid and point to their message.
- The server checks the data again.
- A failed send says so in text.
RememberAn error message is part of the form. Put it next to the field, say how to fix the problem, and make sure screen readers get it as well.
We build forms like this in our web design service. Our WCAG 2.2 guide covers the rest of the accessibility standard.
Quick answers about form validation
What is form validation?
Checking what someone typed before the form is accepted: that required fields are filled in and that an email or a date has the right format. When a check fails, the form says which field is wrong and how to fix it.
Should I validate in the browser or on the server?
Both. Checks in the browser give fast feedback, but MDN warns they are too easy to bypass. The W3C adds that browser checks alone don’t make a form secure, so the data has to be checked on the server too.
When should an error message appear?
After the person finishes a field, not while they are still typing. NN/g recommends inline validation once a field is complete. MDN adds that an empty required field shouldn’t be marked with aria-invalid until the person tries to send the form.
Where should an error message go?
Next to the field that has the problem, usually below it. NN/g says the message should be explicit, polite and precise and give constructive advice. WCAG asks that the error is described in text, not only with color.
How does a screen reader know that a field has an error?
Mark the field with aria-invalid="true" and link it to its error message. MDN asks your own validation scripts to add aria-invalid together with visible styling and a message that explains how to fix the mistake.
Sources
Read on November 4, 2026. W3C Web Accessibility Initiative: Understanding SC 3.3.1 Error Identification (Level A), Understanding SC 3.3.3 Error Suggestion (Level AA) and the forms tutorial Validating Input. MDN Web Docs: Client-side form validation and ARIA: aria-invalid attribute. Nielsen Norman Group: 10 Design Guidelines for Reporting Errors in Forms. Our case: the contact form on our site, checked on November 4, 2026.