Short answer: A good contact form asks only for what you need to answer, usually a name, the email or phone number you’ll reply to and a short message. Give every field a visible label and mark which ones are required. Use the right input types so phones show the right keyboard and browsers can fill them in, and confirm clearly when the form is sent.
What a contact form should ask
The simplest way to make a form easier is to remove fields you don’t need. web.dev adds that fewer fields are better for privacy and can reduce the cost and liability of the data you store.
For the name, web.dev recommends a single input unless you have a good reason to store its parts apart. For email and phone, use type="email" and type="tel": phones show the matching keyboard and browsers run basic checks. Don’t use type="number" for a phone number: web.dev notes it adds up and down arrows that make no sense there.
How to build each field
| Field | How to build it | Our form |
|---|---|---|
| Name | One field with a visible label and autocomplete="name" | One «Full name» field, required |
| type="email" and autocomplete="email" | Required, with the email keyboard on phones | |
| Phone | type="tel" and autocomplete="tel" | Required, with the phone keyboard on phones |
| Message | A text area for the request | «What do you need?», optional |
| Send button | Disabled once clicked, since many people click more than once | Disabled until our server answers |
| Bot check | A hidden field or a proof-of-work check, not a puzzle | A hidden field and a proof-of-work check |
From web.dev, “Payment and address form best practices”, and the W3C’s forms tutorial, read November 3, 2026. The last column is our own form that day.
How to build a contact form people finish
- List what you need to answer a request, and cut every other field.
- Give each field a visible label, not only placeholder text inside the box.
- Mark which fields are required and which are optional, and say so before the form.
- Use type="email" and type="tel", with autocomplete values, so browsers can fill the fields in.
- Check each field as people fill it in, and explain any error next to its field in plain words.
- Show a clear message when the form is sent, so people know it worked.
- Send a test from your phone and make sure the message reaches you.
Checks in the browser help people fix mistakes, but the W3C notes they can be bypassed, so the data must be checked again on the server.
If your form asks permission to send text messages, our TCPA guide covers the consent rules. Our ADA website compliance guide covers the rest of an accessible site.
The form on our own site
We read our audit request form on November 3, 2026, in English and in Spanish. Every field has a visible label, and the required ones carry an asterisk plus the required attribute. The name is a single «Full name» field.
The phone field uses type="tel" and the email field type="email", each with its autocomplete value. A required box asks permission to contact the person about the request, and a separate, optional box covers marketing texts. When someone sends it, the button is disabled and marked busy until our server answers, so a second click doesn’t send it twice.
To stop bots, the form carries a field that people never see and a proof-of-work check. The visitor’s browser solves it in the background in about a second on a phone, and it asks nothing of the visitor.
Before you put the form live
- Every field is one you need to answer.
- Each field has a visible label.
- Required fields are marked, and people know it before they start.
- Email and phone fields use their own input types and autocomplete.
- Errors say what went wrong and how to fix it.
- A test sent from your phone reached your inbox.
RememberAsk less, label everything, and tell people clearly that their message arrived.
If you want a site whose forms bring you leads, see our web design service.
Quick answers about contact forms
What fields should a contact form have?
Only what you need to answer: usually a name, the email or phone number you’ll reply to and a short message. web.dev notes that removing fields also helps privacy and can reduce the cost and liability of the data you keep.
Should the name be one field or two?
One, unless you have a good reason to store first and last names apart. web.dev recommends a single name input, which makes the form simpler and works for names that don’t split into two parts.
Can placeholder text replace a label?
No. web.dev warns that the placeholder disappears as soon as someone starts typing, so it’s easy to forget what the field is for. The W3C adds that most people prefer, or need, visible labels to understand a form.
Should I use a CAPTCHA on my contact form?
Try other options first. A W3C note says the task a CAPTCHA asks for excludes many people with disabilities, and that popular CAPTCHA techniques are no longer particularly effective. It describes other options, such as hidden fields that only robots fill in and proof-of-work checks.
What should happen after someone sends the form?
Tell them clearly whether it worked. The W3C asks for concise feedback after a form is sent: error messages that explain how to fix the problem, and a success message that confirms the task is done.
Sources
Read on November 3, 2026. W3C Web Accessibility Initiative: Labeling Controls, Form Instructions, Validating Input and User Notification. Also from the W3C: Understanding Success Criterion 1.3.5: Identify Input Purpose and Inaccessibility of CAPTCHA. web.dev: Payment and address form best practices. Our own case: our audit request form, read as a visitor on November 3, 2026.