WCAG 2.2: wat webshops en websites nú moeten doen om compliant te zijn

Geplaatst op door

WCAG 2.2: wat webshops en websites nú moeten doen om compliant te zijn – wcagtool.nl

WCAG 2.2: wat webshops en websites nú moeten doen om compliant te zijn

WCAG 2.2 brengt concrete eisen die direct invloed hebben op gebruiksvriendelijkheid en juridische toegankelijkheid van webshops en content-sites. Voor teams die dagelijks ontwerpen, bouwen en publiceren betekent dit: kleine veranderingen leveren grote winst voor bezoekers met beperkingen, en verkleinen het risico op klachten of claims.

Dit artikel geeft praktische, technische en redactionele acties die je vandaag kunt toepassen. Geen lange theorie — alleen duidelijke checks, codevoorbeelden en teststappen zodat designers, developers en redacties meteen aan de slag kunnen.

Wat betekent dit?

WCAG 2.2 voegt extra aandachtspunten toe of scherpt bestaande regels aan. Belangrijke thema’s voor webshops en content-sites zijn onder andere: zichtbare focusindicatoren, genoeg klik/tap-ruimte (target size), keyboard-toegankelijkheid, alternatieven voor drag-only interacties en toegankelijke authenticatie (inloggen/betalen). Deze elementen hebben directe impact op formulieren, navigatie, productpagina’s en checkout-stromen.

Mini-checklist: direct inspecteren

  • Kan je de site volledig bedienen met alleen toetsenbord (tab, enter, space, pijlen)?
  • Is de focus altijd goed zichtbaar, ook bij zoomen of op verschillende achtergrondkleuren?
  • Hebben interactieve elementen voldoende targetgrootte (mobiel en desktop touch targets)?
  • Is inloggen/checkout mogelijk zonder cognitieve of sensorische hindernissen (bijv. niet alleen patronen of reCAPTCHA zonder alternatief)?
  • Werken drag-and-drop functies ook via toetsenbord of alternatieve UI?

Waarom dit belangrijk is

Toegankelijkheid vergroot bereik, verlaagt supportverzoeken en voorkomt juridische risico’s. Voor webshops vertaalt toegankelijkheid zich vaak direct naar conversie: klanten die formulieren kunnen invullen, een overzichtelijke checkout en duidelijke knoppen kopen vaker.

Voor designers

  • Ontwerp focusstaten als onderdeel van het componentbibliotheek-ontwerp (niet ad-hoc).
  • Werk met ontwerpregels voor minimaal 44×44 CSS-pixels touch-area, en documenteer uitzonderingen met compensaties.

Voor developers

  • Voeg consistente focus-styling toe via CSS en gebruik semantische elementen (button, a) in plaats van divs met click-handlers.
  • Implementeer toetsenbord-ondersteuning en ARIA alleen daar waar noodzakelijk; voorkom overmatig of verkeerd gebruik.

Voor redacties

  • Schrijf duidelijke link- en knopteksten (geen “klik hier”) en verzorg alternatieve teksten voor afbeeldingen.
  • Houd formulierteksten en foutmeldingen kort, specifiek en machineleesbaar zodat schermlezers ze correct uitspreken.

Direct toepassen

Hier concrete code- en designinterventies die je meteen kunt implementeren.

Focus zichtbaar maken (CSS)

/* Basis focusstijl: toepasbaar op buttons en links */:focus{outline:3px solid #005a9c;outline-offset:2px;box-shadow:0 0 0 3px rgba(0,90,156,0.15);}/* Alternatief voor focus zonder outline (gebruik niet alleen kleur) */:focus:not(:focus-visible){outline:none;}

Touch/target grootte (CSS & pattern)

/* Zorg dat klikbare items minimaal 44x44 CSS pixels interactief zijn */.btn{min-width:44px;min-height:44px;padding:10px 14px;display:inline-flex;align-items:center;justify-content:center;}/* Indien visueel kleiner: voeg extra hit-area met pseudo-element */.icon{position:relative} .icon::after{content:'';position:absolute;inset:-10px;}

Toegankelijke button markup + keyboard

<button type="button" class="add-to-cart">In winkelwagen</button>/* Gebruik semantic button i.p.v. <div role="button"> voor ingebouwde keyboard support */

Formulieren & ARIA

<label for="email">E‑mail</label><input id="email" name="email" type="email" required aria-describedby="email-help"/><div id="email-help">We sturen een bevestiging naar dit adres.</div>

Gebruik aria-invalid en aria-describedby om foutmeldingen voor schermlezers te koppelen.

Hoe test je dat?

Gebruik een mix van geautomatiseerde tools en hands-on tests. Onze WCAG checker/validator pakt veel technische items maar geen volledige keyboard- of inhoudstoegankelijkheid. Volg deze stappen per pagina of component:

  1. Automatisch scannen: run onze WCAG checker en los prioriteit A/B-issues eerst op.
  2. Keyboard-only test: zet muis weg en navigeer, check tabindex-volgorde, focus-states en interactieve elementen.
  3. Screenreader test: test met NVDA (Windows) of VoiceOver (macOS/iOS) en controleer of labels, foutmeldingen en dynamische updates (aria-live) werken.
  4. Mobiel test: activeer 200%+ zoom en controleer reflow; test target sizes op echte apparaten en emulators.
  5. Accessibility walkthrough: laat iemand met beperkte mogelijkheden (of een collega die niet betrokken was bij de bouw) de checkout/proces doorlopen.

Korte testchecklist

  • Alle interactieve elementen zijn focusbaar en hebben logische volgorde.
  • Foutmeldingen worden voorgelezen bij submission zonder pagina-refresh.
  • Drag-only functies hebben toetsenbordalternatief of een andere UI.
  • Inloggen/checkout is mogelijk zonder visuele puzzels of patronen.

Wanneer is dit extra belangrijk?

Sommige pagina’s of momenten vereisen directe prioriteit: checkout, registratie, betaalpagina’s, zoek en filters, productconfigurators en belangrijke navigatie. Fouten op deze pagina’s hebben niet alleen toegankelijkheidsimpact maar direct conversieverlies en klantfrustratie.

Prioriteiten per team

  • Designers: focus en target-size regels in component library opnemen en UX-wijzigingen A/B testen met toegankelijkheid als KPI.
  • Developers: critical-path pages eerst updaten, daarna componentenbibliotheek uitrollen en regressietests toevoegen.
  • Redacties: content-items (CTA-teksten, alt-teksten, foutmeldingen) standaardiseren en reviewprocessen instellen.

Extra tools en resources

Gebruik onze WCAG checker/validator voor snel technisch inzicht, download onze plugin voor CI-integratie en lokale previews via wcagtool.nl/plugin. Voor hulp kun je altijd contact opnemen — ons team reageert binnen 24 uur.

Aanpak voor teams (kort)

  • Sprint 1: run checker op checkout & registratie, fix focus + keyboard issues.
  • Sprint 2: pas component library aan (buttons, forms, modal dialog gedrag).
  • Sprint 3: inhoudscheck door redactie + screenreader-test door QA.

Wil je een snelle scan? Gebruik de WCAG checker en installeer de plugin; wij kunnen ook een quick-audit uitvoeren en concrete backlog-items opleveren.

Praktische tip: documenteer elke uitzondering en fallback-actie in je component library (bijvoorbeeld wanneer een visueel kleiner icoon gebruikt wordt, beschrijf de extra hit-area en teststappen). Voor directe vragen — download onze plugin of stuur ons een bericht via het contactformulier; wij antwoorden binnen 24 uur.