The web form is the oldest interactive element on the web and still the one most sites get wrong. It looks trivial — some inputs and a button — which is exactly why it is rarely given the attention it needs. Web form validation, accessible error handling, and cooperating with the browser instead of fighting it are the difference between a form people complete and one they abandon. None of it is hard; all of it is routinely skipped.
Validation timing is the whole experience
The most common validation mistake is not what you check but when. Validating every keystroke means telling users their email is invalid while they are still typing the first character — technically true, deeply annoying. Validating only on submit means letting someone fill twelve fields before revealing that the second one was wrong.
The pattern that respects people is: validate a field when they leave it, not while they are in it. On the blur event, after the user has finished with a field and moved on, is the natural moment to say “that email is missing an @”. Then, once a field has been marked invalid, switch to validating it on every change so they can see it turn valid as they fix it. First judgment on blur, live feedback thereafter.
field.addEventListener('blur', () => validate(field)); // first check when they leave
field.addEventListener('input', () => {
if (field.dataset.touched) validate(field); // then live, once flagged
});
field.addEventListener('blur', () => { field.dataset.touched = 'true'; });This one change — blur first, then live — eliminates most of what makes forms feel hostile. It is a small amount of code and it is the highest-value thing on this page.
Use the platform before you reach for JavaScript
Browsers ship a great deal of form machinery that teams reimplement badly. The right input type gives you a suitable mobile keyboard, built-in validation, and accessibility for free: type="email" summons the @-key layout and validates the format, type="tel" gives a number pad, type="url" checks for a scheme. Constraint attributes like required, min, max, and pattern express rules the browser enforces without a line of script.
The native constraint validation API then lets your JavaScript read those built-in results rather than duplicating them, so you get consistent messaging and never drift out of sync with the browser’s own checks. Reaching straight for a validation library before using what the platform already provides is how forms end up with a worse mobile keyboard and inaccessible errors than plain HTML would have given. Start from the platform, as the whole render pipeline rewards — the same lesson as preferring native features in our critical rendering path teardown.
Errors a screen reader will actually announce
Here is a failure that is invisible to most developers because they never test it: a form shows a red error message, and a screen reader user has no idea it appeared. Visually the error is obvious; to assistive technology it is silent, because nothing told it that anything changed.
Three things fix this, and they are cheap. Associate each error with its field using aria-describedby so the error text is read when the field is focused. Mark invalid fields with aria-invalid="true" so their state is announced. And put the error message in a container with role="alert" or aria-live, which makes the screen reader announce it the moment it appears, without the user having to go looking.
<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-err">
<span id="email-err" role="alert">Enter an email address including @</span>Colour alone is never enough, for the same reason: a red border is meaningless to someone who cannot see it or cannot distinguish red. Every error needs text, and that text needs to be programmatically tied to its field. This is not a niche concern — it is the difference between a form a blind user can complete and one they cannot, and it is a handful of attributes.
Stop breaking autofill
Browser autofill is a gift to users and clever markup routinely sabotages it. When a form uses correct, standard field names and autocomplete attributes, the browser fills a saved address or payment card in one tap — an enormous convenience, especially on mobile. When a form uses randomised field names or omits autocomplete, the browser cannot recognise the fields and the user types everything by hand.
The fix is to use the standard autocomplete tokens the browser understands: autocomplete="email", autocomplete="given-name", autocomplete="street-address", autocomplete="cc-number", autocomplete="one-time-code" for an SMS code. These are a defined vocabulary; the browser knows them. Disabling autocomplete “for security” on a login or address form almost always harms users more than it helps, and the security benefit is usually imaginary. Work with the browser’s memory, not against it.
Small input details that add up
A cluster of small choices separates a form that respects people from one that fights them. Never disable paste on a password or confirmation field — it breaks password managers and helps no one. Set inputmode to summon the right keyboard even when the type is text. Keep labels visible rather than relying on placeholder text that vanishes the moment someone starts typing and leaves them guessing what a field was for. Make the whole label clickable by associating it with its input, which enlarges the tap target for free.
And on submit, disable the button or otherwise prevent a double submission, because an impatient user on a slow connection will click twice — the client-side half of the exactly-once problem handled server-side by an idempotency key. The two halves belong together: the button prevents the obvious double-click, the server key catches the retry the button cannot.
Client validation is a courtesy; server validation is the rule
Everything above concerns the experience of filling in a form, and it is easy to forget that all of it is a convenience, not a control. Client-side validation exists to give the user fast, friendly feedback — and it can be bypassed completely. Anyone can open developer tools and remove a required attribute, disable your JavaScript, or send a request straight to your endpoint with no form involved at all. The form is just one way to reach your API, and an attacker will not use it.
So the rule is absolute: every validation that matters must run again on the server, and the client version is purely there to make the experience pleasant. Treating client-side checks as a security boundary is one of the most common and most serious web mistakes, because it feels like validation is handled when in fact the only place it counts has been skipped. The email format, the required fields, the length limits, the business rules — the server must enforce all of them regardless of what the client claims to have checked, because the client cannot be trusted and was never meant to be.
This connects to a deeper principle: never trust input that crossed a boundary you do not control, which is the same reasoning behind output encoding and the security headers in our security headers guide. A form field is user input, and user input is hostile until validated on the server — not because your users are malicious, but because you cannot tell which requests came from your form and which came from somewhere else. The two layers have different jobs and both are mandatory: the client layer makes the form kind to fill in, and the server layer makes it safe to accept. Skipping the server layer because the client layer looks thorough is how validation that appears complete turns out to protect nothing at all.
The form is the conversion
It is worth remembering why this matters beyond craft: the form is very often the point of the whole page. The checkout, the signup, the contact request — the form is where intent becomes action, and every point of friction is someone deciding it is not worth it. A validation message that fires at the wrong moment, an error a screen reader misses, autofill that does not work: each is a small tax, and forms are where those taxes compound into abandonment. Interaction responsiveness is part of that too, since a form that janks on every keystroke feels broken — the mechanics are in our INP optimization guide. Get the form right and you have fixed the part of the page that actually decides whether the visit was worth anything.