Wat is ARIA? Rollen, landmarks en live regions

Wat ARIA is — en wat het niet is

ARIA staat voor Accessible Rich Internet Applications. Het is een set attributen, gedefinieerd door het Web Accessibility Initiative (WAI) van het W3C, waarmee ontwikkelaars de betekenis en de toestand van elementen in een gebruikersinterface kunnen doorgeven aan hulptechnologie zoals schermlezers.

De belangrijkste regel over ARIA is meteen ook de regel die het vaakst wordt genegeerd: gebruik geen ARIA wanneer native HTML het werk kan doen. Een <button>-element kondigt zichzelf al aan als knop en reageert op toetsenbordgebeurtenissen. Een <nav>-element communiceert al een navigatielandmark aan schermlezers. role="button" toevoegen aan een <div> en het gedrag er vervolgens omheen scripten is lastiger te onderhouden, makkelijker kapot te maken en meestal slechter voor de toegankelijkheid dan meteen het juiste element gebruiken.

ARIA doet níét het volgende:

• Content zichtbaar of interactief maken — het verandert alleen wat hulptechnologie aankondigt
• Kapotte toetsenbordtoegang repareren — je hebt nog steeds tabindex en event listeners nodig
• Goed gestructureerde semantische HTML vervangen

Waar ARIA wél echt helpt, is wanneer native HTML geen element heeft voor wat je bouwt: een datumkiezer, een banner met live meldingen, een aangepaste combobox, een boomstructuur. In die gevallen kun je met ARIA de semantiek overbrengen die HTML niet kent.

ARIA-rollen

Een rol vertelt hulptechnologie met wat voor soort element het te maken heeft. Elk interactief element heeft een impliciete rol die is afgeleid van de HTML-tag. Het <a>-element heeft de rol link. Het element <input type="checkbox"> heeft de rol checkbox. Het <h2>-element heeft de rol heading.

Bouw je een aangepast element waarvoor geen HTML-equivalent bestaat, dan ken je er een expliciete rol aan toe:

<!-- Een aangepaste schakelaar gebouwd van een div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Donkere modus
</div>

De schermlezer kondigt dit nu aan als een schakelaar en spreekt de aangevinkte toestand uit. Zonder de rol zou het als gewone tekst worden aangekondigd en zou de gebruiker geen idee hebben dat het interactief is.

Veelvoorkomende rollen en wanneer je ze gebruikt

Widgetrollen beschrijven interactieve besturingselementen:

Rol	Gebruik wanneer
button	Een aangepast klikbaar element waarvoor geen betere HTML-tag bestaat
checkbox	Een aangepaste schakelaar voor meervoudige selectie
combobox	Een tekstinvoer gecombineerd met een listbox-dropdown
dialog	Een modale overlay (alleen wanneer je niet het native <dialog>-element gebruikt)
listbox	Een aangepaste keuzelijst
slider	Een aangepast schuifregelaarelement
switch	Een aan/uit-schakelaar
tab, tablist, tabpanel	Een interface met tabbladen
tooltip	Een korte beschrijving die verschijnt bij hover of focus

Documentstructuurrollen beschrijven niet-interactieve content:

• article — een op zichzelf staand stuk content
• figure — een afbeelding met een bijschrift
• list, listitem — wanneer lijstsemantiek nodig is op elementen die geen lijst zijn
• presentation / none — verwijdert de impliciete rol van een element (spaarzaam en zorgvuldig gebruiken)

Een cruciale fout: rollen toevoegen zonder gedrag

Elke rol brengt een contract mee waarvan schermlezer- en toetsenbordgebruikers verwachten dat het wordt nagekomen. Een role="button" moet reageren op zowel Enter als spatie. Een role="checkbox" moet omschakelen met de spatiebalk. Een role="link" moet navigeren bij Enter.

Voeg je de rol toe maar niet het bijbehorende gedrag, dan misleid je gebruikers van hulptechnologie actief. Ze horen dat er een besturingselement wordt aangekondigd, proberen ermee te werken via de verwachte toetsaanslag, en er gebeurt niets. Dat is erger dan helemaal geen ARIA.

ARIA-landmarks

Landmarks vormen het navigatieskelet van de pagina. Ze stellen schermlezergebruikers in staat tussen belangrijke regio’s te springen zonder alles ertussenin te lezen — het equivalent van een ziende gebruiker die de paginalay-out in één oogopslag overziet.

HTML5 introduceerde semantische elementen die rechtstreeks overeenkomen met landmarkrollen. Gebruik ze en je krijgt de landmarks gratis:

HTML-element	Landmarkrol	Doel
<header>	banner	Sitebrede header (alleen wanneer het de header op het hoogste niveau is, niet binnen <article>)
<nav>	navigation	Een navigatiemenu
<main>	main	De primaire content van de pagina
<aside>	complementary	Secundaire content die gerelateerd is aan de hoofdcontent
<footer>	contentinfo	Sitebrede footer
<form>	form	Een formulier (alleen wanneer het een toegankelijke naam heeft)
<section>	region	Een benoemde sectie (alleen wanneer die een toegankelijke naam heeft via aria-label of aria-labelledby)

Je hoeft geen role="main" toe te voegen aan een <main>-element — dat is overbodig. ARIA-landmarkrollen zijn alleen nodig wanneer je het semantische HTML-element niet kunt gebruiken, bijvoorbeeld in een verouderde codebase die <div class="sidebar"> genereert:

<div class="sidebar" role="complementary" aria-label="Gerelateerde artikelen">
  <!-- content van de zijbalk -->
</div>

Landmarks labelen wanneer je er meer dan één hebt

Wanneer een pagina meerdere exemplaren van hetzelfde landmark bevat — twee <nav>-elementen, twee <section>-elementen met role="region" — moet elk een unieke toegankelijke naam hebben zodat gebruikers ze uit elkaar kunnen houden:

<nav aria-label="Hoofdnavigatie">...</nav>
<nav aria-label="Footernavigatie">...</nav>

Zonder labels kondigt een schermlezer beide simpelweg aan als “navigatie”. Mét labels horen gebruikers “Hoofdnavigatie, navigatielandmark” en “Footernavigatie, navigatielandmark” en kunnen ze de juiste kiezen uit een lijst met landmarks.

ARIA live regions

Een live region is een gebied van de pagina waarvan de content dynamisch verandert en waarbij die wijzigingen automatisch aan schermlezergebruikers moeten worden aangekondigd, zonder dat zij de focus hoeven te verplaatsen.

Het kernattribuut is aria-live. Het accepteert drie waarden:

• off — wijzigingen worden niet aangekondigd (de standaard voor alle elementen)
• polite — wijzigingen worden aangekondigd nadat de gebruiker zijn huidige taak heeft afgerond
• assertive — wijzigingen onderbreken onmiddellijk waar de schermlezer mee bezig is

<!-- Een gebied voor statusberichten dat na het verzenden van een formulier wordt gevuld -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Je bericht is verzonden.';
</script>

Wanneer de tekstinhoud verandert, wacht een schermlezer met aria-live="polite" op een pauze in de spraak en kondigt vervolgens de nieuwe content aan. Gebruik polite voor de overgrote meerderheid van dynamische wijzigingen. Reserveer assertive uitsluitend voor kritieke storingen — een betaalfout, een waarschuwing dat de sessie verloopt — waarbij de informatie dringend genoeg is om de gebruiker te onderbreken.

Rolafkortingen voor live regions

Twee rollen bundelen de aria-live-semantiek in één enkel attribuut:

• role="status" — equivalent aan aria-live="polite". Gebruik dit voor succesmeldingen, laadstatussen en niet-urgente wijzigingen.
• role="alert" — equivalent aan aria-live="assertive" en impliceert daarnaast aria-atomic="true". Gebruik dit voor foutmeldingen en kritieke storingen.

<!-- Fout wordt direct aangekondigd en onderbreekt de lopende spraak -->
<div role="alert" id="payment-error"></div>

<!-- Statuswijziging wordt beleefd aangekondigd na de lopende spraak -->
<div role="status" id="cart-count">3 artikelen in winkelwagen</div>

Veelvoorkomende fouten bij live regions

Content toevoegen voordat het element in de DOM staat. De browser registreert de live region op het moment dat het element voor het eerst wordt geparseerd. Injecteer je het element en stel je tegelijkertijd de tekstinhoud in, dan missen sommige schermlezers de aankondiging volledig. Neem de container van de live region altijd op in de initiële HTML en werk de inhoud daarna via JavaScript bij.

assertive voor alles gebruiken. Assertieve live regions onderbreken alles waar de gebruiker mee bezig is, inclusief andere aankondigingen. Een teller met zoekresultaten die bijwerkt terwijl de gebruiker typt, rechtvaardigt geen role="alert". Overmatig gebruik van assertive levert een vijandige ervaring op voor schermlezergebruikers.

De live region te vaak bijwerken. Werkt een voortgangsindicator zijn live region elke 100 milliseconden bij, dan loopt de spraakwachtrij over en horen gebruikers niets bruikbaars. Werk live tekst alleen bij op betekenisvolle mijlpalen — 25%, 50%, 75%, klaar — of debounce de updates met een timer.

aria-atomic vergeten. Standaard wordt alleen het gewijzigde tekstknooppunt binnen een live region aangekondigd. Wil je dat de hele regio opnieuw wordt voorgelezen (niet alleen het gewijzigde fragment), voeg dan aria-atomic="true" toe:

<div aria-live="polite" aria-atomic="true">
  Nog <span id="count">2</span> artikelen te gaan
</div>

Zonder aria-atomic kondigt een schermlezer mogelijk alleen “2” aan wanneer de teller van 3 naar 2 gaat. Mét dat attribuut wordt de volledige zin “Nog 2 artikelen te gaan” uitgesproken, en dat is vrijwel altijd wat je wilt.

Andere essentiële ARIA-attributen

aria-label — geeft een toegankelijke naam wanneer zichtbare tekst niet passend is:

<button aria-label="Dialoogvenster sluiten">✕</button>

aria-labelledby — verwijst naar een ander element waarvan de tekst dient als toegankelijke naam. Verdient de voorkeur boven aria-label wanneer de labeltekst al zichtbaar is op de pagina:

<h2 id="billing-heading">Factuuradres</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — verwijst naar aanvullende tekst die een element beschrijft, bovenop de naam:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Moet minstens 12 tekens bevatten, waaronder één symbool.</p>

aria-expanded — geeft aan of een inklapbaar element (dropdown, accordeon, menu) open of gesloten is. Werk het in JavaScript bij telkens wanneer de toestand verandert:

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — verwijdert een element uit de toegankelijkheidsboom. Gebruik dit voor decoratieve iconen, dubbele tekst of visuele elementen die voor schermlezergebruikers alleen ruis toevoegen:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 van de 5 sterren</span>

aria-disabled="true" — markeert een besturingselement als uitgeschakeld zonder het uit de focusvolgorde te halen. Handig wanneer je wilt dat gebruikers ontdekken dat het element bestaat en begrijpen waarom het niet beschikbaar is, in plaats van dat het stilzwijgend wordt overgeslagen:

<button aria-disabled="true">Verzenden (vul eerst alle velden in)</button>

ARIA testen in de praktijk

ARIA-attributen schrijven is niet ingewikkeld. Ze goed krijgen vereist testen. Geautomatiseerde scanners vangen duidelijk kapotte patronen op — een role="button" zonder toegankelijke naam, een aria-labelledby die naar een niet-bestaand ID verwijst, een live region met een ongeldige aria-live-waarde. Ze kunnen je niet vertellen of de aangekondigde tekst in de context ergens op slaat, of dat een complexe aangepaste widget zich correct gedraagt wanneer je er alleen met het toetsenbord doorheen navigeert.

Voor testen in de praktijk combineer je minstens twee combinaties van schermlezer en browser:

• NVDA + Chrome op Windows — gratis, breed gebruikt, dicht bij de werkelijke schermlezerpopulatie
• VoiceOver + Safari op macOS of iOS — ingebouwd, essentieel voor het testen van mobiele toegankelijkheid
• JAWS + Chrome of Edge op Windows — betaald, maar de meest gebruikte schermlezer in zakelijke omgevingen

Navigeer door je interactieve componenten met alleen het toetsenbord. Luister aandachtig naar wat er wordt aangekondigd wanneer je een menu opent, een formulier met een validatiefout verzendt of een update van een live region uitlokt. Is de aankondiging dubbelzinnig of misleidend, dan is de ARIA-implementatie verkeerd — ongeacht wat een geautomatiseerde tool rapporteert.

De regel die alles dekt

De ARIA-specificatie bevat vijf regels voor auteurs. De eerste is de belangrijkste:

Als je een native HTML-element of -attribuut kunt gebruiken waarin de semantiek en het gedrag die je nodig hebt al zijn ingebouwd, in plaats van een element te herbestemmen en er een ARIA-rol, -toestand of -eigenschap aan toe te voegen om het toegankelijk te maken, doe dat dan.

Bouw met semantische HTML. Grijp pas naar ARIA wanneer HTML tekortschiet. Test met een echte schermlezer. Daarmee dek je vrijwel elke situatie af die je zult tegenkomen.

Wil je praktisch laten controleren hoe ARIA-attributen op je hele site zijn geïmplementeerd, dan omvatten onze handmatige toegankelijkheidsaudits schermlezertests door mensen die elke dag hulptechnologie gebruiken en subtiele ARIA-problemen opmerken die geautomatiseerde tools missen.