Notes / Siteworks
Can people complete your service website’s contact form?
Review your service website’s contact form for clear labels, keyboard access, useful errors and truthful confirmation, with practical checks for your builder.
By Edu Rigonato. Published Sep 25, 2026. 10 min read.
A business owner opens the new website, fills in the contact form and sees a success message. The inquiry reaches the inbox. That is a useful test, but it leaves important questions unanswered: could someone complete the same task without a mouse? Would an error explain what to fix? Would a screen reader announce the result?
An accessible contact form needs understandable fields, controls people can operate, errors they can recover from, and confirmation they can perceive. Review the whole inquiry journey, including the parts that appear only when something goes wrong. The number of fields and the appearance of the page cannot answer those questions by themselves.
For a service business, this is part of making the website useful to a prospective client. Your service pages and client proof may explain why someone should get in touch. The form still has to let that person ask for help. The practical review below gives owners and builders a shared way to discuss that final step.
Make each field understandable before someone types
Start by asking what the team needs to respond to an inquiry. A detailed project brief may eventually be necessary, but the first contact does not always need to collect everything required for delivery. The W3C forms tutorial recommends asking for information needed to complete the process. That is a reason to examine each question, rather than chase a universal field count.
For example, an illustrative landscaping inquiry might need a name, a way to reply, the service requested and enough location information to establish whether the business serves the area. Requiring a full postal address, several budget selections and a precise project date may need more justification. A different business could legitimately need different details. The test is whether each required answer has a clear purpose at this stage.
Then look at the labels. A visitor should be able to identify what belongs in a field after they start typing. Placeholder text inside an empty box disappears as it is filled, so it is a poor substitute for a persistent label. The label also needs a programmatic connection to its control, allowing assistive technology to identify the question. W3C’s labeling guidance explains the available approaches; the builder should implement and test an appropriate association.
Instructions deserve the same attention. If you require a particular format or need an explanation before someone answers, put that information where it can help them. A vague label such as “Details” may be less useful than a short question about what they need. Identify required and optional answers clearly, and do not rely on color alone to convey that distinction.
Frequently asked questions
Is a shorter contact form automatically more accessible?
No. Removing unnecessary questions can reduce effort, but the remaining controls still need understandable labels, keyboard operation and useful feedback. Decide what information the team needs at the inquiry stage, then test whether people can supply it. A field count is not an accessibility assessment.
Can placeholder text replace a field label?
Generally, keep a persistent label for the question. Placeholder text disappears when someone types and should not carry information the visitor still needs. The label also needs an appropriate connection to its control. <a class="inl" href="https://www.w3.org/WAI/tutorials/forms/labels/">W3C’s labeling guidance</a> explains implementation options and contextual exceptions.
Does a clean automated scan mean the form is ready?
No. Ask for a manual review of the task, including keyboard use, relevant assistive technology, error recovery and confirmation. A scanner’s result describes what that tool checked. It does not establish that every visitor can complete the form or that the inquiry reaches the receiving team.
How should we check spam protection without making contact harder?
Include the actual anti-spam mechanism in completion testing, including any challenge or fallback it presents. Review access, privacy and abuse-prevention needs together. If people encounter a barrier, provide a practical way to contact the business while the underlying issue is addressed; an alternative channel does not make the form itself accessible.
Explore Siteworks