building accessible web forms that everyone can use

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.

autocomplete values that actually help

The autocomplete attribute accepts specific token values defined by the HTML specification, and using the right ones makes a measurable difference for users who rely on autofill — particularly people with motor disabilities or cognitive conditions that make typing difficult. A few of the most useful values for common form patterns:

<!-- Contact details -->
<input type="text"  autocomplete="name">
<input type="email" autocomplete="email">
<input type="tel"   autocomplete="tel">

<!-- Shipping address -->
<input type="text" autocomplete="street-address">
<input type="text" autocomplete="address-level2">  <!-- city -->
<input type="text" autocomplete="postal-code">
<select           autocomplete="country">...</select>

<!-- Payment (browser fills from saved cards) -->
<input type="text" autocomplete="cc-name">
<input type="text" autocomplete="cc-number">
<input type="text" autocomplete="cc-exp">

For multi-step forms with separate billing and shipping sections, prefix the token with a section name: autocomplete="shipping street-address" and autocomplete="billing street-address". This lets the browser autofill the right address into the right section without guessing. For new password fields, autocomplete="new-password" signals to password managers that this is a creation field, not a login, which prevents them from filling in the user's existing credentials and gives them the cue to offer a generated password instead.

aria live regions for dynamic validation

Inline validation — checking a field as the user types or immediately on blur — is useful for long or complex forms, but it creates a trap for screen reader users if the feedback appears in a part of the page that is not the current focus point. A user focused on an input does not automatically hear changes elsewhere in the DOM.

The solution is to use an ARIA live region: a container that announces its contents to screen readers whenever they change, regardless of where focus is.

<!-- Static in the DOM, initially empty -->
<div role="status" aria-live="polite" aria-atomic="true" id="form-status"></div>

<!-- JS updates the content as validation runs -->
document.getElementById('form-status').textContent =
  'Password is too short. Use at least 8 characters.';

Use aria-live="polite" for non-urgent messages (validation results, character counts) that wait for the user to finish what they are doing before being announced. Use aria-live="assertive" only for genuinely urgent errors — like a session timeout warning — because it interrupts whatever the screen reader is currently saying. aria-atomic="true" ensures the whole region is read as a single unit when it changes, rather than individual words being announced as they appear.

mobile form considerations

Mobile users interact with forms through a touch interface with a software keyboard that takes up half the screen, no hover state, and fat-finger targets that demand generous sizing. The platform-specific attributes that matter most:

• inputmode controls the keyboard layout without changing the input's validation type. inputmode="numeric" shows a number pad while keeping the field typed as text — useful for PIN codes and reference numbers where you want digits but not the spinner controls that type="number" adds.
• enterkeyhint labels the return key on the software keyboard. enterkeyhint="next" shows "Next" instead of the default return arrow, which signals to the user that submitting is not the action — moving to the next field is. Other values include "done", "search", "send", and "go".
• Touch targets should be at least 44×44 CSS pixels. This is Apple's Human Interface Guideline figure and aligns with WCAG 2.5.5's "Target Size" criterion. Inputs that meet this size automatically satisfy the criterion; checkboxes and radio buttons often need extra padding to reach it.

Avoid positioning labels above fields in a pattern where the label disappears behind the keyboard when the input is focused. Floating labels — which start as placeholder-style text and animate up when the field is focused or filled — keep the label visible throughout the interaction and are a good middle ground between screen real estate and usability.

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.

Watch for the places where you hesitate: where you are not sure which field you are in, where an error message does not tell you how to fix the problem, where you cannot find the submit button by tabbing. Each hesitation is a failure for the users who depend on that interaction path every time they use the web. Accessible forms are not a separate, expensive feature — they are simply forms built the way the web was designed to be built, using the elements and attributes the platform provides for exactly this purpose.