Verlopen sessie tijdens een lang aanvraagformulier

Een sessie kan op drie manieren verlopen: de sessiecookie vervalt, een beveiligingstoken van het formulier vervalt, of een inactiviteitsregel logt de gebruiker uit. Test ze apart, want ze geven elk een ander foutscherm. Vraag je ontwikkelaar welke van de drie in jouw formulier bestaan en na hoeveel tijd.

Stel daarna de principiële vraag: moet er een limiet zijn? De toegankelijkheidstutorial van W3C over formulieren zegt dat formulieren liefst geen tijdslimiet hebben. Is er een limiet nodig, bijvoorbeeld om beveiligingsredenen, dan moet de gebruiker die kunnen uitzetten of verlengen. Uitzonderingen zijn live-situaties zoals een veiling, of gevallen waarin de tijd essentieel is voor een geldige aanvraag. Voor een gewoon aanvraagformulier is dat zelden zo, dus verlengen of waarschuwen is de eerste ontwerpkeuze.

Test in een testomgeving met verzonnen gegevens, nooit met echte klantgegevens. Vraag of de sessieduur in die omgeving tijdelijk korter kan, zodat je niet de volledige echte duur hoeft af te wachten.

1. Vul het formulier voor ongeveer de helft in met testgegevens.
2. Wacht tot de limiet is verstreken en ga zonder herladen verder met invullen.
3. Verzend en noteer wat er gebeurt: foutmelding, omleiding of niets.
4. Herhaal met scenario's: terug-knop, pagina herladen, tweede tabblad waar je uitlogt, tijdelijk geen verbinding, en een mobiel toestel dat in de achtergrond gaat.
5. Noteer per scenario of velden gevuld blijven, of de gebruiker begrijpt wat er misging en waar de focus na de melding staat.
6. Controleer ook de serverkant: de uitleg van MDN over formuliervalidatie benadrukt dat validatie in de browser geen volwaardige beveiliging is en dat de server altijd zelf moet controleren. Een verlopen sessie moet de server dus netjes afhandelen, niet stilzwijgend accepteren of crashen.

Herstel betekent dat je ingevoerde gegevens ergens tijdelijk bewaart. Welke plek je kiest, hangt af van het type gegeven.

Bij twijfel kies je voor minder bewaren. Deze tabel is een redactioneel ontwerpvoorstel en geen bronfeit, geen juridisch oordeel en geen toestemmings- of compliancebeoordeling. De genoemde bronnen behandelen deze bewaarkeuzes niet.

Een goed herstel heeft vier kenmerken. Eerst een waarschuwing vóór het verlopen met de optie om te verlengen, zoals W3C voorstelt. Ten tweede blijft de pagina na het verlopen staan met de ingevoerde waarden, in plaats van een lege herlaadpagina. Ten derde kan de gebruiker opnieuw inloggen in hetzelfde scherm of terugkeren naar dezelfde stap met zijn concept. Ten vierde legt een foutmelding in gewone taal uit wat er gebeurde en wat de gebruiker nu doet.

Deel lange formulieren op in logische stappen met een voortgangsindicatie, zoals W3C aanraadt. Elke stap kun je dan afzonderlijk als concept bewaren. De cursus Learn Forms van web.dev bevat hoofdstukken over opnieuw invoeren vermijden, beveiliging en privacy en het testen van formulieren. Lees die als verdieping, en controleer de details voor je eigen techniek.

Dit is een verzonnen invoer met enkel verwachte controles.

Invoer: een formulier met vier stappen en 38 velden. In de testomgeving is de sessie ingesteld op 15 minuten. De tester vult stap 1 en 2 met testgegevens in, wacht tot de sessie voorbij is en klikt dan op Volgende.

• Er verscheen een waarschuwing vóór het verlopen met een manier om te verlengen.
• Na opnieuw inloggen staat de tester terug op stap 3 en zijn de gegevens van stap 1 en 2 aanwezig.
• In de opslag van de browser (te bekijken in de ontwikkelaarstools) staan geen velden die je als gevoelig hebt geclassificeerd.
• Verzenden na herstel levert in de testomgeving één aanvraag op. Controleer dit in de serverkant aan de hand van een unieke, opvraagbare testactie, want een timeout of foutmelding kan optreden nadat de aanvraag al is opgeslagen. Test ook of herhaald verzenden idempotent wordt afgehandeld.
• Het concept op de server is gewist na verzenden.

Mislukt een punt, dan noteer je de laag (cookie, token, inactiviteit) en geef je het door aan je ontwikkelaar.

Herhaal de zes scenario's na elke wijziging aan sessie-instellingen, inlogmodule of formulier. Test minstens één mobiel toestel en één tweede browser, en gebruik een toetsenbord om te zien of de focus naar de foutmelding gaat. Dit is een praktische controle en bewijst geen volledige WCAG-conformiteit. Controleer ook of de gewiste concepten echt weg zijn.

Grenzen: een publieke website-scan ziet enkel zichtbare signalen en kan niet aantonen hoe je sessies, tokens of concepten technisch werken. De juiste bewaartermijn en rechtsgrond bepaal je met een deskundige. De bronnen beschrijven algemene principes, geen garantie voor jouw platform.

Wil je ook de zichtbare signalen van je website bekijken? Doe dat via Marketing Scan. Die scan meet publieke signalen en voert niet alle controles uit dit artikel uit.