Hoe u de 6 meest voorkomende WCAG-fouten op elke website kunt oplossen

Open een willekeurige website uit de top miljoen en de kans is 96 op 100 dat je een WCAG-schending vindt die een geautomatiseerde scanner in enkele seconden kan detecteren. Op één miljoen homepagina’s werden 56.114.377 afzonderlijke toegankelijkheidsfouten gedetecteerd — een gemiddelde van 56,1 fouten per pagina. Wat dit extra opvallend maakt, is dat 96% van alle gedetecteerde fouten in slechts zes categorieën valt, en die zes meest voorkomende fouttypen zijn de afgelopen zeven jaar hetzelfde gebleven. Dat betekent dat het oplossen van een handvol goed begrepen problemen de toegankelijkheid van het hele web drastisch zou verbeteren — en dat begint bij jouw site.

Waarom dezelfde zes fouten blijven terugkomen

Je vraagt je misschien af hoe het kan dat, in een tijdperk van geavanceerde ontwikkeltools en toenemende juridische controle, dezelfde fouten jaar na jaar op grote schaal blijven bestaan. Het antwoord is systemisch. Deze dichtheid aan fouten weerspiegelt hoe diep ontoegankelijkheid is ingebakken in webontwikkelpraktijken. Templateproblemen vermenigvuldigen zich over elke pagina. Componentfouten herhalen zich door hele sites heen. Zonder gerichte aandacht voor toegankelijkheid leveren standaard ontwikkelworkflows systematisch ontoegankelijke resultaten op.

Er is ook een vals gevoel van vooruitgang dat wordt gevoed door automatisering. Geautomatiseerd testen detecteert slechts 30–40% van de mogelijke WCAG-schendingen. Sites die geautomatiseerde tests doorstaan, kunnen nog steeds aanzienlijke problemen hebben met toetsenbordnavigatie, schermlezers of cognitieve toegankelijkheid. Dit betekent dat zelfs het kleine percentage sites dat op papier conform lijkt, in de praktijk waarschijnlijk tekortschiet.

De juridische inzet is reëel en neemt toe. Volgens Seyfarth Shaw werden in 2024 8.800 federale rechtszaken op basis van ADA Title III aangespannen, waarvan er ongeveer 2.452 specifiek gericht waren op webtoegankelijkheid. E-commercesites lopen een onevenredig groot risico — 77% van de rechtszaken over webtoegankelijkheid is gericht op online retail. Naleving is niet langer een nice-to-have. Het is een kwestie van bedrijfscontinuïteit.

De bemoedigende keerzijde? Deze concentratie heeft praktische implicaties. Organisaties kunnen het merendeel van hun toegankelijkheidsproblemen aanpakken door zich te richten op een handvol probleemtypen. Volledige WCAG-naleving vereist aandacht voor alle 78 criteria, maar de verbeteringen met de grootste impact komen van het oplossen van deze veelvoorkomende fouten. Laten we ze dus één voor één doornemen, met praktische oplossingen die je vandaag nog kunt implementeren.

Fout #1 — Tekst met te weinig contrast (WCAG 1.4.3)

Tekst met weinig contrast — tekst die onvoldoende kleurverschil heeft ten opzichte van de achtergrond — komt voor op 83,6% van de onderzochte homepagina’s. Dit is de meest voorkomende WCAG-schending en treft meer dan vier op de vijf websites. WCAG 1.4.3 (Contrast Minimum) is genadeloos eenvoudig: normale tekst moet een contrastverhouding van minimaal 4,5:1 hebben ten opzichte van de achtergrond, en grote tekst (18pt of 14pt vet) moet minimaal 3:1 halen.

Contrastfouten komen vaak voort uit ontwerpbeslissingen die esthetiek boven leesbaarheid stellen. Lichtgrijze tekst op een witte achtergrond ziet er verfijnd uit voor ontwerpers met perfect zicht. Voor gebruikers met een verminderd gezichtsvermogen, oudere gebruikers of iedereen die leest op een scherm met schittering, is het onleesbaar. Secundaire labels, formulierveld-placeholders, voettekst en uitgeschakelde knopstaten zijn de gebruikelijke boosdoeners — ze worden zo gestyled dat ze subtiel ogen en eindigen als onzichtbaar voor een aanzienlijk deel van je publiek.

De oplossing is bijna altijd een CSS-aanpassing. Laat je kleurparen door een contrastchecker lopen, zoals de contrasttool van WebAIM of het toegankelijkheidspaneel in de browser DevTools, en schuif vervolgens de voorgrond- of achtergrondwaarde bij totdat deze slaagt. Hier is een veelvoorkomend patroon dat faalt en hoe je het corrigeert:

/* Fout — verhouding ongeveer 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Correct — verhouding ongeveer 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Onthoud dat WCAG placeholdertekst als echte tekst beschouwt — niet als een decoratieve hint — dus die moet ook voldoen aan de drempel van 4,5:1. Vermijd het uitsluitend gebruiken van placeholdertekst om instructies over te brengen; combineer die altijd met een zichtbaar <label>-element. Als je afbeeldingen met tekst gebruikt, kun je het contrast niet met CSS oplossen — je moet die afbeeldingen opnieuw genereren, wat nog een reden is om live HTML-tekst te verkiezen boven tekst die in grafische bestanden is ingebakken.

Fout #2 — Ontbrekende alternatieve tekst voor afbeeldingen (WCAG 1.1.1)

Afbeeldingen zonder alternatieve tekst komen voor op 58,2% van de homepagina’s. Wanneer afbeeldingen geen alt-tekst hebben, krijgen schermlezergebruikers stilte of betekenisloze bestandsnamen te horen op plekken waar betekenisvolle inhoud zou moeten staan. Dit probleem is niet nieuw. Alt-tekst is sinds WCAG 1.0 in 1999 een fundamentele toegankelijkheidseis. Vijfentwintig jaar later slagen de meeste websites er nog steeds niet in om dit consequent te implementeren.

De reden dat het blijft bestaan, is een workflowkloof, geen kenniskloof. Dit foutpercentage wijst op systematische gaten in contentworkflows. Schrijvers en redacteuren weten vaak niet dat alt-tekst nodig is. Contentmanagementsystemen vragen er niet altijd om. Kwaliteitscontrole signaleert de afwezigheid niet. De oplossing heeft daarom twee lagen: een technische en een procesmatige.

Aan de technische kant heeft elke betekenisvolle afbeelding een alt-attribuut nodig dat dezelfde informatie overbrengt als de afbeelding zelf. Decoratieve afbeeldingen — puur visuele versieringen die geen informatie toevoegen — moeten een leeg alt="" krijgen zodat schermlezers ze volledig overslaan. Dit onderscheid goed maken is net zo belangrijk als het attribuut überhaupt toevoegen. Een groot percentage afbeeldingen heeft ontbrekende of onjuiste alt-tekst. Sommige betekenisvolle afbeeldingen hebben helemaal geen beschrijving, terwijl decoratieve afbeeldingen vaak als betekenisvolle content worden behandeld. Beide problemen doorbreken WCAG-conformiteit voor waarneembare content.

<!-- Betekenisvolle afbeelding: beschrijf wat deze overbrengt -->
<img src='team-photo.jpg' alt='Het Accsible-engineeringteam tijdens hun offsite in 2024 in Lissabon' />

<!-- Decoratieve afbeelding: lege alt, geen role nodig -->
<img src='wave-divider.svg' alt='' />

<!-- Gelinkte afbeelding: beschrijf de bestemming, niet de afbeelding -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='Bekijk prijsplannen' />
</a>

Aan de proceskant: werk je CMS-templates bij zodat het alt-veld verplicht is voor contentafbeeldingen, en train iedereen die assets uploadt. Geautomatiseerde tools zoals Accsible kunnen sitebreed afbeeldingen met ontbrekende of lege alt-tekst detecteren en je team een controleerbare lijst geven om systematisch af te werken.

Fout #3 — Ontbrekende labels voor formulierinvoer (WCAG 1.3.1, 3.3.2)

48,6% van de websites heeft ontbrekende labels voor formulierinvoer. Deze fout is bijzonder schadelijk omdat formulieren de plekken zijn waar gebruikers daadwerkelijk iets doen — zich inschrijven, afrekenen, contact opnemen, supportverzoeken indienen. Veel formulieren missen toegankelijke labels, vertrouwen uitsluitend op placeholders, maken instructies en foutmeldingen niet toegankelijk of ondersteunen geen uitsluitend toetsenbordgebruik. Omdat formulieren essentieel zijn voor de meeste digitale ervaringen, zorgen deze fouten voor ernstige bruikbaarheidsbarrières.

De meest voorkomende fout is het gebruik van placeholdertekst als vervanging voor een <label>. Placeholders verdwijnen zodra een gebruiker begint te typen, waardoor iedereen met een kortetermijngeheugenstoornis — of iemand die simpelweg wordt afgeleid halverwege het formulier — geen idee meer heeft waar het veld voor is. Schermlezers verschillen in hoe ze met placeholders omgaan, en geen van de benaderingen is zo betrouwbaar als een correcte labelkoppeling.

Het juiste patroon is het gebruik van een <label>-element dat aan de invoer is gekoppeld via overeenkomende for- en id-attributen. Als een zichtbaar label om ontwerpredenen niet mogelijk is, gebruik dan aria-label of aria-labelledby — maar grijp niet naar ARIA als je ook gewoon een <label> kunt gebruiken.

<!-- Correct: expliciete labelkoppeling -->
<label for='email'>E-mailadres</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Fout: alleen placeholder -->
<input type='email' placeholder='E-mailadres' />

<!-- Acceptabel wanneer het label visueel verborgen moet zijn -->
<label for='search' class='visually-hidden'>Doorzoek de site</label>
<input type='search' id='search' name='q' />

Foutmeldingen moeten ook programmatisch gekoppeld zijn. Wanneer een formulier valideert en een fout vindt, moet het bericht aan het veld worden gekoppeld met aria-describedby, en idealiter moet de focus naar het eerste ongeldige veld worden verplaatst. Formuliervalidatiefouten moeten efficiënt, intuïtief en toegankelijk zijn — de fout moet duidelijk worden geïdentificeerd, snelle toegang tot het problematische element moet worden geboden en de gebruiker moet de fout eenvoudig kunnen herstellen en het formulier opnieuw kunnen indienen.

Fout #4 — Lege links en knoppen (WCAG 2.4.4, 4.1.2)

44,6% van de websites heeft lege hyperlinks. Lege knoppen werden op bijna 30% van de pagina’s aangetroffen, en dit aantal is gestegen ten opzichte van het voorgaande jaar. Dat betekent dat blinde of slechtziende gebruikers het doel van knoppen zoals verzenden, resetten, filteren of zoeken niet zullen begrijpen. Samen vormen lege links en knoppen een van de meest frustrerende ervaringen voor schermlezergebruikers — interactieve elementen zonder naam tegenkomen is alsof je aan een deurklink trekt zonder label en zonder enig idee waar die naartoe leidt.

Lege links ontstaan meestal wanneer een icoon of afbeelding het enige kind is van een <a>-tag en er geen tekstalternatief is voorzien. Lege knoppen ontstaan wanneer knoppen die alleen uit een icoon bestaan — hamburgermenu’s, sluiticonen, knoppen voor delen op sociale media — geen toegankelijke naam hebben. Beide zijn eenvoudig te verhelpen.

<!-- Lege link — fout -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Opgelost met aria-label -->
<a href='/dashboard' aria-label='Ga naar dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Lege knop — fout -->
<button><svg>...</svg></button>

<!-- Opgelost met visueel verborgen tekst -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Menu sluiten</span>
</button>

Let op het aria-hidden='true' op de SVG in elk gecorrigeerd voorbeeld. Wanneer je een tekstalternatief biedt via aria-label of visueel verborgen tekst, wil je de SVG onderdrukken in de toegankelijkheidsboom — anders kunnen schermlezers zowel het label als de eigen titel of beschrijving van de SVG aankondigen, wat een verwarrende dubbele aankondiging oplevert. Onduidelijke linktekst — zinnen als "klik hier", "lees meer" of "meer info" — is een verwante fout. Andere hyperlinkproblemen, zoals onduidelijke linktekst, werden op bijna 14% van de homepagina’s aangetroffen, een stijging ten opzichte van het voorgaande jaar. Hyperlinks met correcte tekst zijn belangrijk zodat gebruikers weten waar een link hen naartoe brengt. De toegankelijke naam van elke link moet los van de context begrijpelijk zijn, omdat schermlezergebruikers vaak navigeren door een lijst van alle links op een pagina op te vragen.

Fout #5 — Ontbrekende documenttaal (WCAG 3.1.1)

Dit lijkt misschien een kleinigheid vergeleken met contrast of alt-tekst, maar ongeveer 16% van de pagina’s mist een ingestelde documenttaal — en de impact op schermlezergebruikers is direct en schokkend. Als een schermlezergebruiker het specifieke taalpakket heeft geïnstalleerd, wordt de content correct uitgesproken. Anders klinkt het als een slecht accent en is het mogelijk niet te begrijpen.

De oplossing is één enkel HTML-attribuut — letterlijk één regel code — en er is geen excuus om het weg te laten. Voeg het lang-attribuut toe aan je <html>-element met de juiste BCP 47-taalcode. Als delen van je pagina in een andere taal zijn dan de pagina als geheel, voeg dan ook een lang-attribuut toe aan die specifieke elementen.

<!-- Ontbrekend: geen lang-attribuut -->
<html>

<!-- Correct: Engelstalige pagina -->
<html lang='en'>

<!-- Correct: Franstalige pagina -->
<html lang='fr'>

<!-- Inline taalwissel binnen een pagina -->
<p>De Franse uitdrukking <span lang='fr'>joie de vivre</span> betekent een vrolijk genieten van het leven.</p>

Als je een CMS of static site generator gebruikt, moet het lang-attribuut in je basistemplate worden ingesteld. Controleer je template één keer, corrigeer het één keer, en elke pagina op je site is direct verbeterd. Dit is misschien wel de fix met de hoogste opbrengst per inspanning op deze hele lijst — één enkele templatewijziging elimineert het probleem op je hele domein.

Fout #6 — Ontoegankelijke toetsenbordnavigatie en focusbeheer (WCAG 2.1.1, 2.4.7)

Toetsenbordtoegankelijkheid is het gebied waar de kloof tussen geautomatiseerd testen en bruikbaarheid in de echte wereld het grootst is. Geautomatiseerde tools kunnen sommige toetsenbordfouten detecteren — zoals interactieve elementen die zijn gebouwd met niet-semantische tags — maar ze kunnen de tabvolgorde, focustrapping of de ervaring van het navigeren door een dropdownmenu met alleen pijltjestoetsen niet simuleren. Sites verwijderen vaak de standaard focusindicatoren zonder alternatieven te bieden, waardoor toetsenbordnavigatie vrijwel onmogelijk wordt. Dit treft niet alleen gebruikers met motorische beperkingen, maar ook iedereen die de voorkeur geeft aan toetsenbordnavigatie, power users en mensen die schakelapparaten gebruiken.

De meest voorkomende toetsenbordfouten zijn: aangepaste interactieve componenten die zijn gebouwd met <div>- of <span>-tags die nooit focus krijgen; CSS-regels die de standaard focusring van de browser verwijderen met outline: none of outline: 0 zonder die te vervangen door iets dat even goed zichtbaar is; modale dialogen die de focus niet vastzetten (waardoor toetsenbordgebruikers achter de overlay kunnen tabben); en carrousels of accordeons die niet zonder muis te bedienen zijn.

<!-- Aangepaste knop zonder toetsenbordtoegang — fout -->
<div class='btn' onclick='doSomething()'>Verzenden</div>

<!-- Correct: gebruik een echte knop -->
<button type='button' onclick='doSomething()'>Verzenden</button>

<!-- Focusstijlen verwijderen — schendt WCAG 2.4.7 -->
* {
  outline: none; /* doe dit nooit globaal */
}

<!-- Beter: focus zichtbaar stylen met behoud van esthetiek -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

De pseudo-class :focus-visible is hier je beste vriend. Die toont focusstijlen wanneer een gebruiker met het toetsenbord navigeert, maar onderdrukt ze bij muisklikken — zo krijg je een strak uiterlijk zonder toegankelijkheid op te offeren. Gebruik voor modals en drawers een utility voor focustrapping die de tabnavigatie beperkt tot de dialoog zolang die open is, en de focus terugzet naar het element dat de dialoog opende zodra deze sluit. Pop-ups verschijnen vaak zonder goed focusbeheer, zonder labels of zonder ondersteuning voor toetsenbordnavigatie. Dit veroorzaakt aanzienlijke verstoringen, vooral in kritieke gebruikersflows zoals aanmeldingen, logins en checkoutprocessen.

Kijk naast individuele componenten ook naar een skiplink — een visueel verborgen link die zichtbaar wordt bij focus en toetsenbordgebruikers in staat stelt om repetitieve navigatie over te slaan en direct naar de hoofdinhoud te springen. Skiplinks waarmee gebruikers repetitieve navigatie kunnen overslaan, ontbreken op de meeste sites. Het is drie regels HTML en een klein CSS-fragment, en het maakt een wereld van verschil voor iedereen die een contentrijke pagina met het toetsenbord navigeert.

<!-- Plaats dit als allereerste element binnen <body> -->
<a href='#main-content' class='skip-link'>Ga naar hoofdinhoud</a>

<!-- Dan in je CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Een opmerking over ARIA: gebruik het zorgvuldig

Veel teams grijpen naar ARIA (Accessible Rich Internet Applications)-attributen als snelle oplossing voor toegankelijkheidsgaten. De data suggereert dat dit vaker averechts werkt dan helpt. Ongeveer 79% van de geëvalueerde homepagina’s gebruikte ARIA, een stijging ten opzichte van het voorgaande jaar. Homepagina’s met ARIA hadden meer dan twee keer zoveel fouten als pagina’s zonder ARIA. ARIA zelf is niet het probleem — het is meestal verkeerd of onjuist gebruik van ARIA. Veel goedbedoelende ontwikkelaars denken dat ze content toegankelijker maken door ARIA toe te voegen, terwijl ze die in werkelijkheid vaak minder toegankelijk maken.

Het leidende principe is eenvoudig: gebruik eerst semantische HTML. Een <button> is beter dan een <div role='button'>. Een <nav> is beter dan een <div role='navigation'>. Native HTML-elementen worden geleverd met ingebouwd toetsenbordgedrag, focusbeheer en impliciete ARIA-rollen die je bij aangepaste markup handmatig moet repliceren — en juist bij die handmatige replicatie sluipen de fouten erin. Bewaar ARIA voor gevallen waarin HTML de semantiek die je nodig hebt echt niet kan uitdrukken, zoals live regions, complexe samengestelde widgets of dynamische statuswijzigingen.

Toegankelijkheid in je workflow inbouwen

Bestaande schendingen oplossen is noodzakelijk, maar voorkomen dat er nieuwe ontstaan is wat volwassen toegankelijkheidsprogramma’s onderscheidt van eenmalige compliance-inspanningen. Toegankelijkheid is geen eenmalige fix. Elke contentupdate, ontwerpwijziging of codedeploy kan nieuwe problemen introduceren. De zes foutcategorieën in deze gids zijn meestal template-niveauproblemen — los de header, footer en gedeelde componenten op en je elimineert het probleem in één keer op honderden pagina’s.

Integreer geautomatiseerde scans in je CI/CD-pijplijn zodat schendingen worden opgevangen voordat ze productie bereiken. Tools zoals axe-core kunnen worden ingebed in unit tests en end-to-end testsuites. Combineer dat met periodieke handmatige toetsenbordrondes en testen met schermlezers — VoiceOver op macOS en iOS, NVDA op Windows — omdat geautomatiseerd testen veelvoorkomende toegankelijkheidsfouten kan detecteren, maar handmatig testen helpt de gaten te vullen. Voor teams die een snellere instap nodig hebben, kan een toegankelijkheidsoverlay zoals Accsible een aanzienlijk deel van de problemen op het renderniveau zichtbaar maken en verhelpen, terwijl langetermijnoplossingen op codeniveau worden gepland en uitgerold.

Pak tot slot het grootste hefboompunt in je codebase aan: je templates. De meeste websites gebruiken templates — een header, footer, navigatie en paginalay-out die op elke pagina terugkomen. Problemen in deze templates vermenigvuldigen zich over je hele site. Los die als eerste op voor maximale impact. Eén gecorrigeerde basistemplate kan 10.000 WCAG-schendingen in één keer terugbrengen naar nul.

Belangrijkste inzichten

• Zes typen problemen domineren het landschap. Tekst met weinig contrast, ontbrekende alt-tekst, niet-gelabelde formulierinvoer, lege links en knoppen, ontbrekende documenttaal en kapotte toetsenbordnavigatie zijn verantwoordelijk voor het overgrote deel van de WCAG-schendingen. Het oplossen van deze zes categorieën levert een buitenproportioneel groot resultaat op in verhouding tot de inspanning.
• De meeste oplossingen zijn CSS- of HTML-wijzigingen van één regel. lang='en' toevoegen aan je <html>-tag, outline: none vervangen door :focus-visible-stijlen en labels koppelen aan invoervelden kosten uren werk, geen maanden — maar ze elimineren fouten die elke gebruiker met een beperking treffen die je site bezoekt.
• Templates zijn de plek met de grootste hefboomwerking. Toegankelijkheidsbugs in gedeelde componenten en paginatemplates worden over je hele site gerepliceerd. Controleer eerst je header, footer, navigatie en formulieren — wat je daar oplost, los je overal op.
• ARIA is een laatste redmiddel, geen eerste reactie. Sites die zwaar leunen op ARIA zonder een sterke basis van semantische HTML hebben doorgaans aanzienlijk meer toegankelijkheidsfouten, niet minder. Geef waar mogelijk de voorkeur aan native HTML-elementen.
• Geautomatiseerde scans detecteren minder dan de helft van de echte problemen. Vul je tooling aan met handmatige toetsenbordrondes en testen met schermlezers om de fouten te vinden die geen enkele scanner zal tonen, waaronder focustraps, problemen met logische tabvolgorde en dynamische content die wijzigingen niet aankondigt.