Contact form: make data entry and monitoring more reliable

9 min read

A reliable contact form collects useful information, explains errors and only confirms registration after acceptance by the server. Verification also covers the path to the recipient team: a reassuring interface does not prove that an email has arrived.

Reduce the fields, distinguish between recorded request and transmitted notification, then test errors and restarts only in pre-production.

The following method and matrix constitute a proposed operational acceptance testing, not a regulatory reference nor a compliance audit.

Choose the data necessary for the first exchange

Start from the expected action: qualify a project and organize a reminder, rather than putting together a complete file. The CNIL points out that processing must have a purpose and that collection is not justified by possible usefulness.^[15] W3C recommends requesting only the information necessary for the process.^[12]

In our explicitly fictitious example, an installer asks the municipality to verify its sector of intervention, the nature of the project to guide the request and the contact details necessary for the response. The date of birth is excluded: it does not help with this qualification.

The model requires “Community”, “Nature of the project”, then “How would you like to be contacted?” ". “By email” makes the address mandatory; “By telephone” makes the number mandatory. The other channel, the name and the comment remain optional. Add the instruction: “Do not transmit sensitive documents or information here.”

Record the purpose of each field and have this sheet validated by the business manager. Information on the processing, its legal basis and its conservation requires dedicated verification; collapsing fields does not demonstrate compliance.

Make keyboard input usable

Each control must be identified: the W3C tutorial recommends in particular the element <label> and, for linked control groups, <fieldset> with <legend>.^[12] In the example, the question on the answer channel becomes the caption for the radio button group. Indicative text in a field does not replace its visible label.

In pre-production, then navigate the form with Tab, Shift+Tab, radio button arrows, and Enter. The focus must remain visible, follow an understandable order and reach the send button. Also check that a mobile screen does not hide the active field or its error.

We suggest leaving the errors displayed until they are corrected: “Enter an email address to receive a response by email”, rather than “Invalid value”. Link each message to the field, for example with aria-describedby, and use aria-invalid="true" after error detection. After a rejected submission, a targetable summary can lead to the relevant fields, without clearing the entry.

These controls extend the keyboard and mobile accessibility tests for the contact path. They do not replace a comprehensive assessment with assistive technologies.

Separate contact form validation and server acceptance

Checking in the browser helps to quickly correct an omission. However, it can be circumvented; the server must therefore independently apply the selected rules before accepting the request. Fix the required fields, maximum lengths and permitted values ​​in a single specification. Do not confuse a plausible syntax address with a truly reachable address.

Our control order is as follows: check the chosen channel, check the corresponding coordinate, validate common and project category, then examine the limits of the comment. A server error returns with the concerned field and a usable message. The W3C tutorial recommends reporting errors and explaining how to correct them.^[12]

In staging, also replay a query that ignores browser controls. It must be refused if it violates these rules. A technical response of success is only acceptable as proof of registration if the application actually preserved the request. The planned response contract then contains its reference and its state; the browser never invents this reference.

State matrix: display, proof and responsible

The following matrix is populated for the fictitious installer. It serves as a contract between design, development and operation. The proposed wordings are examples; the evidence should come from your test environment.

For each line tested, keep a screenshot of the screen, the technical reference and the decision: accepted, to be corrected or not demonstrated. The designated manager must be able to link what the user sees to the observed state, without copying their contact details into the report.

Acknowledgment of receipt and email delivered: two different proofs

“Your request is saved” describes an application action. “An email has been sent to you” describes a different transaction and requires different proof. Acceptance of a message by a sending service provider does not demonstrate its presence in the inbox, much less its reading. A delivery status depends on what the messaging infrastructure actually allows you to observe.

So keep the recording separate from notifications, both to the requester and to the team. In our proposal, a failed notification does not delete the request: it triggers an internal check. Provide a way to view saved requests even when the email is missing.

In staging, use a test box or message collector. Check the configured recipient, the link with the reference and the simulated rejections. If your tool does not provide any proof of delivery, enter “delivery not demonstrated”, not “message received”.

Try again without creating a duplicate

An interrupted connection can leave the browser unresponsive even though the server has registered the request. Immediately displaying “Failed, Resend” may result in a new request for the same project.

The proposed solution is a submission key retained during the attempt. The server imposes the uniqueness of this key during registration: an identical recovery finds the request instead of creating a second one. A disabled button during sending improves the interface, but is not enough against a double click, a network resume or two competing requests. The status check should not expose other people's requests.

Test these situations separately. If the same key comes back with modified data, plan for an explicit response rather than a silent merge. Also define the length of time the key remains usable and the behavior after expiration. The expected proof is a unique record for the same attempt, not just an identical confirmation screen.

acceptance testing in pre-production: decide on evidence

Gather the field sheet, validation rules, error texts, response contract, messaging configuration and those responsible for the matrix before the acceptance testing. Prepare only fictitious data. Verify that staging uses test recipients and does not trigger sales messages or tasks to an operations team.

Run the checks in this order:

1. Keyboard navigation, labels and mobile display.
2. Input errors and retention of values.
3. Server refusal despite bypassed browser validation.
4. Registration confirmed by reference.
5. Network outage after save, resume and concurrency.
6. Notification accepted, deferred or rejected in test device.

Record for each scenario the visible result, the redacted server trace and the decision. Do not log the full content of the message by default: a technical reference is often enough to reconcile the events.

Block validation if the screen announces a missing recording, if a restart creates a duplicate or if an error prevents keyboard correction. Never test an actual form for this acceptance testing. Any unobservable scenario remains “undemonstrated”: it calls for instrumentation or a business decision, not a supposition.

Frequently asked questions

Should we ask for a specific address before the first exchange?

Not necessarily. For the fictitious installer, the municipality serves to guide demand; the site address can then be requested if a visit becomes relevant. If your organization requires an address at this stage, document the action that justifies it and separate this data from response contact information. Avoid extending the collection simply in anticipation.

Can we automatically refuse an unrecognized municipality?

A list can facilitate orientation, but its absence of results does not prove that the municipality is invalid. Provide a manual entry solution or category to check, with an understandable message. In particular, test compound nouns and common variants. The business decision must distinguish uncovered territory and search in the list without result.

Is an attachment useful for first contact?

For this course, we suggest carrying over the attachments after qualification. If a photo is essential for the first exchange, open a separate technical site: accepted types, authorized size, file control and access to documents. Reports must cover a refused or partially transmitted file. A simple upload field does not address these issues.

Proceed to corrections with a shared contract

Start by validating the field sheet and assigning a person responsible for each state of the matrix. Then run the acceptance testing in pre-production, with separate proofs of registration and test notifications. To frame interface or processing corrections, you can consult the web services of 4SYSTEM and prepare an exchange based on the documented anomalies.

Sources

• Forms Tutorial | Web Accessibility Initiative (WAI) | W3C (accessed 2026-10-08)
• RGPD : de quoi parle-t-on ? | CNIL (accessed 2026-10-08)