Meertrapsformulier met een duidelijke terugknop

Je test of een bezoeker in elke stap kan zien waar hij staat, kan teruggaan zonder gegevens te verliezen en voor het verzenden alles kan nalopen. Je beoordeelt niet of meerdere stappen beter zijn dan één pagina. Dat hangt van de lengte en het soort vragen af.

De richtlijn van W3C over toegankelijke formulieren, de formulierentutorial van W3C, zegt dat je lange formulieren kunt verdelen in kleinere formulieren die logische stappen vormen, en dat je gebruikers over hun voortgang informeert. Ze merkt ook op dat gebruikers vaker afhaken als je irrelevante of te veel gegevens vraagt. Begin je audit dus met een schrapronde: elke vraag die de aanvraag niet nodig heeft, valt weg voor je de stappen test.

Een indicatie is meer dan een cijfer in een hoek. Test elke stap met onderstaande vragen:

• Staat het stapnummer en het totaal als tekst op de pagina, bijvoorbeeld "Stap 2 van 4", en niet enkel als kleur of icoon?
• Heeft elke stap een korte, unieke kop die zegt wat je invult?
• Worden verwante velden gegroepeerd, met een duidelijke groepsnaam voor hulpsoftware? W3C beveelt hiervoor fieldset en legend aan, samen met een label bij elk veld.
• Staat vooraf hoeveel stappen er zijn en wat je nodig hebt, zoals een documentnummer?

Test dit ook met enkel het toetsenbord en met je scherm op een smalle breedte. Een bezoeker die de indicatie niet ziet of niet kan lezen, gokt hoeveel werk er nog is.

De terugknop is een van de meest onderschatte onderdelen. Je test niet enkel je eigen knop, maar ook de terugknop van de browser.

1. Vul stap 1 en 2 in, klik op je eigen Vorige-knop en controleer of alle ingevulde velden van stap 1 er nog staan.
2. Herhaal met de terugknop van de browser. Het is een verschil of je enkel vooruit navigeert of de pagina opnieuw laadt.
3. Ga terug, wijzig één antwoord en ga vooruit. Blijven de latere antwoorden behouden, of verdwijnen ze zonder waarschuwing?
4. Vernieuw de pagina halverwege. Je legt vast wat er gebeurt, ook als het antwoord "alles weg" is.

Het doel is niet om elk scenario technisch perfect te maken, maar om bewuste keuzes te nemen en bezoekers erover te informeren. De leergang Learn Forms van web.dev behandelt ook hoe je gebruikers helpt om gegevens niet opnieuw in te voeren en hoe je formulieren test. Laat je ontwikkelaar die onderdelen daar naslaan.

Controleer de fouten per stap, niet pas aan het einde. De MDN-uitleg over formuliervalidatie stelt dat controle aan de clientkant een eerste check is die de gebruiker snel laat corrigeren, maar dat ze geen volledige beveiliging is. Je gegevens moeten ook aan de serverkant gecontroleerd worden, omdat de controle in de browser makkelijk te omzeilen is.

Test dit praktisch:

• Laat een verplicht veld leeg en kijk of de foutmelding bij dat veld staat en zegt wat te doen.
• Vul een ongeldig e-mailadres in en kijk of het formaat uitgelegd wordt.
• Staat de foutmelding in tekst, en niet enkel in een rode rand?
• Vraag je ontwikkelaar uitdrukkelijk te bevestigen dat ook de servercontrole bestaat. Een publieke test kan dat niet bewijzen.

Redactionele aanbeveling (geen brontstelling): controleer dat een bezoeker die op Vorige klikt, niet geblokkeerd wordt door een foutmelding in de huidige stap.

De laatste stap is een overzicht waarin de bezoeker alles kan nalopen. W3C noemt bij validatie van invoer dat je opties biedt om wijzigingen ongedaan te maken en gegevensinvoer te bevestigen. Een samenvattingsstap is een redactionele manier om dat te toetsen. Gebruik deze checklist als eigen controle, niet als bewijs van WCAG-conformiteit:

Fictieve invoer: een aanvraagformulier met vier stappen: contactgegevens, omschrijving van de vraag, voorkeur voor een afspraak en een samenvatting. De testpersoon vult stap 1 tot 3 in, gaat via Vorige naar stap 1, wijzigt het telefoonnummer, gaat opnieuw vooruit en vernieuwt dan de pagina in stap 3.

Verwachte technische controles:

• Na Vorige staan de gegevens van stap 1 er nog, ook met de terugknop van de browser.
• Het gewijzigde telefoonnummer verschijnt in de samenvatting.
• Antwoorden uit stap 2 en 3 blijven behouden, of het formulier meldt duidelijk dat ze gewist zijn.
• Een ongeldig e-mailadres geeft een melding bij het veld in tekst.
• De samenvatting laat toe om per onderdeel terug te gaan.

Test op een telefoon en een computer, en met toetsenbordnavigatie. Noteer per test geslaagd, mislukt of onbekend, met de datum en wie het deed. Wil je weten welke publieke signalen van je site zichtbaar zijn, bekijk ze dan via Marketing Scan. Een publieke scan ziet niet wat er in je formulier na het invullen gebeurt en bewijst geen volledige technische implementatie.