Wat zijn ARIA-attributen? WAI-ARIA eenvoudig uitgelegd

ARIA staat voor Accessible Rich Internet Applications. Het is een set HTML-attributen, door het W3C gestandaardiseerd als WAI-ARIA (actuele versie 1.2, gepubliceerd in juni 2023), die hulptechnologie zoals schermlezers extra informatie geeft over elementen in de interface. ARIA wordt nodig waar de semantiek van native HTML ophoudt: een tabinterface, een accordion, een zelfgebouwde dropdown of een statusmelding die dynamisch verschijnt. Het vocabulaire bestaat uit drie bouwstenen: roles beschrijven wat een element is, states beschrijven de huidige toestand, en properties beschrijven eigenschappen en relaties. ARIA is tegelijk krachtig en gevaarlijk. Correct gebruikt maakt het complexe widgets bruikbaar voor schermlezergebruikers, verkeerd gebruikt sloopt het de toegankelijkheid actief, en juist daarom luidt de belangrijkste regel van ARIA dat je native HTML-elementen verkiest zodra die het werk aankunnen.

Waar staat ARIA voor en waarom bestaat het?

HTML heeft rijke ingebouwde semantiek: een button wordt aangekondigd als knop, een nav is een navigatie, een aangevinkte checkbox meldt zijn toestand vanzelf. Schermlezers lezen dit allemaal uit de accessibility tree die de browser uit je markup opbouwt. Het probleem begint bij alles waar HTML geen element voor heeft. Er is geen native tabpaneel, geen accordion, geen toastmelding. Ontwikkelaars bouwen die uit divs en spans, en voor een schermlezergebruiker is een accordion van divs simpelweg stilte: geen naam, geen rol, geen toestand.

WAI-ARIA vult precies dat gat. Je vertelt hulptechnologie wat je zelfgebouwde widget is en wat die doet, zonder iets te veranderen aan hoe de pagina er voor de rest uitziet of zich gedraagt.

Roles, states en properties: de drie bouwstenen van ARIA

• Roles bepalen wat een element is. role="dialog", role="tablist", role="alert". Een role is een belofte aan de gebruiker: dit ding gedraagt zich als een dialoogvenster.
• States beschrijven de huidige, veranderlijke toestand van een element. aria-expanded="true", aria-checked="false", aria-disabled="true". States veranderen terwijl de gebruiker bezig is, en je JavaScript moet ze bijhouden.
• Properties beschrijven eigenschappen en relaties die zelden veranderen. aria-labelledby verwijst naar het element dat dit element een naam geeft, aria-controls verwijst naar het element dat dit element bedient, aria-required markeert een verplicht veld.

Het onderscheid tussen states en properties is in het dagelijks werk academisch, het zijn allebei gewoon attributen. Het mentale model dat wel telt: role zegt wat iets is, al het andere zegt hoe het heet, wat het doet en waar het bij hoort.

De eerste regel van ARIA: gebruik geen ARIA

Het W3C-document Using ARIA opent met een regel die als een grap klinkt maar bloedserieus is: bestaat er al een native HTML-element met de semantiek en het gedrag dat je nodig hebt, gebruik dat dan in plaats van een ander element te herbestemmen en er ARIA op te plakken. Vergelijk deze twee manieren om een knop te bouwen:

<!-- Ziet eruit als een knop voor ziende gebruikers, is een dode div voor alle anderen -->
<div class="btn" onclick="save()">Opslaan</div>

<!-- Alles inbegrepen: rol, toetsenbordondersteuning, focus -->
<button type="button" onclick="save()">Opslaan</button>

Om de div-variant te repareren heb je role="button", tabindex="0" en extra JavaScript voor Enter en spatie nodig. Het native element doet dat allemaal gratis, en blijft het doen in browsers die je nooit hebt getest. Dezelfde logica geldt voor links, checkboxes, formuliervelden en koppen.

Achter deze regel zit een ontnuchterend cijfer. WebAIM analyseert jaarlijks de homepages van het miljoen grootste sites, en de rapporten vinden telkens dat pagina's met ARIA gemiddeld méér gedetecteerde toegankelijkheidsfouten hebben dan pagina's zonder. Niet omdat ARIA slecht is, maar omdat het zo vaak verkeerd wordt toegepast. Geen ARIA is beter dan kapotte ARIA.

De belangrijkste ARIA-attributen uitgelegd

• aria-label: geeft een element rechtstreeks zijn toegankelijke naam. Het klassieke geval is een knop met alleen een icoon: aria-label="Sluiten" op de X van een modal.
• aria-labelledby: verwijst naar de ID van een ander element, waarvan de zichtbare tekst de naam wordt. Heeft de voorkeur boven aria-label als er een zichtbaar label bestaat, omdat de twee dan niet uit elkaar kunnen lopen.
• aria-describedby: verwijst naar aanvullende beschrijvende tekst, meestal een hint of een foutmelding onder een formulierveld.
• aria-hidden="true": haalt een element en zijn kinderen uit de accessibility tree. Prima voor decoratieve iconen, gevaarlijk op alles wat focus kan krijgen.
• aria-expanded: geeft op de trigger aan of het bijbehorende gebied open of dicht is. De ruggengraat van accordions, dropdownmenu's en mobiele navigatie.
• aria-controls: verbindt een trigger met het element dat die bedient.
• aria-live: maakt van een element een live region waarvan inhoudswijzigingen automatisch worden aangekondigd. polite wacht op een pauze, assertive onderbreekt meteen en hoort voorbehouden te blijven aan echt dringende meldingen.
• aria-current: markeert het huidige item in een verzameling, bijvoorbeeld aria-current="page" op de actieve navigatielink.
• aria-required en aria-invalid: communiceren verplichte velden en mislukte validatie in formulieren. Met native HTML-validatie dekt required alleen al het eerste deel af.

Wat zijn ARIA landmark roles?

Landmarks delen een pagina op in benoemde regio's waar schermlezergebruikers direct naartoe kunnen springen, zoals ziende gebruikers visueel over een layout scannen. Het goede nieuws: moderne HTML-elementen maken de meeste landmarks impliciet aan, dus in een goed gestructureerd document schrijf je deze roles zelden met de hand.

• header wordt het landmark banner
• nav wordt navigation
• main wordt main, en daar hoort er precies één van per pagina te zijn
• aside wordt complementary
• footer wordt contentinfo
• form en section worden de landmarks form en region zodra ze een toegankelijke naam hebben

Eén gewoonte is het overnemen waard: heeft een pagina twee navigaties, geef ze dan aparte namen met aria-label="Hoofdmenu" en aria-label="Footermenu". Twee keer navigatie horen zonder onderscheid helpt niemand.

Praktische ARIA-voorbeelden: accordion en live region

Een minimale toegankelijke accordionkop laat zien hoe de onderdelen samenwerken. De knop draagt de toestand, het paneel wordt via de ID aangewezen, en JavaScript zet allebei om bij een klik:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Verzending en retouren
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Wij verzenden binnen 2 tot 4 werkdagen...</p>
</div>

En een live region voor feedback die verschijnt zonder de pagina te herladen, bijvoorbeeld na het toevoegen aan de winkelwagen of na een gefilterde zoekopdracht:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 producten gevonden'
</script>

Zonder de live region filtert een schermlezergebruiker een productlijst en hoort helemaal niets. Mét die regio wordt het aantal resultaten aangekondigd op het moment dat het verandert. Klein attribuut, groot verschil.

Veelgemaakte ARIA-fouten om te vermijden

• aria-hidden="true" op elementen die focus kunnen krijgen: het element verdwijnt uit de accessibility tree maar blijft in de tabvolgorde staan. Toetsenbordgebruikers landen op een spook. Dit is een van de meest voorkomende ARIA-fouten in het wild.
• Overbodige roles: role="button" op een button of role="navigation" op een nav voegt ruis toe en verraadt dat de markup niet begrepen is.
• Roles zonder gedrag: role="tab" belooft navigatie met de pijltjestoetsen. Levert je JavaScript dat niet, dan maakt de role het erger dan géén role, omdat het verwachtingen wekt die de widget niet waarmaakt.
• Verouderde states: een aria-expanded die eeuwig op false blijft staan omdat niemand hem bijwerkt in de clickhandler. Schermlezergebruikers horen ingeklapt terwijl ze naar een open paneel staren.
• aria-label op elementen met platte tekst: op een div of span zonder role wordt aria-label door de meeste hulptechnologie genegeerd. Het is geen tooltip voor algemeen gebruik.
• Te veel assertive live regions: onderbreekt elke update van de winkelwagen, cookiemelding en nieuwsbriefbox de gebruiker, dan verdrinken de meldingen die er echt toe doen.

ARIA in WordPress-themes en -plugins

De WordPress-core staat er redelijk voor: het navigatieblok beheert aria-expanded op submenu-toggles, de CSS-klasse screen-reader-text voor visueel verborgen labels is al lang een conventie, en de formuliercomponenten uit de core hebben zinnige attributen. De problemen komen meestal met wat er bovenop wordt geïnstalleerd. Pagebuilders, sliderplugins, megamenu's en popuptools zijn de plekken waar divsoep met ontbrekende of kapotte ARIA zich opstapelt. Beoordeel je een theme, dan is de tag accessibility-ready in de WordPress-themedirectory een echt signaal, want die themes gaan door een review tegen vastgestelde criteria. Voor al het andere documenteert de ARIA Authoring Practices Guide beproefde patronen voor vrijwel elke widget die je ooit bouwt, inclusief werkend toetsenbordgedrag.

Hoe controleert InspectWP het gebruik van ARIA?

InspectWP onderzoekt je gerenderde pagina's als onderdeel van de toegankelijkheidsanalyse en markeert ARIA-problemen die geautomatiseerde tooling betrouwbaar kan vinden: ongeldige rolnamen, ARIA-attributen die niet zijn toegestaan op het element waar ze staan, verwijzingen naar ID's die niet bestaan, elementen met focus die met aria-hidden zijn verborgen en interactieve elementen zonder toegankelijke naam. De bevindingen zijn gegroepeerd op ernst, zodat een kapotte naam in je hoofdnavigatie zwaarder weegt dan een overbodige role in de footer. Omdat uiteindelijk het gedrag van de schermlezer bepaalt wat werkt, gebruik je het rapport het beste als snelle, herhaalbare eerste ronde, en verifieer je de kritieke routes daarna met een echte schermlezer.