Checklist websitetoegankelijkheid voor kleine bedrijven en webshops

Stel u een klant voor die een schermlezer gebruikt. Ze vindt de sneakers die ze zoekt, kiest een maat en drukt op wat ze voor de winkelwagenknop houdt. Haar schermlezer zegt “knop”. Verder niets. Er staan er drie op de pagina en geen enkele heeft een naam, dus ze vertrekt, en u komt nooit te weten waarom.

Zo zien de meeste toegankelijkheidsproblemen op sites van kleine bedrijven eruit: onzichtbaar voor de eigenaar, een doodlopende weg voor de klant. Deze checklist is voor iedereen met een site op Shopify, WooCommerce, Wix of Squarespace zonder eigen ontwikkelaar.

Moet de website van mijn kleine bedrijf toegankelijk zijn?

Als u aan consumenten in de EU verkoopt, waarschijnlijk wel. De European Accessibility Act (opent in een nieuw tabblad), in Nederland omgezet via de Implementatiewet toegankelijkheidsvoorschriften producten en diensten, geldt sinds 28 juni 2025 voor e-commerce. De belangrijkste uitzondering geldt voor micro-ondernemingen die diensten leveren: bedrijven met minder dan 10 werknemers en een jaaromzet of jaarlijks balanstotaal van ten hoogste € 2 miljoen.

E-commerce betekent hier verkopen op afstand, via een website of app, “op individueel verzoek van een consument met het oog op het sluiten van een consumentenovereenkomst” (artikel 3, punt 30, van de richtlijn). Een webshop of boekingsmodule valt daaronder. De uitzondering geldt alleen voor diensten: wie producten verkoopt waarvoor de wet geldt, zoals e-readers, krijgt nog steeds met productregels te maken (artikel 4, lid 5). Buiten de EU gevestigd zijn helpt ook niet, want een Britse webshop die aan klanten in Frankrijk verkoopt, valt er voor die klanten onder (artikel 3, punt 4). Nationale wetten en boetes staan in onze gids over de European Accessibility Act.

De Britse Equality Act 2010 (opent in een nieuw tabblad) vraagt om redelijke aanpassingen voor mensen met een beperking, maar legt geen technische norm voor websites vast. In de Verenigde Staten zegt het ministerie van Justitie in zijn richtlijnen van maart 2022 (opent in een nieuw tabblad) dat bedrijven die open zijn voor het publiek ook hun online aanbod toegankelijk moeten maken, en dat normen zoals WCAG “nuttige richtlijnen bieden”. Wat de wet ook zegt: een klant die niet kan afrekenen, koopt niets.

Wat zijn de meest voorkomende toegankelijkheidsproblemen op websites?

Zes fouten overheersen. In de WebAIM Million 2026 (opent in een nieuw tabblad), een automatische scan van de 1 miljoen meestbezochte homepages in februari 2026, had 95,9% van de pagina's gedetecteerde WCAG-fouten, gemiddeld 56,1 per pagina. Tekst met te weinig contrast was het vaakst het probleem, op 83,9% van de homepages.

WCAG, de Web Content Accessibility Guidelines (in het Nederlands: Richtlijnen voor Toegankelijkheid van Webcontent), is de norm achter deze controles. De meeste wetten verwijzen naar niveau AA, en onze gids over WCAG 2.2 legt de nieuwste versie uit. Een aantal controles hieronder kan geen enkele scanner beoordelen.

Kan iedereen uw tekst lezen en uw afbeeldingen begrijpen?

Begin hier, want deze verbeteringen zijn goedkoop en grotendeels zelf te doen in de site-editor. Tekst heeft genoeg contrast nodig, afbeeldingen met informatie hebben alt-tekst nodig, en niets mag alleen op kleur leunen. Ongeveer 1 op de 12 mannen en 1 op de 200 vrouwen heeft een vorm van kleurenblindheid, volgens Colour Blind Awareness (opent in een nieuw tabblad).

• Contrast. Gewone tekst heeft een contrastverhouding van ten minste 4,5:1 (opent in een nieuw tabblad) met de achtergrond nodig, grote tekst ten minste 3:1. Test uw kleuren in een gratis contrastchecker, ook tekst over bannerfoto's. Onze gids over kleurcontrast laat oplossingen zien waarbij uw huisstijl overeind blijft.
• Alt-tekst bij producten. Beschrijf wat een koper moet weten: “Marineblauwe wollen trui met geribde rolkraag, vooraanzicht” is beter dan “productafbeelding 1”. Begin met uw tien bestsellers.
• Decoratieve afbeeldingen. Een sierlijke achtergrondkrul hoort een lege alt-tekst te hebben, zodat schermlezers hem overslaan. Sommige platforms vullen een leeg alt-veld met de bestandsnaam, dus controleer het uwe.
• Alleen kleur. “Uitverkocht” dat alleen als grijs kleurvlakje te zien is, of een verplicht veld dat alleen rood is gemarkeerd, bereikt niet iedereen. Bekijk de pagina met het grijstintenfilter van uw telefoon en voeg een woord of pictogram toe overal waar de betekenis verdwijnt.
• Zoomen. Bij 200% zoom in de browser moet tekst groter worden zonder te overlappen of te worden afgekapt, en het menu moet blijven werken.
• Paginataal. Elke gratis checker meldt een ontbrekende taalaanduiding. Dat lost u op met een thema-instelling of één regel in de template.

Is uw site met een toetsenbord te gebruiken?

Veel mensen surfen zonder muis: schermlezergebruikers, mensen met een tremor of beperkte handfunctie, en iedereen van wie het touchpad er net mee is opgehouden. Leg uw muis weg en druk op Tab. U moet elke link, knop en elk formulierveld in een logische volgorde bereiken, altijd zien waar u bent en nergens vast komen te zitten.

• Zichtbare focus. Een kader moet laten zien welk element actief is, en een vaste header of chatbubbel mag het niet afdekken (WCAG 2.2, 2.4.11 Focus niet bedekt). Veel thema's halen het kader om esthetische redenen weg; een ontwikkelaar kan het terugzetten.
• Geen vallen. Open het menu, de maatkiezer, pop-ups en de fotogalerij met het toetsenbord, kies iets en probeer er dan weer uit te komen. Escape moet pop-ups sluiten.
• Namen voor pictogrammen. Elke pictogramlink en -knop heeft een naam nodig die een schermlezer kan uitspreken, zoals “Winkelwagen, 2 artikelen”. Vervang “Klik hier” door woorden die zeggen waar de link naartoe gaat.
• Skiplink en koppen. Bij de eerste druk op Tab hoort bij voorkeur een link “Naar de inhoud” te verschijnen. In de schermlezerenquête van WebAIM uit 2024 (opent in een nieuw tabblad) zei 71,6% van de deelnemers dat ze een lange pagina eerst via de koppen verkennen, dus gebruik echte kopniveaus en geen vetgedrukte tekst.
• Aanraakgebieden. WCAG 2.2 vraagt om aanwijsgebieden van ten minste 24 bij 24 CSS-pixels, of genoeg ruimte eromheen (succescriterium 2.5.8 (opent in een nieuw tabblad)).

Komt iedereen door uw formulieren, winkelwagen en checkout?

Bij het afrekenen kosten toegankelijkheidsproblemen u direct geld, dus test het van begin tot eind, ook wat er gebeurt als er iets misgaat. Elk veld heeft een zichtbaar label nodig, foutmeldingen moeten het probleem in woorden uitleggen, en inloggen mag niet afhangen van geheugentests of puzzels. De pagina's van uw betaalprovider tellen ook mee.

• Labels, geen placeholders. Placeholdertekst verdwijnt zodra iemand typt en is vaak te licht om te lezen. Elk veld heeft een label nodig dat zichtbaar blijft.
• Foutmeldingen. Verstuur het formulier leeg. Elke fout moet uitgeschreven zijn (“Vul een postcode in, bijvoorbeeld 1012 AB”), naast het veld staan en worden voorgelezen, en niet alleen een rand rood kleuren.
• Vraag het niet twee keer. Bied “Factuuradres is hetzelfde” aan in plaats van mensen hun bezorgadres opnieuw te laten typen. WCAG 2.2 maakte dit een eis op niveau A: 3.3.7 Overbodige invoer.
• Inloggen. Laat mensen wachtwoorden en eenmalige codes plakken en wachtwoordmanagers gebruiken. Wie plakken blokkeert, voldoet niet aan het WCAG 2.2-criterium voor toegankelijke authenticatie (opent in een nieuw tabblad), tenzij er een andere manier is om in te loggen.
• CAPTCHA's. Schermlezergebruikers noemden de CAPTCHA in de WebAIM-enquête van 2024 het lastigste onderdeel van het web. Hebt u botbescherming nodig, vermijd dan visuele puzzels en bied altijd een niet-visueel alternatief.
• Tijdslimieten. Verloopt een winkelwagen of reservering, waarschuw mensen dan en laat ze de tijd verlengen.

Horen delen van de checkout bij uw platform of betaalprovider, test ze dan toch, meld de fouten en vermeld ze als bekende problemen.

En cookiebanners, pop-ups en chatwidgets?

Voor uw klanten horen scripts van derden gewoon bij uw website. Een cookiebanner die niet met het toetsenbord te sluiten is, blokkeert elke pagina, en een nieuwsbriefpop-up die midden in het afrekenen de focus pakt, kan een verkoop kosten. Test elk script en elke plug-in die u hebt toegevoegd, en vraag leveranciers naar toegankelijkheid voordat u iets nieuws installeert.

• Cookiebanner. Kunt u accepteren en weigeren met Tab bereiken, beide lezen bij 200% zoom en daarna verdergaan waar u was?
• Pop-ups. De focus moet naar de pop-up gaan, daar blijven tot hij sluit en dan terugkeren. Escape moet hem sluiten.
• Chatwidgets. De knop heeft een naam nodig, het venster moet met het toetsenbord open en dicht kunnen, en op een telefoon mag het niet over “Nu betalen” heen liggen.
• Carrousels. Alles wat langer dan vijf seconden automatisch beweegt, moet te pauzeren, te stoppen of te verbergen zijn (WCAG 2.2 (opent in een nieuw tabblad), succescriterium 2.2.2).
• Embeds. Reviewwidgets, kaarten en boekingstools staan ook op uw pagina. Meld fouten bij de leverancier.

Werken uw video's, pdf's en menukaarten voor iedereen?

Video heeft ondertiteling nodig, audio een transcript, en belangrijke informatie hoort niet alleen in een pdf of afbeelding te staan. Een restaurant met een ingescande pdf als menukaart, of een webshop met een foto van een tabel als maatgids, sluit schermlezergebruikers buiten en iedereen die op een telefoon moet inzoomen.

• Ondertiteling en transcripten. Corrigeer automatische ondertitels voordat u publiceert. Podcasts hebben een tekstversie nodig.
• Afbeeldingen van tekst. Zet menukaarten, prijslijsten, maattabellen en openingstijden op een gewone webpagina. Moet het per se een pdf zijn, exporteer die dan met koppen en tags uit uw tekstverwerker in plaats van een afdruk in te scannen.
• Oudere bestanden. De EAA verplicht u niet om kantoorbestanden of vooraf opgenomen audio en video aan te passen die vóór 28 juni 2025 zijn gepubliceerd, of archieven die u niet meer bijwerkt (artikel 2, lid 4). Nieuwe bestanden vallen er wel onder.

Wat kan ik zelf oplossen, en wanneer heb ik een ontwikkelaar of audit nodig?

De meeste inhoudsproblemen lost u zelf op in het CMS: alt-tekst, koppen, linkteksten, kleuren, ondertiteling en veel formulierlabels. Problemen op themaniveau, zoals ontbrekende focusstijlen, toetsenbordvallen en zelfgebouwde uitklapmenu's, vragen om een ontwikkelaar. Een audit heeft het meeste zin als de basis op orde is, of voordat een herontwerp live gaat.

Welke rol speelt een widget zoals de onze? Met een paneel voor bezoekers zoals SiteAccessible kunnen mensen het contrast verhogen, tekst vergroten of een leeshulp aanzetten. Dat helpt sommige bezoekers, maar het vinkt niets af op deze checklist: een knop zonder naam blijft naamloos en een toetsenbordval blijft een val. Breng eerst de site op orde en zie een widget als extraatje.

Hoe leg ik vast wat ik heb gedaan?

Houd een eenvoudig logboek bij van wat u wanneer hebt getest, wat u hebt opgelost en wat nog niet werkt, en publiceer een eerlijke samenvatting in een toegankelijkheidsverklaring. Geldt de EAA voor u, dan moet u ook informatie publiceren over hoe uw dienst aan de toegankelijkheidseisen voldoet, meestal in uw algemene voorwaarden of een gelijkwaardig document.

Die tweede plicht komt uit bijlage V van de richtlijn; de nationale wet bepaalt de vorm. Onze gids voor het schrijven van een toegankelijkheidsverklaring bevat een sjabloon dat u kunt aanpassen. Maak er daarna een vaste routine van:

1. Loop de checklist door op uw drie belangrijkste pagina's en maak van elke fout een screenshot.
2. Los de inhoudspunten deze week zelf op.
3. Geef een ontwikkelaar de punten over thema en checkout door, de ergste eerst.
4. Test elke oplossing opnieuw, met een toetsenbord en met een checker.
5. Publiceer of actualiseer uw verklaring, met datum.
6. Herhaal dit telkens als u een app toevoegt, van thema wisselt of een nieuwe landingspagina lanceert.