LFW

Insights · Getting forms right · 5 minutes

Tap Targets and Mobile Keyboards

Fingertips are not cursors. Target sizes, tappable labels, and the field settings that decide which keyboard appears — the mobile details that quietly determine whether your form gets finished.

By Leland Fiegel · Web operations, LFW · August 9, 2026

The form was approved on a screen nobody fills it in on

Forms are reviewed the way they're built: on a large monitor, with a mouse, by someone at a desk. Then they're used on a phone, in a hallway, one-thumbed, by someone who was in the middle of something else. For most organizations, the phone version isn't the edge case — it's where much, often most, of the traffic actually is. The desktop version your team approved is the minority experience.

A mouse pointer is a single pixel that goes exactly where it's aimed. A fingertip is a soft, imprecise instrument roughly a centimeter wide that hides the thing it's touching at the moment of contact. Every mobile form frustration downstream — the mistap, the wrong checkbox, the link hit instead of the button beside it — starts with a layout that was sized for the pixel and shipped to the fingertip.

Size targets for fingers, and let the label take the tap

Accessibility guidelines put hard numbers on what a fingertip needs — the common benchmarks land around 44 pixels for a comfortable target, with roughly 24 as the floor below which mistaps are essentially designed in. Native checkboxes and radio buttons come nowhere near that on their own; unassisted, they're among the smallest interactive elements on the web, asked to do precision work on the least precise input device most people own.

The oldest fix is still the best one, and it's free: associate the label with the control properly, and the entire label becomes tappable. The visitor stops aiming at a small box and just taps the words 'Subscribe to the newsletter' — a target twenty times the size, achieved with markup the form should have had anyway. It's the same association that makes the label work for screen readers, which is a pattern worth noticing: on forms, the accessible construction and the comfortable construction keep turning out to be the same construction.

Spacing is the other half of sizing. Two adequately sized targets pressed against each other still produce wrong-button taps, and the most expensive place for that is the one every form has: Submit next to Cancel or Reset. If a misplaced centimeter can erase the visitor's work, the layout — or the existence of that reset button at all — deserves a second look.

Your markup decides which keyboard appears

When a visitor taps a field on a phone, the software keyboard that slides up is not fate — it's chosen by the field's declared type. Mark the field as an email field and the keyboard arrives with @ and the period on its first screen. Mark it as a telephone field and a number pad appears. Leave everything as the default generic text field and the visitor gets the generic keyboard for all of it, hunting through symbol layers to type an address your markup could have made two taps easier.

The same declarations feed autofill. Fields that state what they are — name, email, organization, street address — let the browser offer to fill them from what it already knows, collapsing the most tedious stretch of any mobile form into one tap. For a visitor on a phone, that's frequently the difference between finishing now and abandoning for a 'later' that doesn't come.

One more phone-specific trap: some mobile browsers zoom the whole page when the visitor focuses a field whose text is smaller than the browser considers readable. The visitor finishes typing, the page is still magnified and off-center, and the form suddenly feels broken. Keeping field text at a comfortable, honest size prevents the zoom from ever firing — a reminder that on mobile, small type isn't just hard to read; it has side effects.

Turn off the helpfulness that hurts

Phone keyboards ship with reflexes tuned for prose: capitalize the first letter, autocorrect unfamiliar words. Aimed at a message field, those reflexes help. Aimed at an email address, they vandalize it — capitalizing the first letter, 'correcting' an unusual surname or domain into a dictionary word, and manufacturing exactly the wrong-address problem this series opened with. The visitor typed carefully; the keyboard un-typed it.

Fields that hold identifiers rather than sentences — emails, usernames, reference numbers — should tell the keyboard to stand down: no auto-capitalization, no autocorrect. It's a one-line decision per field, invisible when it's right, and quietly corrosive when it's wrong, because the visitor rarely notices the keyboard's edit before pressing submit.

The audit is in your pocket

None of this requires a lab. Take out your phone, open your own form, and fill it in for real — thumb only, walking pace, no charity. Every mistap, every wrong keyboard, every pinch-zoom to hit a checkbox is a note a real visitor has already taken silently. Ten minutes of this is the cheapest usability testing your organization will ever run, and the punch list it produces is refreshingly concrete.

It also closes the loop on this series so far: labels that stay visible are also the labels that take the tap; submissions that preserve work matter twice as much when retyping means thumb-typing; errors that explain themselves matter more on a screen that shows one field at a time. The next installment stays on the theme of things that look fine on the designer's screen — native form controls on a dark theme, and the dropdown arrow that vanishes into the background.

Keep reading

August 8, 2026 · 5 minutes

Error Messages That Actually Help

A form's error messages are the only conversation it ever has. What a useful error says, where it belongs on the page, when it should speak up, and who has to be able to perceive it.

August 6, 2026 · 5 minutes

Submitting Without Losing the Page

In-page submission done honestly: the four states a submit button owes the visitor, why typed work must survive every failure, and how to make success audible as well as visible.

Prefer to write?

Tell us what needs to work better.

Slow, fragile, hard to edit, missing a workflow — say it plainly. You'll get a straight answer, not a ticket number.

You'll get a straight answer, usually the same day.