ARIA correct gebruiken: complete gids voor toegankelijke websites

ARIA correct gebruiken betekent: kies eerst semantisch HTML en voeg alleen ARIA toe als een dynamisch of complex interfaceonderdeel daarmee nog niet begrijpelijk of bedienbaar is. ARIA kan rollen, namen en statussen doorgeven aan hulptechnologie, maar maakt een onderdeel niet vanzelf klikbaar, toetsenbordbedienbaar of WCAG-conform.

Voor een toegankelijke WordPress-website is dat een belangrijk uitgangspunt. ARIA is geen reparatiemiddel voor onduidelijke markup of een onhandig ontwerp. Het is een aanvulling voor situaties waarin native HTML de benodigde semantiek niet volledig kan bieden.

Wat is ARIA?

WAI-ARIA staat voor Web Accessibility Initiative, Accessible Rich Internet Applications. Het is een verzameling attributen waarmee je extra informatie geeft aan hulptechnologie, zoals screenreaders. Denk aan de rol van een interfaceonderdeel, de naam ervan of de actuele status.

ARIA werkt vooral bij dynamische interfaces: uitklapbare secties, modals, navigatiemenu's, tabs, meldingen en aangepaste formulierelementen. De informatie uit ARIA komt terecht in de accessibility tree van de browser, die hulptechnologie gebruikt om een pagina te interpreteren.

Volgens W3C bestaat ARIA onder meer uit roles, states en properties:

• Roles beschrijven wat een element is, zoals button, dialog of tab.
• States beschrijven een veranderlijke toestand, zoals aria-expanded="true" of aria-selected="false".
• Properties leggen relaties of extra informatie vast, zoals aria-labelledby en aria-describedby.

De eerste regel: gebruik native HTML als dat kan

Een gewone knop maak je met <button>, niet met een <div role="button">. Een link maak je met <a href="…">, niet met een klikbaar <span>. Native HTML heeft al ingebouwde semantiek en gedrag. Een button is bijvoorbeeld standaard focusseerbaar en reageert op relevante toetsen.

Gebruik ARIA dus niet om native elementen na te bootsen als native HTML beschikbaar is. De W3C-richtlijn Using ARIA vat dit samen als de eerste regel van ARIA: geen ARIA gebruiken is vaak beter dan slechte ARIA gebruiken.

<!-- Goed: native semantiek en gedrag -->
<button type="button">Offerte aanvragen</button>

<!-- Niet nodig en foutgevoelig -->
<div role="button" tabindex="0">Offerte aanvragen</div>

De tweede variant vraagt extra JavaScript voor activering met het toetsenbord, focusgedrag en mogelijke states. Ontbreekt één van die onderdelen, dan is de bediening niet gelijkwaardig.

Toegankelijke namen: zichtbare tekst eerst

Een interactieve bediening heeft een toegankelijke naam nodig: de naam die een screenreader aankondigt. Zichtbare knoptekst is meestal de beste oplossing, omdat iedereen dezelfde betekenis krijgt.

<button type="button">Menu openen</button>

Is zichtbare tekst niet mogelijk, bijvoorbeeld bij een icoonknop, gebruik dan aria-label.

<button type="button" aria-label="Zoeken">
  <svg aria-hidden="true">…</svg>
</button>

Gebruik aria-labelledby wanneer bestaande, zichtbare tekst elders op de pagina de naam moet vormen. Dit is bijvoorbeeld bruikbaar bij een dialoogvenster.

<section role="dialog" aria-labelledby="offerte-titel">
  <h2 id="offerte-titel">Vraag een offerte aan</h2>
  …
</section>

Met aria-describedby koppel je aanvullende uitleg aan een invoerveld of bediening. Gebruik dit voor hulpinformatie, niet als vervanging voor een zichtbaar label.

<label for="telefoon">Telefoonnummer</label>
<input id="telefoon" aria-describedby="telefoon-uitleg">
<p id="telefoon-uitleg">Vul een nummer in waarop we je kunnen bereiken.</p>

Veelgebruikte ARIA-attributen

• aria-expanded: geeft aan of een uitklapbaar onderdeel open of dicht staat.
• aria-controls: verwijst naar het element dat een bediening aanstuurt.
• aria-hidden: verbergt puur decoratieve of dubbele inhoud voor hulptechnologie.
• aria-live: laat belangrijke dynamische meldingen aankondigen.
• aria-current: markeert bijvoorbeeld de huidige pagina in een navigatie.
• aria-invalid: geeft aan dat een formulierveld een fout bevat, in combinatie met een duidelijke foutmelding.

Een attribuut is alleen correct wanneer het blijft aansluiten op wat er daadwerkelijk op het scherm en in de interactie gebeurt. Verandert een accordion van gesloten naar open, dan moet ook aria-expanded wijzigen.

Componentenscorecard: wat gebruik je per situatie?

Gebruik deze scorecard bij een nieuw ontwerp, een WordPress-template of een controle van een plugin. De kolom 'controleren' maakt duidelijk welk gedrag naast de markup nodig is.

Component	Voorkeur voor HTML	ARIA alleen waar nodig	Controleren
Link naar een pagina	<a href>	aria-current="page" voor de actieve navigatielink	Link heeft een duidelijke bestemming en werkt met toetsenbord.
Actieknop	<button type="button">	aria-label als een icoon de enige zichtbare inhoud is	Enter en spatie activeren de actie; naam beschrijft de actie.
Accordion	<button> voor de kopbediening	aria-expanded, eventueel aria-controls	Status verandert mee; inhoud is bereikbaar en logisch geplaatst.
Hoofdnavigatie	<nav>, lijsten en links	aria-label bij meerdere navigatielanden; aria-expanded voor submenu-knoppen	Submenu's zijn met toetsenbord te openen, sluiten en verlaten.
Modal of dialoog	<dialog> waar passend	Bij een eigen dialoog: role="dialog", aria-modal="true", aria-labelledby	Focus gaat naar de dialoog, blijft daarin tijdens gebruik en keert terug na sluiten.
Formulierveld	<label> gekoppeld aan <input>	aria-describedby voor hulptekst; aria-invalid bij een fout	Label, foutmelding en herstelactie zijn begrijpelijk zonder kleur als enige signaal.
Statusmelding na actie	Gewone tekst in de pagina wanneer mogelijk	aria-live="polite" voor relevante dynamische bevestiging	Melding is kort, tijdig en wordt niet onnodig herhaald.

ARIA correct implementeren: stappenplan

1. Inventariseer interactieve onderdelen. Loop menu's, filters, formulieren, tabs, pop-ups, sliders en accordeons na. Noteer wat een bezoeker kan openen, sluiten, selecteren of versturen.
2. Vervang generieke klikbare elementen door native HTML. Kies bijvoorbeeld button voor acties, a voor navigatie, input voor invoer en details met summary voor eenvoudige uitklapbare inhoud.
3. Bepaal welke informatie nog ontbreekt. Heeft een icoonknop geen zichtbare naam? Is een open- of dichtstatus niet duidelijk? Voeg alleen dan het passende ARIA-attribuut toe.
4. Koppel ARIA aan de werkelijke staat. Laat JavaScript bij een opening bijvoorbeeld zowel de zichtbare inhoud als aria-expanded aanpassen. ARIA mag nooit een andere situatie aankondigen dan de interface toont.
5. Regel toetsenbord en focus. Controleer Tab, Shift+Tab, Enter, spatie en Escape waar die relevant zijn. Bij een modal is focusbeheer essentieel; bij een gewone knop komt veel gedrag al mee vanuit HTML.
6. Test de accessibility tree. Inspecteer in de browser of naam, rol en status kloppen. Vergelijk wat de accessibility tree toont met wat een bezoeker op het scherm ziet en doet.
7. Test met een echt gebruikerspad. Doorloop bijvoorbeeld het openen van een menu, invullen van een formulier en sluiten van een modal zonder muis. Test aanvullend met de screenreader en browsercombinatie die voor jouw doelgroep of organisatie relevant is.
8. Leg componentafspraken vast. Neem de gekozen patronen op in je design system, componentbibliotheek of ontwikkelrichtlijnen. Zo voorkom je dat dezelfde knop of accordion telkens anders wordt gebouwd.

Voorbeeld: een toegankelijk accordion

Een accordion heeft een knop nodig, een inhoudsgebied en een status die synchroon loopt met de zichtbare inhoud. Voor een eenvoudig geval kan native details en summary voldoende zijn. Bouw je een eigen variant, zorg dan minimaal voor dit patroon:

<h3>
  <button type="button"
          aria-expanded="false"
          aria-controls="antwoord-1">
    Kan ik mijn website zelf beheren?
  </button>
</h3>
<div id="antwoord-1" hidden>
  Ja, mits het beheergedeelte en de contentblokken daarop zijn ingericht.
</div>

Bij een klik moet de code zowel het attribuut aria-expanded als het attribuut hidden aanpassen. Alleen de inhoud tonen zonder de state te actualiseren is onvoldoende. Alleen de ARIA-state aanpassen zonder de inhoud te tonen is dat ook.

ARIA voegt geen bediening toe

Dit is een veelgemaakte fout: een rol of attribuut toevoegen en aannemen dat de component daarmee toegankelijk is. ARIA voegt geen JavaScript-interactie, focusbeheer of toetsenbordbediening toe. De ARIA Authoring Practices Guide beschrijft daarom niet alleen markup, maar ook verwachte toetsenbordinteractie per patroon.

Een element met role="button" gedraagt zich bijvoorbeeld niet automatisch als een echte button. Een element met role="dialog" houdt focus niet automatisch binnen de dialoog. En aria-live maakt een onduidelijke foutmelding niet ineens bruikbaar.

Veelgemaakte fouten met ARIA

• Dubbele of strijdige semantiek: een native knop krijgt een onnodige afwijkende rol of tegenstrijdige naam.
• Een klikbare div of span: de ontwikkelaar voegt een rol toe, maar vergeet toetsen, focus of statusbeheer.
• Onjuiste aria-hidden: belangrijke inhoud of een focusseerbaar element wordt verborgen voor screenreaders.
• Statische states: aria-expanded, aria-selected of aria-pressed verandert niet mee met de interface.
• Alleen een visueel icoon: een knop heeft geen toegankelijke naam, waardoor de functie onbekend blijft.
• ARIA als WCAG-stempel: een attribuut kan bijdragen aan toegankelijkheid, maar bewijst niet dat een complete gebruikersflow aan WCAG voldoet.

ARIA controleren in WordPress

In WordPress komen ARIA-problemen vaak uit thema's, page builders, formulierplugins, cookieoplossingen en menuplugins. Controleer dus niet alleen losse pagina-inhoud, maar ook globale componenten zoals header, mobiele navigatie, zoekfunctie en footer.

Praktische werkwijze:

• Open een pagina in de browser en bedien de volledige route met alleen het toetsenbord.
• Controleer de broncode van knoppen, links en formuliervelden. Zoek vooral naar klikbare div- en span-elementen.
• Gebruik browserhulpmiddelen om naam, rol en state in de accessibility tree te bekijken.
• Test een menu, modal en formulier na elke plugin- of thema-update opnieuw.
• Laat maatwerkcomponenten bouwen op basis van bewezen patronen in plaats van losse ARIA-attributen te kopiëren.

De WordPress-richtlijnen voor toegankelijkheid verwijzen eveneens naar WCAG en de WAI-ARIA Authoring Practices. Dat past bij een bredere aanpak waarin ontwerp, content, techniek en onderhoud samenkomen. Een solide basis begint bij strategisch en creatief webdesign, waarin interacties niet pas na oplevering toegankelijk hoeven te worden gemaakt.

ARIA en WCAG 2.2

ARIA is relevant voor meerdere toegankelijkheidsvraagstukken, waaronder het begrijpelijk maken van naam, rol en waarde van interfaceonderdelen. De techniekpagina ARIA4 van W3C legt de relatie met succescriterium 4.1.2 uit. Dat betekent niet dat één ARIA-techniek volledige conformiteit garandeert.

Beoordeel altijd de hele ervaring: is de bediening via toetsenbord mogelijk, blijft focus logisch, is de tekst duidelijk, is de foutmelding bruikbaar en kondigt hulptechnologie dezelfde relevante informatie aan als visuele gebruikers krijgen?

Praktische checklist voor publicatie

• Zijn alle acties gebouwd met een native button en alle navigatie met een echte link?
• Heeft iedere interactieve bediening een duidelijke, toegankelijke naam?
• Zijn zichtbare statuswijzigingen ook programmatisch beschikbaar?
• Wijzigen ARIA-states altijd mee met de werkelijke interface?
• Zijn decoratieve iconen verborgen zonder belangrijke inhoud of focus te verbergen?
• Werken menu's, accordeons, modals en formulieren zonder muis?
• Is focus zichtbaar en logisch tijdens openen, sluiten en foutafhandeling?
• Zijn thema, plugins en maatwerk na updates opnieuw getest?

Samenvatting

Correct ARIA-gebruik begint niet met attributen, maar met semantisch HTML en een begrijpelijke interactie. Voeg ARIA alleen toe als die aantoonbaar extra betekenis geeft. Test vervolgens altijd naam, rol, status, toetsenbordbediening en focus als één geheel.

Toegankelijkheid hangt ook samen met technisch onderhoud. Foutieve links en foutpagina's kunnen gebruikers eveneens blokkeren; lees daarom onze gids over 404- en soft-404-fouten oplossen. Wil je toegankelijkheid structureel meenemen in ontwerp, ontwikkeling en optimalisatie? Bekijk dan de diensten van LYNX Media of bespreek je website of online groeikansen met LYNX Media.