By Accessible.org · Reviewed
Product reference: Free 1.4.0 / Pro 1.3.2
A contact form should help someone start a conversation with the right person. For a small business, community group or service website, a message and a way to reply often provide enough information to begin.
The field plan below is an example to configure in Accessible Forms. You can begin with the Free Contact starter, then change its questions and settings for your team. The suggested wording is editorial guidance to adapt, rather than a claim that every contact form needs identical fields.
Decide what happens after someone writes
Choose the person or shared inbox responsible for these messages before designing the form. A general enquiry form works well when one team can read the message and decide what to do next. If you already have a separate route for existing customer support, show that route beside a brief explanation of this form's purpose.
Write the introduction around the visitor's task: “Tell us what you would like help with. Our team will reply by email.” Add a response time only when the team can consistently meet it. An accurate introduction lets people judge whether this is a suitable way to contact you.
Start with a small field plan
Use the plan below as a first draft, then remove any question that does not help your team respond. GOV.UK's name guidance explains why a single name field accommodates more naming conventions. Its email guidance recommends explaining why an address is requested; here, that purpose is the reply.
Example questions to build
- Your name — Text, optional
- Useful for a personal reply. A single field is enough for this enquiry; leave the required setting off if the team can respond without a name.
- Email address — Email, required
- Help text: “We will use this address to reply to your message.” Set the email autofill purpose and check that this wording reflects your actual use.
- How can we help? — Message, required
- Help text: “Tell us what you are trying to do and what you need from our team.” Give people space to explain without demanding a particular writing style.
Add a question only when the answer changes the response
A topic question can help a busy team scan incoming messages, but it also asks visitors to classify their problem. Add it when the categories are familiar, such as “A new project”, “An existing service” and “Something else”. Avoid internal department names a first-time visitor would not recognise.
Do not add a telephone field merely because other contact pages have one. If your team offers callbacks, explain that option and keep the email route usable. A postal address, job title, organisation size or mandatory attachment rarely helps answer a simple initial question. Collect extra details in the conversation when their purpose becomes clear.
Connect the form to a reliable reply process
Set a recognisable notification subject and check the recipient. Select the visitor's email field for Reply-To so a team member can respond to the person who wrote. Keep the button direct, such as “Send message”. A suitable confirmation is: “Your message has been received. Our team will reply to the email address you provided.”
Test a real submission on a staging page using an inbox you control. Find the stored entry, check the notification and send a reply. A successful submission and an email arriving in the inbox are separate things to verify. Revisit the questions after the team has handled a sample of genuine enquiries: repeated follow-up questions can reveal missing context, while unused answers reveal fields to remove.
Before you publish
- A visitor can understand who will read the message and how a reply will arrive.
- Only information needed to start the conversation is required.
- The notification reaches the intended inbox and Reply-To uses the visitor's email.
- A missing required answer produces a usable error, and a completed submission shows the expected confirmation.
Using Accessible Forms
Configure this example with the Contact starter or build its fields manually.
In Free: Free includes the text, email and message fields, required settings, help text, notifications, stored submissions and publication checks needed here.
With Pro: Pro can add conditional follow-up questions when different enquiry types need different details. Keep the first version short unless that extra behaviour solves a real problem.
Sources & further reading
The examples and field plans are suggestions to adapt to your form. These references explain the underlying design and accessibility guidance.
- GOV.UK Design System: Names
Supports the single-field name choice and asking for a name only when the service needs it.
- GOV.UK Design System: Email addresses
Supports explaining the email address's purpose and using an email input with autofill.