Accessibility guidance for forms tends to arrive as a list of eighty checkpoints, which is accurate and almost useless. Eighty things all presented as equally important is a list nobody starts.
In practice a small number of things decide whether a form is usable at all, and the rest are refinements. These are the five, in the order I would fix them.
1. Every field has a real label
Not a placeholder. A placeholder disappears the moment somebody starts typing, which means anyone who is interrupted has no way to recover what the field was for. It is announced inconsistently across screen readers. And it almost always fails contrast requirements, because placeholder grey is chosen to look secondary.
A label element, associated with the input, is the entire fix. If the design genuinely cannot show one, a visually-hidden label is still enormously better than nothing — but consider whether a design that cannot show what its fields are for is a good design.
This one is first because it is the most common and the most complete failure. A form of unlabelled inputs is not difficult to use; it is impossible.
2. Errors say what to do
"Invalid input" tells somebody that something is wrong and nothing whatsoever about what. "Enter a date in the past" tells them what to type next.
The error also has to be associated with its field programmatically, and announced when it appears. Otherwise a screen reader user learns that there is an error somewhere on the form and gets to hunt for it, which is the single most demoralising experience a form can offer.
And errors must survive submission. A form that clears what somebody typed when it rejects it is asking them to do the whole thing again.
"Invalid input" tells somebody something is wrong and nothing about what.
3. Focus goes somewhere sensible
This is the one that breaks conversational forms specifically, and it breaks them completely.
When the next question appears, focus has to move to it. If it stays on the button that has just been removed from the page, focus falls back to the body — a keyboard user is stranded at the top of the document, and a screen reader user has no indication that anything happened at all. The form appears to have frozen.
The same applies to anything that opens: a dialog takes focus, traps it while open, and returns it to whatever opened it when it closes. This is not exotic; it is the difference between a component that works and one that doesn't.
4. The focus ring is visible
Somebody, at some point, removed the default outline because it looked untidy on one button, and never put anything back. Now nobody navigating by keyboard can tell where they are on the page.
If you remove it, replace it. A two-pixel ring in a colour that contrasts with both the component and the background, with a little offset so it reads as separate from the element. It should be at least as visible as the browser default, not a subtle hint.
Test it the obvious way: put your mouse down and tab through your own form. If you lose track of where you are even once, it is not good enough.
5. Nothing depends on colour alone
A required field marked only by a red asterisk. An error state shown only by a red border. A rating where the selected value differs from the others only in hue.
Add a word, an icon, a shape — anything that is not exclusively colour. It helps people with colour vision deficiency, which is roughly one man in twelve, and it helps everybody else in bright sunlight, on a bad screen, or in a hurry.
What this costs
Almost nothing, if you do it while building. A great deal, if you do it afterwards, because focus management and error association are structural and retrofitting them means touching every component.
It is also worth saying plainly: this is not a niche concern about a small group. Temporary and situational impairments are enormously common — a broken wrist, a bright day, a phone held one-handed on a train — and every one of these five fixes helps in those cases too.
None of this requires an audit or a consultant to start. Label your fields, say what went wrong, move focus, show it, and don't rely on colour. That gets you most of the way, and you can do it this afternoon.
How to check, without buying anything
Three tests, in increasing order of how much they will teach you.
Unplug the mouse. Tab through the form from the top and complete it. You will find the focus problems immediately, and you will find them in the order a real user would.
Run an automated checker. The browser's own accessibility audit or an axe extension takes thirty seconds and catches missing labels, contrast failures and broken associations. It is worth being clear that automated tools catch perhaps a third of real issues — they can tell you a label is missing, not that it is wrong — but a third for thirty seconds is a good trade.
Turn on the screen reader that came with your operating system and try to complete the form with your eyes closed. This is uncomfortable and slow the first time, and it is the only one of the three that shows you what the experience is actually like rather than whether a rule was followed.
The ones that come next
Once the five are done, these are the next most valuable, and they are refinements rather than blockers:
- Group related controls. A set of radio buttons needs a fieldset and a legend, or a screen reader announces five unrelated options with no idea what the question was.
- Set the right input types and autocomplete attributes. type="email" gets the correct keyboard on a phone; autocomplete="tel" lets the browser fill it in. Both help everybody, and disproportionately help people for whom typing is difficult.
- Don't put a time limit on it. If you must, say so up front and let people extend it.
- Respect reduced-motion. Someone who has asked their operating system to stop animations has asked for a reason, and a form that slides every question in regardless can cause genuine nausea.
- Make the tap targets big enough. Around 44 pixels square. This is an accessibility requirement and also simply better for anyone on a train.