Het formulier meldt succes maar de aanvraag ontbreekt

Een formulier is een keten. De browser controleert velden, verstuurt een verzoek, een server of externe dienst verwerkt het, de gegevens belanden ergens in opslag en een notificatie waarschuwt een persoon. Een script kan de bedanktekst tonen op basis van eigen logica, ook als de server de aanvraag niet heeft verwerkt. MDN legt uit dat validatie in de browser een eerste controle is en dat de server de gegevens altijd zelf opnieuw moet controleren. Wat de server weigert, merk je pas na een heen-en-terugreis (MDN over formuliervalidatie).

Dat betekent dat een succesmelding in de browser en een afgeleverde aanvraag twee verschillende feiten zijn. De rest van deze gids toetst telkens één schakel, zodat je kunt aanwijzen waar de keten breekt.

Gebruik nooit gegevens van een echte klant. Maak een herkenbare marker, bijvoorbeeld TEST gevolgd door datum en je initialen, en zet die in het berichtveld en in de naam. Gebruik een e-mailadres dat je zelf beheert en test alleen in een omgeving waar een testaanvraag veilig is: controleer vooraf of een testaanvraag geen automatische mails, CRM-opvolging of facturatie start, en markeer of verwijder de testrecords achteraf. Vul alle velden in, ook de optionele, en noteer tot op de minuut het tijdstip, het toestel en de browser. Maak een schermafbeelding van de bedanktekst.

web.dev heeft een cursus over formulieren met aparte onderdelen over testen en over het verzamelen van gegevens (web.dev cursus over formulieren). Gebruik die als achtergrond. Bepaal vooraf bij wie het resultaat terechtkomt, in welke tool je het terugvindt en wie in de keten toegang heeft, zodat je tijdens de test niet hoeft te zoeken.

1. Browser: verstuur eerst het formulier leeg en daarna correct. Verschijnen de foutmeldingen, en bij welke velden? Noteer in de paginabron het action-adres, de methode en de veldnamen.
2. Verzoek: open de netwerkweergave van de ontwikkeltools van je browser (de naam verschilt per browser), verstuur de test en noteer URL, methode, statuscode en antwoord. Zie je geen verzoek, dan stopt het probleem vóór het versturen. Een foutstatus samen met een bedanktekst is een duidelijke aanwijzing.
3. Verwerking: vraag aan je ontwikkelaar of formulierleverancier of het verzoek in hun logs of overzicht staat.
4. Opslag: zoek de marker in de plek waar aanvragen horen te komen: een overzicht in de formuliertool, een CRM of een database.
5. Notificatie: zoek de marker in het postvak van de ontvanger, in spam en in regels of filters. Controleer of het verzendadres bij je domein past.
6. Opvolging: wie ziet de melding, wie neemt ze op, en wie vervangt die persoon bij afwezigheid?

Heb je op een schakel geen toegang, noteer dan 'niet te controleren' in plaats van te gokken.

Beslisregel: pas het eerste rode punt in de keten aan en test daarna de hele keten opnieuw. Meerdere schakels tegelijk herstellen maakt de oorzaak onzichtbaar.

Dit voorbeeld bevat enkel invoer en verwachte controles. Invoer: een contactformulier met naam, e-mailadres, telefoonnummer (optioneel) en bericht. De melding moet in een gedeelde mailbox van de zaak komen en in een overzicht in de formuliertool. Je gebruikt de marker TEST-A in de naam en TEST-B, TEST-C en TEST-D in drie varianten.

Variant A heeft alle velden ingevuld. Variant B laat het telefoonnummer leeg. Variant C bevat accenten en een lang bericht. Variant D wordt vanaf een telefoon via mobiel internet verstuurd. Verwachte controles per variant: staat er een netwerkverzoek met een geslaagde status, komt de marker in het overzicht van de formuliertool, komt de e-mail in de gedeelde mailbox en niet in spam, en blijft de bedanktekst weg wanneer je het verzoek bewust laat mislukken? Noteer de uitslag per variant in je blad.

De W3C-handleiding over toegankelijke formulieren vraagt om meldingen over geslaagde taken en over fouten, met uitleg om fouten te herstellen (W3C over formulieren). De bron zegt niet hoe je dat technisch moet inrichten. Als eigen redactioneel voorstel: laat de ontwikkelaar de tekst alleen tonen wanneer de server of leverancier een succes meldt, en bij een fout een duidelijke boodschap met een alternatief contactkanaal. Let op dat een timeout of foutmelding ook kan optreden nadat de aanvraag al is opgeslagen: controleer in opslag of er een dubbele of juist een wel opgeslagen aanvraag staat voordat je opnieuw verstuurt.

Herhaal na elke wijziging aan plugin, thema, hosting of e-mailinstellingen dezelfde testreeks met een nieuwe marker. Spreek met je team af wie dat doet en hoe vaak, en bewaar de uitslag per datum. Houd rekening met de grenzen: je test een bepaald tijdstip en een bepaald toestel, geen garantie voor alle toekomstige aanvragen.

Wil je ook bekijken welke publieke signalen je website toont rond contact en opvolging? Dat kan via Marketing Scan. Een publieke scan ziet je formulier niet van binnen en vervangt de testaanvraag hierboven niet.