A contact form checklist for website templates
Check form delivery, labels, validation, error messages, and service ownership before you publish a website template.
On this page
A contact form needs a working delivery path. Its appearance does not show whether a person receives the message. Check that path before you choose a template or publish the site.
This guide covers a simple enquiry form. Payment forms, account registration, and sensitive records need additional checks for their specific risks.
Identify what processes the submission
Find the form destination in the template instructions. Determine whether a server endpoint or an external service processes the request. A demonstration may show only the form fields.
The MDN form submission guide explains how a form sends data to its destination. The destination still needs to process that data.
Record the service owner, recipient address, and place where delivery errors appear. Check which account pays for the service. Ask what happens when a service limit stops new submissions.
Do not put secret service credentials in HTML or public JavaScript. Use the integration method that the service documents for a public website.
Review the fields before connecting delivery
Ask for the information needed to answer the enquiry. Explain optional fields. A company website may need a name, reply address, and message. That example does not justify collecting extra personal details.
Give each input a clear label. Keep the label visible when the person enters a value. Explain any required format before submission.
Read the form with a keyboard. Confirm that the focus indicator identifies the current control. Check the same form on a phone with the software keyboard open.
Use the accessibility checklist for the initial review. It does not establish full accessibility conformance.
Check validation at both ends
Submit a missing required value and an incorrectly formatted reply address. Confirm that the form identifies the problem. Check whether entered values remain available for correction.
Browser validation helps people correct input. It does not protect the server on its own. MDN validation guidance explains why the server also needs validation.
Ask the integration owner how the endpoint handles invalid data. A custom error message in the browser does not answer that question.
Separate acceptance from delivery
A success message can mean that the service accepted a request. It does not necessarily mean that the final recipient received an email.
Use an address you control for the check. Put a unique test phrase in the message. Confirm that the intended recipient receives that phrase and can reply.
Keep the confirmation text accurate. State that the request was received only when the system confirms that event. Do not promise a reply time without an agreed support process.
The W3C form notification tutorial describes ways to explain errors and successful completion. Clear wording remains necessary with each method.
Keep a repeatable delivery record
| Check | Evidence to record | Problem to resolve |
|---|---|---|
| Valid submission | Identifiable message at the intended destination | Missing or incorrect delivery |
| Required field missing | Specific correction instruction | Submission fails without an explanation |
| Invalid reply address | Rejection at the applicable validation steps | Unusable contact details |
| Service failure | Accurate failure message and retry path | False success message |
| Mobile use | Main task completed on a real phone | Hidden fields or inaccessible controls |
| Ownership | Named account owner and recovery method | Nobody can repair delivery |
These rows define checks. They do not report a tested template or service.
Repeat delivery checks after a recipient change, domain change, or service update. Use test data instead of customer details.
Finish the launch decision
Publish the form when the required checks pass. Record any remaining limitation with its owner. Keep a direct contact alternative available when your support process permits one.
Use the static website launch checklist to review the rest of the release. Browse the template directory when a candidate lacks a maintainable form integration.
