ARIA: bij 1 op de 3 websites gaat het mis
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
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 <div> terwijl een <button>-element dezelfde functionaliteit biedt, inclusief keyboard-support en screen reader-herkenning. Dit leidt tot een onnodig complexe code die minder robuust is.
Voorbeeld:
- Slecht: <div role='button' tabindex='0'>Klik mij</div>
- Goed: <button>Klik mij</button>
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.
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
| Check | Wat het meet | Waarom het belangrijk is |
|---|---|---|
| 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, 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
| Fout | Oplossing |
|---|---|
| role='button' op een <div> zonder keyboard-handlers | Gebruik een <button>-element |
| aria-expanded zonder toggle-functionaliteit | Implementeer JavaScript voor open/sluiten |
| aria-label die verschilt van zichtbare tekst | Zorg voor consistentie tussen label en visuele tekst |
| Geen tabindex op ARIA-elementen | Voeg tabindex='0' toe waar nodig |
| aria-hidden='true' op belangrijke content | Gebruik alleen op decoratieve elementen |
Wanneer is een professionele audit nodig?
Zelfs met de beste tools en kennis is het een grote uitdaging om alle elementen op orde te krijgen. Een professionele audit is nodig wanneer:
- Uw site complexe interactieve elementen bevat (webshops, configurators, live chats)
- U onder de EAA/WCAG valt en rechtszekerheid wilt
- U al 30-40% van de fouten heeft gefixt, maar de site nog niet volledig toegankelijk aanvoelt
Gratis scans zoals WCAG-checker zijn uitstekend voor het signaleren van basisproblemen, maar voor complexe ARIA-implementaties is menselijke expertise/ervaring onvermijdelijk. Dat geldt overigens niet alleen voor ARIA, maar voor alle onderdelen die meewegen voor digitale toegankelijkheid. We lichten ARIA hier uit omdat het gemiddeld de grootste bron van fouten is.
Conclusie
ARIA kan uw website toegankelijker maken, maar alleen als het zorgvuldig en bewust wordt toegepast. Begin altijd met native HTML en gebruik ARIA alleen waar nodig. Test grondig met zowel tools als echte gebruikers.
In de praktijk zien we dus dat het in heel veel gevallen veel beter moet. Want toegankelijkheid is niet vrijblijvend meer. De wet vereist een toegankelijk internet voor iedereen en de juiste toepassing van ARIA moet daar aan bijdragen.