Købsflow og transaktionsforløb
Et website kan have fuldt tilgængelige statiske tekster, men stadig tabe kunder, hvis brugeren eller en AI-agent ikke kan gennemføre et køb. Her beskrives metoden for vurdering af dynamiske transaktionsforløb.
Et transaktionsforløb er en sammenhængende kæde af trin, som en bruger skal igennem for at opnå et mål. TRAQ Blueprint vurderer altid to komplette forløb som en integreret del af standardundersøgelsen.
Hvorfor dynamiske flows er afgørende
De mest kritiske barrierer opstår i dynamiske tilstande, hvor sidens indhold ændrer sig uden et traditionelt sideskift:
- Når en variantvælger opdaterer DOM-strukturen asynkront.
- Når en kurv-skuffe åbnes som en modal uden korrekt fokusindkapsling.
- Når en formular validerer et felt og viser en fejlbesked, som en skærmlæser ikke opfanger.
- Når tastaturfokus forsvinder, fordi en knap erstattes af en indlæsningsindikator.
Disse fejl identificeres ved at gennemleve forløbet trin for trin med tastatur, skærmlæser og devtools.
Transaktionsmodellens bestanddele
Hvert forløb opdeles og registreres efter fire faste elementer:
- Trin (Steps): De enkelte milepæle i processen (fx produktside, kurv, leveringsadresse, forsendelsesvalg).
- Tilstande (States): En sides specifikke tilstand (fx tom formular, udfyldt formular, valideringsfejl, åben modal).
- Handlinger (Actions): Brugerens interaktion (fx tastaturnavigation, aktivering med Enter/Mellemrum, skærmlæserkommando).
- Stoppunkt (Stopping point): Den fastlagte grænse for, hvor testen afsluttes.
Hovedforløbet for e-handel
For webshops følger hovedtransaktionen normalt denne faste sekvens:
| Trin | Undersøgte tilstande | Typiske fejlpunkter |
|---|---|---|
| 1. Varevalg | Grundtilstand, variant skiftet, udsolgt variant | Skift i størrelse/farve annonceres ikke til skærmlæser; tastaturfokus mister position |
| 2. Læg i kurv | Knap aktiveret, indlæsning, feedback bekræftet | Ingen tilbagemelding om at varen er tilføjet; kurv-notifikation ignoreres af hjælpeteknologi |
| 3. Kurv / Checkout | Kurv-skuffe åben, linjeantal ændret, vare fjernet | Tastaturfælde i kurv-modal; fjern-knap mangler tilgængeligt navn |
| 4. Kundeoplysninger | Tom formular, delvist udfyldt, valideringsfejl | Manglende autocomplete-attributter (1.3.5); fejlbeskeder vises kun visuelt i rød tekst |
| 5. Leveringsvalg | Radioknapper for fragt, pakkeshop-vælger | Kortvisning af pakkeshop kan ikke betjenes med tastatur; radioknapper mangler gruppelabel |
| 6. Betalingstrin | Frem til betalingsvinduet (stoppunkt) | Tredjeparts-iFrames mangler titel; betalingsknapper uden tastaturfokus |
Fejlgrene testes systematisk
Et købsflow testes aldrig udelukkende med gyldige input (den såkaldte happy path).
Det er et krav i vores vurderingsmetode, at almindelige fejlforløb fremprovokeres bevidst:
- Indsendelse af en tom formular.
- Indtastning af ufuldstændigt postnummer eller ugyldig e-mailadresse.
- Forsøg på at gå videre uden at vælge en obligatorisk variant eller forsendelsesmetode.
Dette afgør, om sitet opfylder succeskriterium 3.3.1 Fejlidentifikation (at fejlen beskrives i tekst for hjælpeteknologier) og 3.3.3 Fejlretningsforslag (at brugeren får klar vejledning i, hvordan fejlen udbedres).
Risikofri test frem til betalingsstoppunktet
Testen afvikles med syntetiske testdata og følges præcist frem til betalingsstoppunktet: det øjeblik, hvor kunden skal indtaste egentlige betalingskortoplysninger i betalingsgatewayens vindue (fx hos Quickpay, Stripe, Nets, Klarna eller Shopify Payments).
Denne afgrænsning sikrer:
- Fuld sikkerhed: Jeres regnskab, lagerstyring og finansielle drift berøres overhovedet ikke, og der sker ingen håndtering af kortdata.
- Klar ansvarsfordeling: Der skelnes præcist mellem jeres eget tema-checkout og betalingsudbyderens eksterne modul.