The form says “Thank you.” The visitor closes the tab. Your inbox stays empty.
That failure can remain invisible for a long time because everyone assumes the success message means the enquiry was delivered. It may only mean that the browser finished an animation or that an email service accepted a request.
Before sending more people to a contact page, test the whole route. You can do much of this yourself with a phone, a laptop, and an email address you control. Ask the developer to help with controlled failure tests rather than trying to break the live site.
Prepare a test you can recognise
Choose a unique subject or message marker, such as “Website contact test, Monday morning.” Use realistic but non-sensitive content. Do not enter customer information simply to make the test feel authentic.
Write down the page URL, device, time, and receiving inbox you expect. If several forms exist, test each route separately. A homepage form and a contact-page form can look identical while using different code or settings.
Agree who will check receipt and who owns any failures. Testing is only useful if someone can act on what it reveals.
Complete the normal journey first
Open the page as a visitor would, preferably without being signed into the website’s admin tools. Read the labels and enter a valid enquiry.
Watch what happens after clicking Submit. The button should make the pending state understandable and avoid accidental repeated submissions. The page should confirm what happened without promising a response time the business cannot meet.
Now check the actual receiving inbox. Look for the complete message, correct contact details, service selection, and any agreed source information. Search spam or quarantine folders during setup if it is missing, but do not call the test successful merely because a provider dashboard says “accepted.”
Reply from the normal business mailbox. Verify that the reply reaches the test address. This catches an easy-to-miss configuration problem where the original notification arrives correctly but replies go to a no-reply address.
Check the questions you ask
For every required field, ask why it is needed before the first conversation. Name, email, service, and message may be enough for some businesses. Others genuinely need a location or project date.
Make optional fields visibly optional. Do not use placeholder text as the only label; it disappears when someone types and can make reviewing the form harder.
Try a longer message and a business name with punctuation. Use an international name and an email address you control with a plus tag if your email provider supports it. Valid customer details should not be rejected by unnecessarily narrow rules.
Do not ask people to share passwords, payment-card information, or other sensitive material through a general enquiry form.
Test mistakes and recovery
Submit an empty form, omit a required field, and enter an invalid email address. The page should identify the problem near the relevant field and explain how to fix it. It should preserve the other information already entered.
The W3C notification guidance explains clear error and success feedback. Ask the developer to verify that assistive technologies can detect the messages, rather than relying only on colour changes.
In a controlled test environment, simulate a delivery failure or disconnected network. The visitor should receive an honest error and a useful retry option. A backend failure must not produce the same confirmation as a successful submission.
Try a second click while submission is pending and refresh after completion. Confirm duplicate handling is sensible. You do not want one impatient tap sequence to create several indistinguishable leads.
Use a phone and a keyboard
On a phone, make sure the keyboard does not hide the field or submit button. Check for horizontal scrolling and text too small to read comfortably. Increase text size where supported.
On a laptop, navigate using Tab and Shift+Tab. The focused control should be visible, the order should make sense, and submission should be possible without a mouse. Labels should identify the fields correctly.
A manual check does not certify complete accessibility, but it catches practical problems that a screenshot review misses.
Confirm someone will answer
Finally, treat the test as a lead. Who notices it? Where is the next action recorded? What happens if that person is away?
Keep a short record of the result and repeat the check after changes to the form, domain, email provider, or deployment configuration. Agree a periodic check that fits the importance and volume of enquiries.
Use the launch checklist to document the wider journey. If forms are delivering but leads still disappear between inboxes, our growth and automation service can help clarify ownership and handoffs. A working form ends with a reachable person, not a green tick.