Meer dan 94% van de e-commercesites heeft meetbare WCAG-toegankelijkheidsproblemen, terwijl de gemeenschap van mensen met een beperking een wereldwijde markt van $13 biljoen vertegenwoordigt. Deze gids biedt website-eigenaren, ontwikkelaars en compliance managers een concreet, praktisch stappenplan om hun online winkels in overeenstemming te brengen met WCAG 2.2 — van productpagina’s tot en met de checkout.

Stel je voor dat je tien minuten probeert online een verjaardagscadeau te kopen — om vervolgens vast te lopen in een dropdownmenu dat je schermlezer niet kan verwerken, of een afrekenformulier dat je toetsenbordfocus vasthoudt en niet meer loslaat. Voor de naar schatting 61 miljoen volwassenen met een beperking in de Verenigde Staten is dit geen hypothetisch scenario. Het is dagelijkse realiteit. En voor online retailers vertaalt dit zich direct in omzetverlies: onderzoek suggereert dat er jaarlijks $2.3 miljard aan online omzet verdampt door ontoegankelijke checkoutflows, terwijl 71% van de gebruikers met een beperking ontoegankelijke e-commercesites onmiddellijk verlaat in plaats van zich erdoorheen te worstelen.

Waarom toegankelijkheid in e-commerce niet langer optioneel is

De juridische en financiële inzet rond webtoegankelijkheid is nog nooit zo hoog geweest, en e-commerce ligt daarbij precies in de vuurlinie. Alleen al in 2024 werden 4.605 ADA-rechtszaken over websites aangespannen bij federale rechtbanken in de VS, waarbij de e-commercesector de zwaarste klappen kreeg — goed voor ongeveer 68–77% van alle zaken, afhankelijk van de bron. De trend versnelt: in de eerste helft van 2025 werden 2.014 rechtszaken over digitale toegankelijkheid aangespannen, een stijging van 37% ten opzichte van dezelfde periode in 2024, waardoor de sector op koers ligt om tegen het einde van het jaar meer dan 4.975 rechtszaken te overschrijden.

Schikkingen zijn ook niet triviaal. Typische regelingen variëren van $25.000 tot $75.000, plus advocaatkosten aan beide kanten en de kosten van de herstelwerkzaamheden die je eigenlijk in de eerste plaats had moeten doen. Nog confronterender: in 2024 werd bijna de helft van alle zaken aangespannen tegen bedrijven die al eerder waren aangeklaagd en hun sites niet grondig hadden hersteld. Eén keer schikken beschermt je niet tegen de volgende rechtszaak als de onderliggende code kapot blijft.

Ook wereldwijd wordt het regelgevend kader strenger. De European Accessibility Act (EAA) werd afdwingbaar op 28 juni 2025 en heeft betrekking op e-commerceplatforms die verkopen op EU-markten — met boetes tot €100.000 of 4% van de jaarlijkse omzet in sommige lidstaten. In de Verenigde Staten publiceerde het Department of Justice in april 2024 een definitieve regel die WCAG 2.1 Level AA formeel verplicht stelt voor websites van lokale en staatsoverheden, en hoewel private bedrijven nog niet met een bindende federale technische standaard worden geconfronteerd, gebruiken rechtbanken en het DOJ WCAG consequent als de facto referentie bij de beoordeling van ADA-claims. De beweging is onmiskenbaar: wachten op duidelijkere regelgeving is een strategie met hoog risico.

Naast juridisch risico staat er een enorme, onderbediende markt op het spel. Mensen met een beperking en hun families zijn goed voor naar schatting $13 biljoen aan wereldwijde economische activiteit, en alleen al het besteedbare inkomen van de wereldwijde gemeenschap van mensen met een beperking wordt geschat op $1.9 biljoen per jaar. Merken die toegankelijkheid prioriteren zien ook meetbare loyaliteitsvoordelen — één studie vond een 18% hogere klantretentie onder consumenten met een beperking die zich goed bediend voelden. Toegankelijkheid is geen liefdadigheid. Het is goed ondernemerschap.

WCAG begrijpen: de standaard die er echt toe doet

De Web Content Accessibility Guidelines (WCAG), ontwikkeld door het World Wide Web Consortium (W3C), vormen het internationaal erkende technische raamwerk voor digitale toegankelijkheid. Ze zijn georganiseerd rond vier kernprincipes — bekend onder het acroniem POUR: content moet Perceivable (waarneembaar), Operable (bedienbaar), Understandable (begrijpelijk) en Robust (robuust) zijn. Elk principe wordt opgesplitst in specifieke, testbare succescriteria.

De huidige versie, WCAG 2.2, werd gepubliceerd in oktober 2023 en voegt negen nieuwe succescriteria toe aan de vorige versie, terwijl volledige achterwaartse compatibiliteit behouden blijft. Als je voldoet aan WCAG 2.2, voldoe je automatisch aan WCAG 2.1 en 2.0. Voor de meeste e-commercebedrijven zou het doel Level AA-conformiteit moeten zijn — dit is de standaard waarnaar in vrijwel elk regelgevend kader wordt verwezen, waar rechtbanken naar kijken in ADA-procedures, en het niveau dat de breedste groep gebruikers daadwerkelijk bedient. Level A is het absolute minimum, en Level AAA is, hoe bewonderenswaardig ook, in de praktijk niet haalbaar voor de meeste complexe transactionele sites.

De negen nieuwe criteria van WCAG 2.2 hebben verschillende vereisten toegevoegd met directe, zwaarwegende implicaties voor online retail: minimale aanraakdoelgroottes (2.5.8), focusindicatoren die niet worden bedekt door sticky headers (2.4.11), het voorkomen van dubbele invoer in meerstaps-checkoutflows (3.3.7), toegankelijke authenticatie die niet leunt op cognitieve puzzels zoals complexe CAPTCHA’s (3.3.8), en consistente plaatsing van helpmechanismen op pagina’s (3.2.6). Dit zijn geen abstracte richtlijnen — ze sluiten direct aan op de frictiepunten die ervoor zorgen dat klanten hun winkelwagen verlaten.

De meest voorkomende toegankelijkheidsfouten op e-commercesites

Onderzoek laat consequent zien dat e-commercesites struikelen over een voorspelbare set problemen. Inzicht in deze faalpatronen is de eerste stap om je herstelwerk te prioriteren. Volgens het WebAIM Million-rapport 2026 blijft tekst met laag contrast het meest wijdverspreide probleem, nu aanwezig op 83.9% van de homepagina’s — tegen 79.1% een jaar eerder. De gemiddelde homepagina bevat nu 34 afzonderlijke gevallen van tekst met laag contrast. Dat betekent dat je sale-banner, je knoplabels, je prijskaartjes — een aanzienlijk deel van je klanten met een verminderd gezichtsvermogen kan ze waarschijnlijk simpelweg niet lezen.

Naast contrast ontdekte het Baymard Institute dat onder 33 e-commercesites met de hoogste omzet, beoordeeld op WCAG 2.1 AA: 82% toegankelijkheidsproblemen had met productafbeeldingen, 73% problemen met links, 64% problemen met toetsenbordnavigatie en 58% problemen met formulierveldmarkering. Dit zijn geen randgevallen — het zijn fundamentele onderdelen van de gebruikersreis van elke online winkel, van browsen tot kopen.

Dit zijn de foutcategorieën die het vaakst opduiken in zowel audits als ADA-rechtszaken tegen online winkels:

Ontbrekende of slechte alt-tekst bij productafbeeldingen: Schermlezers kondigen de bestandsnaam van de afbeelding aan of slaan deze volledig over als alt-tekst ontbreekt. Goede alt-tekst beschrijft wat de afbeelding daadwerkelijk laat zien — niet alleen “productafbeelding”, maar bijvoorbeeld “Donkerblauwe merinowollen trui met ronde hals, plat neergelegd op witte achtergrond”.
Ontoegankelijke formulierlabels en foutmeldingen: Elk invoerveld in je checkout moet een programmatisch gekoppeld <label>-element hebben. Foutmeldingen die alleen als rode tekst verschijnen — zonder tekstuele beschrijving — zijn onzichtbaar voor schermlezergebruikers en voldoen niet aan de kleurgebruikcriteria.
Toetsenbordvallen in modals en schuifpanelen: Winkelwagenoverlays, maatselecties en kortingsmodals die de toetsenbordfocus onderscheppen maar de gebruiker niet laten ontsnappen met de Escape-toets, vormen een veelvoorkomende en ernstige barrière. Een gebruiker die de modal niet kan verlaten, kan zijn aankoop niet afronden.
Interactieve elementen die niet met het toetsenbord te bedienen zijn: Carrousels, aangepaste dropdowns, stapelaars voor aantallen en zoomregelaars voor afbeeldingen die zijn gebouwd zonder ARIA-rollen en toetsenbordeventhandlers, bestaan simpelweg niet voor gebruikers die alleen een toetsenbord gebruiken.
Dynamische winkelwagenupdates die niet worden aangekondigd aan ondersteunende technologie: Wanneer een gebruiker een artikel aan de winkelwagen toevoegt en het winkelwagenaantal via JavaScript verandert zonder paginavernieuwing, merken schermlezers dit niet op, tenzij je dit expliciet aankondigt met een ARIA live-regio.
Onvoldoende aanraakdoelgroottes: WCAG 2.2 vereist dat interactieve elementen minstens 24×24 CSS-pixels zijn. Kleine “Toevoegen aan verlanglijst”-iconen, sluitknoppen op modals en kleurstalen voor varianten falen hier op mobiel regelmatig op.
Focusindicatoren die worden verborgen door sticky headers of overlappende content: Wanneer een gebruiker naar een link of knop tabt en de focusring verborgen is onder een persistente navigatiebalk of cookiebanner, kan die niet zien waar hij of zij zich op de pagina bevindt.

Een handige vuistregel: als je je volledige aankoopflow — van landingspagina tot orderbevestiging — niet uitsluitend met een toetsenbord en zonder muis kunt doorlopen, is je checkout niet toegankelijk.

Een pagina-voor-pagina toegankelijkheidsroadmap voor je winkel

Toegankelijkheid in e-commerce is niet één probleem — het is een verzameling specifieke, contextafhankelijke problemen die per paginatype verschillen. De meest effectieve herstelstrategie werkt de klantreis systematisch door, beginnend bij de gebieden met de grootste impact.

Product Listing Pages (PLP’s): Zorg dat filterbesturingselementen — selectievakjes, sliders, dropdowns — met het toetsenbord te bedienen zijn en zichtbare focusstaten hebben. Als filters resultaten dynamisch bijwerken, omhul dan de resultatenregio met een aria-live-regio zodat schermlezers aankondigen dat de productlijst is gewijzigd. Elke productkaartlink moet beschrijvende tekst hebben (niet alleen “Bekijk” of “Meer info”) en productafbeeldingen hebben betekenisvolle alt-tekst nodig.

Product Detail Pages (PDP’s): Variantselectoren (maat, kleur, materiaal) zijn een berucht faalpunt. Aangepast gestylede keuzerondjes of knoppen die als toggles worden gebruikt, hebben correcte ARIA-rollen en -staten nodig. Als je een maattabel in een modal gebruikt, moet die modal de focus correct beheren — deze binnen de dialoog vasthouden wanneer hij open is en terugbrengen naar het triggerelement wanneer hij wordt gesloten. Productvideo’s moeten ondertiteling hebben; audiobeschrijvingen zijn nodig wanneer betekenisvolle visuele informatie wordt overgebracht zonder gesproken toelichting.

Winkelwagen en mini-winkelwagen: Wanneer een gebruiker een artikel aan de winkelwagen toevoegt, moet de bevestiging worden aangekondigd aan schermlezers via een aria-live-regio met role='status' of role='alert'. Aantalregelaars moeten met het toetsenbord te bedienen zijn, en de knop “Artikel verwijderen” moet voor elke regel een unieke, beschrijvende toegankelijke naam hebben — niet simpelweg vier keer “Verwijderen” voor vier verschillende producten.

Checkoutflow: Dit is waar de zwaarste WCAG-overtredingen zich bevinden en waar de duurste rechtszaken ontstaan. Volgens het conformiteitsmodel van WCAG moet elke pagina in een proces voldoen — je kunt niet een toegankelijke productpagina en een ontoegankelijke betalingspagina hebben en toch claimen dat je voldoet. Belangrijke vereisten zijn: alle formulierinvoervelden moeten blijvende zichtbare labels hebben (niet alleen placeholdertekst, die verdwijnt zodra de gebruiker begint te typen), foutmeldingen moeten het specifieke veld identificeren en in tekst beschrijven wat er misging, autocomplete-attributen (autocomplete='email', autocomplete='cc-number', enz.) moeten aanwezig zijn om gebruikers met cognitieve en motorische beperkingen te helpen, en de volledige flow moet zonder muis te doorlopen zijn. WCAG 2.2 verbiedt ook dat gebruikers informatie opnieuw moeten invoeren die ze in dezelfde sessie al hebben opgegeven — dus als je checkout om een factuuradres vraagt nadat de klant net een verzendadres heeft ingevoerd, moet die informatie automatisch in te vullen zijn.

Accountlogin en registratie: Het criterium Accessible Authentication (3.3.8) van WCAG 2.2 betekent dat je gebruikers niet mag verplichten een cognitieve functietest op te lossen — zoals een standaardafbeeldings-CAPTCHA — als enige vorm van authenticatie. Bied alternatieven zoals magic links per e-mail, sms-codes of OAuth van derden. Als je toch CAPTCHA gebruikt, is een audio-alternatief het minimum, maar pleiten experts op het gebied van cognitieve toegankelijkheid ervoor om helemaal weg te bewegen van CAPTCHA ten gunste van minder belastende methoden.

Implementatie op codeniveau: hoe toegankelijke e-commerce er in de praktijk uitziet

Toegankelijkheid is uiteindelijk een codeprobleem, en abstracte richtlijnen brengen je maar tot op zekere hoogte. Dit is hoe correcte implementatie eruitziet voor enkele van de meest voorkomende e-commercepatronen.

Voor een skipnavigatielink (essentieel voor toetsenbordgebruikers die niet op elke pagina door je hele header willen tabben):

<a href='#main-content' class='skip-link'>Skip to main content</a>

<style>
  .skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 9999;
    text-decoration: none;
  }
  .skip-link:focus {
    top: 0;
  }
</style>

<main id='main-content' tabindex='-1'>
  <!-- your page content -->
</main>

Voor een winkelwagenupdate-aankondiging die schermlezers automatisch oppikken wanneer een artikel wordt toegevoegd:

<!-- Place this in your page HTML -->
<div
  role='status'
  aria-live='polite'
  aria-atomic='true'
  class='visually-hidden'
  id='cart-announcement'
></div>

<!-- Then in your JavaScript, after a cart update: -->
<script>
  function announceCartUpdate(message) {
    const region = document.getElementById('cart-announcement');
    region.textContent = '';
    // Force the browser to register the DOM change before updating
    requestAnimationFrame(() => {
      region.textContent = message;
    });
  }
  // Example usage:
  announceCartUpdate('Blue Linen Shirt added to cart. Cart now contains 3 items.');
</script>

Voor een WCAG 2.2-conforme focusindicator die voldoet aan de contrast- en groottevereisten:

<style>
  /* Remove browser default and replace with a strong custom indicator */
  :focus-visible {
    outline: 3px solid #0057b8;
    outline-offset: 3px;
    border-radius: 2px;
  }
  /* Ensure sticky header doesn't obscure focused elements (WCAG 2.4.11) */
  :focus {
    scroll-margin-top: 80px; /* match your header height */
  }
</style>

Voor correct gekoppelde formulierlabels en inline foutmeldingen in de checkout:

<div class='form-field'>
  <label for='email'>Email address <span aria-hidden='true'>*</span></label>
  <input
    type='email'
    id='email'
    name='email'
    autocomplete='email'
    aria-required='true'
    aria-describedby='email-error'
  />
  <span
    id='email-error'
    role='alert'
    class='error-message'
  ><!-- Populated by JS on validation failure --></span>
</div>

Testen: geautomatiseerde tools zijn een startpunt, geen eindpunt

Een van de gevaarlijkste misvattingen rond toegankelijkheidscompliance is dat geautomatiseerde scanners je kunnen vertellen of je site toegankelijk is. Dat kunnen ze niet. Geautomatiseerde tools kunnen ongeveer 30–40% van de WCAG-problemen detecteren — zaken als ontbrekende alt-attributen, duidelijke contrastfouten en ontbrekende formulierlabels. De overige 60–70% van de problemen vereist menselijk oordeel: beschrijft deze alt-tekst de afbeelding daadwerkelijk op een betekenisvolle manier? Is de leesvolgorde logisch wanneer je met een schermlezer navigeert? Is de foutmelding echt behulpzaam, of staat er alleen “ongeldige invoer”?

Een realistische teststrategie voor een e-commercesite gebruikt meerdere lagen. Begin met een geautomatiseerde scanner — tools zoals axe-core, WAVE of Lighthouse — die je draait op elk paginatemplate (PLP, PDP, winkelwagen, checkout, account). Dit brengt het laaghangende fruit snel in beeld. Voer vervolgens een sessie uit met alleen het toetsenbord: koppel je muis los en probeer een volledige aankoop te voltooien. Tab door alles heen. Probeer modals te openen en te sluiten. Probeer een winkelwagenaantal bij te werken. Probeer een kortingscode toe te passen. Als je ergens vastloopt, is dat een fout.

Test daarna met minstens één schermlezer. NVDA met Firefox en VoiceOver met Safari zijn de meest representatieve combinaties voor de meeste doelgroepen. Luister hoe je productpagina wordt aangekondigd. Geeft de schermlezer alle informatie door die een ziende gebruiker zou krijgen? Is de checkoutflow logisch wanneer die lineair wordt voorgelezen? Test ten slotte, en het meest waardevol, met echte gebruikers met een beperking. Geautomatiseerde tools en ontwikkelaarstests zullen altijd dingen missen die echte gebruikers tegenkomen door de specifieke manier waarop zij met ondersteunende technologie omgaan.

Voor voortdurende compliance moeten toegankelijkheidscontroles worden geïntegreerd in je CI/CD-pijplijn, zodat nieuwe code-deployments automatisch worden gescand voordat ze live gaan. E-commercesites veranderen voortdurend — nieuwe promoties, nieuwe productcategorieën, nieuwe checkoutstappen — en elke wijziging is een kans om nieuwe barrières te introduceren. Toegankelijkheid is een proces, geen eenmalig project.

De vraag rond overlay-widgets: wat je moet weten

Als je naar toegankelijkheidsoplossingen hebt gekeken, ben je vrijwel zeker overlay-widgets tegengekomen — JavaScripttools die beloven je site compliant te maken door een laag geautomatiseerde fixes bovenop je bestaande code te leggen. Sommige producten brengen dit op de markt als een oplossing van één regel. De werkelijkheid is complexer, en het risicoprofiel is aanzienlijk.

In 2024 werden meer dan 1.000 bedrijven aangeklaagd ondanks dat ze toegankelijkheidswidgets op hun websites hadden geïnstalleerd, goed voor meer dan 25% van alle ADA-zaken dat jaar. De reden is eenvoudig: overlays voegen een JavaScriptlaag toe bovenop kapotte HTML, maar schermlezers stuiten op de onderliggende toegankelijkheidsbarrières voordat de overlayscripts kunnen ingrijpen — als ze al ingrijpen. Overlay-widgets kunnen ook hun eigen toegankelijkheidsproblemen introduceren, waaronder modaldialogen die de focus vasthouden en functies die conflicteren met de eigen instellingen van de ondersteunende technologie van de gebruiker.

In januari 2025 verplichtte de Federal Trade Commission AccessiBe — een van de meest agressief vermarkte overlayproviders — om $1 miljoen te betalen om beschuldigingen te schikken dat het de mogelijkheden van zijn product om websites WCAG-compliant te maken, verkeerd had voorgesteld. Geen enkele rechtbank heeft een overlay-widget geaccepteerd als bewijs van ADA-compliance.

Dit betekent niet dat alle client-side toegankelijkheidstools waardeloos zijn. Een goed gebouwde toegankelijkheids-SDK — een die echte herstelwerkzaamheden op codeniveau aanvult in plaats van vervangt — kan echte waarde bieden: gebruikers een voorkeurenpaneel geven waarin ze contrast, lettergrootte of bewegingsinstellingen kunnen aanpassen; een toegankelijkheidsverklaring aanbieden met een duidelijk feedbackkanaal; en herstelwerk bieden in gebieden waar volledige code-toegang beperkt is (zoals bepaalde widgets van derden). Het onderscheid is enorm belangrijk: een tool die gebruikers assisteert en correcte herstelwerkzaamheden aanvult, is fundamenteel anders dan een tool die claimt deze te vervangen. Oplossingen zoals Accsible zijn met deze filosofie ontworpen — ze bieden een SDK die de gebruikerservaring verbetert voor bezoekers die aanpassingen nodig hebben, terwijl duidelijk wordt gemaakt dat echte compliance in de code is ingebouwd.

Een toegankelijkheidsprogramma opbouwen, niet alleen bugs fixen

Het meest robuuste pad naar WCAG-compliance — en het pad met de kleinste kans op herhaalde rechtszaken — is toegankelijkheid behandelen als een doorlopende organisatorische praktijk in plaats van een eenmalig technisch project. Herstel zonder procesverbetering is als water uit een lekkende boot scheppen zonder het gat te dichten.

Begin met het publiceren van een Accessibility Statement op je site. Deze pagina moet de standaard beschrijven waar je op mikt (WCAG 2.2 Level AA), de bekende beperkingen van je huidige implementatie, hoe gebruikers toegankelijkheidsbarrières kunnen melden en hoe snel je zult reageren. Dit toont goede wil, geeft gebruikers een manier om hulp te zoeken en is expliciet vereist onder de EU-wetgeving. Koppel dit aan een echt feedbackmechanisme — een e-mailadres of formulier dat daadwerkelijk iemand bereikt met de bevoegdheid om dingen te repareren.

Train je hele team, niet alleen ontwikkelaars. Designers die contrastverhoudingen en vereisten voor focusstaten begrijpen, zullen toegankelijke mockups maken. Contentmakers die weten hoe ze effectieve alt-tekst moeten schrijven, zullen velden niet langer leeg laten. Productmanagers die WCAG begrijpen, zullen zich verzetten wanneer een voorgestelde feature geen toetsenbordpad heeft. Verspreide toegankelijkheidskennis binnen een team is veel duurzamer dan één toegankelijkheidsspecialist die aan het eind alles probeert op te vangen.

Documenteer ten slotte je auditbevindingen, de toegepaste fixes en de testresultaten. Dit creëert een audittrail die intern waardevol is — om voortgang te volgen — en extern, als bewijs van inspanningen te goeder trouw als je ooit met een juridische uitdaging wordt geconfronteerd. Eén op de vier rechtszaken in 2024 betrof terugkerende gedaagden die waren aangeklaagd en geschikt zonder het probleem daadwerkelijk op te lossen. Een gedocumenteerd, uitgebreid herstelprogramma is je beste verdediging tegen dat scenario.

Belangrijkste punten

E-commerce is het primaire doelwit van rechtszaken over toegankelijkheid. Met ongeveer 70% van alle ADA-rechtszaken over digitale toegankelijkheid lopen online winkels het hoogste risico in het digitale landschap. Schikkingen lopen routinematig op tot $25.000–$75.000 plus herstelkosten, en een eerdere schikking beschermt je niet tegen latere zaken als de barrières blijven bestaan.
Richt je op WCAG 2.2 Level AA — daarmee dek je 2.1 en 2.0 automatisch af. WCAG 2.2 is achterwaarts compatibel, dus mikken op de nieuwste standaard geeft je de breedste juridische dekking in Amerikaanse rechtbanken, onder de Europese Accessibility Act en in de meeste andere rechtsgebieden wereldwijd.
Repareer eerst de aankoopfunnel. De checkoutflow — van winkelwagen tot orderbevestiging — is waar de risicovolste barrières zich bevinden en waar gebruikers met een beperking het meest geneigd zijn af te haken. Geef prioriteit aan toetsenbordtoegankelijkheid, formulierlabels, foutafhandeling en aankondigingen van dynamische content in elke checkoutstap.
Geautomatiseerde tools vangen slechts 30–40% van de WCAG-problemen. Vul geautomatiseerde scans aan met testen met alleen het toetsenbord, testen met schermlezers en sessies met echte gebruikers. Integreer toegankelijkheidscontroles in je CI/CD-pijplijn zodat nieuwe code geen regressies introduceert.
Toegankelijkheid is een programma, geen pleister. Train je designers, ontwikkelaars en contentteam. Publiceer een Accessibility Statement met een echt feedbackkanaal. Documenteer je herstelwerk. Bouw toegankelijkheid in je ontwikkelproces in zodat het opgelost blijft terwijl je winkel zich ontwikkelt.

E-commerce-toegankelijkheid: hoe u uw online winkel WCAG-conform maakt