Een contactformulier voor je KMO: minder velden, duidelijke fouten en veilige verwerking

Kort samengevat: Een contactformulier moet iemand helpen een vraag te stellen. Vraag alleen nuttige gegevens, maak fouten begrijpelijk en laat de server elke aanvraag controleren. Vertel daarna eerlijk wat er met het bericht is gebeurd.

Dit is een praktische evergreen-analyse voor Belgische zelfstandigen en KMO's, geen nieuwsbericht of aankondiging van nieuwe wetgeving. De bronnen zijn gecontroleerd op 12 oktober 2026.

Begin bij de vraag, niet bij je CRM

Een bezoeker wil weten of je zijn website kunt vernieuwen. Je formulier vraagt eerst een telefoonnummer, adres, ondernemingsnummer, personeelsaantal en budget. Welke gegevens heb je werkelijk nodig om die eerste vraag te beantwoorden?

W3C/WAI adviseert korte, eenvoudige formulieren die alleen vragen wat nodig is voor de handeling.[3] Begin bijvoorbeeld met een e-mailadres en een bericht. Vraag een naam als die voor je opvolging nuttig is. Maak bedrijf of telefoon optioneel, tenzij je kunt uitleggen waarom dat veld voor deze aanvraag nodig is. Een offerteproces kan later meer informatie vragen.

Dit is ook een privacykeuze. Volgens de Europese Commissie moet je persoonsgegevens beperken tot wat noodzakelijk is voor het doel.[5] Een eerste contact is geen reden om alvast een volledig klantendossier op te bouwen. We beloven hier geen conversiestijging; het gaat om een begrijpelijke route naar contact.

Geef elk veld een blijvend label

Zet "E-mailadres" zichtbaar boven het invoerveld. Een voorbeeld binnen het veld kan helpen, maar mag niet de enige uitleg zijn. WAI beschrijft hoe een echt label technisch aan het veld wordt gekoppeld: het for-attribuut van het label verwijst naar het id van het veld.[6]

Vermeld welke velden verplicht zijn en toon beperkingen vóór iemand verzendt. Schrijf bijvoorbeeld "Bericht, maximaal 2.000 tekens" als dat je gekozen limiet is. Dat getal is een ontwerpvoorbeeld, geen verplichte norm.

Test het formulier met alleen een toetsenbord en met een schermlezer. Is de volgorde logisch? Zijn de labels hoorbaar en blijft de focus zichtbaar? Voorzie dezelfde uitleg in de taal van de pagina. Een Nederlandse foutmelding op een Engelse contactpagina helpt de bezoeker niet.

Leg uit hoe iemand een fout herstelt

"Ongeldige invoer" vertelt weinig. "Vul een e-mailadres in, bijvoorbeeld naam@bedrijf.be" geeft een volgende stap. WAI adviseert begrijpelijke fouten die het betrokken veld benoemen en uitleggen hoe de gebruiker ze oplost.[7]

Toon de fout bij het veld en koppel die melding technisch aan het invoerveld. Bij meerdere fouten kan een overzicht met links naar de velden helpen. Gebruik tekst naast kleur en zorg dat dynamische meldingen ook voor hulptechnologie waarneembaar zijn.[7] Bewaar de reeds ingevulde tekst na een fout, zodat iemand niet opnieuw zijn hele vraag moet typen.

Laat de server begrensd controleren

Browsercontroles geven snelle feedback, maar zijn te omzeilen. MDN waarschuwt daarom dat ook de server ingediende formuliergegevens moet valideren.[4]

Laat je ontwikkelaar per veld vastleggen wat de server accepteert: het verwachte type, verplichte waarden, lengtegrenzen en toegestane opties. Een keuzelijst "Website" of "Onderhoud" moet op de server dezelfde toegestane waarden controleren. OWASP adviseert bovendien een limiet op de aanvraaggrootte vóór het inlezen of verwerken van de inhoud.[1]

Voor vrije tekst betekent dit niet dat je alle leestekens verbiedt. Namen met apostroffen, accenten en gewone Unicode-tekst kunnen legitiem zijn. OWASP maakt onderscheid tussen passende invoerregels en aparte beveiliging bij het gebruik van die gegevens.[1] Controleer het formaat van een e-mailadres, maar doe niet alsof daarmee bewezen is dat de mailbox bestaat of van de afzender is.

Geef een bericht weer als tekst, niet als code

Een goedgekeurd bericht blijft onbetrouwbare invoer. Wanneer het later in een beheerscherm of HTML-e-mail verschijnt, moet de uitvoer veilig worden opgebouwd. OWASP beschrijft contextspecifieke outputencoding: bescherming voor HTML-tekst is niet automatisch geschikt voor een HTML-attribuut, URL of JavaScript-context.[2]

Gebruik de veilige tekstweergave en automatische escaping van je framework waar die van toepassing zijn. Laat gewone contactberichten niet als ruwe HTML renderen. Als je werkelijk opgemaakte HTML wilt toestaan, vraagt dat een afzonderlijke sanitiseringsaanpak.[2]

HTML-escaping voorkomt geen spamcampagne en bewijst geen identiteit. Bespreek misbruikbeperking afzonderlijk met je ontwikkelaar, bijvoorbeeld aanvraaglimieten en monitoring. Geen van deze maatregelen maakt het formulier op zichzelf volledig veilig.

"Ontvangen" is niet hetzelfde als "afgeleverd"

Kies de bevestiging op basis van wat je systeem werkelijk weet. "Je aanvraag is ontvangen" past als de server de aanvraag betrouwbaar heeft opgeslagen. "Je bericht is afgeleverd" vraagt bewijs van die latere stap. Aanvaarding door een maildienst bewijst nog niet dat een medewerker het bericht heeft gelezen.

Dit is een ontwerpaanbeveling: bepaal welke gebeurtenis elke melding rechtvaardigt. Controleer in een testomgeving ook een mislukte mailverzending en een tijdelijke serverfout. Toon dan een bruikbare vervolgstap of alternatief contactkanaal. Beloof geen antwoordtermijn die je organisatie niet heeft afgesproken.

Een vraag is geen nieuwsbriefinschrijving

Leg bij het formulier kort uit waarvoor je de gegevens gebruikt en verwijs naar een begrijpelijke privacyverklaring. De Commissie noemt doelbinding, transparantie en beperkte bewaring als GDPR-principes.[5] Spreek intern af wie aanvragen mag bekijken en wanneer je ze wist of opnieuw beoordeelt.

Beoordeel de rechtsgrond voor het beantwoorden van een vraag en die voor marketing afzonderlijk. Een contactbericht is geen automatische toestemming voor een nieuwsbrief. Deze analyse bepaalt niet welke rechtsgrond jouw situatie vereist. Laat ook de toepasselijke marketingregels beoordelen. Als je nieuwsbriefinschrijving aanbiedt, houd die keuze apart, vrijwillig en niet vooraf aangevinkt; maak je antwoord niet afhankelijk van die keuze.

Veelgestelde vragen

Moet een telefoonnummer verplicht zijn?

Alleen als het voor deze aanvraag nodig is. Kun je de vraag per e-mail beantwoorden, maak het nummer dan optioneel of laat het weg.

Is een groen vinkje bewijs dat de mail aankwam?

Niet zonder bewijs van aflevering. Laat de melding aansluiten op de aantoonbare stap, zoals het opslaan van de aanvraag.

Waar begin ik met verbeteren?

Schrap onnodige velden. Test daarna labels, foutmeldingen en de bevestiging. Bespreek de servercontroles en veilige uitvoer met je ontwikkelaar. Wil je jouw contactroute laten bekijken? Bespreek je website met IntrICT.

Bronnen

[1] https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html — Input Validation - OWASP Cheat Sheet Series

[2] https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html — Cross Site Scripting Prevention - OWASP Cheat Sheet Series

[3] https://www.w3.org/WAI/tutorials/forms — Forms Tutorial - W3C WAI

[4] https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation — Client-side form validation - MDN

[5] https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en — Principles of personal data processing under the GDPR - European Commission

[6] https://www.w3.org/WAI/tutorials/forms/labels — Labeling Controls - W3C WAI

[7] https://www.w3.org/WAI/tutorials/forms/notifications — User Notification - W3C WAI