Plan a contact form that delivers the message.

1. Define the purpose and who handles replies

Write one sentence describing what the form accepts, such as business enquiries or corrections to a directory listing. Choose the inbox or workflow that receives those requests and the person responsible for checking it. If different request types go to different people, agree on that routing before adding a category menu.

Describe a response expectation you can maintain. A receipt confirmation is different from a promise that someone has reviewed the message. Decide what happens during absences and where a visitor can find another contact route if the form is unavailable.

2. Choose fields that support that purpose

W3C recommends short forms that request only information needed for the task, with labels and instructions that help people understand each control. Ask why every field exists. Mark required and optional information clearly, and give an example when a format or request is easy to misunderstand.

A visible label should remain understandable while someone types. Add a brief note asking people to avoid passwords or unrelated private information. Use labels programmatically associated with the controls, rather than relying only on placeholder text.

Sources: [1]

3. Connect the form to a real receiving service

MDN explains that an HTML form sends data to a server; its action identifies the destination, and its method affects how the data travels in the request. The receiving code or service must process that submission. A styled submit button and a thank-you message alone do not create a working delivery path.

Have the builder identify the destination, server-side validation, and how a received message reaches your inbox or queue. Use HTTPS and avoid putting sensitive message content in URL query parameters. Agree on storage, access, and deletion settings for the information you collect, and explain the relevant handling to visitors.

Sources: [2]

4. Make errors and success understandable

W3C advises clear feedback on both successful submissions and errors, with simple instructions for correcting problems. Identify the field that needs attention, explain the issue in text, and keep the message available to assistive technology. Do not rely on a red border alone to convey what went wrong.

Write the success message to match the event you can confirm. “Your enquiry was received” requires a confirmed receiving response. It does not mean a person has read or answered it. If delivery fails, show a useful recovery route and preserve the entered message where practical so the visitor does not have to start over.

Sources: [3]

5. Test the journey and give it an owner

Use clearly labeled sample data to try a normal submission, a missing required field, an invalid reply address, and a service failure in a safe test setup. Check the actual destination for the message and make sure any reply route works. Confirm that error correction does not silently discard the visitor’s text.

Use the form with a keyboard and on a phone as well as a desktop. Check focus, labels, readable feedback, and the submit control. Assign someone to repeat the delivery check after changes to the form service, inbox, or domain settings, and to monitor missed or misrouted enquiries.