Tap Targets and Mobile Keyboards

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

Forms get reviewed the way they're built: on a large monitor, with a mouse, by someone at a desk. Then people use them on a phone, in a hallway, with one thumb, in the middle of something else. For most organizations, phones aren't the edge case. Much of the traffic, often most of it, comes from phones. The desktop version your team approved is what the minority sees.

A mouse pointer lands exactly where you aim it. A fingertip is about a centimeter wide, imprecise, and covers the thing it's touching. Most mobile form trouble (the mistap, the wrong checkbox, the link hit instead of the button next to it) comes from a layout sized for a mouse and used with a finger.

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

Accessibility guidelines put numbers on this. The common benchmarks are about 44 pixels for a comfortable target, with about 24 as the floor. Below that, mistaps are close to guaranteed. Native checkboxes and radio buttons come nowhere near that on their own. Without help, they are among the smallest controls on the web, and people have to hit them with the least precise pointer they own.

The oldest fix is still the best, and it's free. Connect the label to its control properly, and the whole label becomes tappable. Your visitor can tap the words 'Subscribe to the newsletter' instead of aiming at a small box. That's a target twenty times the size, from markup the form should have had anyway.

The same connection is what lets screen readers announce the label. On forms, the accessible way to build something and the comfortable way usually turn out to be the same.

Spacing matters as much as size. Two well-sized targets pressed together still cause wrong-button taps. The costliest spot is one every form has: Submit next to Cancel or Reset. If a misplaced centimeter can erase your visitor's work, rethink the layout, or whether that Reset button needs to exist at all.

Your markup decides which keyboard appears

When a visitor taps a field on a phone, the field's declared type decides which keyboard slides up. Mark it as an email field and the keyboard shows @ and the period on its first screen. Mark it as a phone field and a number pad appears. Leave everything as a generic text field and the visitor gets the generic keyboard for all of it, digging through symbol screens to type an address.

The same settings feed autofill. When fields say what they are (name, email, organization, street address), the browser can offer to fill them from what it already knows. The most tedious part of a mobile form becomes one tap. For someone on a phone, that's often the difference between finishing now and putting it off until a 'later' that never comes.

One more phone trap: some mobile browsers zoom the whole page when someone taps into a field whose text is smaller than the browser considers readable. When they finish typing, the page is still zoomed in and off-center, and the form feels broken. Keep field text at a comfortable size and the zoom never happens.

Turn off autocorrect where it hurts

Phone keyboards are set up for writing sentences. They capitalize the first letter and autocorrect words they don't know. In a message field, that helps. In an email field, it damages the address: a capital first letter, or an unusual surname or domain 'corrected' into a dictionary word. That's the wrong-address problem this series started with. The visitor typed carefully, and the keyboard changed it.

Fields that hold identifiers, like emails, usernames, and reference numbers, should turn off auto-capitalization and autocorrect. It's a one-line setting per field. Nobody notices when it's right. When it's wrong, the damage goes unseen, because visitors rarely spot the keyboard's change before they press Submit.

Test it on your own phone

You don't need a lab for any of this. Take out your phone, open your own form, and fill it in for real: thumb only, while walking, and don't go easy on it. Each mistap, wrong keyboard, or pinch-zoom to hit a checkbox is something a real visitor has already run into without telling you. Ten minutes of this is the cheapest usability testing your organization will ever do, and you'll come away with a concrete list of fixes.

This ties back to the earlier posts in the series. Labels that stay visible are also the labels people can tap. Saving the visitor's work matters twice as much when retyping means thumb-typing. Clear error messages matter more on a screen that shows one field at a time. The next post stays with things that look fine on the designer's screen: native form controls on a dark theme, and the dropdown arrow that disappears into the background.