Je hebt waarschijnlijk wel eens gehoord dat je website “toegankelijk” moet zijn. Maar wat betekent dat concreet? Een belangrijk onderdeel zijn ARIA labels: onzichtbare instructies die screenreaders helpen begrijpen wat er op je website staat. In dit artikel lees je wat ARIA labels precies zijn, wanneer je ze nodig hebt (en wanneer juist niet), en hoe je ze correct toepast. Zonder technische ballast, met praktische voorbeelden die je vandaag nog kunt gebruiken.
Inhoudsopgave
- Wat zijn ARIA labels?
- Wanneer gebruik je ARIA labels (en wanneer niet)?
- De belangrijkste ARIA label attributen
- Praktijkvoorbeelden voor ARIA labels op jouw website
- Veelgemaakte fouten met ARIA labels (en hoe je ze voorkomt)
- ARIA labels en WCAG-richtlijnen
- Hoe test je of je ARIA labels goed werken?
- Conclusie
Want hier is het rare: veel websites gebruiken ARIA labels verkeerd. Ze plakken ze overal, terwijl goed geschreven HTML vaak al genoeg is. Dit artikel helpt je die valkuil te vermijden.
Wat zijn ARIA labels?
ARIA staat voor Accessible Rich Internet Applications. Het is een set attributen die je aan HTML-elementen kunt toevoegen om ze toegankelijker te maken voor mensen die je website niet kunnen zien, maar beluisteren via een screenreader zoals NVDA of VoiceOver.
Stel je voor: iemand bezoekt je website, maar ziet de knoppen, afbeeldingen en menu’s niet. In plaats daarvan laat een screenreader voor wat er op het scherm staat. Een knop met alleen een icoon (bijvoorbeeld een vergrootglas voor zoeken) is voor die bezoeker onbruikbaar. De screenreader leest geen afbeeldingen voor, alleen tekst. Hier komt ARIA om de hoek kijken.
Met een aria-label voeg je een onzichtbare tekstbeschrijving toe die wél wordt voorgelezen. De knop ziet er voor ziende bezoekers nog steeds uit als een simpel vergrootglas-icoon, maar de screenreader vertelt: “Zoeken, knop”. Probleem opgelost.
ARIA is ontwikkeld door de Web Accessibility Initiative (WAI), een onderdeel van het World Wide Web Consortium (W3C). De standaard bestaat sinds 2014 en wordt door alle moderne browsers en screenreaders ondersteund. Je kunt ARIA zien als een extra laag bovenop je HTML. Het verandert niets aan hoe je website eruitziet, maar alles aan hoe hulptechnologie je website interpreteert.
ARIA labels zijn niet hetzelfde als de zichtbare tekst op je pagina. Een knop met de tekst “Meer lezen” heeft geen ARIA label nodig, want de tekst is al beschikbaar voor screenreaders. ARIA vul je alleen in waar iets ontbreekt: bij elementen zonder zichtbare tekst, of waar de zichtbare tekst niet voldoende context geeft.
De WAI-ARIA specificatie bevat tientallen attributen. In de praktijk
kom je vooral aria-label, aria-labelledby,
aria-describedby en aria-hidden tegen.
Wanneer gebruik je ARIA labels (en wanneer niet)?
Laat ik direct zijn: gebruik geen ARIA als je native HTML kunt gebruiken. Dit is de meest genegeerde regel in webtoegankelijkheid.
Dat klinkt misschien contra-intuïtief als je net hebt gelezen dat
ARIA zo belangrijk is voor toegankelijkheid. Maar het punt is dit: goed
geschreven HTML is al toegankelijk. Browsers en screenreaders begrijpen
HTML-elementen perfect. Als je een <button> gebruikt,
weet een screenreader dat het een knop is. Als je een
<nav> gebruikt, weet de screenreader dat het een
navigatiemenu is. ARIA heb je alleen nodig als HTML tekortschiet.
Voorbeelden waar je ARIA NIET nodig hebt
Neem deze knop:
<button>Verstuur formulier</button>Perfect toegankelijk. De screenreader leest: “Verstuur formulier, knop”. Voeg je hier een aria-label aan toe, dan creëer je verwarring:
<button aria-label="Klik hier om het formulier te versturen">Verstuur formulier</button>Nu leest de screenreader alleen het aria-label voor, niet de zichtbare tekst. Dat betekent dat de screenreader-gebruiker iets anders hoort dan wat er visueel staat. Verwarrend en onnodig.
Hetzelfde geldt voor links met duidelijke tekst:
<a href="/contact">Neem contact op</a>Een aria-label zou hier de toegankelijkheid juist verslechteren.
Voorbeelden waar ARIA WÉL nodig is
Nu een knop die alleen een icoon bevat:
<button>
<svg><!-- vergrootglas-icoon --></svg>
</button>Voor een ziende bezoeker is dit herkenbaar als een zoekknop. Voor een screenreader is het een naamloze knop, dus onbruikbaar. Hier is ARIA de oplossing:
<button aria-label="Zoeken">
<svg><!-- vergrootglas-icoon --></svg>
</button>Nu leest de screenreader: “Zoeken, knop”. Duidelijk en bruikbaar.
Een ander voorbeeld: een navigatiemenu waarin je visueel aangeeft
welke pagina actief is met een kleur of onderstreping. Een screenreader
ziet die styling niet. Hier helpt aria-current:
<nav>
<a href="/">Home</a>
<a href="/over-ons">Over ons</a>
<a href="/diensten" aria-current="page">Diensten</a>
</nav>De screenreader meldt bij “Diensten”: “Huidige pagina”.
Het besliskader
Twee vragen helpen je beslissen:
Is er zichtbare tekst die duidelijk maakt wat dit element doet? Dan heb je geen ARIA nodig. Kan je een semantisch HTML-element gebruiken? Doe dat in plaats van ARIA.
ARIA is een reparatiemiddel, geen standaardprocedure. Als je HTML goed in elkaar zit, heb je minder ARIA nodig.
De belangrijkste ARIA label attributen
Vier attributen kom je in de praktijk het meest tegen. Elk heeft z’n eigen toepassing.
aria-label
Het simpelste attribuut. Je voegt een onzichtbare tekstbeschrijving toe waar geen zichtbare tekst is.
Je ziet dit vooral bij iconknoppen. Een hamburger-menu bijvoorbeeld:
<button aria-label="Menu openen">
<svg><!-- hamburger-icoon --></svg>
</button>De screenreader leest: “Menu openen, knop”. Zonder dat label zou je alleen “Knop” horen, wat niemand helpt.
Belangrijk: gebruik aria-label niet op elementen die al zichtbare tekst hebben. Het overschrijft die tekst, en dat leidt tot verwarring als je de zichtbare tekst later wijzigt maar vergeet het label aan te passen.
aria-labelledby
Dit attribuut verwijst naar tekst die al ergens op de pagina staat. Waarom de tekst herhalen in een aria-label als je ernaar kunt linken?
<h2 id="contact-kop">Neem contact op</h2>
<form aria-labelledby="contact-kop">
<!-- formuliervelden -->
</form>De screenreader koppelt het formulier aan die kop: “Neem contact op, formulier”. Als je de kop later aanpast, werkt de koppeling nog steeds. Dat scheelt onderhoud.
Een handig detail: je kunt meerdere ID’s opgeven door ze te scheiden met spaties. De screenreader combineert ze dan tot één label:
<h2 id="stap-1">Stap 1</h2>
<p id="stap-1-toelichting">Vul je contactgegevens in</p>
<fieldset aria-labelledby="stap-1 stap-1-toelichting">
<!-- velden -->
</fieldset>Resultaat: “Stap 1, Vul je contactgegevens in, groep”.
aria-describedby
Waar aria-labelledby het primaire label levert, voegt aria-describedby context toe. Helptekst bij een formulierveld, of een foutmelding.
<label for="wachtwoord">Wachtwoord</label>
<input type="password" id="wachtwoord" aria-describedby="wachtwoord-hint">
<p id="wachtwoord-hint">Minimaal 8 tekens, met hoofdletter en cijfer</p>De screenreader leest achtereenvolgens het label, het veldtype en dan de hint. Alles in logische volgorde, zonder dat je iets hoeft te herhalen.
Voor foutmeldingen gebruik je hetzelfde patroon, gecombineerd met aria-invalid:
<input type="email" id="email" aria-describedby="email-fout" aria-invalid="true">
<p id="email-fout">Dit is geen geldig e-mailadres</p>aria-hidden
Soms wil je juist dat een screenreader iets negeert. aria-hidden=”true” verstopt elementen voor screenreaders terwijl ze visueel zichtbaar blijven. Handig voor decoratie die geen betekenis heeft.
Een knop met een icoon én tekst bijvoorbeeld:
<button>
<svg aria-hidden="true"><!-- vinkje-icoon --></svg>
Opslaan
</button>De screenreader leest alleen “Opslaan, knop”. Het icoon is puur visuele versterking, dus die mag overgeslagen worden.
Let op: zet aria-hidden=”true” nooit op interactieve elementen zoals knoppen of links. Dan kan een screenreader-gebruiker er niet bij, terwijl een ziende gebruiker het wel ziet. Dat is een ernstige toegankelijkheidsfout.
Praktijkvoorbeelden voor ARIA labels op jouw website
Hieronder zie je situaties die je op bijna elke MKB-website tegenkomt. De voorbeelden zijn direct toepasbaar.
Iconknoppen in een navigatiemenu
Veel websites hebben een mobiel menu dat openklapt als je op een hamburger-icoon klikt. Dat icoon is voor ziende bezoekers herkenbaar, maar voor een screenreader is het niks.
Zonder ARIA:
<button class="menu-toggle">
<span></span>
<span></span>
<span></span>
</button>De screenreader leest: “Knop”. Meer niet. De gebruiker weet niet wat deze knop doet.
Met ARIA:
<button class="menu-toggle" aria-label="Menu openen" aria-expanded="false">
<span></span>
<span></span>
<span></span>
</button>Nu leest de screenreader: “Menu openen, knop, samengevouwen”. Als het
menu openklapt, verander je aria-expanded naar
true, en idealiter ook het label naar “Menu sluiten”. Dat
kan met JavaScript, maar het belangrijkste is dat je überhaupt een label
toevoegt.
Zoekformulier met alleen een pictogram
Een zoekbalk met een vergrootglas-knop, zonder zichtbare tekst “Zoeken” ernaast. Veelvoorkomend, en vaak niet toegankelijk.
Zonder ARIA:
<form>
<input type="search" placeholder="Zoeken...">
<button type="submit">
<svg><!-- vergrootglas --></svg>
</button>
</form>Het invoerveld heeft een placeholder, maar dat is geen vervanger voor een echt label. De knop heeft geen tekst. Een screenreader kan hier weinig mee.
Met ARIA:
<form role="search">
<label for="zoek-invoer" class="visually-hidden">Zoeken</label>
<input type="search" id="zoek-invoer" placeholder="Zoeken...">
<button type="submit" aria-label="Zoeken">
<svg aria-hidden="true"><!-- vergrootglas --></svg>
</button>
</form>Het <label> element is de beste oplossing voor het
invoerveld. Je verstopt het visueel met CSS (de class
visually-hidden), maar screenreaders lezen het wel. De knop
krijgt een aria-label, en het icoon wordt verborgen met aria-hidden
omdat het puur decoratief is.
Social media iconen in de footer
LinkedIn-, Twitter- en Facebook-iconen onderaan je pagina. Zonder tekst, alleen logo’s. Voor een screenreader is dat een reeks “Link” zonder doel.
Zonder ARIA:
<a href="https://linkedin.com/company/jouwbedrijf">
<img src="linkedin-icon.svg" alt="">
</a>De alt="" op de afbeelding is correct (het icoon is
decoratief), maar de link zelf heeft geen label. Screenreader leest:
“Link”. Waar die naartoe gaat? Geen idee.
Met ARIA:
<a href="https://linkedin.com/company/jouwbedrijf" aria-label="Volg ons op LinkedIn">
<img src="linkedin-icon.svg" alt="">
</a>Nu is het duidelijk. Je kunt ook aria-labelledby gebruiken als je ergens op de pagina al de tekst “LinkedIn” hebt staan, maar in dit geval is aria-label simpeler.
Modal of pop-up venster
Een overlay die over de pagina heen verschijnt, met een sluitknop rechtsboven (vaak een kruisje). Dat kruisje heeft meestal geen tekst.
Zonder ARIA:
<div class="modal">
<button class="close-button">×</button>
<h2>Nieuwsbrief</h2>
<p>Ontvang wekelijks tips in je inbox.</p>
</div>Het × symbool is geen toegankelijk label. Sommige screenreaders lezen het voor als “maal” of “keer”, anderen slaan het over.
Met ARIA:
<div class="modal" role="dialog" aria-labelledby="modal-titel" aria-modal="true">
<button class="close-button" aria-label="Dialoog sluiten">×</button>
<h2 id="modal-titel">Nieuwsbrief</h2>
<p>Ontvang wekelijks tips in je inbox.</p>
</div>De modal krijgt role="dialog" (dit is een aria role,
niet een label, maar wel nuttig om te vermelden),
aria-labelledby linkt naar de titel zodat de screenreader
weet waar het over gaat, en aria-modal="true" geeft aan dat
de achtergrond inactief is. De sluitknop krijgt een duidelijk label.
Veelgemaakte fouten met ARIA labels (en hoe je ze voorkomt)
Verkeerd gebruikt maakt ARIA je website juist minder toegankelijk. Dit zijn de fouten die ik regelmatig tegenkom.
ARIA toevoegen aan elementen die het niet nodig hebben
De gedachte “meer ARIA = meer toegankelijk” klopt niet. Als een element al toegankelijk is, voegt ARIA niks toe.
Fout:
<button aria-label="Verstuur">Verstuur</button>Het aria-label overschrijft de zichtbare tekst. Als je later de knop wijzigt naar “Verzenden” maar vergeet het label bij te werken, ontstaat er verwarring. Beter:
<button>Verstuur</button>Dubbele labels creëren
Bij afbeeldingen gebeurt dit regelmatig:
<img src="logo.png" alt="Bedrijfsnaam Logo" aria-label="Bedrijfsnaam Logo">Het alt-attribuut is al de toegankelijke naam. Een aria-label daarbovenop is overbodig en sommige screenreaders lezen het dubbel voor.
Verkeerde aria-labelledby referenties
Een ID dat niet bestaat, of dat naar een leeg element verwijst, breekt de koppeling.
Fout:
<button aria-labelledby="niet-bestaand-id">Klik hier</button>De screenreader vindt het element niet en valt terug op de zichtbare tekst. Dat werkt misschien, maar het is niet wat je wilde. Controleer altijd of het ID bestaat.
aria-hidden op interactieve elementen
Als je aria-hidden=”true” zet op een knop of link, verstop je het voor screenreaders terwijl het visueel nog wel klikbaar is.
Fout:
<button aria-hidden="true">Download</button>Een ziende gebruiker ziet en klikt de knop. Een screenreader-gebruiker kan hem niet vinden. Gebruik aria-hidden alleen voor decoratie.
ARIA gebruiken in plaats van native HTML
Soms zie je dit:
<div role="button" tabindex="0" aria-label="Verstuur">Verstuur</div>Dit is een button verpakt in een div. Waarom? Gebruik gewoon een button:
<button>Verstuur</button>HTML-elementen hebben ingebouwde toegankelijkheid. Een echte button is standaard focusbaar en reageert op Enter en Spatie. Bij een div moet je dat allemaal zelf bouwen. Meer werk en meer kans op fouten.
ARIA labels en WCAG-richtlijnen
Als je je website toegankelijk wilt maken, kom je vroeg of laat WCAG tegen: de Web Content Accessibility Guidelines. Dit zijn internationale standaarden die beschrijven hoe toegankelijke websites eruit zien.
WCAG heeft drie niveaus: A (minimaal), AA (streefnorm), en AAA (hoogste niveau). De meeste wetgeving en richtlijnen vereisen niveau AA. In Europa wordt dit extra relevant door de European Accessibility Act, die vanaf 28 juni 2025 van kracht is. Vanaf dat moment moeten veel bedrijven aantonen dat hun websites en apps toegankelijk zijn volgens WCAG 2.1 niveau AA.
ARIA labels komen vooral terug bij twee WCAG-succescriteria:
1.3.1 Info en relaties (niveau A): Als je visueel laat zien dat twee dingen bij elkaar horen, moet een screenreader dat ook begrijpen. ARIA attributen zoals aria-labelledby en aria-describedby maken die koppeling programmatisch beschikbaar.
4.1.2 Naam, rol, waarde (niveau A): Alle interactieve elementen moeten een toegankelijke naam hebben. Een knop zonder tekst faalt, tenzij je een aria-label toevoegt.
Wat betekent dit voor jou als MKB-ondernemer? Je hoeft niet alle 78 WCAG-succescriteria uit je hoofd te leren. Maar als je een website laat bouwen of aanpassen, vraag dan of de ontwikkelaar rekening houdt met WCAG AA. En als je zelf websites bouwt (bijvoorbeeld in WordPress of Webflow), check dan of interactieve elementen zonder zichtbare tekst een aria-label hebben. Dat alleen al dekt een groot deel van de basis.
Er zijn online tools waarmee je je website kunt scannen op WCAG-naleving. Die behandelen we zo.
Hoe test je of je ARIA labels goed werken?
ARIA labels zijn onzichtbaar. De enige manier om te weten of ze werken, is testen met de tools die je doelgroep gebruikt.
Test met een screenreader
Download een gratis screenreader en navigeer door je website. NVDA voor Windows, VoiceOver op Mac (activeer met Cmd+F5). Gebruik de pijltjestoetsen om door de pagina te gaan en Tab om tussen interactieve elementen te springen.
Als een knop geen naam heeft, hoor je alleen “Knop”. Dat is het signaal dat je een label moet toevoegen.
Het voelt onwennig in het begin, maar na een paar minuten krijg je al een goed beeld van hoe toegankelijk je website is.
Browser-extensies voor toegankelijkheid
Voor een snelle scan zijn browser-extensies handiger. WAVE en axe DevTools (beide gratis) analyseren je pagina en markeren problemen.
WAVE kleurt elementen: rood voor fouten, oranje voor waarschuwingen. Klik op een rood icoon en je ziet wat er mis is. “Knop heeft geen toegankelijke naam” betekent dat je een aria-label moet toevoegen.
axe DevTools draait in je browser developer tools en geeft een rapport met uitleg per probleem.
Geautomatiseerde validatie
Lighthouse (ingebouwd in Chrome DevTools) draait een toegankelijkheidsaudit. Open DevTools, ga naar Lighthouse, selecteer “Accessibility” en genereer een rapport. Je krijgt een score en een lijst met problemen.
Let op: geautomatiseerde tools vinden zo’n 30-40% van problemen. Ze zien dat een aria-labelledby naar een leeg element verwijst, maar niet of een label inhoudelijk klopt. Handmatig testen blijft nodig.
Toetsenbordnavigatie
Gebruik je website zonder muis. Kun je met Tab door alle knoppen en links navigeren? Activeert Enter een knop? Is er een zichtbare focus indicator?
Als je vastloopt in een modal die niet sluit met je toetsenbord, heb je een toegankelijkheidsprobleem. ARIA labels lossen dat niet op, maar het is goed om dit te testen terwijl je toch bezig bent.
Conclusie
ARIA labels zijn geen wondermiddel, maar een gereedschap dat je bewust inzet. Gebruik ze alleen waar standaard HTML tekortschiet. Een knop met zichtbare tekst heeft geen aria-label nodig. Een iconknop zonder tekst wel.
Begin klein. Zoek op je homepage elementen zonder zichtbare tekst: het menu-icoon, de zoekknop, social media links. Voeg daar aria-labels aan toe. Test met een screenreader of WAVE.
De Europese toegankelijkheidswetgeving (European Accessibility Act) maakt dit vanaf juni 2025 niet alleen een kwestie van goede service, maar ook van compliance. Of je nou een webshop, nieuwssite of portfoliosite hebt: toegankelijkheid wordt een standaardeis.
En als dit allemaal wat overweldigend klinkt? Dat is normaal. Toegankelijkheid is een breed onderwerp met veel nuance. Wil je hulp bij het toegankelijk maken van je website, of advies over waar je moet beginnen? Neem contact op met Redfactory. We helpen je graag verder.