De European Accessibility Act is op 28 juni 2025 in werking getreden. De meeste ecommerce-discussie over toegankelijkheid heeft zich gericht op WCAG 2.1 AA, de standaard waarnaar de EAA formeel verwijst. Maar WCAG 2.2, gepubliceerd door het W3C in oktober 2023, voegt negen nieuwe succescriteria toe die relevanter zijn voor ecommerce dan wat dan ook in 2.1.
WCAG 2.2 is nog niet wettelijk verplicht onder de EAA. De wet verwijst naar de oudere versie. Maar drie redenen maken het de moeite waard om er nu al aandacht aan te besteden.
Ten eerste: EN 301 549, de Europese technische standaard die de EAA gebruikt om compliance te definiëren, volgt W3C-updates. De huidige W3C-standaard is 2.2. Regelgevende normen volgen de trend. Nu bouwen naar 2.2 betekent dat je geen tweede compliancecyclus nodig hebt wanneer die afstemming formeel plaatsvindt.
Ten tweede: de nieuwe criteria pakken UX-fouten aan die extreem veelvoorkomend zijn op ecommerce-winkels specifiek. Ze zijn deels geschreven omdat het W3C ontdekte dat ecommerce-checkouts, productoverzichten en authenticatieflows gebruikers op terugkerende, systematische manieren in de steek lieten die WCAG 2.1 niet vastlegde. De criteria zijn niet abstract. Ze beschrijven dingen die je vrijwel zeker zelf hebt zien mislukken op jouw winkel of de winkels van jouw klanten.
Ten derde, en meest praktisch: de fixes voor de 2.2-criteria die voor ecommerce van belang zijn, zijn goedkoop. Dit zijn geen volledige herontwerpen. Het zijn CSS-minimumgroottes, invoervelden naast sliders, en vooraf ingevulde factuuradresgegevens. De implementatiekosten zijn dagen, niet maanden. Het commerciële voordeel (betere bruikbaarheid voor iedereen, niet alleen gebruikers met beperkingen) is onmiddellijk.
Dit artikel behandelt de vijf WCAG 2.2-criteria die de meeste fouten veroorzaken in ecommerce, hoe fouten er in de praktijk uitzien, en wat je moet repareren. Voor de volledige WCAG 2.1 AA-vereisten die de EAA wettelijk verplicht stelt, zie onze EAA-compliancegids voor ecommerce.
Wat er veranderd is van WCAG 2.1 naar WCAG 2.2
WCAG 2.2 heeft twee structurele wijzigingen aangebracht:
Negen nieuwe succescriteria toegevoegd. Vijf zijn op niveau A of AA (de niveaus die de EAA vereist). Vier zijn op niveau AAA (aspiratief, niet wettelijk verplicht). De tabel hieronder geeft de criteria die relevant zijn voor ecommerce:
| Criterium | Niveau | Wat het aanpakt |
|---|---|---|
| 2.4.11 Focusweergave | AA | Zichtbare focusindicatoren moeten minimale grootte en contrast hebben |
| 2.5.7 Sleepbewegingen | AA | Sleepinteracties moeten een alternatief met één aanwijzer hebben |
| 2.5.8 Doelgrootte (minimum) | AA | Interactieve doelen moeten minimaal 24×24 CSS-pixels zijn |
| 3.2.6 Consistente hulp | A | Hulpmechanismen moeten op elke pagina op dezelfde locatie verschijnen |
| 3.3.7 Redundante invoer | A | Gebruikers mogen niet worden gevraagd informatie opnieuw in te voeren die al is verstrekt |
| 3.3.8 Toegankelijke authenticatie (minimum) | AA | Authenticatie mag geen cognitieve tests vereisen zonder alternatieven |
Eén criterium verwijderd. 4.1.1 Parsing is verwijderd. Dit vereiste eerder geldige, schone HTML zodat ondersteunende technologie pagina’s correct kon verwerken. Het W3C verwijderde het omdat moderne browsers nu slordige HTML op een correcte manier verwerken. De foutmodus die het criterium moest voorkomen, treedt in de praktijk niet meer op.
De vijf criteria die het vaakst mislukken op ecommerce-winkels
Het volgende is gebaseerd op QuickScan-audits die ik op Nederlandse ecommerce-winkels heb uitgevoerd sinds WCAG 2.2 werd gepubliceerd. Dit zijn de fouten die ik in bijna elke audit vind.
1. Doelgrootte (2.5.8). De meest voorkomende fout
Wat het vereist: Elk interactief element moet minimaal 24×24 CSS-pixels zijn. Als een element kleiner is dan 24×24, moet er minimaal 24px afstand zijn tussen dat element en het dichtstbijzijnde andere interactieve element (zodat de afstand de kleine doelgrootte compenseert).
Waarom ecommerce faalt: Maatvariant-selectors. Filterchips op productoverzichtspagina’s. Hoeveelheid-plus en -min knoppen. Quick-add-iconen op productkaarten. In de Nederlandse ecommerce-winkels die ik auditeer, zijn deze elementen in desktop-CSS routinematig 16×16 of 18×18 pixels, en nog kleiner op mobiel wanneer percentage-breedte-layouts ze verder comprimeren.
De meest voorkomende boosdoener is de kleur/maat-variantselector op productdetailpagina’s. Een modewinkeltje dat negen maatopties in een horizontale strip toont, heeft vaak 16px vierkante taptargets. Gebruikers met motorische controleproblemen kunnen deze targets niet betrouwbaar tikken of klikken. Dat geldt ook voor veel mensen zonder beperking op mobiel, wat verklaart waarom hoge winkelwagenverlating op mobiele productpagina’s sterk correleert met kleine variantselectors.
De 24px-afstandsregel is een gedeeltelijke oplossing, maar vereist bewuste spatiëringsbeslissingen in CSS. Ze is niet automatisch. De meeste winkels met technisch kleine targets gebruiken ook strakke gridlay-outs die minder dan 24px ruimte laten tussen aangrenzende elementen.
Oplossing: Stel een minimale hoogte en breedte van 24px in op alle interactieve elementen in je basis-CSS. Voor het daadwerkelijke aanraakdoel in mobiele contexten ligt de bruikbaarheidsdrempel hoger: Apple HIG raadt 44×44px aan en Google Material Design 48×48px. Als je al 44×44px instelt op mobiel (wat je sowieso zou moeten doen voor CRO-redenen, los van toegankelijkheid), voldoe je automatisch ruimschoots aan de WCAG 2.2-vereiste.
/* Minimum om aan WCAG 2.2 te voldoen — waarschijnlijk al onder je bruikbaarheidsdoel */
.variant-selector,
.qty-button,
.quick-add {
min-width: 24px;
min-height: 24px;
}Auditmethode: open DevTools, inspecteer elke variantselector, filterchip en icoonsknop. Controleer de berekende breedte en hoogte. Markeer alles onder 24px.
2. Redundante invoer (3.3.7). Het factuuradresprobleem
Wat het vereist: Als een gebruiker informatie heeft verstrekt in een eerdere stap van een meerstapsproces, mogen ze niet worden verplicht dezelfde informatie opnieuw te verstrekken in een latere stap. Het systeem moet de informatie automatisch invullen, of de gebruiker moet een manier worden aangeboden om de eerder verstrekte waarde te selecteren.
Waarom ecommerce faalt: Factuuradres. In een standaard meerstapscheckout voert een gebruiker hun naam en verzendadres in bij stap 1. Bij stap 3 (betaling) krijgen ze een apart factuuradresformulier. Als het factuuradres hetzelfde is als het verzendadres, wat voor de meerderheid van aankopen geldt, is dubbele invoer een WCAG 2.2 Niveau A-fout.
Ik kom dit in twee vormen tegen in Nederlandse ecommerce-audits. De voor de hand liggende vorm: er bestaat helemaal geen optie “zelfde als verzendadres”, en gebruikers moeten hun volledige adres opnieuw typen. De minder voor de hand liggende vorm: de optie bestaat, maar staat niet standaard aangevinkt, en wanneer een gebruiker terug door de checkoutstappen navigeert en terugkeert naar de betaalpagina, gaat de selectie verloren en moet deze opnieuw worden aangevinkt.
Gedwongen adreshervoer is ook een conversieprobleem los van toegankelijkheid. Baymard’s checkout-onderzoek identificeert het als een bijdragende factor aan formulierverlatingen, met name op mobiel waar opnieuw typen meer moeite kost.
Oplossing: Toon een selectievakje “zelfde als verzendadres” bij de betaalstap, standaard aangevinkt. Wanneer een gebruiker door de checkoutstappen navigeert, sla deze selectie op in sessiestatus zodat die niet wordt gereset. Valideer dat dit werkt bij zowel voorwaartse navigatie (stappen 1→2→3) als achterwaartse navigatie (terugkeren naar stap 1 en opnieuw vooruit gaan).
In Shopify’s standaard checkout is dit standaard correct afgehandeld. De fout verschijnt het meest in aangepaste checkout-implementaties, headless-builds, of winkels die checkout-extensie-apps gebruiken die een apart factuurformulier injecteren.
3. Toegankelijke authenticatie (3.3.8): CAPTCHA in je checkout
Wat het vereist: Authenticatiestappen, inloggen, accountaanmaak, checkout-verificatie, mogen geen cognitieve functietest vereisen tenzij er een tweede mechanisme beschikbaar is. Een cognitieve functietest is alles wat een gebruiker vraagt objecten te herkennen, informatie te onthouden of puzzels op te lossen, inclusief het CAPTCHA-formaat “klik alle afbeeldingen met verkeerslichten”.
Waarom ecommerce faalt: Visuele en afbeeldingsgebaseerde CAPTCHA bij gastcheckout of accountaanmaak. reCAPTCHA v2-selectievakje (het “Ik ben geen robot”-selectievakje met optionele afbeeldingspuzzel) vereist technisch gezien cognitieve functie als de puzzel wordt geactiveerd. Veel winkels die Shopify of WooCommerce gebruiken, hebben beveiligingsapps geïnstalleerd die v2-selectievakje CAPTCHA bij checkout injecteren.
Een audio-CAPTCHA-alternatief voldoet aan de vereiste, maar audio-alternatieven ontbreken frequent, zijn slecht geïmplementeerd, of werken niet wanneer de visuele CAPTCHA wordt geïnjecteerd door een externe app.
Oplossing: Schakel over naar reCAPTCHA v3. Dit is de onzichtbare, scoregebaseerde versie die geen gebruikersinteractie vereist. Het detecteert bots door gedragspatronen te analyseren, niet door gebruikers te vragen objecten te identificeren. Het is nauwkeuriger dan v2 en volledig compliant met 3.3.8.
Als je niet kunt migreren naar v3, zorg dan dat een audio-alternatief beschikbaar en functioneel is. Test het: activeer de CAPTCHA-puzzel en klik op het audio-icoon. Controleer of het afspeelt, de transcriptie correct is, en de audio-uitdaging kan worden voltooid zonder de visuele puzzel.
Let op: als je Shopify Payments gebruikt, wordt de checkoutflow beheerd door Shopify en gebruikt standaard v3. Het probleem doet zich voor op accountaanmaakpagina’s, abonnementsapps, of aangepaste checkoutflows buiten Shopify’s beheerde checkout.
4. Sleepbewegingen (2.5.7). De prijsrangeslider
Wat het vereist: Elke functionaliteit die afhankelijk is van een sleepbeweging (klikken en vasthouden, dan bewegen) moet ook bedienbaar zijn met een actie met één aanwijzer die geen slepen vereist. Een enkele klik, enkel tikken, of een apart tekstinvoerveld zijn allemaal geldige alternatieven.
Waarom ecommerce faalt: Prijsrangesliders. Dit zijn de meest voorkomende sleepafhankelijke interactie op ecommerce-productoverzichtspagina’s. Een dubbele hendel-slider (minimale en maximale prijs) vereist dat de gebruiker klikt, vasthoudt en sleept om een prijsrange in te stellen. Er is geen standaard niet-sleep-alternatief tenzij de ontwikkelaar er expliciet een biedt.
Carrousels voor productafbeeldingen met sleep-naar-veeg-navigatie zijn een secundaire fout. Als de enige manier om de carrousel te laten doorgaan is deze te slepen, worden gebruikers die niet kunnen slepen uitgesloten. (Carrouselnavigatiepijlen voldoen aan de vereiste, dus dit is meestal een kleine aanpassing, maar pijlknoppen worden in mobiele carrouselimplementaties frequent verborgen of verwijderd.)
Oplossing: Voeg nummeropmaakvelden toe voor minimum- en maximumprijs naast elke rangeslider. De invoervelden moeten verbonden zijn met de slider: het wijzigen van het invoerveld werkt de sliderpositie bij, en vice versa. De meeste moderne filter-UI-bibliotheken ondersteunen dit standaard. Aangepaste sliders-implementaties moeten het expliciet toevoegen.
Voor carrousels: controleer of pijlnavigatie-knoppen aanwezig, zichtbaar en bedienbaar zijn via toetsenbord. Vertrouw niet uitsluitend op swipe-gebaren.
<!-- Prijsrange met niet-sleep-alternatief -->
<label for="prijs-min">Minimumprijs</label>
<input type="number" id="prijs-min" name="price_min" min="0" max="500" value="0">
<input type="range" aria-label="Minimumprijs" min="0" max="500" value="0">
<input type="range" aria-label="Maximumprijs" min="0" max="500" value="500">
<label for="prijs-max">Maximumprijs</label>
<input type="number" id="prijs-max" name="price_max" min="0" max="500" value="500">5. Focusweergave (2.4.11). De onderdrukte focusring
Wat het vereist: De toetsenbord-focusindicator moet zichtbaar zijn en aan minimale grootte- en contrastvereisten voldoen. Het gebied in focusstatus moet specifiek ten minste 3:1 contrastratio afwijken van de ongeconcentreerde staat, en de focusindicator moet het gefocuste onderdeel omringen met een omtrek van minimaal 2 CSS-pixels.
Waarom ecommerce faalt: Thema-basis-CSS. De meest voorkomende toegankelijkheidsfout in ecommerce-winkelthema’s is outline: none of outline: 0 globaal toegepast in de basisstijlpagina, vaak met een opmerking dat het is verwijderd voor “ontwerpconsistentie”. Dit verwijdert alle toetsenbord-focusindicatoren van elk interactief element op de site.
Zonder een focusindicator kan een toetsenbord- of schakelaargebruiker niet zien waar ze zich op de pagina bevinden. Ze kunnen je productfilters, je checkoutformulierenvelden of je betaalknoppen niet navigeren. De site is feitelijk onbruikbaar voor toetsenbordnavigatie.
Deze fout is ouder dan WCAG 2.2: WCAG 2.1 vereiste ook focuszichtbaarheid (criterium 2.4.7). Wat WCAG 2.2 toevoegt, is een specifiek minimum voor de grootte en het contrast van de indicator. Maar in de praktijk falen winkels die focusringen volledig hebben onderdrukt tegelijkertijd aan 2.1 en 2.2.
Oplossing: Verwijder alle globale outline: none of outline: 0 uit je basis-CSS. Vervang ze door een aangepaste focusstijl die voldoet aan het minimum van 3:1 contrast:
/* Verwijder dit — het onderbreekt toetsenbordnavigatie */
* { outline: none; }
/* Vervang door een zichtbare, hoog-contrast aangepaste focusindicator */
:focus-visible {
outline: 2px solid #005fcc; /* 4.5:1 contrast op witte achtergrond */
outline-offset: 2px;
}Gebruik :focus-visible in plaats van :focus. :focus-visible toont de focusring alleen wanneer de gebruiker navigeert via toetsenbord, niet wanneer ze met een muis klikken. Dit behoudt het visuele ontwerp voor muisgebruikers terwijl het toetsenbordnavigatie herstelt voor gebruikers die het nodig hebben.
Hoe je jouw winkel auditeert op WCAG 2.2
Geautomatiseerd testen (40% van de fouten): De Axe DevTools-browserextensie (gratis) voert een geautomatiseerde scan uit van elke pagina en markeert WCAG-fouten. Voer het uit op je homepage, een categoriepagina, een productpagina en je checkoutflow. Geautomatiseerde tests vangen contrastfouten, ontbrekende alt-tekst, ongeldig ARIA-gebruik en sommige focusindicatorfouten. Ze vangen geen doelgrootte-, sleepbeweging- of redundante invoerproblemen op: die vereisen handmatig testen.
Handmatige testchecklist voor WCAG 2.2:
- Meet alle variantselectors, filterchips en icoonskonppen met DevTools. Alles onder 24×24px is een 2.5.8-fout
- Navigeer handmatig door je checkout. Identificeer elk veld waar je wordt gevraagd informatie van een vorige stap opnieuw in te voeren
- Test je checkout-authenticatieflow. Activeer elke CAPTCHA, controleer of audio-alternatief aanwezig en functioneel is
- Identificeer alle sleepinteracties op productoverzichtspagina’s. Controleer of er voor elk een niet-sleep-alternatief is
- Verwijder je muis en navigeer je volledige checkout alleen via toetsenbord. Elke stap moet voltooibaar zijn via Tab, Enter en pijltoetsen
- Controleer je basis-CSS op
outline: none. Verwijder het en vervang het door aangepaste:focus-visible-stijlen
De WebAIM WCAG 2.2-checklist biedt een gestructureerd kader voor het uitvoeren van de volledige handmatige doorloop.
Hoe WCAG 2.2 past in je EAA-compliance
De EAA vereist wettelijk WCAG 2.1 AA. Als je nu pas begint met EAA-compliancewerkzaamheden, begin daar dan: de EAA-compliancegids voor ecommerce behandelt wat WCAG 2.1 in de praktijk vereist voor elk ecommerce-paginatype.
De vijf WCAG 2.2-criteria hierboven, met name 2.5.8 en 3.3.7, zijn het aanpakken waard zelfs voordat 2.2 formeel verplicht is, omdat ze UX-fouten oplossen die alle gebruikers treffen. Doelgrootte-fouten en dubbele factuuradresinvoer zijn conversieproblemen die verschijnen in sessieopnames en checkout-verlatingdata los van de context van beperking. Ze repareren verbetert je winkel voor iedereen.
De implementatiekosten voor alle vijf problemen zijn laag. In QuickScan-audits is de meest voorkomende bevinding dat de grootste toegankelijkheidsverbeteringen de kleinste ontwikkelingswijzigingen vereisen: een minimumgrootte in CSS, twee nummeropmaakvelden naast een slider, een standaard aangevinkt selectievakje, een CAPTCHA-bibliotheekswitch. Dit zijn uren werk, geen maanden. De barrière is gewoonlijk bewustzijn, geen complexiteit.