The route from a search query to a website is well documented by now. What happens next often is not: people read a service description, compare two or three providers, and then face a contact form. That is where attention either turns into an inquiry or quietly disappears. This guide covers which fields a first reply genuinely requires, what error messages look like when they help instead of block, how to keep automated submissions out without shutting people out, what should happen the moment someone hits send, and what data protection and retention law expect from incoming inquiries.
Where inquiries get lost along the way
Between the first contact with a page and a submitted inquiry sit more decisions than it seems. The visitor has to recognise that they are in the right place, find the way to the form, judge what they are handing over, and believe that a reply will follow. Every one of those points is a possible place to drop out. Four patterns show up particularly often: the form sits at the end of a long page with no earlier pointer to it; it asks for details that a first reply does not require; it reports errors in language that few people outside engineering understand; and it confirms receipt so casually that it stays unclear whether anything happened at all. Businesses that work hard to be found locally frequently invest heavily in visibility and very little in the last fifteen seconds before the inquiry. Yet that is exactly where the rest of the effort either pays off or does not.
How sound web forms actually are can be measured. The annual WebAIM Million analysis runs automated checks across the home pages of one million websites. In the 2025 edition, around 95 percent (WebAIM Million 2025) of those pages showed at least one automatically detectable failure against the Web Content Accessibility Guidelines, with around 50 (WebAIM Million 2025) detected errors per page on average. Missing labels on form fields have been among the recurring error classes for years; the HTTP Archive Web Almanac lists them among the frequent findings in its accessibility chapter as well. Automated checks cover only part of the criteria, so these figures describe a lower bound. For forms that means a substantial share of input fields on the web is not cleanly named for screen readers, and what is not named is hard to fill in reliably. Technical speed helps only so far. Getting the foundation of static delivery right buys pace, but not yet a form that carries its weight.
Ask only what the reply requires
Data minimisation inside a contact form is not a concession to privacy law; it is the strongest lever for more inquiries. Article 5(1)(c) GDPR requires personal data to be adequate, relevant and limited to what is necessary for the purpose. The purpose of a contact form is narrow: to be able to write a first, useful reply. Everything beyond that is stockpiling with a drop-out risk attached. A simple split works well in practice. On one side sit the details without which no reply is possible: a name, a way to respond, and a description of the request. On the other side sit the details that would make the first conversation easier: budget range, headcount, timeline, industry. That second group either moves into clearly marked optional fields or leaves the form entirely. Anyone drafting their own service description already knows which details a solid quote needs, and can reverse the order: reply first, then ask specific follow-up questions.
- Name: a single field rather than separate boxes for salutation, title, first name and surname. A reply only needs the spelling the person chooses themselves.
- Return channel: an email address or a phone number, not both as mandatory. Whoever wants to be reached by phone will add the number voluntarily.
- Request: a free text field without a tight character limit. Most people describe their project in a few sentences more precisely than any dropdown could capture.
- Town or postcode: useful for location-bound services, because travel, responsibility and appointment windows follow from it.
- Timeframe: optional and as a rough choice, for example short notice, within the next few months, or still open.
- Company name: only where the offer is aimed at businesses and the reply depends on it.
- Budget, headcount, industry and turnover: in our experience the fields with the highest drop-out effect. Those questions belong in the first conversation, not in the form.
The field test
Labels, autofill and the keyboard
A form does not become good by looking tidy; it becomes good by working with the tools people already use. That includes the keyboard, contact details stored in the browser, the on-screen keyboard on a phone, and assistive technology such as screen readers or magnification software. Two decisions carry particularly far here. The first is the visible label: a field whose name exists only as placeholder text loses that name the moment someone starts typing. Anyone who loses the thread has to clear their own text to see the question again. The second is the machine-readable purpose expressed through the autocomplete attribute. It is anchored in the Web Content Accessibility Guidelines as success criterion 1.3.5 (W3C, WCAG 2.2) and is also what makes stored address data get offered at all. Neither costs any design freedom, and both save noticeable time on a phone. The demo websites show how this looks on finished forms.
Visible label
Every field carries a permanently visible label above or beside the input. Placeholder text disappears as soon as typing starts and therefore does not work as a substitute.
Prepare autofill
The autocomplete attribute assigns each field its purpose. Browsers then suggest name, email and phone number from stored data; success criterion 1.3.5 asks for exactly this markup.
Matching keyboard
The input type decides which on-screen keyboard appears on a phone. For email addresses and phone numbers that saves several layout switches per entry.
Targets large enough
Controls and choice fields need room for a fingertip. WCAG 2.2 sets a lower bound of 24 by 24 CSS pixels, or sufficient spacing, in success criterion 2.5.8.
One field per row
Fields placed side by side shorten the page visually but raise the error rate on narrow displays. A single column reads down one straight line.
Separate required from optional
Marking optional fields as optional works better than an asterisk on every required one. People who can see that little is asked of them are more likely to start.
Error messages that actually help
Errors in a form are the rule, not the exception. People mistype, switch tabs, fill in half of it and come back later. What matters is therefore not preventing errors but making them understandable. The Web Content Accessibility Guidelines set out two criteria for this: success criterion 3.3.1 requires that an input error is identified and described in text, and success criterion 3.3.3 additionally requires a correction suggestion where one is known (W3C, WCAG 2.2). A red outline satisfies neither, because without colour perception and without text it says nothing at all. Three points make the difference in practice: the message names the field and the expected input; it appears directly at the field and additionally as a summary with jump links when several fields are affected; and the values already entered are preserved. A form that comes back empty after an error loses most inquiries not because of the error but because of the forced repetition.
| Situation | Sound implementation | Typical risk |
|---|---|---|
| Required field empty | Message directly at the field, text names field and expected input | General notice at the top of the page with no link to the field |
| Wrong format | An example of a valid entry inside the message text | Plain rejection with no hint about what is expected |
| Several errors | Summary at the top with jump links to the affected fields | Only the first error shows, the rest trickle in one by one |
| Time of validation | Checked when the field is left and when the form is submitted | Checked on every keystroke, the message flickers while typing |
| After the error | Entered values are preserved in full | The form is cleared and the entry starts over |
| Announcement | Error text is announced by assistive technology and focus moves there | Error marked by colour alone, without text and without a focus change |
<label for="inquiry-email">Email address</label>
<input
id="inquiry-email"
name="email"
type="email"
autocomplete="email"
inputmode="email"
required
aria-describedby="inquiry-email-hint inquiry-email-error">
<p id="inquiry-email-hint">So that we can reply to you.</p>
<p id="inquiry-email-error" role="alert">
Please enter a complete email address,
for example name@company.com
</p>Accessibility inside the form
Since 28 June 2025 (German Accessibility Strengthening Act) accessibility requirements also apply to services in electronic commerce. Websites through which consumers can conclude contracts or initiate services are covered. Micro-enterprises with fewer than 10 employees and at most 2 million euros in annual turnover or balance sheet total are exempt (German Accessibility Strengthening Act). The technical yardstick is the harmonised European standard EN 301 549, which points to the Web Content Accessibility Guidelines at conformance level AA. For forms this does not mean exotic extra work but a manageable list of verifiable properties that can be worked through in one pass. Anyone who wants the relationship between law, standard and testing practice laid out once will find it in the article on the accessibility act and WCAG 2.2 AA. The list below summarises what an inquiry form should cover.
- Every input field has a permanently visible label that is programmatically associated with it.
- Fields that belong together, such as choice groups, are marked up and named as a group.
- The purpose of common fields is declared through the autocomplete attribute (success criterion 1.3.5).
- The order in which the keyboard moves through the form matches the visible order.
- The keyboard focus is clearly visible, including on coloured surfaces and inside outlined fields.
- Errors are described in text, with a correction hint, and announced by assistive technology (success criteria 3.3.1 and 3.3.3).
- Controls measure at least 24 by 24 CSS pixels or keep sufficient spacing (success criterion 2.5.8).
- Details already asked for in the same process are not requested a second time (success criterion 3.3.7).
Keeping spam out without shutting people out
Spam through contact forms is real: as soon as an address is on the web, automated submissions arrive. The obvious answer, putting a picture puzzle in front of the form, is also the most expensive one. In its working group note on the inaccessibility of CAPTCHA the W3C has described for years why visual and audio puzzles exclude people with visual, hearing or cognitive impairments, and why they achieve little against determined attackers (W3C). WCAG 2.2 picked up the idea for authentication in success criterion 3.3.8 and restricted cognitive function tests there (W3C, WCAG 2.2). The criterion does not apply directly to inquiry forms, but the principle transfers. On top of that comes a data protection question: verification services from external providers transmit data to third parties and thereby trigger information and often consent duties, as the article on GDPR and consent describes in detail. Server-side methods that assess a submission only after it arrives are more effective and far less intrusive.
| Method | Effect on automated submissions | Hurdle for visitors |
|---|---|---|
| Hidden extra field (honeypot) | Catches simple scripts that fill in every field they find | None, the field is invisible to people and excluded from assistive technology |
| Timing between page load and submit | Filters out entries created within fractions of a second | None, as long as the threshold is chosen generously |
| Server-side content checks | Detects recurring patterns, link lists and unusual character sequences | None, provided rejected entries are reported back in an understandable way |
| Rate limit per source and period | Noticeably slows bulk submissions from a single source | Low, as a rule it only affects repeated attempts in quick succession |
| Arithmetic task or picture puzzle | Works against simple scripts, hardly at all against paid human relay | High, particularly for people with visual or cognitive impairments |
| Verification service of an external provider | Effective, but moves the check outside your own area of responsibility | Extra data transfer and therefore information and consent questions |
Confirmation, response time and reachability
Everything after the send button is the part a business can influence most easily. An inquiry is an advance of trust, and that advance has a short shelf life. Two things belong together immediately: a visible confirmation in the browser and a confirmation by email to the address given. The browser confirmation should be its own page or a clearly marked region whose text is announced by screen readers; a notice that fades in briefly at the edge of the screen is not enough for that. The email confirmation repeats the content of the inquiry, names a responsible contact and, as far as it can be kept, a timeframe for the reply. A sentence such as typically within one working day carries more weight than any superlative, because it can be checked. The order matters as well: store the inquiry first, then confirm. If sending the email stalls, the record itself should still survive.
- The inquiry is stored before any notification goes out.
- The browser shows a dedicated confirmation page with a heading, a short summary and the responsible contact.
- Keyboard focus moves to the confirmation so that assistive technology can announce it.
- A confirmation email goes to the address given and repeats the content of the inquiry.
- A timeframe for the reply is stated, phrased as an experience value rather than a firm commitment.
- Internally the inquiry receives a status and an owner, so that open cases stay visible.
A form is one channel, not the channel. Section 5 of the German Digital Services Act requires details that allow fast electronic contact and direct communication, including an electronic mail address. The Court of Justice of the European Union has held that an electronic enquiry template can serve as the second means of communication, provided that inquiries are answered within 30 to 60 minutes as a rule (Court of Justice of the European Union, case C-298/07). For most businesses the simpler solution is to offer several routes side by side: an email address, a phone number with the hours it is staffed, a postal address and the form. People choose differently, and the choice depends less on technology than on urgency. Which details are legally required and where they belong is set out in the article on imprint and privacy policy. Anyone working across language borders should also check that form, confirmation and error messages exist in every language delivered; the article on multilingual sites and hreflang covers those requirements.
Data protection: legal basis, retention, evidence
An incoming inquiry is processing of personal data and needs a legal basis. In most cases Article 6(1)(b) GDPR carries it, because the inquiry aims at pre-contractual measures; for general questions Article 6(1)(f) with a documented balancing test comes into play. An additional consent checkbox is then not merely redundant, it weakens the position, because a withdrawn consent makes the ongoing handling contestable. What is required instead is the information under Article 13 GDPR at the time of collection, sensibly placed as a short note below the form with a link to the full privacy policy. Transport belongs encrypted under Article 32 GDPR; the German data protection authorities note in their guidance for telemedia providers that transport encryption counts as state of the art for forms carrying personal data. And forwarding to a mailbox is a station of its own: distributing inquiries by email typically leaves the encrypted connection behind, so the forwarded content should be limited deliberately.
- Record the legal basis per type of inquiry: pre-contractual measure, or legitimate interest with a documented balancing test.
- Information under Article 13 GDPR below the form, kept short and linking to the full privacy policy.
- Transport encryption for the submission, and for forwarding a deliberate decision about which content leaves the system.
- Access to inquiry management restricted to people who actually handle inquiries, with traceable access.
- Deletion rules per category: inquiries without follow-up business after a few months, contract-related records according to commercial and tax law periods.
- Clarify processor arrangements as soon as an external service is involved in receiving, storing or sending.
- Plan for access and deletion requests: Article 12(3) GDPR sets a deadline of one month (Regulation (EU) 2016/679).
An inquiry is something entrusted to you. Storing it cleanly, handling it traceably and deleting it on time protects more than data; it protects the trust that triggered the contact in the first place.
Form, spam protection and inquiry management with XICflow
XICflow is an AI website builder: a briefing turns into a complete company website with structure, copy and images, maintained as a configuration and delivered as static files. The contact form is not a component bolted on afterwards but part of the generated page. It ships with visible labels, machine-readable purpose attributes, error messages in text form and a confirmation page that assistive technology can announce. Spam protection works server-side, without picture puzzles and without a verification service from an external provider. Incoming inquiries do not just land in a mailbox but in an inquiry management view with status, history and search, so it stays traceable which case was answered when. The page on how it works describes the route from briefing to finished site, and the pricing overview shows the available tiers.
Form out of the box
Labels, purpose attributes for autofill, error messages in text form and a dedicated confirmation page are part of the generated page rather than the result of later rework.
Spam protection without puzzles
Hidden extra field, timing check, content rules and rate limits per source all run on the server. As a rule visitors notice none of it.
Inquiry management
Every inquiry gets a status, an owner and a history. Open cases stay visible instead of disappearing into a shared mailbox.
Accessible operation
Keyboard order, visible focus, target sizes and error announcement follow the Web Content Accessibility Guidelines at conformance level AA.
Data protection built in
Encrypted submission, an Article 13 GDPR notice below the form, generated legal texts per domain and configurable deletion periods for stored inquiries.
The form in every language
Labels, error messages and confirmations exist in every maintained language, matching the hreflang markup and the translated addresses.
Getting started needs little preparation. Open your own form and try to fill it in and submit it completely using the keyboard alone. Then submit it deliberately broken and check whether the message names the affected field, whether the entries survive, and whether focus moves to the place that needs fixing. Next, count the mandatory fields and remove every one that a first reply could do without. Finally, check how long incoming inquiries sit around and when they are deleted. Four passes like that lift most of the available effect before anyone starts talking about visual design. More articles on building and running a company website are collected in the blog overview.