EAA en uw checkout: praktische toegankelijkheidscheck

Een klant heeft een product gekozen, vult zijn gegevens in en loopt vast op een knop die alleen met een muis werkt. U ziet die gemiste bestelling meestal niet terug in Analytics. Voor een e-handelsdienst aan consumenten, zoals een webshop waarin op afstand een overeenkomst wordt gesloten, kan dit sinds 28 juni 2025 ook onder de European Accessibility Act (EAA) vallen.

De EAA is geen opdracht om iedere pagina cosmetisch op te poetsen. Kijk eerst naar de momenten waarop iemand een consumentenovereenkomst sluit: een product kiezen, configureren, reserveren, gegevens invullen, betalen en de bevestiging ontvangen. Kan iemand die stappen met toetsenbord, vergroting of schermlezer afmaken? Dan heeft u een bruikbaar vertrekpunt.

Begin bij de klantreis, niet bij een score

Een automatische scan is handig om fouten te vinden, maar hij vertelt niet of uw checkout werkt. Een scan ziet bijvoorbeeld niet altijd dat de toetsenbordfocus na het openen van een dialoogvenster verdwijnt, of dat een foutmelding pas zichtbaar wordt nadat een schermlezer er al overheen is gegaan.

Kies drie taken die een consumentenovereenkomst raken. Denk aan een bestelling plaatsen, een boeking afronden en een betaling bevestigen. Laat iemand elke taak uitvoeren met alleen het toetsenbord. Herhaal de test op 200% zoom en met een smalle viewport, zodat essentiële bediening niet buiten beeld of alleen via twee-dimensionaal scrollen bereikbaar is. Test waar mogelijk ook met een schermlezer. Leg per blokkade vast:

• de URL en de precieze stap;
• wat de gebruiker niet kan doen;
• hoe vaak die stap voorkomt en wie eigenaar is van de oplossing.

Zo krijgt u geen lijst met abstracte WCAG-codes, maar een herstelplanning die uw team kan uitvoeren.

Herstel de patronen die een transactie blokkeren

In veel projecten zitten de grootste problemen niet in de huisstijl, maar in hergebruikte componenten. Een modal, datumkiezer of formulierfout komt op tientallen plekken terug. Los de component op en controleer daarna elke flow die hem gebruikt.

Begin bij deze patronen:

• Een zichtbare focusstand en een logische tabvolgorde. Bezoekers moeten altijd zien waar zij zijn en nergens vastlopen.
• Labels die programmatisch aan invoervelden gekoppeld zijn, met duidelijke instructies en foutteksten. Kondig dynamisch toegevoegde fouten en statusmeldingen ook aan.
• Knoppen met een duidelijke naam. Een icoon zonder toegankelijke naam vertelt een schermlezer niets.
• Gebruik naast kleur altijd tekst of een ander duidelijk signaal bij statusmeldingen. Groen of rood alleen is voor een deel van de bezoekers onvoldoende.
• Bij een stap die een financiële transactie of juridische verplichting veroorzaakt: geef de klant een controle- of bevestigingsmogelijkheid, of een kans om fouten te corrigeren vóór definitief indienen.

WCAG 2.2 biedt hiervoor toetsbare technische criteria. Het is een goed werkkader voor ontwerp en ontwikkeling, maar geen automatische juridische uitspraak over uw specifieke dienst. Laat bij twijfel over de wettelijke reikwijdte of een uitzondering een jurist of toezichthouder meekijken.

De EAA vraagt om een gerichte scopecheck

De richtlijn noemt e-handelsdiensten expliciet: diensten die op afstand, via websites of diensten op mobiele apparaten, elektronisch en op individueel verzoek van een consument worden verleend met het oog op het sluiten van een consumentenovereenkomst. Dat betekent niet dat iedere informatieve bedrijfswebsite hetzelfde risico heeft. Een B2C-webshop of boekingsflow kan eronder vallen wanneer daarin zo'n overeenkomst wordt gesloten.

Voor micro-ondernemingen die diensten aanbieden bestaat in de richtlijn een uitzondering. Die definitie is smal: minder dan tien personen én een jaaromzet of een jaarlijks balanstotaal van ten hoogste €2 miljoen. Gebruik die uitzondering niet als reden om een klantreis niet te testen. Toegankelijkheidsproblemen blijven ook gewoon afhakers en extra support opleveren.

Maak toegankelijkheid onderdeel van uw releaseproces

Een eenmalige audit zakt snel weg als een nieuwe betaalprovider, cookiebanner of formuliertool de site verandert. Zet daarom eenvoudige acceptatiecriteria bij wijzigingen aan checkout, authenticatie en formulieren. Controleer bij oplevering ten minste de toetsenbordroute, foutafhandeling, zoom en de tekst van knoppen en meldingen.

Leg daarnaast vast wie beslissingen neemt. De producteigenaar bepaalt welke klanttaak voorrang heeft. De technische eigenaar bewaakt dat het component ook in volgende releases goed blijft werken. Bewaar testresultaten, herstelbesluiten en release-notities op één plek. Dat maakt een hertest na een grotere wijziging een stuk minder tijdrovend.

Een praktische aanpak voor deze maand

1. Breng in een uur de B2C-flow van eerste klik tot bevestiging in kaart.
2. Test de drie belangrijkste taken met toetsenbord, 200% zoom en een smalle viewport. Noteer blokkades, geen losse voorkeuren.
3. Groepeer de bevindingen per component en herstel eerst blokkades in checkout, boekingsflow en formulieren.
4. Laat dezelfde taken na de release opnieuw doorlopen en bewaar het resultaat.

Daarmee maakt u de toegankelijke checkout niet afhankelijk van één audit of één medewerker. U bouwt een werkwijze die ook bij de volgende wijziging nog werkt.

Bronnen

• Richtlijn (EU) 2019/882, art. 2 lid 2 onder h, art. 3, art. 4 lid 5 en art. 31
• Europese Commissie: European Accessibility Act
• W3C: Web Content Accessibility Guidelines 2.2

Plan na elke grotere wijziging in checkout, formulieren of betaling opnieuw een taakgerichte hertest.