# ARIA: bij 1 op de 3 websites gaat het mis Bron: https://wcag-checker.nl/blog/aria-bij-1-op-de-3-websites-gaat-het-mis Gepubliceerd: 2026-07-31 Leestijd: 12 minuten ARIA is krachtig, maar bij 1 op de 3 websites zorgt het juist voor onbereikbaarheid. Lees wat ARIA is, waarom het misgaat en hoe u dat herstelt. Veel mensen hebben er wellicht nog nooit van gehoord, of moeten denken aan de opera: ARIA. In potentie een redder in nood voor complexe webapplicaties, maar in de praktijk is het vaak de oorzaak van net datgene wat u probeert te voorkomen: onbereikbaarheid. ARIA is een krachtig gereedschap, maar zoals elk krachtig gereedschap kan het net zo makkelijk schade toebrengen. Vergelijk het met een apparaat in de sportschool waarvan bijna niemand weet hoe het goed gebruikt moet worden. In dit artikel duiken we in de wereld van ARIA: wat is het, waarom bestaat het, hoe kunt u problemen signaleren en verbeteren en welke elementen uit de WCAG-checker helpen u om te controleren of u op de goede weg bent. ARIA staat voor Accessible Rich Internet Applications. Het is een specificatie die werd ontwikkeld door het World Wide Web Consortium (W3C) via hun Web Accessibility Initiative (WAI). De eerste versie van ARIA werd gepubliceerd in 2014 als een World Wide Recommendation (ARIA 1.0), met daarvoor al een werkversie vanaf 2010. ## De ARIA-tijdlijn - **1999** — WCAG 1.0 verschijnt (geen ARIA) - **2004** — ARIA-werkgroep gestart bij W3C - **2010** — ARIA 1.0 werkkader - **2014** — ARIA 1.0 als Recommendation gepubliceerd - **2018** — ARIA 1.1 gelanceerd - **2023** — ARIA 1.2 in ontwikkeling - **Heden** — ⅓ van websites heeft ARIA-problemen Het doel van ARIA was duidelijk: het web evolueerde snel van statische pagina's naar dynamische webapplicaties. Traditionele HTML kon deze nieuwe interactieve componenten niet voldoende ondersteunen voor gebruikers van schermlezers en andere hulpmiddelen. Denk aan drag-and-drop interfaces, live-updates, sliders, tabbladen en modale dialoogvensters. Zonder extra informatie zouden deze elementen onzichtbaar of onbegrijpelijk blijven voor mensen die afhankelijk zijn van toegankelijkheidstechnologie. ARIA biedt dus een set aan code die ontwikkelaars kunnen toevoegen aan HTML-elementen. Deze attributen geven extra informatie aan assistieve technologieën, zodat ze kunnen communiceren wat een element is, hoe het zich gedraagt en welke status het heeft. De motivatie achter ARIA was om een brug te slaan tussen de rijkdom van moderne webinterfaces en de behoeften van mensen met een beperking. Het is een aanvulling op HTML om toegankelijkheid te vergroten. ## Toch gaat het in de praktijk vaak mis ARIA is ontwikkeld om dynamische, interactieve elementen toegankelijk te maken voor gebruikers van schermlezers. Denk aan sliders, tabbladen, modale dialoogvensters en live-updates. Zonder ARIA zouden deze elementen voor veel mensen onzichtbaar of onbegrijpelijk blijven. Maar hier schuilt een gevaar: ARIA is geen magie. Het lost geen HTML-problemen op. Sterker nog: het kan bestaande problemen verergeren als het zonder inzicht wordt toegepast. Vanaf hier gaat dit artikel ook technisch worden. Helaas wordt ARIA niet geleverd in hapklare brokken informatie die gemakkelijk uit te leggen is. Dat is waarschijnlijk ook de oorzaak van de vele problemen. Uit onze eigen metingen bij wcag-checker.nl blijkt dat ARIA bij 36,8% van ruim 2.000 gescande websites te laag scoort. Omdat een geautomatiseerde QuickScan niet alles kan detecteren, zoals keyboard-gedrag dat alleen bij handmatige tests aan het licht komt en de elementen die interactie nodig hebben om te testen, ligt het werkelijke percentage vermoedelijk hoger, naar schatting tussen de 50 en 60%. ARIA wordt dus vaak toegepast, maar lang niet altijd op de juiste manier. Er zijn drie terugkerende patronen die leiden tot toegankelijkheidsproblemen: ### 1. Overmatig gebruik van ARIA waar HTML voldoende is Veel ontwikkelaars voegen role='button' toe aan een
terwijl een ### 2. Ontbrekende keyboard-navigatie ARIA definieert semantiek, maar niet gedrag. Als u aria-expanded='true' toevoegt aan een menu, moet dat menu ook daadwerkelijk met het toetsenbord te openen en sluiten zijn. Veel developers vergeten dit aspect. ### 3. Verkeerde of ontbrekende statussen en properties Een slider zonder aria-valuenow, aria-valuemin en aria-valuemax is voor een schermlezer niets meer dan een statisch plaatje. Of nog erger: een aria-label die de context verkeerd beschrijft. ![Illustratie van ARIA-problemen: code met onjuiste rollen en een waarschuwingsicoon](/blog-aria-problemen.jpg) *ARIA is krachtig, maar bij 1 op de 3 websites zorgt het juist voor onbereikbaarheid.* ## Hoe signaleert u ARIA-problemen? Gelukkig zijn er tools die u kunnen helpen om ARIA-fouten op te sporen. Onze WCAG-checker neemt ARIA automatisch mee bij de toegankelijkheidsanalyse: ### Elementen uit de WCAG-checker voor ARIA-controle | ARIA-attributen op afbeeldingen | Controleert of afbeeldingen een alternatief hebben via aria-label, aria-labelledby, role="presentation/none" of aria-hidden="true" | Decoratieve afbeeldingen kunnen worden genegeerd; informatieve afbeeldingen krijgen alsnog een bruikbare naam | | ARIA als formulierlabel, knop- of linktekst | Detecteert invoervelden, knoppen en links zonder zichtbaar label, maar mét een aria-label | Zorgt dat schermlezers de bedoeling van interactieve elementen kunnen voorlezen | | Geldigheid van ARIA-attributen | Controleert of gebruikte aria-* attributen bestaan en geen lege waarden hebben | Voorkomt dat hulpmiddelen onbekende of lege instructies negeren | | Focusvolgorde (tabindex) | Signaleert positieve tabindex-waarden die de logische tabvolgorde doorbreken | Zorgt dat toetsenbordgebruikers in de verwachte volgorde door de pagina gaan | ## Praktische stappen voor betere ARIA-toepassing ### Stap 1: Evalueer of ARIA echt nodig is Vraag uzelf af: "Kan ik dit met standaard HTML oplossen?" Als het antwoord ja is, gebruik dan HTML. Pas als dat niet kan, ga dan verder met ARIA. ### Stap 2: Volg de WAI-ARIA Authoring Practices De [WAI-ARIA APG](https://www.w3.org/WAI/ARIA/apg/), een richtlijnendocument van het W3C, biedt gedetailleerde richtlijnen voor elk type interactief component. Gebruik deze als blauwdruk voor uw implementatie. ### Stap 3: Test met meerdere tools Gebruik zowel geautomatiseerde scanners (zoals axe DevTools, WAVE en WCAG-checker) als handmatige tests met schermlezers (NVDA, VoiceOver, JAWS). ### Stap 4: Test met het toetsenbord Navigeer door uw site zonder muis. Alle interactieve elementen moeten bereikbaar en bedienbaar zijn via Tab, Enter, Space en pijltjestoetsen. ### Stap 5: Documenteer uw keuzes Leg vast waarom u bepaalde ARIA-attributen heeft gekozen. Dit helpt bij toekomstige onderhoud en audits. ## Veelgemaakte fouten | role='button' op een
zonder keyboard-handlers | Gebruik een