Formulierfouten bewaren de invoer niet: herstelplan

Vul een testaanvraag in met een herkenbare projectomschrijving die geen persoonsgegevens bevat. Laat bewust één verplicht veld leeg en probeer te verzenden. Noteer welke velden daarna leeg zijn, welke waarden veranderd zijn en waar de bezoeker terechtkomt. Een compleet verdwenen formulier vraagt een andere ingreep dan één keuzelijst die terugvalt naar de eerste optie. Maak daarom een schermafbeelding vóór en na de fout, met de ingevulde testwaarden leesbaar.

Herhaal de proef met een verkeerd geschreven e-mailadres, een ontbrekende bijlage en een ongeldige datum wanneer die onderdelen bestaan. Test elk geval afzonderlijk. Anders weet je achteraf niet welke controle de herstart veroorzaakt. Schrijf ook op of de fout ontstaat voordat er een netwerkverzoek vertrekt of nadat de server antwoordt. Je webbouwer kan zo gericht zoeken naar de plaats waar de invoer verloren gaat.

Gebruik bij iedere proef dezelfde korte controlelijst:

1. Noteer de gewone tekstvelden en keuzes die vóór verzending zijn ingevuld.
2. Veroorzaak precies één afwijzing en controleer welke waarden daarna nog zichtbaar zijn.
3. Lees de foutmelding zonder hulp en navigeer naar het betreffende veld met het toetsenbord.
4. Corrigeer alleen het foute veld en verzend opnieuw zonder de andere velden opnieuw te typen.
5. Zoek de herkenbare testaanvraag terug in het ontvangende systeem en controleer dat er slechts één complete aanvraag is.

Een vergeten veld is een herstelbare invoerfout. Een onbereikbare server of verlopen sessie is iets anders. De boodschap moet dat verschil zichtbaar maken. Bij een invoerfout wil je weten welk veld je moet aanpassen. Bij een technische fout moet duidelijk zijn of de aanvraag wel of niet ontvangen is en welke veilige vervolgstap beschikbaar is. Laat een technisch probleem niet voorstellen alsof de klant zijn gegevens verkeerd invult.

MDN beschrijft validatie in de browser en op de server. Een browsercontrole vervangt de servercontrole niet. Vraag je ontwikkelaar daarom beide paden te testen: een fout die lokaal wordt tegengehouden en dezelfde fout die de server afwijst. Het voorgestelde testblad is onze praktische werkwijze; de documentatie bewijst geen specifieke conversiewinst voor jouw formulier.

Voor een gewone offerteaanvraag is het nuttig dat naam, gekozen dienst en projectomschrijving nog aanwezig zijn na een herstelbare fout. Dat betekent niet dat je alle inhoud langdurig in de browser moet opslaan. Vraag eerst waar de gegevens nu staan: alleen in de geopende pagina, tijdelijk in de serverrespons of blijvend in lokale opslag. Dat zijn verschillende keuzes met verschillende gevolgen voor iemand die een toestel deelt.

Maak een veldlijst met de kolommen behouden tijdens herstel, opnieuw laten invullen en reden. Plaats wachtwoorden, betaalgegevens en gevoelige documenten niet zonder afzonderlijke beoordeling in een algemene bewaaroplossing. Een bestandsveld kan bovendien niet altijd zomaar worden teruggevuld. Leg bij zo'n veld duidelijk uit dat de bezoeker opnieuw een bestand moet kiezen, terwijl de overige invoer behouden blijft. Laat de technische aanpak door de verantwoordelijke ontwikkelaar beoordelen.

De bezoeker moet na afwijzing kunnen zien wat er misgaat en hoe hij verder kan. Een tekst als fout opgetreden helpt onvoldoende als er eigenlijk alleen een huisnummer ontbreekt. Schrijf bijvoorbeeld dat het huisnummer nog ontbreekt en dat de overige gegevens zijn bewaard, maar alleen wanneer dat werkelijk getest is. Een melding over bewaren die niet klopt maakt het herstel juist onduidelijker.

De W3C-uitleg over formuliermeldingen behandelt duidelijke terugkoppeling bij fouten en voltooiing. Gebruik die technische achtergrond om de fout zichtbaar bij het betreffende veld te plaatsen en een bruikbaar overzicht te geven wanneer meerdere velden verkeerd zijn. Controleer vervolgens met alleen het toetsenbord of de bezoeker de fout kan bereiken, het veld kan corrigeren en opnieuw kan verzenden. Laat een tweede persoon de melding lezen zonder mondelinge toelichting.

Stuur je webbouwer geen algemene opdracht om het formulier beter te maken. Geef de pagina, het geteste toestel, de gekozen browser en de precieze handelingen door. Voeg de verwachte uitkomst toe: na een ontbrekend huisnummer blijven de andere gewone tekstvelden behouden; het huisnummerveld krijgt begrijpelijke hulp; na correctie wordt één aanvraag aangemaakt. Vermeld afzonderlijk wat er met bijlagen moet gebeuren.

Laat het herstel daarna opnieuw testen met dezelfde invoer. Controleer niet alleen de zichtbare tekst maar ook het werkelijk ontvangen aanvraagrecord. Een geslaagde tweede poging mag geen tweede onbedoelde aanvraag opleveren. Noteer datum en geteste versie, zodat iemand later weet waarop de goedkeuring betrekking had. Als de fout alleen op een bepaald toestel voorkwam, hoort dat toestel of een passende nabootsing opnieuw bij de controle. Bewaar geen echte klantinhoud in het foutticket.

Een formulier is pas klaar voor gebruik wanneer het volledige pad begrijpelijk werkt: invullen, fout herkennen, corrigeren, verzenden en ontvangst terugvinden. Laat de verantwoordelijke collega één eigen test uitvoeren en de uitkomst aftekenen. Plan daarnaast een nieuwe controle wanneer velden, opslag of de dienst die aanvragen ontvangt veranderen. Je hoeft daarvoor geen nieuwe marketingcampagne of echte klantaanvraag te versturen.

Wil je eerst zien welke publiek waarneembare signalen op je website aandacht vragen? Begin met Marketing Scan. Die eerste controle kan je websiteonderzoek structureren, maar bewijst niet dat jouw interne formulieropslag of mailaflevering correct werkt. Daarvoor blijft de hierboven beschreven testaanvraag nodig. Gebruik de uitkomst om een concrete herstelactie te kiezen en leg de afsluiting vast met dezelfde controle die het probleem zichtbaar maakte.