Een bestelknop zonder verrassingen vlak ervoor

Met de bestelzone bedoelen we alles wat de klant ziet vanaf het moment dat de winkelmand definitief wordt tot en met de bevestiging. De kernvraag is simpel: zegt elke plek in dat traject hetzelfde over wat de klant betaalt en wat er nog moet gebeuren?

Het W3C beschrijft in zijn tutorial over toegankelijke formulieren dat gebruikers meestal korte, eenvoudige formulieren verkiezen en sneller afhaken als er irrelevante of overbodige gegevens gevraagd worden. Vertaald naar je bestelproces: elk veld dat je vraagt moet nodig zijn om de bestelling af te ronden. Dat is een principe uit die bron. Of het in jouw winkel meetbaar effect heeft, moet je zelf nagaan.

Leg voor je begint vast welke zaken tot de hoofdinformatie horen. Een bruikbare minimumlijst:

• Totaalbedrag inclusief leverkosten en eventuele toeslagen.
• Gekozen leveringswijze en de levertermijn zoals jij die kan waarmaken.
• Betaalwijze en het moment waarop er betaald wordt.
• Het aantal resterende stappen tot de bevestiging.
• Wat er gebeurt na het klikken op de knop (is de bestelling bindend, volgt er nog een stap?).

Een juridische beoordeling van de teksten rond de knop valt buiten deze gids. Laat dat desgewenst nakijken door iemand die daarvoor bevoegd is.

Verrassingen ontstaan zelden op één plek. Ze sluipen in waar verschillende onderdelen van je winkel hun eigen waarheid tonen. Loop deze vier bronnen na en noteer per bron wat de klant te zien krijgt:

1. Productpagina: toont een prijs, soms met een vermelding over levering. Staat daar een kost die later anders blijkt?
2. Winkelmand: toont vaak een tussentotaal zonder leverkosten. Is dat duidelijk zo benoemd?
3. Afrekenstap: hier komen leverkosten, korting en betaalkosten samen. Wijzigt het totaal nog na een keuze, en is dat zichtbaar?
4. Bevestigingsmail en bevestigingspagina: kloppen bedrag en levering met wat vlak voor de knop stond?

Let extra op situaties waarin het totaal van waarde verandert zonder dat de klant het merkt: een leveroptie die automatisch voorgeselecteerd staat, een gratis-leveringsdrempel die pas na een wijziging in de mand verdwijnt, of een kortingscode die een minimumbedrag nodig heeft. Dit zijn plekken om te testen, geen vaststaande oorzaken van afhaken.

Noteer bij elke bevinding de bron (welke pagina of welk bericht) en wat je verwachtte. Zo blijft de diagnose controleerbaar voor wie na jou kijkt.

Een samenvatting kan perfect zijn en toch een bestelling laten mislukken als het formulier erachter onduidelijk is. De cursus over formulieren op web.dev bundelt daarvoor onderwerpen zoals gebruikers helpen gegevens correct in te voeren, autofill en het testen van formulieren. Gebruik die onderwerpen als leidraad voor je eigen controle.

Loop het formulier met toetsenbord en zonder muis door en beantwoord per veld:

• Heeft elk veld een zichtbaar label dat bij het veld hoort? Het W3C wijst het label-element aan als standaardmiddel om een bedieningselement te benoemen.
• Zijn verwante velden, zoals leveringsadres en factuuradres, logisch gegroepeerd?
• Staan instructies (bijvoorbeeld het verwachte formaat van een telefoonnummer) vóór het veld in plaats van pas in een foutmelding?
• Zegt een foutmelding wat er mis is en hoe je het herstelt?

MDN legt in zijn uitleg over formuliervalidatie uit dat validatie in de browser een eerste controle is die de gebruiker snel laat corrigeren, maar dat ze geen volledige beveiligingsmaatregel is. Je server moet de ingevoerde gegevens dus ook zelf controleren. Voor je bestelproces betekent dat: test niet alleen wat de browser toont, maar ook wat er gebeurt als een ongeldige waarde toch de server bereikt.

Een controle zonder beslisregels eindigt in een lijstje bevindingen waar niemand iets mee doet. Gebruik onderstaand beslisblad om per afwijking te bepalen wat er gebeurt. De kolom 'Eigenaar' vul je zelf in volgens jouw team.

Ga niet uit van één verhaal voor alle winkels. Een winkel met enkel digitale producten heeft geen leverkosten en dus een kortere lijst; een winkel met meerdere leveropties heeft meer te controleren.

Stel: een kleine webwinkel verkoopt keukenaccessoires. De eigenaar vermoedt dat de laatste stap onduidelijk is en geeft je de opdracht de samenvatting te controleren. Hieronder staat uitsluitend de invoer en de verwachte controle, geen resultaat.

Invoer (fictief): mandtotaal 40,00 euro; standaardlevering 5,00 euro; kortingscode die geldt vanaf een minimumbedrag van 50,00 euro; één verplicht veld 'bedrijfsnaam' dat ook voor particulieren zichtbaar is.

Testgeval 1: voeg het artikel toe, kies standaardlevering en noteer het totaal op mand, afrekenstap en bevestiging. Verwachte controle: alle drie tonen 45,00 euro, of een uitleg waarom niet.

Testgeval 2: voer de kortingscode in met een mand van 40,00 euro. Verwachte controle: de klant krijgt een melding waarom de code niet werkt, en de samenvatting blijft ongewijzigd.

Testgeval 3: laat 'bedrijfsnaam' leeg bij een particuliere bestelling. Verwachte controle: het veld is optioneel of de verplichting wordt gemotiveerd.

Overdracht naar de ontwikkelaar: noteer per testgeval de URL van de stap, wat je invulde, wat je zag en wat je verwachtte. Zo kan de ontwikkelaar elk punt reproduceren zonder te gokken.

Elke aanpassing aan teksten, velden of leveropties verdient een korte hertest. Herhaal minstens de testgevallen uit je overdracht, op een desktop en op een telefoon, omdat toetsenborden en schermformaten anders reageren. De cursus op web.dev behandelt dit apart onder het testen van formulieren over apparaten en platformen heen.

Een compacte hertest na elke wijziging:

1. Werk in een testomgeving of met testbetalingen, nooit met echte betaalgegevens in de live winkel. Een time-out of foutmelding kan optreden nadat de bestelling al is opgeslagen; controleer daarom na een mislukte poging in het ordersysteem of er toch een bestelling is aangemaakt en of een herhaalde klik geen dubbele bestelling geeft.
2. Doorloop het hele traject met toetsenbord, zonder muis. Dit is een bruikbaarheidscontrole en bewijst geen volledige WCAG-conformiteit.
3. Vergelijk het totaal op alle vier de plekken uit de diagnose.
4. Test minstens één ongeldige invoer per verplicht veld en lees de foutmelding.
5. Controleer de bevestigingsmail met de samenvatting ernaast.
6. Noteer datum, wat je wijzigde en wat je opnieuw testte.

Grenzen: deze procedure toetst consistentie en bruikbaarheid van wat je zelf kan zien en invullen. Ze bewijst niet dat meer bezoekers bestellen, en ze vervangt geen gebruikerstest met echte mensen. Wil je dat, dan hoort daar een aparte testopzet bij. Wil je weten welke zichtbare signalen je website nu al toont, bekijk dan je publieke signalen via Marketing Scan. Die scan bekijkt wat publiek zichtbaar is en voert niet alle controles in deze gids uit.