Mobile Forms: Keyboards, Autofill and Thumb Reach

A mobile form converts when it respects three physical realities: typing on a phone is slow and error-prone, so the form should need as little of it as possible; the screen is small and often used one-handed, so fields and buttons must sit within thumb reach and read at a glance; and the phone already knows the visitor's name, email and address, so autofill should be invited, not blocked. Get the input types right (email, number and phone keyboards where they belong), label fields in the code so autofill maps correctly, keep targets generous, and test the whole form one-thumbed. Mobile form craft is mostly subtraction of friction that desktop testing never reveals.

Each field type can request its proper keyboard: email fields get the keyboard with @ and the domain key prominent, phone fields get the dialling pad, numeric fields get digits, and ordinary text keeps the full keyboard with sensible capitalisation. The visitor never notices this when it works - they just type faster with fewer errors - and notices immediately when a postcode field offers them a full alphabet hunt or a card field opens letters. Set the input type and mode in the form's code or builder settings for every field, and turn off autocorrect and autocapitalisation where they corrupt data: emails, codes, names of places, voucher strings.

Phones and browsers will complete name, email, phone and address fields in one tap when the fields carry the standard autocomplete names in their code. Most form builders expose these settings; many templates omit them, and the visitor pays in typing for the omission. Check each field's autocomplete attribute against its true purpose - a form where the email field is coded as free text gets no help, and a delivery address coded as billing invites the wrong address entirely. Never disable paste or autofill for security theatre on ordinary business forms: blocking the password manager and the pasted email address punishes careful visitors and prevents nothing relevant at this scale.

Place the primary action where a thumb resting at the screen's lower half can reach without a grip shift, size tap targets generously with clear space between adjacent controls, and never put a destructive or reset action beside the submit button. Long forms may earn a sticky continue or submit bar on mobile, weighed against the screen space it permanently eats; test it, because on short forms it is pure cost. Zoom traps matter too: form text smaller than the threshold that triggers automatic zoom on focus makes the page lurch at every field, a small disorientation multiplied by every field on the form.

The single column of the layout guide is non-negotiable on phones, labels stay above fields rather than beside them, and field groups that were side by side on desktop must stack in the order a person answers them - a stack that separates a label from its field, or puts the day after the year, breaks the form at its smallest size. Check the form with the keyboard open, because the visible area halves and any fixed header or sticky bar takes its share of what remains; a submit button that hides behind the keyboard at the final field loses completions at the last metre.

Mobile forms are completed on trains, in queues, in bright light and on ageing phones with cracked screens and slow connections. Each step of a multi-step form must load fast and forgive interruption: a form that loses everything when the connection drops in a tunnel, or when the visitor switches away to check a detail and returns, converts its own audience's reality into abandonment. Keep individual steps short, preserve entries wherever the tooling allows, and avoid timed sessions that expire mid-answer without warning. The desktop test at the office desk certifies none of this; only phone testing in the wild does.

Formalise the test: one person, a mid-range phone, one thumb, standing, completing each public form with realistic data, while someone notes every zoom, scroll hunt, wrong keyboard, autofill failure and reach stretch. Fix in order of pain, retest, and log the pass. Run it after every theme or form-tool update, because mobile form breakage arrives through updates, not through anyone deciding to break it. The speed side of the mobile experience - how fast the form page itself arrives - is covered by the speed bench, speed and mobile conversion; this guide's narrower claim is that a fast form a thumb cannot operate still does not convert.