Make an enquiry form easier to complete

A useful enquiry form tells visitors what to enter, helps them recover from mistakes and makes the result of submitting clear. Start with the information your business needs to reply. Then check the whole route from the first field to the message arriving in the right place.

The example below uses a name, email address and project description. It’s a markup illustration for a developer to adapt. It doesn’t include a working submission service.

Decide Which Details You Need for a Reply

Write a sample enquiry in plain language before designing the fields. For a brochure website, that might be someone asking whether you can repair a damaged garden gate. You need a way to reply and enough information to understand the request. Decide whether a name is essential, whether a phone number is genuinely needed and whether a full address can wait.

Make optional details visibly optional. If you need a postcode to check service coverage, explain that beside the field. Avoid making visitors invent an answer to a question that doesn’t apply to them. A required company-name field, for example, needs reconsidering if you also serve individuals.

Give Each Control a Visible Label

The World Wide Web Consortium’s Web Accessibility Initiative provides guidance on form labels. An explicit label association uses a label’s for value to match the control’s id. This gives the field a programmatically associated name and lets someone activate the control by selecting its label.

<label for="enquiry-email">Email address (required)</label>
<input id="enquiry-email" name="email" type="email"
       autocomplete="email" required>

<label for="enquiry-message">What would you like help with? (required)</label>
<textarea id="enquiry-message" name="message" rows="6"
          required></textarea>

Keep labels visible while someone types. A placeholder can disappear as soon as the field has a value, so use it only for supplementary examples. Instructions such as the accepted date format should remain available beside the relevant control. Give every id a unique value on the page.

Read the labels without the surrounding design. “Email address” still makes sense. “Details” may need rewriting. If two controls ask for different phone numbers, name the difference in their labels.

Use Browser Checks and Explain Server Errors

An email field and the required attribute can provide useful browser checks. Mozilla’s HTML constraint validation guide explains how these checks work. A syntactically acceptable email address still needs to belong to someone who can receive your reply. Browser validation can’t establish that.

The receiving service must validate the submitted data too. W3C’s input validation guidance explains why client-side checks alone are insufficient. Ask your developer how the server handles missing values, unexpected input and requests made without the normal browser form. Any entered text returned to an HTML page must also be safely escaped.

Make the Correction Obvious

For an invalid email address, “Enter an email address such as name@example.com” gives a useful next step. “Invalid input” leaves the visitor guessing. Display the explanation beside the field and retain the other values already entered. Colour can reinforce the message, but the text should carry the meaning.

For a server-rendered error state, a developer might associate the message like this. The invalid state should appear only when an actual validation error exists.

<label for="enquiry-email">Email address (required)</label>
<input id="enquiry-email" name="email" type="email"
       autocomplete="email" required aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error">Enter an email address such as name@example.com.</p>

Where several fields need attention, provide an error summary with links to those controls. W3C’s form notification examples explain ways to communicate errors and successful completion. Custom interfaces also need deliberate focus and announcement behaviour. Adding ARIA attributes alone doesn’t verify that behaviour.

Test an Enquiry From Start to Finish

Run a small test with harmless, clearly identified test details. Give each test a recognisable message, such as “Website form check, Tuesday afternoon”, so the recipient can confirm what arrived.

1. Use the keyboard to reach each control. Check that focus remains visible and that the order follows the page.
2. Submit empty required fields, then an incomplete email address. Check that each correction is understandable.
3. Correct one field and check that the rest of the message remains intact.
4. Submit a valid test enquiry and check the confirmation shown to the visitor.
5. Confirm receipt in the intended mailbox or enquiry system. Check spam folders and any forwarding route.

A success message should reflect what the system actually knows. If it has accepted a request for processing, avoid promising that a person has already read it. Keep a separate test for delivery failures with the developer, because a normal successful submission won’t demonstrate that recovery path. These checks help find specific problems, but a wider accessibility review still needs to cover the surrounding website.