Signup forms break on mobile for a small number of repeatable reasons: the keyboard covers the submit button, a fixed banner sits on top of the form, the wrong keyboard opens for the field, validation messages render off-screen, and the confirmation step depends on an email that a phone client shows differently. None of these appear in a desktop browser, which is where most forms get tested. This article lists the causes, how to reproduce each one in a few minutes, and how to catch them before users do.
Why the desktop test passes and the phone fails
A desktop browser has a mouse, a 1440 pixel wide window, no on-screen keyboard and a stable viewport. A phone has none of those. The form that looks fine in a device emulator still fails on a real phone, because the emulator does not open a keyboard, does not autofill, and does not run the vendor browser (Safari on iPhone, Chrome or Samsung Internet on Android). So the first rule: test the signup on a real phone, on mobile data, in a private window.
The eight usual causes
1. The keyboard covers the button
On a phone the on-screen keyboard takes about half the screen. If the submit button sits right under the last field, tapping into that field pushes the button out of view, and some users never find it. Reproduce: tap the last input and look for the button. Fix: let the page scroll (do not fix the form's height), or put the button above the fold of the keyboard, or move "Continue" into the keyboard's return key with the right form markup.
2. A fixed banner sits on the form
Cookie notices, chat widgets and "download our app" bars are usually position fixed at the bottom. On a 640 pixel tall phone screen they cover the last field or the submit button. Reproduce: open the page fresh so the banner shows, scroll to the form. Fix: add bottom padding to the page equal to the banner's height while the banner is visible, or make the banner dismissable with one tap.
3. The wrong keyboard opens
An email field that opens the default keyboard forces users to hunt for the @ sign; a phone number field that opens the text keyboard invites typos. Reproduce: tap each field and look at the keyboard. Fix: use type="email", type="tel", inputmode="numeric" where it applies, and autocomplete attributes (email, new-password, given-name) so the phone can fill the form in one tap.
4. Validation messages render off-screen
Inline errors placed above the field, or in a toast at the top of the page, are invisible when the keyboard is open and the page is scrolled to the input. The user taps submit, nothing visible happens, and they leave. Reproduce: submit with an empty required field while the keyboard is open. Fix: put the error directly under the field, scroll to the first invalid field on submit, and change the button state so it is clear the submit was rejected.
5. Autofill fills the wrong fields
Password managers and the phone's own autofill guess fields by their labels and names. A "Company" field named "name" gets the user's name; a "Confirm password" field without autocomplete="new-password" gets the old password. Reproduce: use the phone's autofill on the form and read what landed where. Fix: correct name and autocomplete attributes, one per field.
6. The confirmation email does not work on the phone
The signup succeeds, the email arrives, and the link opens in an in-app browser (Gmail's, Instagram's) with no session, so the user lands on a login page instead of the confirmed dashboard. Reproduce: sign up on the phone, open the email in the Gmail app, tap the link. Fix: make the confirmation link work without a session (confirm by token, then show a login prompt), and make the link single-use with a clear message when it is reused.
7. Zoom on focus
On iPhone, an input with a font size under 16 pixels makes Safari zoom in when it gets focus, and the page stays zoomed after the keyboard closes. The form then looks broken. Reproduce: tap a field on an iPhone. Fix: set the input font size to 16 pixels or more on small screens.
8. Tap targets too close together
Checkbox for the terms, a link to the terms, and the submit button within a few pixels of each other means a thumb hits the wrong one. Reproduce: try to tick the terms checkbox three times in a row. Fix: 44 by 44 pixel targets and at least 8 pixels between them.
How to catch these before users do
A ten-minute routine before each release that touches the form:
- On a real phone, in a private window, with the cookie banner showing, open the signup page.
- Fill the form using autofill where offered. Check what landed in each field.
- Submit with one required field empty. Confirm the error is visible without scrolling.
- Submit correctly. Open the confirmation email in the phone's mail app and tap the link.
- Rotate the phone once on the form page and once on the page after signup.
If you have more than one form, or the form changes often, this becomes the kind of check that an automated end-to-end test should own. AnyTest's testing agents explore the signup from your URL, write the test, and run it on every release; a FAILED result comes with a step timeline so you can see which of the eight causes above hit. The free capability audit on anytest.dev reads your public pages first and lists what the agents would test, so you know before anything runs.
FAQ
Can I test mobile signup with the browser's device toolbar? Partly. It shows layout at phone widths, which catches cause 2 and sometimes 8. It does not open a keyboard, does not autofill and does not run Safari, so causes 1, 3, 5, 6 and 7 stay hidden.
Which phone should I test on? The one most of your visitors use, usually an iPhone with Safari and an Android phone with Chrome. Your analytics will say which. One of each is enough for a first pass.
My signup works on my phone. Why do users still report problems? Your phone has your autofill data, your saved session and your network. Use a private window, a fresh email address and mobile data, and try the flow from an email link rather than from a bookmark.
What should a signup form error message say? What is wrong and what to do: "Enter an email address with an @" beats "Invalid input". Put it under the field, keep it visible with the keyboard open, and keep the typed value in the field.
Is there a cheap way to have someone else run this check? Yes. On WURK, AnyTest runs a one-time QA audit of your web app for $5: the signup and one or two other flows you name, on your URL, with a report that gives a proposed fix for every issue, within 2 days. Order it here: https://wurk.fun/store/6cad00c3-f394-4ca0-9743-55a929979acf
Latest comments
0