Answer 38 of 50
Designing User-Friendly and Error-Free Form Fields in Web Design
Forms are not the main reason shoppers abandon a purchase. In Baymard Institute’s cart abandonment research, extra costs such as shipping, tax, and fees lead the list at 40%, while 17% of US online shoppers point to a “too long / complicated checkout process”. But forms are a cause design alone can fix: Baymard finds the average US checkout shows 23.48 form elements by default (14.88 counting only fields), against an ideal flow of 12 to 14 elements (7 to 8 fields).
The payoff is measurable in error rates too. A 2014 CHI paper by Seckler and colleagues, summarized by Nielsen Norman Group, found that 78% of people submitted guideline-compliant forms correctly on the first try, against 42% for forms that broke the guidelines.
Cut every field you cannot justify
Nielsen Norman Group’s form design guidelines suggest removing fields whose information can be “(a) derived in some other way, (b) collected more conveniently at a later date, or (c) simply omitted” and state that every field you cut increases a form’s conversion rate. Baymard estimates that for most checkouts it’s possible to show 20% to 60% fewer form elements by default.
Treat the direction as reliable and the size of the gain as something to test, especially on lead forms where a sales team relies on a qualifying field. A field-by-field review looks like this:
| Field | Keep it if | Otherwise |
|---|---|---|
| Phone number | You will call, or delivery needs it | Remove it, or mark it optional and say why you ask |
| Company name | It changes pricing, routing, or the account you create | Ask later, after the first conversion |
| Middle name | A legal or identity check requires it | Remove it |
| Confirm email | Your error rate on email addresses is high and costly | Remove it and show the address back on the confirmation step |
| "How did you hear about us?" | Someone reviews the answers and acts on them | Move it to the confirmation page or a later survey |
| Separate billing address | Billing differs from shipping for a meaningful share of your buyers | Default to "same as shipping" with a checkbox |
Collecting information over several visits, sometimes called progressive profiling, is the fallback when the business needs more than the first form should ask: email now, company details on a later visit, preferences once the person uses the product.
Keep labels visible and next to their fields
NN/g’s guidance is to place labels “immediately above the field for mobile and shorter desktop forms, or next to the field for extremely long desktop forms”, and to present fields in a single column, with exceptions for short related fields such as City, State, and ZIP code on one row.
An eye-tracking test cited for top-aligned labels is Matteo Penzo’s 2006 study for UXmatters. It concluded that a label above the field “works better in most cases,” and that if labels sit to the left, right-aligning them cut the number of fixations by nearly half compared with left-aligned labels. Penzo also wrote that the “ad-hoc test setup didn’t resemble real-world conditions”, so read the result as a strong default rather than a law.
Placeholder text as the only label fails on three counts that NN/g’s article on placeholders in form fields documents: the hint disappears when typing starts and strains short-term memory, not all screen readers read placeholder text aloud, and the default light gray has poor contrast against most backgrounds. If you use floating labels, which move the placeholder above the field on focus, check that the floated label still meets contrast and size requirements.
Write labels in the reader’s words. “Email” beats “Electronic mail address,” and “ZIP code” beats “Postal routing number.”
Choose the input type before you style the field
The right HTML attributes prevent errors before any validation runs: they bring up the right keyboard on phones and let browsers fill in saved details.
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">
<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">
<label for="ship-zip">ZIP code</label>
<input id="ship-zip" name="ship-zip" inputmode="numeric" autocomplete="shipping postal-code">MDN’s reference for the inputmode attribute describes numeric as a keyboard that only requires the digits 0 to 9 and says inputs for telephone numbers “should typically use” type="tel" instead. Its autocomplete reference shows how to keep shipping and billing fields separate with tokens such as shipping postal-code and billing postal-code. The numeric keyboard suits a US-only ZIP field; a form that accepts addresses abroad should not force digits on postal codes.
Size each field to its expected input. Baymard’s 2010 article on form field width recommends matching a field’s width to the length of the expected input, so a ZIP code field looks short and a street address field looks long.
Show the format instead of forcing it
The UK government’s design system advice on phone number fields is to let people enter numbers in whatever format is familiar to them: “Allow for additional spaces, hyphens, dashes and brackets, and be able to accommodate country and area codes.” A rigid input mask that rejects those characters works against that advice and against international numbers.
The safer pattern is a visible example above or below the field, such as (555) 555-0123 for a US number, with the system accepting the digits however they arrive and normalizing them after the person finishes. The same thinking applies to card numbers: display them in groups of four if you like, but do not block a pasted number because it lacks the spaces.
Prevent the errors you can predict
Several prevention steps come down to telling people the rule before they break it:
- Show requirements up front. If a password needs a length or character mix, list it beside the field before the first keystroke.
- Don’t ask twice in the same process. WCAG 2.2 success criterion 3.3.7, Redundant Entry (Level A), asks that information already entered in the same process be auto-populated or available to select, with exceptions where re-entry is essential, required for security, or the earlier entry is no longer valid. A “billing same as shipping” checkbox satisfies it.
- Let password managers do their job. Criterion 3.3.8, Accessible Authentication (Minimum) (Level AA), says a cognitive function test “(such as remembering a password or solving a puzzle)” is not required for any authentication step unless an alternative or assistance mechanism is offered. Blocking paste on a password field works against it.
- Keep what people typed. When an error does occur, leave the entry in the field so the person can see what to fix.
When to validate (as someone leaves a field or when they submit) and how to word the messages has two defensible answers, compared in how to write error messages people can act on.
The accessibility criteria a form is measured against
| WCAG 2.2 criterion | Level | What it asks of a form |
|---|---|---|
| 1.3.5 Identify Input Purpose | AA | Fields that collect information about the user can be identified by software; in HTML, through the autocomplete attribute |
| 3.3.1 Error Identification | A | A detected error is identified and described to the user in text |
| 3.3.3 Error Suggestion | AA | If a correction is known, suggest it, unless that would jeopardize security or purpose |
| 3.3.7 Redundant Entry | A | Information already entered in the same process is filled in or selectable |
| 3.3.8 Accessible Authentication (Minimum) | AA | No memory or puzzle test at login unless an alternative or assistance is available |
| 2.5.8 Target Size (Minimum) | AA | Pointer targets at least 24 by 24 CSS pixels, or enough spacing, with listed exceptions |
| 2.5.5 Target Size (Enhanced) | AAA | Pointer targets at least 44 by 44 CSS pixels, with listed exceptions |
The underlying technique, a label element tied to each input through matching for and id attributes, is explained in WebAIM’s guide to creating accessible forms. The criterion pages for 1.3.5, 3.3.1, 3.3.3, and 2.5.8 carry the exceptions. How target size plays out for buttons is covered in where and how to size CTA buttons.
Splitting a long form into steps
A multi-step form helps only if each step behaves well:
- Show which step the person is on and how many remain.
- Keep every entry when someone goes back, which is also what Redundant Entry asks for within a process.
- Balance the steps, so a “step 3 of 4” does not hide most of the work.
- Offer a review screen before a purchase or application is submitted.
- Save progress if the form takes long enough that people may leave and return.
Spam protection and email checks
A visible puzzle CAPTCHA adds work for every legitimate user and, at login, runs into criterion 3.3.8. Google describes reCAPTCHA v3 as a score-based system that assesses interactions “without interrupting their experience”; your server checks the score and decides what to do, starting from a default threshold of 0.5 that Google suggests adjusting to your traffic.
For email addresses, a format check catches typos like a missing @, and a verification email confirms the address works. How far to go depends on what a bad address costs: a newsletter signup can live with format checks, while account recovery and order confirmations justify verification.
Audit fields first, fix input types and autocomplete second, then labels, formats, and the WCAG criteria in the table; that order removes predictable errors before a single validation message has to appear. Checkout fields sit inside a wider trust picture, covered in how design builds trust in ecommerce.