If your WordPress contact form appears to ignore Send on mobile, check for feedback outside the visible screen before blaming submission handling. Run two controlled tests on a real phone: leave an upper required field blank, then submit valid dummy data.
Track the response, scroll position and focus separately. Focus is the field, button or other page element set to receive keyboard input. Feedback hidden without a usable cue points to an interface problem. No conclusive feedback means the response is unresolved—not that the submission failed.
Prepare a safe test and a reusable record
Use a representative staging copy, or authorised live submissions routed to an inbox you control. Check downstream actions, including tickets and automatic replies, before testing. Use synthetic content and contact details you control, never real enquiries.
Record shared details once: public form URL, phone, operating system, browser, orientation and signed-in status. Use the same form choices and orientation for both cases.
Copy these labels into a separate note for each case:
- Inputs: Form choices and omitted field, if any.
- Feedback: What appeared immediately; what appeared only after scrolling; message location.
- Position: Page movement, focused element and on-screen keyboard state; mark unknowns.
- Timing: Test time and time zone, how long you waited and any later response.
- Entries: Which test entries remained or disappeared.
- Outcome: Result, next owner and action.
Keep enquiry contents and account details out of shared notes and screenshots.
Case 1: leave an upper required field blank
Complete the other required fields with valid test data. Leave one required field near the top empty, scroll to Send and tap once.
Before scrolling or tapping elsewhere, observe any inline error, summary or browser validation prompt. Did the page move? Is feedback covered by a sticky header or the on-screen keyboard? Did focus move to a field or summary, or stay on Send?
Look for a text cursor or visible focus indicator where available. If focus is unclear, record it as unknown: scrolling does not establish focus.
Then inspect the whole form, including sections above Send. Follow any error-summary link: can you reach and edit the linked field? Check whether other entries remain, and complete the case note.
A browser may block an invalid submission before a submission request is sent. That is validation, not evidence of server failure.
A visibility problem is reproduced when an error exists off-screen with no clear visible cue pointing to it. An off-screen inline error is not necessarily a problem if a visible, usable summary makes it easy to find.
Case 2: submit valid dummy data
Reopen a clean form, confirm previous feedback is gone and repeat the same form choices. Complete every required field with valid dummy data, including the field omitted before. Tap Send once.
Record the initial response before moving around: confirmation text, redirect, replacement view, another error, verification challenge or loading state. If nothing is visible, inspect above and below the form for a status message.
Complete any expected verification step; if it blocks the test, record that limit. Note your waiting period and any later response. Do not keep pressing Send, which could create duplicate submissions. Complete the second case note.
Visible success does not prove email delivery. Check the controlled inbox separately. A confirmation hidden without a usable cue is a visibility issue; a missing expected email needs a separate delivery investigation. If the form’s response remains unclear, record “no conclusive feedback observed,” not “submission failed.”
Choose a repair or an investigation
Hypothetical example: On a staging form using custom validation, leaving the upper Email field blank produces an error found only after scrolling. No visible cue points to it, focus is unknown and other entries remain. The valid-data test produces no conclusive feedback.
Route each result separately: give the hidden-error case to the form or template maintainer, and the unresolved valid-data case to a developer for request/response investigation. Neither proves email failure. Fixing the first must not close the second.
Hidden feedback: request a scoped repair
Request only changes that address an observed defect:
- No usable error cue: Improve error placement or provide a visible summary with links that reveal and focus invalid controls. Associate inline messages with their fields.
- Hidden confirmation: Make the status discoverable from the post-submit view.
- Obscured feedback: Address fixed-header or keyboard obstruction in the affected layout.
- Lost entries: Preserve valid entries when validation fails.
Agree on focus and screen-reader announcement behaviour. Invalid submissions may need focus on a summary or the first invalid control; an in-page success message may need a status announcement while focus stays predictable. Scrolling alone proves neither. If focus was unknown, request verification, not a repair for an assumed failure.
Use supported form settings where available; otherwise ask for form or template development.
Both cases clear: not reproduced
If both cases respond clearly, this run did not reproduce the visibility complaint. Compare the reported device, browser and form path without requesting the visitor’s enquiry content, then repeat the relevant case.
Escalate unexpected error messages separately; a visible error is not itself a visibility failure.
No conclusive response: investigate
Give a developer the two-case notes, exact reproduction steps, test time and waiting period. Ask them to reproduce the issue with synthetic data, check browser errors and determine whether a submission request is sent. If a request is sent, they should inspect any response or network error.
Share only minimal, redacted diagnostics without enquiry contents or security tokens. Do not blame email hosting merely because Send looked inactive.
Retest the changed behaviour
Compare the original notes with new results on the affected phone.
Close only the reproduced visibility issue once its retest passes. Keep unresolved submission responses and delivery questions separate, with a named owner and next action in the case notes.
