Contact form 7 not working on mobile: tap by tap

The laptop test passes because a laptop has room for everything at once. On a phone, the keyboard takes half the screen, so the Send button sits behind it, or a fixed header or cookie bar covers the bottom of the form. Tapping a small field can zoom the page on some phones, and the layout shifts under the thumb. A link from a social app opens in that app's browser, which may restrict the scripts or cookies the form needs. The owner who checks the form in a wide desktop window never sees the button move.

• At phone width, tap each field and check that the Send button stays visible above the keyboard.
• Look for a sticky header, chat bubble or cookie bar that covers the bottom of the form.
• Read the input font size. Under 16 pixels, iPhone zooms the page when a field gets focus.
• Open the link from a social app, then from the phone's own browser, and compare the two.
• Check that the reply shows near the Send button, since a message above the visible area is easy to miss.

On iPhone, Safari zooms into any field whose text is smaller than 16 pixels. When the zoom releases, the page can settle in a different position, and the Send button may now sit below the visible area. The visitor has already typed, so they scroll, find nothing where they expected, and leave. This only happens on the phone, and only on fields a theme styled small.

Android keyboards handle the same field differently. The keyboard can cover the lower part of the screen, and a page that does not scroll the focused field into view leaves the Send button under the keyboard. The visitor sees a form with no visible button, which looks broken. Visitors who hit that seldom tell you, and nothing in your inbox says why.

A sticky header, a chat bubble, a cookie banner or an app install bar can sit on top of the bottom of the form at phone width. A laptop layout leaves room for them, so the owner never sees the overlap. Test by scrolling to the Send button and tapping it, not by checking that the button exists on the page.

A link opened inside a messaging or social app runs in that app's built-in browser. Some of these browsers restrict scripts or cookies, and a form that depends on them can fail without a message. Open the same link in the phone's own browser to tell an app problem from a page problem. Then compare the two results before you change any code.

Set the run to a phone browser and start it on the contact address. The visitor taps into each field in order, so the keyboard opens and closes the way it does for a stranger. The report marks the tap where Send became unreachable, or where the reply appeared outside the screen, with a screenshot at that step. It also records failed requests and script errors on the same step.

The test is one visitor path on one phone setting. It does not try every phone size or every in-app browser, so run it on the two or three devices your visitors use most, from the traffic you see in your own analytics. It cannot tell you how a particular model's keyboard behaves, or whether a visitor's own keyboard app changes the layout.

A new header, a new cookie banner or a chat widget can cover the form after an update that looked fine on a desktop. Rerun the same phone visit after each change and after each preview deploy. Owners who gate their pages behind a site password add the password to the run, so the phone reaches the form the same way a visitor would.