How to Design a Contact Form People Finish
- Difficulty
- Moderate
- You need
- Access to the form's HTML or form builder
- Optional
- A screen reader for testing
On this page
A contact form people finish asks only for what you need, labels every field clearly, works with a keyboard and a screen reader, explains errors in plain words and confirms the message was sent. A form that asks too much, or breaks quietly, loses enquiries however good the button looks. This guide is part of our website design best practices guide.
You'll need access to the form's HTML, component code or form builder, plus a keyboard and your device's built-in screen reader for testing. If the form sits on a campaign page, read landing page conversion best practices for the page around it.
What a good contact form does
A contact form is a small agreement. The visitor gives you their details and their problem; you promise to read it and reply. Everything about the form should make that exchange feel easy and safe.
In practice that means four things. It's short, so it looks quick before anyone starts. It's clear, so nobody wonders what a field means or why it's needed. It's forgiving, so mistakes are easy to spot and fix. And it's reliable, so every message reaches a person.
Which fields to ask for
Start from what you need to send a useful first reply. Everything else can wait for the conversation. Here is how we usually decide for a service business, with the HTML settings that help browsers fill each field in:
| Field | Ask for it? | autocomplete value | Input type |
|---|---|---|---|
| Name | Yes, as one field | name | text |
| Yes | |||
| Phone | Optional, unless you reply by phone | tel | tel |
| Company | Only if it changes your reply | organization | text |
| Message | Yes, with a helpful prompt | off or omitted | textarea |
| Budget | Usually no; ask in your first reply | n/a | n/a |
| How did you hear about us? | No; use analytics instead | n/a | n/a |
Steps
- Decide what happens after someone sends it.
Before designing the form, agree who receives each message, where it's stored and how quickly someone replies. Only tell visitors when to expect a reply if you can keep that promise every time. Send messages to a shared inbox or CRM, not one person's email, so nothing waits while someone is away.
- Cut every field you don't need.
Go through each field and ask what you'd lose without it. Use a single name field rather than first and last name, which also suits names that don't split neatly. Make phone optional unless you only reply by phone. Questions about budget or how people found you can wait for the first conversation.
- Use visible labels, not placeholders.
Give every field a label element connected to its input, placed above the field. Don't rely on placeholder text as the label: it disappears once someone starts typing, so people forget what the field was for. A connected label also gives the field a name for screen readers and a bigger tap target. Here is the pattern:
html<label for="email">Email</label> <input id="email" name="email" type="email" autocomplete="email" required aria-describedby="email-hint"> <p id="email-hint">We'll only use this to reply to you.</p> - Choose the right input types and autocomplete.
Use type email for email and type tel for phone numbers, so phones show the right keyboard. Add autocomplete values such as name, email and tel, so browsers and password managers can fill the form in. WCAG 2.2 asks for this on fields that collect a person's own details, under Identify Input Purpose.
- Mark required and optional fields in text.
If most fields are required, mark the optional ones with the word "optional" in the label. If you use an asterisk for required fields, explain it above the form. Don't rely on colour alone, such as a red label, because not everyone can see the difference.
- Write errors that say how to fix the problem.
"Invalid input" helps nobody. Say what's wrong and how to put it right, such as "Enter an email address, like name@example.com". Show the error next to the field in text, keep what the person already typed, and on submit list all errors at the top with links to each field.
- Make it work with a keyboard and screen reader.
Tab through the whole form: every field and the button should be reachable, in order, with a visible focus indicator. Avoid custom dropdowns and date pickers unless they're built to work by keyboard. Then turn on your screen reader and check each field announces its label, its hint and any error.
- Stop spam without puzzles.
Puzzle CAPTCHAs block some disabled visitors and slow everyone else. Start with a hidden honeypot field that people never see but bots often fill in, plus spam filtering on the server. Add rate limits if one source sends many messages. Reach for a stronger check only if spam still gets through.
- Confirm the message and follow up.
After a valid submission, show a clear message on the same page saying the message was sent and what happens next. Make sure screen readers announce it too. Then record each submission as a key event, as covered in how to set up conversion tracking, so you can see whether changes help.
If you'd rather have forms designed, built and connected to your inbox and analytics for you, our in-house web team designs and develops sites with SEO foundations built in.
Form accessibility, criterion by criterion
Forms are where many accessibility problems hit hardest, because a barrier here blocks the enquiry itself. These are the WCAG 2.2 success criteria a contact form touches most:
- Info and Relationships (1.3.1, Level A). Labels must be connected to their fields in code, not just placed nearby.
- Labels or Instructions (3.3.2, Level A). Every field needs a label, and any format rules need to be explained before people type.
- Identify Input Purpose (1.3.5, Level AA). Fields for personal details need the right autocomplete values.
- Error Identification (3.3.1, Level A) and Error Suggestion (3.3.3, Level AA). Errors must be described in text and, where possible, say how to fix them.
- Keyboard (2.1.1, Level A) and Focus Visible (2.4.7, Level AA). Everything works from a keyboard, and people can see where they are.
- Target Size (Minimum) (2.5.8, Level AA). Buttons and checkboxes are at least 24 by 24 CSS pixels, or well spaced.
- Redundant Entry (3.3.7, Level A). In a multi-step form, don't ask for details people already gave.
- Status Messages (4.1.3, Level AA). Success and error summaries are announced without moving focus unexpectedly.
A status message can be as simple as an element with a status role, which screen readers announce when its text changes:
<p role="status" id="form-status"></p>When the form is sent, put the confirmation text inside it. For the rest of the site, our website accessibility testing checklist has a forms group you can run in a few minutes.
Troubleshooting
Enquiries stop arriving in the inbox
Cause: the form still works for visitors, but messages don't reach anyone. The usual culprits are emails from the site being filtered as spam, a plugin or integration that broke after an update, an expired API key for a CRM, or a change of staff that left messages going to an unused address. Because visitors still see a thank-you message, nobody notices until enquiries seem to dry up.
Fix: send a test message every month, and after every site update, and check it arrives. Store each submission in the CMS, CRM or database as well as sending an email, so nothing is lost if email fails. Send form emails from an address on your own domain, with the domain's email authentication set up, and check the spam folder. Compare form_submit events in analytics with messages received to spot gaps.
Spam keeps getting through
Cause: bots fill in every field they find, including your honeypot if it's named obviously, and some spam is sent by people rather than scripts. Forms that submit to a public endpoint without any server-side check are easy targets, and so are forms whose honeypot is hidden in a way bots can detect. A sudden rise often means the form's address has been added to a spam list.
Fix: give the honeypot field an ordinary-looking name, hide it with CSS rather than the hidden attribute, and keep it out of the tab order and away from screen readers. Add server-side filtering for links, known spam phrases and repeat senders, and limit how often one source can submit. If spam persists, add a less intrusive check, and only then consider a challenge, with an accessible alternative.
Screen reader users can't tell what went wrong
Cause: errors are shown visually but never announced or connected to their fields. Red borders, icons or text placed near a field mean nothing to someone who can't see them. Some forms also clear the fields or move focus to the top of the page on error, so people lose their place and their typing, and have to start again.
Fix: connect each error message to its field with aria-describedby, and mark the field as invalid. On submit, show an error summary at the top with links to each field, and move focus to the summary so it's read out. Keep everything the person typed. Then test with your device's screen reader: submit the form empty and check each error is announced and easy to reach.
Common questions
How many fields should a contact form have?
As few as you need to reply well. For most service businesses that's a name, one way to reach the person and a message box, with a phone field marked optional. Each extra field, such as budget or company size, is another reason to stop. Ask those questions in your first reply or on the call, when you can explain why you need them.
Should I use a CAPTCHA on my contact form?
Avoid puzzle CAPTCHAs if you can. The W3C's work on CAPTCHA accessibility explains that tests asking people to read distorted text or pick images exclude some disabled visitors, and they frustrate everyone else. Start with less intrusive checks, such as a hidden honeypot field and server-side spam filtering, and add a stronger check only if spam still gets through.
Should form errors appear as people type or when they submit?
Mostly when they leave a field or submit. Errors that fire on every keystroke interrupt people who haven't finished typing and can flood screen reader users with announcements. A good pattern is to check each field when focus leaves it, check everything again on submit, then show a summary at the top with links to each problem.