Moderne websites zitten vol onderdelen die HTML niet kent. Uitklapmenu’s, tabbladen, accordeons, meldingen die verschijnen. Voor een ziende bezoeker werkt dat prima. Een screenreader ziet alleen een stapel naamloze divs. De gebruiker hoort dan niets zinnigs en klikt weg.
ARIA is bedoeld om dat gat te dichten. Maar let op: verkeerd gebruikt maakt het je site juist onbruikbaar. De eerste regel van ARIA luidt niet voor niets: gebruik geen ARIA.
Een makelaarskantoor uit Alkmaar liep hier tegenaan. Hun woningfilter werkte met mooie schuifjes en schakelaars. Een bezoeker met een screenreader hoorde alleen het woord knop. Of de filter aan of uit stond, bleef volstrekt onduidelijk. Aanvragen via dat filter kwamen nauwelijks binnen.
Ik heb de schakelaars omgebouwd naar echte checkboxes. Waar dat niet kon, voegde ik aria-checked toe. Die waarde wordt nu keurig bijgewerkt in JavaScript. Het filter is sindsdien volledig bruikbaar met toetsenbord en screenreader. De klant kreeg er geen extra ontwerpwerk bij, alleen betere code.
Wat betekent ARIA?
ARIA staat voor Accessible Rich Internet Applications. Het is een set aria-attributen die je aan HTML toevoegt. Die attributen vertellen hulpsoftware wat een element doet. Ze veranderen niets aan het uiterlijk. Ze veranderen ook niets aan de werking.
Dat laatste is cruciaal. ARIA belooft iets, maar bouwt het niet. De echte functionaliteit schrijf je zelf in JavaScript.
ARIA voegt betekenis toe waar gewone HTML tekortschiet.
Waarom bestaat ARIA?
Gewone HTML heeft een beperkt aantal elementen. Een knop, een link, een formulierveld, een lijst. Moderne interfaces gaan verder dan dat. Denk aan tabbladen en meldingen die live veranderen.
Voor zulke onderdelen bestaat geen standaard HTML-element. Een screenreader ziet dan alleen een reeks divs. ARIA vult dat gat met betekenis. Zo weet de gebruiker wat hij voor zich heeft.
De drie soorten ARIA-attributen
Roles: wat is dit ding?
Een role beschrijft de functie van een element. Bijvoorbeeld role is dialog bij een modal. Of role is navigation bij je hoofdmenu. De screenreader kondigt die rol vervolgens aan.
States: in welke toestand staat het?
States veranderen tijdens het gebruik. Denk aan aria-expanded bij een uitklapmenu. Die waarde springt van false naar true. Of aria-checked bij een schakelaar. Jij moet die waarde wel bijwerken in je code.
Properties: welke eigenschappen horen erbij?
Properties zijn meestal vast. Denk aan aria-label voor een naam. Of aria-describedby voor een verwijzing naar uitleg. Ze koppelen elementen aan elkaar binnen de DOM.
Praktijkvoorbeelden uit mijn werk
Een hamburgermenu
Voor een toegankelijk menu krijgt de knop aria-expanded en aria-controls. Bij openen zet ik de waarde op true. De screenreader meldt dan netjes uitgeklapt. Zonder die attributen hoort de gebruiker helemaal niets.
Een icoonknop zonder tekst
Een kruisje om te sluiten heeft geen zichtbare tekst. Ik geef die knop dan een aria-label. Bijvoorbeeld sluiten of menu sluiten. Zo krijgt de knop alsnog een naam.
Een melding na het versturen van een formulier
Een succesmelding verschijnt vaak dynamisch op de pagina. Met aria-live is polite wordt die voorgelezen. De gebruiker weet daardoor dat zijn bericht is verstuurd.
Valkuilen waar ik regelmatig tegenaan loop
Vier veelgemaakte fouten
Een div met role is button, terwijl een button-element bestaat.
Een aria-label dat afwijkt van de zichtbare tekst.
Een state die nooit wordt bijgewerkt in JavaScript.
ARIA op elementen die al de juiste semantiek hebben.
Dat laatste noemen we dubbele aankondiging. De gebruiker hoort dan twee keer hetzelfde. Vervelend en verwarrend.
Ook aandacht voor toetsenbordbediening
ARIA regelt geen focus en geen toetsenbordbediening. Bouw je een custom tabblad, dan schrijf je dat zelf. Denk aan pijltjestoetsen en de escape-toets. Zonder die logica is de rol een lege belofte.
Hoe test je ARIA?
Ik open eerst de accessibility-boom in de browser. Daarin zie je hoe hulpsoftware je pagina interpreteert. Daarna doe ik een ronde met een echte screenreader. Tot slot check ik de code op validatie fouten.
Automatische scanners vinden veel, maar niet alles. Ze zien niet of een label logisch klopt. Handmatig testen blijft daarom noodzakelijk. Ik neem zo’n ronde mee bij periodiek onderhoud, want een thema-update kan ARIA stilletjes breken.
Mijn advies
Begin altijd met correcte, semantische HTML. Kom je daarmee niet uit, pak dan ARIA erbij. Werk gericht en test elke toevoeging. En houd die eerste regel in je achterhoofd. Minder ARIA is meestal beter dan meer. Kijk ook naar je navigatie als startpunt.
Meer vragen over ARIA
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat is ARIA en waar gebruik je het voor?
Wanneer gebruik je ARIA en wanneer juist niet?
Wat is het verschil tussen ARIA en semantische HTML?
Hoe test je of ARIA op je website klopt?
Hoe maak je een uitklapmenu toegankelijk?
Welke fouten met ARIA komen het vaakst voor?
Is ARIA verplicht?
Ja, en dat is geen theoretisch risico. Foute ARIA is aantoonbaar erger dan helemaal geen ARIA. Onderzoek naar toegankelijkheidsfouten laat dat elk jaar opnieuw zien.
Het komt doordat ARIA een belofte doet. Zeg je role is button, dan verwacht de gebruiker een knop. Werkt die knop niet met de spatiebalk, dan is het vertrouwen weg. De bezoeker denkt dat de site kapot is.
Een tweede klassieker is de verkeerde naam. Je zet aria-label op sluiten, terwijl er versturen staat. Een ziende bezoeker leest versturen, een blinde bezoeker hoort sluiten. Spraakbediening werkt dan ook niet meer.
De derde is een state die nooit meebeweegt. Aria-expanded blijft op false staan, terwijl het menu open is. Dan lieg je continu tegen je bezoeker.
Zorg dus dat elke toevoeging klopt. Test daarna met een echte screenreader.
Laat het bij twijfel liever weg. Een kale div zonder rol is verwarrend. Een div met de verkeerde rol is misleidend, en dat is erger.
Kan ARIA mijn website slechter maken?
ARIA zelf is niet verplicht. Er staat nergens in de wet dat je aria-attributen moet gebruiken. Wat wel steeds vaker verplicht is, zijn de richtlijnen van WCAG.
Dat verschil is belangrijk. WCAG beschrijft het doel: je site moet bruikbaar zijn voor iedereen. ARIA is slechts één gereedschap om dat doel te halen. Er zijn vaak betere gereedschappen beschikbaar.
Neem een uitklapmenu. Je kunt dat bouwen met divs en ARIA erbij. Je kunt het ook bouwen met een button-element en een details-element. De tweede route is korter, robuuster en foutgevoeliger.
Mijn volgorde is daarom altijd hetzelfde. Eerst kijken of standaard HTML het kan. Kan dat niet, dan pas ARIA erbij pakken. En daarna testen met echte hulpsoftware. Zo voldoe je aan de richtlijn zonder onnodige complexiteit toe te voegen.
Vraag het jezelf per onderdeel af. Bestaat hier een standaard element voor? Zo ja, gebruik dat. Zo nee, dan pas ARIA erbij pakken.
Wat is het verschil tussen ARIA en semantische HTML?
Semantische HTML is het echte materiaal. Een button-element is een knop, met alles erop en eraan. Hij is klikbaar, bereikbaar met de tabtoets en werkt met enter en spatie. Dat krijg je gratis van de browser.
ARIA is slechts een label op materiaal dat die eigenschappen niet heeft. Een div met role is button ziet eruit als een knop voor hulpsoftware. Maar hij doet nog niets. De browser levert geen gedrag, alleen de betekenis is aangepast.
Dat is het hele verschil in één zin. HTML geeft betekenis én gedrag, ARIA geeft alleen betekenis.
Daarom luidt de eerste regel: gebruik geen ARIA als HTML het kan. Je bespaart jezelf code en je bespaart jezelf fouten. ARIA is er voor de gevallen waar HTML echt tekortschiet. Denk aan tabbladen, meldingen en complexe filters.
Denk ook aan focusgedrag. Een echte knop krijgt automatisch focus, een div niet. Dan moet je tabindex zelf toevoegen, en dat wordt vaak vergeten.
Beinvloedt ARIA mijn vindbaarheid in Google?
Niet rechtstreeks. Zoekmachines kijken naar je HTML-structuur, niet naar je aria-attributen. Een role of een aria-label levert je geen positie op.
Toch is er wel een verband. ARIA gebruik je meestal in een bredere aanpak rond accessibility. En die aanpak raakt wel zaken die Google meeweegt. Nette koppen, duidelijke linkteksten, werkende navigatie.
Er is ook een negatief scenario. Bouw je alles met divs en plak je er ARIA op? Dan mist Google de semantiek volledig. Een zoekmachine ziet dan geen navigatie en geen koppen. Dat kost je wel degelijk.
De conclusie is dus genuanceerd. Gebruik ARIA niet als SEO-middel, want dat werkt niet. Gebruik semantische HTML als basis, want dat werkt voor allebei. ARIA is de aanvulling, nooit het fundament.
Kijk daarom eerst naar je HTML-opbouw. Gebruik je header, nav, main en footer? Zo niet, dan is dat je eerste verbeterpunt. Pas daarna is ARIA aan de beurt. Die volgorde bespaart je bovendien een hoop overbodige code.
Hoe test ik of mijn ARIA klopt?
Ik werk in vier stappen en dat kost me een half uur per sjabloon.
Stap één is de accessibility-boom in je browser. Die opent bij de ontwikkelaarstools. Daarin zie je precies hoe hulpsoftware jouw pagina interpreteert. Staat er een knop zonder naam, dan zie je dat meteen.
Stap twee is het toetsenbord. Ik navigeer de hele pagina met alleen de tabtoets. Elk element moet bereikbaar zijn en een zichtbare focusrand hebben. Kom ik ergens vast te zitten, dan is er werk.
Stap drie is een echte screenreader. Automatische scanners vinden ongeveer een derde van de problemen. De rest hoor je pas als je luistert.
Stap vier is de code zelf. Ik controleer op fouten via validatie. Dubbele id’s en verkeerde verwijzingen zijn een veelvoorkomende oorzaak.
Doe deze ronde na elke grote wijziging. Een nieuwe plugin of een thema-update kan alles omgooien. Vijf minuten controleren voorkomt maanden onopgemerkte fouten. Noteer je bevindingen kort, zodat je bij de volgende ronde sneller werkt.
Twijfel je of jouw menu of filter bruikbaar is met hulpsoftware? Laat het me weten via het formulier hieronder. Ik test je belangrijkste sjablonen met toetsenbord en screenreader. Je krijgt een korte lijst met wat er misgaat en waarom. Zet je plaats erbij, dan weet ik meteen waar je zit.
Waar kan ik je mee helpen?
Ook bekend als: Accessible Rich Internet Applications, WAI-ARIA, aria-attributen
