Why people abandon your forms — and how to design ones they finish
Most forms lose people long before the submit button. Here's why they bail — too many fields, vague labels, brutal error handling — and how to design a form that's quick, clear and accessible enough to actually complete.
You can do everything right — drive people to your form, write a clear call to action, make the case for why they should fill it in — and still lose most of them somewhere between the first field and the submit button. Form abandonment is quiet. Nobody emails to tell you they gave up halfway through your referral form; they just close the tab.
The good news is that the reasons people abandon forms are well understood and almost entirely fixable. None of them require a redesign of your whole product. They're mostly about respecting the person's time and not making them guess.
The length problem nobody wants to hear
The single biggest predictor of whether someone finishes a form is how long it looks. Not how long it actually takes — how long it looks. A wall of twenty fields reads as "this will take a while", and a meaningful share of people decide it's not worth it before typing a thing.
The fix is uncomfortable because it's a discipline, not a feature: question every field. For each one, ask "what happens if we don't collect this?" If the answer is "nothing, really" or "we'd be nice to have it", cut it. Phone and email when an email will do. A title field ("Mr/Mrs/Ms") you never use. A second address line that's optional but still adds visual weight.
Optional fields still cost you
An optional field isn't free just because people can skip it. It still adds length, still has to be read and reasoned about, and still makes the form look longer. If you don't truly need it, removing it beats marking it optional.
Labels that make people stop and think
People fill in forms on autopilot. Anything that breaks that flow — a label they have to re-read, a field where they're unsure what you want — is a moment where they might give up. A few patterns cause most of the friction:
Hidden or placeholder-only labels
Designers love the clean look of a field whose label lives inside it as grey placeholder text. The problem: the placeholder disappears the moment someone starts typing, so they can no longer check what the field was for. It also fails colour contrast and isn't reliably announced by screen readers. Keep a visible label above every field.
Vague or internal wording
"Reference" means nothing to the person filling in your form. "Your booking reference (on your confirmation email)" tells them exactly what to type and where to find it. Write labels for the person, not for your database.
No indication of format
If you need a date in a particular format, or a phone number with no spaces, say so before they get it wrong — not after. A short hint under the field beats a red error every time.
Error handling is where forms go to die
Here's a familiar experience: you fill in a long form, hit submit, and the page comes back with a single line — "Please correct the errors below" — and no clear sign of which field is wrong or why. That's the moment a lot of people close the tab. They've done the work, been told it's wrong, and not been told how to fix it.
Good error handling is mostly about being specific and being kind:
Hostile errors
Errors appear only after submit. The message is generic ("Invalid input"). The problem field isn't highlighted, isn't scrolled to, and a screen reader user gets no announcement at all — they just land back on a form that didn't go through, with no idea why.
Helpful errors
The field with the problem is clearly marked, the message says what's wrong and how to fix it ("Enter an email address, like name@example.com (opens in new tab)"), focus moves to the first error, and assistive technology announces it. The person knows exactly what to do next.
Notice that the "helpful" column isn't just nicer — it's more accessible. Associating each error with its field, moving focus to the first problem, and announcing errors to assistive technology are WCAG requirements. As so often with forms, doing the accessible thing and doing the usable thing turn out to be the same thing.
Accessibility isn't a separate project
It's tempting to file "accessibility" under compliance — a box to tick once, separately from the real design work. But almost everything that makes a form accessible also makes it easier for everyone to finish: visible labels, logical tab order, decent contrast, clear errors, fields grouped sensibly. The person using a screen reader and the person filling your form in a hurry on a phone in poor signal want the same things.
For a lot of UK organisations it isn't optional anyway. The Equality Act 2010 applies broadly, and public sector bodies have specific duties under the accessibility regulations. But the framing that gets you a better form is the practical one: an accessible form is a form more people can actually complete.
A quick self-check
Try filling in your own form using only the keyboard — no mouse. Can you reach every field in a sensible order, tell which one is focused, and understand every error? If you can't, neither can a good chunk of the people you're asking to use it.
Where FormGenius fits
This is the thinking baked into FormGenius. Forms you design on the canvas publish as WCAG 2.2 AA web forms with visible labels, a sensible focus order, and error messages that are properly associated with their fields and announced to assistive technology — so the accessible behaviour above is the default, not something you have to remember to build. The same design also exports as a tagged PDF/UA document, so a form works whether it's filled in online or on paper.
You still have to make the hard calls — which fields you genuinely need, how to word them — because no tool can decide that for you. But the part that's fiddly and easy to get wrong, the accessibility plumbing underneath, comes out correct by default.
No account needed — design a form, see how it reads as an accessible web form and a tagged PDF, and ship something people can actually finish.
Build an accessible form free
