By Mehdi HassanHow do you build accessible forms?
You build accessible forms by making every field understandable, operable and recoverable for everyone, including people using screen readers, keyboards, voice control and magnification. Concretely: visible labels linked in code, instructions before input, clear errors in text, full keyboard support, sensible autocomplete, and login and multi-step flows that don't depend on memory. Form accessibility is the part of WCAG that touches conversion most directly.
Forms are where accessibility failures cost the most, because a form is usually the point of the page: a signup, a demo request, a checkout. If someone can't complete it, nothing else on the page matters. For the bigger picture of what the law requires, see our hub on website accessibility compliance, and for every criterion by role, the WCAG 2.2 checklist.
How should form labels work?
Every form field needs a visible label that stays on screen while people type, and that label must be linked to the field in code so screen readers announce it. Use a label element tied to the input, not text that just sits nearby. Placeholder text isn't a label: it disappears on typing, often fails contrast, and isn't announced reliably.
- Label above the field. It's the easiest pattern to scan, works at zoom and fits longer translations.
- Group related choices. Radio buttons and checkbox groups need a group label, using a fieldset with a legend, so 'Yes' and 'No' make sense out of context.
- Mark required fields in text. Write 'required' or explain that all fields are required; don't rely on a red color or a symbol alone.
- Match visible and accessible names. Voice control users say what they see, so a button that reads 'Get started' shouldn't be named 'submit form' in code.
- Floating labels need care. If the label shrinks into the field, keep it readable and above contrast minimums.
Label wording is copy work. Short, specific labels and helper text reduce errors for everyone; our guide to microcopy that converts goes deeper on labels, hints and reassurance text.
What makes form instructions and input accessible?
Accessible input means people know what's expected before they type and the browser can help them fill it in. Put format hints, like a date format or password rules, in visible text linked to the field, not in a tooltip or placeholder. And use the right input types and autocomplete attributes so devices offer the right keyboard and saved details.
Field | Input type | Autocomplete value |
|---|---|---|
Full name | text | name |
Phone | tel | tel |
Company | text | organization |
Street address | text | street-address |
Postal code | text | postal-code |
New password | password | new-password |
Current password | password | current-password |
WCAG 1.3.5 expects fields collecting the user's own personal data to expose their purpose, which autocomplete values do, and they're a cheap improvement on any form. They help people with motor and memory impairments most, and they save every visitor typing. Don't disable autocomplete on these fields.
How do you write accessible error messages?
Accessible error messages say exactly what went wrong and how to fix it, appear in text next to the field, and are announced to screen readers when they appear. 'Invalid input' in red under a field fails on several counts. 'Enter an email address like name@company.com' in text, with an icon, linked to the field, passes.
Validate at the right moment
Check on submit, or when someone leaves a field, not on every keystroke. Errors that appear while people are still typing are confusing and noisy for screen readers.
Show errors next to the field
Put the message directly below the field, linked to it in code, with an icon and text, not color alone.
Add a summary on long forms
On submit, show a short list of errors at the top with links to each field, and move focus to it.
Announce the result
Use a live region or move focus so screen reader users know the form didn't submit and why.
Keep what people typed
Never clear valid fields when one field fails. Re-typing everything is the fastest way to lose a signup.
Confirm success clearly
After submitting, show and announce a confirmation that says what happens next.
For forms that create legal or financial commitments, like purchases or account deletion, WCAG also asks that submissions can be reviewed, corrected or reversed. A simple review step before payment covers it.
What do WCAG 2.2's redundant entry and accessible authentication rules mean for forms?
WCAG 2.2 added two criteria aimed directly at forms. Redundant entry (3.3.7, Level A) says people shouldn't have to re-enter information they've already given in the same process. Accessible authentication (3.3.8, Level AA) says logging in shouldn't depend on a cognitive test, like remembering a password or solving a puzzle, unless there's an alternative or help.
- Carry data forward. In a multi-step form, prefill later steps with earlier answers, or offer a 'same as billing address' option.
- Allow paste in every field. Blocking paste into password or email confirmation fields fails accessible authentication and frustrates everyone.
- Support password managers. Use proper autocomplete values on login fields so managers can fill them.
- Offer a show-password toggle so people can check what they typed.
- Offer passwordless options. Passkeys, magic links and sign-in with an existing account all avoid memory tests.
- Replace puzzle CAPTCHAs. Use invisible bot checks or honeypot fields instead of distorted text or image puzzles.
If you're deciding whether to split a long form into steps, redundant entry is one more thing to plan for. Our comparison of multi-step vs single-step forms covers when each converts better.
How do you make forms work with a keyboard?
A form works with a keyboard when people can reach every field and control with Tab, operate it with standard keys, see where focus is and submit without a mouse. Native HTML inputs do most of this for free. Problems usually come from custom dropdowns, date pickers, toggles and file uploads built from generic elements.
- Use native controls where you can. A styled native select is more accessible than most custom dropdowns.
- Follow the visual order. Tab order should match the layout, top to bottom and left to right.
- Show focus clearly. Use a visible focus ring with 3:1 contrast; our guide to accessible design basics covers styling.
- Size targets properly. Checkboxes, radio buttons and their labels should give at least 24 by 24 CSS pixels of target, and clicking the label should select the option.
- Let Enter submit. Keep forms inside a real form element with a real submit button.
Where third-party form tools go wrong
Embedded form builders, scheduling widgets and CRM forms are a frequent source of barriers because you don't control their markup. Common problems are labels that aren't linked to fields, error messages that aren't announced, custom dropdowns that can't be opened by keyboard and iframes with no title.
Before adopting one, test it with a keyboard and a screen reader. On a custom-built site, native forms posting to your CRM through an API usually give you more control; our guide to forms and integrations on Next.js marketing sites explains how that works. Whatever you use, make sure submissions actually arrive: see email deliverability for website forms.
Do accessible forms convert better?
Accessible forms tend to convert better because most accessibility fixes remove friction for everyone: clear labels, helpful errors, autocomplete, kept input and no puzzles. We can't give you a universal uplift figure, because it depends on how broken the form was, but the direction is consistent. Measure it on your own site by tracking starts, errors and completions before and after.
Set that up with proper events, as described in conversion tracking for lead-gen websites, so you can see which field causes drop-off. Check whether the field with the worst accessibility problems is also the one where people abandon.
