Forms are where the web gets serious. A blog post can be skimmed, but a form is a contract: sign up, check out, book the appointment, send the message. When a form is hard to use, people do not complain — they leave. And for the millions of people who navigate the web with a screen reader, a keyboard, voice control, or simply a small screen and shaky hands, a careless form is not an inconvenience but a wall. The good news is that accessible forms are mostly a matter of using the platform correctly. This guide covers the techniques that make the biggest difference.
start with a real label
Every input needs a programmatically associated label. Not placeholder text, not a nearby paragraph — an actual <label> element tied to the input. This is the single most important thing you can do, because the label is what a screen reader announces, and it is what gives the input a larger click and tap target.
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">Placeholders are not labels. They vanish the moment a user starts typing, they often fail contrast requirements, and assistive technology treats them inconsistently. Use a placeholder for an example of the expected format if you like, but never as the only signal of what a field is for.
use the right input type and autocomplete
The HTML platform gives you a rich set of input types, and using them correctly is free accessibility. A type="email" field brings up the right on-screen keyboard on mobile; type="tel" shows a number pad; type="date" offers a native picker. Pair these with the autocomplete attribute so browsers and password managers can fill fields reliably. Correct autocomplete values are also a genuine help to people with cognitive or motor disabilities, who benefit most from not having to retype information.
group related fields
When several controls belong together — a set of radio buttons, or a billing address split across multiple inputs — wrap them in a <fieldset> with a <legend>. The legend gives the group a shared, announced name, so a screen reader user understands that "Standard," "Express," and "Overnight" are three options for one question rather than three unrelated checkboxes.
handle errors with care
Error handling is where most forms fall apart for assistive technology. A red border alone is invisible to a screen reader and to anyone who cannot perceive colour. Good error handling does three things: it identifies which field is wrong, explains why in plain language, and tells the user how to fix it.
Connect the error message to its input with aria-describedby, and mark the field invalid with aria-invalid="true" so the state is announced:
<label for="pw">Password</label>
<input id="pw" type="password" aria-describedby="pw-error" aria-invalid="true">
<p id="pw-error">Use at least 8 characters, including a number.</p>When the user submits a form with errors, move focus to the first invalid field or to a summary at the top of the form. Never rely on colour alone, and never clear the fields a user has already filled in — making someone retype a long form is a quiet cruelty.
respect the keyboard
Everything in a form must work with the keyboard alone, in a logical order. Use native elements wherever possible: a real <button> is focusable, clickable with both Enter and Space, and announced as a button automatically. If you build a custom control out of <div> elements, you take on the full burden of adding roles, states, focus management, and key handling by hand — and it is remarkably easy to get wrong. The strong default is to lean on the platform.
Make sure the focus indicator is clearly visible. Removing focus outlines with outline: none and no replacement is one of the most damaging things you can do to keyboard users. If the default ring clashes with your design, style a better one with :focus-visible rather than removing it.
do not disable the submit button
A common pattern is to disable the submit button until the form is "valid." It feels tidy, but it is hostile: a disabled button gives no feedback about why it is disabled, and it is skipped by keyboard navigation, so a user can be left tabbing in confusion. It is almost always better to leave the button enabled and validate on submit, showing clear, specific errors if something is wrong.
test the way people actually use it
Automated checkers like axe or Lighthouse catch the obvious failures — missing labels, low contrast — and you should run them. But they cannot tell you whether your form is genuinely usable. The real test takes five minutes: put your mouse aside and complete the form with the keyboard alone, then turn on a screen reader such as VoiceOver or NVDA and try again with your eyes closed. The friction you feel is the friction your users feel every day. Accessible forms are not a separate, expensive feature; they are simply forms built the way the web was designed to be built.