Mobile form design: the keyboard, autofill and tap choices that matter
Forms on mobile are quick when the phone does most of the typing. Give each field the right type so the matching keyboard appears, add autocomplete values so the browser can fill in names, emails and addresses, keep to one column with large tap targets, and ask for as little as you can. Every field you remove saves more time than any styling.
Let the keyboard match the answer
On a phone, the input's type decides which on-screen keyboard appears. An email field with type="email" brings up a keyboard with the @ sign close at hand; type="tel" brings up a number pad. The type also gives the browser simple validation. Where you want a particular keyboard without that validation, the inputmode attribute is a hint only; MDN's inputmode reference lists the values and recommends using the right type first.
| Field | Markup | What the visitor gets |
|---|---|---|
type="email" | Keyboard with @ and . to hand | |
| Phone | type="tel" | Telephone keypad |
| Quantity or age | type="text" inputmode="numeric" | Digits only, without a spinner |
| Price with decimals | inputmode="decimal" | Digits and the local decimal separator |
| Website | type="url" | Keyboard with / and .com keys on many phones |
| Search box | type="search" | A Search key in place of Return |
| Card or one-time code | inputmode="numeric" with autocomplete="one-time-code" | Number pad, and codes from messages offered above the keyboard |
Avoid type="number" for things that aren't really amounts, such as postcodes, card numbers or phone numbers. It drops leading zeros and adds spinner arrows nobody wants.
Autocomplete attributes do the typing
The autocomplete attribute tells the browser what a field is for, so it can offer saved details. MDN's autocomplete reference lists the tokens: name, given-name, email, tel, street-address, postal-code and many more. It's also an accessibility requirement: WCAG's Identify Input Purpose, at level AA, asks that fields collecting information about the user declare their purpose in code, which helps people who struggle to recall or type personal details.
- Prefer a single
namefield over separate first and last name, unless you really need them apart. - Don't set
autocomplete="off"on ordinary fields. It removes a feature many people depend on. - Match the token to the field exactly. A billing postcode marked as
postal-codewithbillingin front helps the browser fill the right address.
Layout for thumbs
- One column. Side-by-side fields on a phone make labels wrap and inputs too narrow to read back what was typed.
- Labels above fields, not inside them. Placeholder text vanishes the moment someone types, and on a small screen there's no room to guess.
- Big targets. Fields and buttons at least 44px tall, with space between them. WCAG's target size minimum sets a floor of 24 by 24 CSS pixels; comfortable thumbs need more. See touch target size.
- Text at 16px or larger in inputs. Some phone browsers zoom into fields with smaller text, which shifts the layout under the visitor's thumb.
- Choices as buttons, not dropdowns, when there are only a handful. Tapping "10:00" is quicker than opening a select and scrolling.
- The send button at the end of the form, full width on phones, with a label that says what happens: "Request this time", not "Submit".
Ask for less
Every field is a small task on a phone. Before styling, cut. Ask for a phone number or an email unless you genuinely need both. Leave out "How did you hear about us?". Don't make people confirm their email by typing it twice. When a field is optional, say so in the label, or better, remove it. A three-field contact form, such as the ones described in contact form design, gets more replies than a nine-field one, and nobody needs to scroll to find the button.
Common mobile form problems
- The keyboard covering the field being typed in, because the form sits in a fixed panel that can't scroll.
- Dates entered in three separate dropdowns instead of the native date picker or a few tappable days.
- Error messages placed below the field, hidden behind the keyboard. See form error messages.
- A cookie or chat panel parked over the send button.
Forms in Anticode
Anticode's contact, booking and newsletter forms use fixed fields: name, email and a message for contact; the service, day, time, name, phone and email for bookings; and an email address for the newsletter. Sentinel checks every build for a label on each field and a type and length limit on every text field, which is what gives phones the right keyboard. Days and times on the booking form are tappable choices rather than typed dates.
Questions people ask
What's the difference between inputmode and type?
type defines the kind of data and adds basic validation, and it also sets the keyboard. inputmode only hints at which keyboard to show.
Why does my phone zoom in when I tap a form field?
Some mobile browsers zoom into inputs whose text is smaller than 16px. Set input text to 16px or more.
Should mobile forms use one column?
Yes, in almost every case. Short pairs such as a postcode and house number can share a row only if both stay readable.