WAI-ARIA

Wat is WAI-ARIA?

WAI-ARIA is een specificatie van het W3C. Het voegt semantiek toe aan elementen door middel van attributen zoals:

• role (wat is het element)
• aria-* states (wat is de huidige toestand)
• aria-* properties (extra eigenschappen of relaties)

Voorbeelden:

• role="button"
• aria-expanded="true"
• aria-label="Zoeken"

Belangrijk: ARIA verandert geen styling en voegt geen interactie toe. Het voegt alleen betekenis toe
voor hulptechnologie.

De gouden regel: gebruik eerst HTML

Als je een knop wil, gebruik dan een <button>. Als je navigatie bouwt, gebruik <nav>. Standaard HTML-elementen hebben ingebouwde toegankelijkheid, inclusief toetsenbordgedrag en screenreader-ondersteuning.

ARIA is pas de tweede stap.

Vuistregel: “Geen ARIA is beter dan slechte ARIA.”

Wanneer heb je WAI-ARIA wél nodig?

1) Custom componenten die geen native HTML alternatief hebben

Bijvoorbeeld:

• custom dropdown (combobox)
• accordion
• tabs
• modal dialog

Deze patronen hebben vaak extra semantiek nodig, zodat screenreaders snappen wat er gebeurt.

2) Dynamische content updates

Als content verandert zonder page reload, moet je dat soms “announceable” maken:

• aria-live="polite" bij statusmeldingen
• role="status" of role="alert" bij meldingen

3) Naamgeving wanneer er geen zichtbaar label is

Soms is er een icon-only button en moet je een toegankelijke naam toevoegen met:

• aria-label
• of aria-labelledby

Wanneer je ARIA beter níet gebruikt

1) Om semantiek te “fixen” die je met HTML hoort te doen

Een <div role="button"> is bijna altijd slechter dan <button>, omdat je zelf toetsenbord-interactie en states moet bouwen.

2) Om te verbergen wat zichtbaar is (of omgekeerd)

Bijvoorbeeld een element zichtbaar maken maar aria-hidden="true" laten staan. Dat is verwarrend en kan content volledig onbruikbaar maken voor screenreaders.

3) Als je niet alle bijbehorende interactie en states implementeert

ARIA vraagt vaak om een compleet “contract”: toetsenbordbediening, focus management, juiste states.

Praktische ARIA voorbeelden (goed en fout)

Voorbeeld 1: icon button met toegankelijke naam

Goed

<button aria-label="Zoeken">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Waarom goed?

• Knop is native (<button>)
• Screenreader krijgt een duidelijke naam
• Icon wordt genegeerd door hulptechnologie

Voorbeeld 2: accordion met
aria-expanded

Goed (basis)

<button aria-expanded="false" aria-controls="sectie-1" id="toggle-1">
  Veelgestelde vragen
</button>

<div id="sectie-1" role="region" aria-labelledby="toggle-1" hidden>
  ...
</div>

Belangrijk

• aria-expanded moet updaten naar true of false
• hidden moet mee togglen (of display: none)
• Focus moet logisch blijven

Voorbeeld 3: “div button” (fout)

Fout

<div role="button">Verzenden</div>

Wat gaat hier mis?

• Niet focusable (tab werkt niet)
• Enter en Spatie werken niet automatisch
• Geen disabled state ondersteuning
• Je moet alles zelf bouwen

Beter

<button type="submit">Verzenden</button>

ARIA en WCAG: welke criteria raken dit?

WAI-ARIA is geen WCAG-succescriterium op zichzelf, maar speelt vaak mee bij:

• 1.3.1 Info and Relationships (semantiek en relaties)
• 4.1.2 Name, Role, Value (toegankelijke naam, rol en status)
• 2.1.1 Keyboard (toetsenbordbediening, zeker bij custom componenten)
• 1.1.1 Non-text Content (icon-only controls die geen naam hebben)

In audits zien we dat ARIA-fouten vaak direct zorgen voor issues in Name, Role, Value en Keyboard.

Veelgemaakte ARIA fouten (audit checklist)

• aria-label gebruikt terwijl er al een zichtbaar label is (dubbele naamgeving)
• aria-expanded niet synchroon met de echte UI state
• aria-controls verwijst naar een ID die niet bestaat
• aria-hidden="true" op parent terwijl interactieve children eronder zitten
• Roles gebruiken die niet passen bij het element
• Live regions spammen met te veel updates
• Focus verdwijnt bij modals of menus door ontbrekend focus management

Snelle best practices

• Gebruik native HTML waar het kan
• ARIA is aanvullend, niet vervangend
• Geef interactieve elementen altijd een toegankelijke naam
• Test met toetsenbord en een screenreader
• Houd states synchroon met de UI
• Gebruik bewezen ARIA patterns (accordion, dialog, tabs)

Veelgestelde vragen

Is ARIA verplicht voor WCAG?

Nee. Maar als je custom componenten bouwt, is ARIA vaak nodig om aan WCAG te voldoen.

Mag ik ARIA gebruiken om een div een button te maken?

Technisch kan het, maar vrijwel altijd is een echte <button> beter. Als je toch een custom element gebruikt, moet je ook focus, toetsenbordgedrag en states volledig correct implementeren.

Wat is het verschil tussen aria-label en aria-labelledby?

aria-label geeft een directe tekstnaam. aria-labelledby verwijst naar bestaande tekst in de pagina,
meestal beter omdat het zichtbaar en consistent is.