10 Most seen problems that cause bad webforms

If you have audited more than a handful of forms, you start to see the same problems on rotation. Not exotic ones — the obvious, well-documented, fix-it-in-an-afternoon kind. They survive because nobody owns them, or because the team is busy testing button colours instead.

This is a ranked list of the ten that show up most often, why each one matters, and what to do about it. The ranking matters: not every problem is worth the same effort. Baymard Institute's research consistently puts checkout usability problems above price, shipping, and trust as the leading drivers of cart abandonment, and the pattern holds for non-commerce forms too.

1. Are required fields actually marked as required?

Required fields need an unambiguous visual marker — usually an asterisk or the word "required" in the label — and the convention should be consistent across the entire form. Marking optional fields instead, or leaving the user to discover requirements through error messages, is the most common cause of avoidable submission failures.

The fix is small, but the impact is not. When users hit a wall of red errors after pressing submit, a measurable percentage simply leave. Worse, some forms only mark requirement through error states, which means a first-time visitor learns the rules by failing first.

If your form has more optional than required fields, flip the convention: mark the optional ones with "(optional)" and let everything else be assumed required. Nielsen Norman Group's guidance on this has held for over a decade and still gets ignored.

2. Do your field labels survive a five-second test?

A field label should tell the user exactly what to type, in plain language, without abbreviations or internal jargon. Float labels, placeholder-only labels, and ambiguous one-word labels ("Reference", "Code", "ID") all create hesitation. The test: can a stranger fill the field correctly without context?

Placeholder-only labels are the worst offender because the prompt disappears the moment a user starts typing. They look clean in mockups and fail in practice — particularly on long forms where users tab back to verify what they entered.

Use a visible label above the field, in plain English, in the user's vocabulary. "Reference" might mean something inside your CRM; to a customer it could mean an order number, a quote ID, or nothing at all.

3. When and where do error messages appear?

Error messages should fire on blur, not only on submit, and they should appear adjacent to the field that caused them — not in a banner at the top of the form. They should explain what is wrong and what to do, in that order. "Invalid input" is not an error message, it is a shrug.

The painful version is the long mobile form that validates only on submit and then sends the user scrolling through five screens hunting for the red field. By the time they find it, they have forgotten what was wrong. A measurable share of them do not come back.

Inline validation — clear, specific, and timed to the field's blur event — fixes most of this. Avoid validating mid-typing on free-text fields, which surfaces errors before the user is finished and reads as accusatory.

4. Does the format expectation match what users actually type?

If a field expects a specific format — phone numbers with country codes, dates as DD/MM/YYYY, postcodes with spaces — say so before the user types, and accept reasonable variations. Forcing a user to guess between +44 and 0044, or between 04/05/2026 and 05/04/2026, is unnecessary failure.

The phone field is the worst offender across every dataset we have seen. The date-of-birth field is a close second, particularly when it asks for a four-digit year but accepts two-digit input silently and then misroutes the customer to a different cohort.

Provide an inline hint below the field, accept multiple formats, and normalise on submission. The work belongs in your code, not in the user's head.

5. Is the form actually built for the device most people use?

Most commercial sites now see more than half their traffic on mobile, yet many forms are still designed desktop-first and shrunk to fit. The signs are everywhere: keyboards that show letters when a number is needed, tap targets too small for thumbs, fields that overlap the keyboard on focus, autocapitalisation on email fields.

The single highest-impact fix on most mobile forms is correct inputmode and autocomplete attributes — each one changes the keyboard the user sees, and each one shaves seconds and errors off the journey. The most useful pairings:

A mobile form should be tested on a real mobile device, by a real person with average-size thumbs, every quarter. Emulators lie about touch behaviour.

6. Does the submit button tell the user what will happen?

"Send", "Submit", and "Continue" are filler words that ask the user to take it on faith. A submit button should describe the outcome of pressing it: "Book my room", "Get my quote", "Create my account". The verb-plus-noun pattern reduces hesitation by removing the question of what happens next, and gives the user a clear sense of the commitment.

This is one of the cheapest changes possible and it punches above its weight. Multiple eye-tracking studies show users pause on generic button copy as they parse the consequence; specific copy collapses that pause to near zero.

The other underrated fix: state the post-submit expectation in microcopy under the button. "We will email your quote within two minutes" sets the right expectation and reduces post-submit anxiety.

7. Can a stranger navigate the form without thinking?

The order of fields should match the order in which users naturally think about the information — typically personal details, then contact details, then anything that requires looking up. Tab order should follow visual order. Keyboard navigation should not skip fields, trap focus, or land in unpredictable places.

The classic violation is the multi-column form where tabbing moves down the left column instead of across the row. The visual flow says one thing, the keyboard says another, and users with assistive technology are punished worst.

Test the form using only a keyboard. If you cannot complete it without reaching for the mouse, neither can a meaningful share of your visitors.

"Almost every form problem worth fixing is invisible to the team that built it. Watching one real session changes that in about ninety seconds."

8. Does the user know how much further they have to go?

On forms of three steps or more, a progress indicator earns its place — it tells the user how much effort is left and reduces the urge to abandon at step two. On shorter forms, indicators add visual noise without value. The decision is binary: long enough to need one, or short enough to skip it.

The worst version is a progress bar that lies. Showing "Step 2 of 3" and then revealing a fourth step on submission is a betrayal that costs more than no indicator at all. If steps are conditional, say so up front.

For e-commerce checkouts, the strongest pattern is the labelled three-step bar — Address, Delivery, Payment — visible from step one. Users sign an implicit contract with that bar; do not break it.

9. Is autofill helping or actively hurting?

Autofill is a quiet conversion lever when configured correctly and a quiet conversion killer when it is not. Browsers and password managers rely on standard autocomplete attribute values; if your form uses non-standard names or omits the attribute, you get random behaviour — first names landing in last-name fields, the wrong saved address chosen, silent failure.

Audit the form with the WHATWG autocomplete reference open and use the standard token for each field. Five minutes of work, immediate effect on completion time. The values you will reach for most:

The opposite mistake is just as common: forms that disable autofill entirely on the assumption that it interferes with custom validation. It does not, and the user pays for the team's nervousness.

10. Is the form usable by people who need it to be?

Accessibility is no longer an optional polish. Under the European Accessibility Act, which became enforceable across the EU in June 2025, commercial digital services — including most forms — must meet WCAG 2.2 AA. Beyond compliance, the same fixes (contrast, labels, keyboard support, focus states) tend to lift conversion for everyone.

The most common accessibility failures on forms are insufficient label-to-input association, low contrast on placeholder text, missing focus indicators, and error messages communicated only by colour. None are hard to fix; all are easy to overlook.

Run your form through an automated checker as a baseline, then have a person test it with a screen reader. Automated tools catch about a third of issues; the rest need a human.

So where should you actually start?

Rank the ten by how many users each problem affects, multiplied by the friction it causes. A 19% error rate on a phone field that every visitor must fill is a bigger lever than a missing progress bar on a single-page form. Field-level analytics or session replays make this triage straightforward; without them, you are guessing.

This is where having instrumentation matters. Field-level form analytics show which fields cause the most drop-off, retries, and corrections — meaning you can act on the worst offender first instead of redesigning the whole form on intuition.

The other half of the answer is cultural: form quality belongs to someone. If it lives in the gap between marketing, design, and engineering, none of these problems will get fixed because none of them is anyone's job. Pick an owner.