A contact form can display a cheerful success message while the inquiry still fails to reach the person who should answer it. Test the whole journey: find the form, complete it, submit it, receive the inquiry, and reply.
This contact form testing checklist gives a small business a practical way to check that route. It includes basic accessibility checks, but it is not a complete accessibility audit. W3C makes the same distinction in its Easy Checks guidance: an initial review can identify issues without establishing full conformance.
Prepare a test that cannot be mistaken for a customer
Tell the people who receive website inquiries that you are testing. Use an email address you control and clearly label the message, for example, “Website test: contact page, mobile.” Do not use a real customer’s details or someone else’s address.
Write down the expected destination before submitting. Does the form send an email, create a customer relationship management (CRM) record, save an entry in the website, or use a combination? Ask the person responsible for the site if you do not know.
Check whether submission starts other actions, such as an automated reply, a sales task, or an external booking workflow. Agree on a safe test method before triggering anything consequential. Record the page address, date, device, browser, test label, and expected result.
Reach the form through the normal customer route
Start on a page customers actually use, such as a service page. Follow its inquiry link. Check that the destination matches the action promised: a quote request should not land on an unrelated newsletter form.
Repeat on a phone. Look for cookie banners, sticky buttons, or layout problems that cover a field or the submit button. Increase the browser zoom and check whether you can still read instructions and complete the form without losing essential controls.
If there are separate forms for different services or locations, treat each as a separate route. Similar appearance does not establish that they share the same delivery settings.
Check labels, instructions, and keyboard access
Every field should have a clear label that remains understandable while you type. Placeholder text inside an empty field should not carry all the instructions. Required fields and format requirements should be explained before submission. W3C’s form-label guidance also explains why labels need to be associated with their controls for assistive technology.
- Use the Tab key to move through links, fields, and buttons.
- Check that you can see which control has focus.
- Check that the order follows a sensible path through the form.
- Operate available choices and the submit button with the keyboard.
- Confirm that you can move away from every control without getting trapped.
Ask an accessibility-aware tester to check the form with assistive technology, including field names and announcements of errors or success. A keyboard test alone cannot verify what a screen reader receives.
Make ordinary mistakes on purpose
Try submitting with an empty required field. Try an incomplete email address. If the form requests a telephone number or postcode, check that valid formats your customers use are accepted.
Look for useful recovery instructions. “Enter an email address” is clearer than “Invalid input.” The message should identify the affected field in text, rather than relying only on a red border. Correct information already entered should remain available so the visitor does not need to start again. W3C’s form-notification guidance covers clear errors and feedback after submission.
Fix the error and submit again. Record whether the form recovers normally. If it includes spam checks, include them in the normal test journey and flag any accessibility problems. Do not disable protections just to produce a passing result.
Read the confirmation as a customer would
A successful submission should produce a clear, noticeable confirmation. Check it on both the phone and larger screen. It should explain what has happened and give an honest next step.
“Your inquiry has been submitted” is different from “Your appointment is booked.” Use the statement the workflow can support. If you publish a response expectation, confirm that the business can meet it. Avoid inventing a deadline to make the message sound helpful.
If an automated acknowledgment is expected, check its arrival at your test address. Read its subject and message, verify any links, and confirm that its reply instructions are accurate. A customer acknowledgment and an internal notification are separate checks.
Find the actual inquiry at its destination
Ask the receiving person to locate your unique test label. Check the expected inbox and, if needed, spam or filtered folders. For a CRM route, inspect the record and its assigned owner. For a website entry store, confirm that the entry exists if storage is part of the intended setup.
- Are the name, contact details, service selection, and message complete?
- Did the inquiry reach the correct team or location?
- Does the record preserve useful formatting and characters?
- Can the assigned person find it in their normal working view?
- Does replying reach the address used for the test?
Send that test reply and check that it arrives. An inquiry is operationally useful when someone can take responsibility for it and contact the sender.
Record failures precisely and retest the fix
For each route, record pass, fail, or not yet verified. Keep the test label, relevant times, expected destination, and a screenshot of any visible error. Remove private information before sharing evidence.
If the form confirms submission but no inquiry arrives, report that exact observation. It does not establish where the failure occurred. The form, delivery service, receiving mailbox, and integrations may require separate investigation.
Use the checklist again after relevant form, website, mailbox, or integration changes. Agree on a recurring check appropriate to how much your business depends on inquiries. Keep a named owner for the test and for the follow-up work.
Need help tracing a failure? Send Imbark the form’s page address and your test findings. Our website support covers troubleshooting and updates. If the form journey needs a broader rethink, we can also discuss custom web design.
