• gepubliceerd
  • leestijd
    ± 4 minuten

De 5 regels van ARIA

In dit blog vertel ik wat je kan met ARIA en wat je er vooral niet mee moet doen. Hoe kan ARIA digitale toeganke­lijkheid beinvloeden in HTML?

Afgelopen woensdag 10 maart en donderdag 11 maart was het einde­lijk tijd voor axe-con, Deque’s eigen online toeganke­lijkheidscongres. Twee dagen bomvol lezingen over de toekomst van toeganke­lijkheid, praktische tips en concrete voorbeelden. Ik keek naar de lezing ARIA Spec for the Uninitiated van Gerard Cohen van het accessibility team van Twitter. Wat kan je met ARIA en wat moet je er vooral niét mee doen? Ik vertel het je in dit blog.

html uitgebeeld op toetsenbord

Wat is ARIA?

Je weet inmiddels dat het over het algemeen het beste is om ‘schone HTML’ te gebruiken bij het maken van je website, als je die zo toeganke­lijk moge­lijk wilt maken. De HTML-standaard is goed in staat om structuur en betekenis te geven aan web elementen en die informatie door te geven aan hulpsoftware. Maar hoe maak je iets toeganke­lijk, wanneer HTML dat niét kan? Dan kan de Web Accessibility Initiative’s Accessible Rich Internet Applications specification, WAI-ARIA voor vrienden, je uit de brand helpen. Met ARIA voeg je attributen toe aan je HTML, die de informatie in de accessibility tree (een versie van de DOM die gebruikt wordt door hulpsoftware om de informatie op websites te interpreteren) wijzigen. ARIA is een hele fijne manier om toeganke­lijkheid te waarborgen, óf een desastreuse manier om je website totaal ontoeganke­lijk te maken. Het is maar wat je er mee doet. Daarom spreken onderzoekers en developers die zich specialiseren in digitale toeganke­lijkheid ook wel gekscherend over de 5 regels van ARIA. Herinner je je de eerste regel van Fightclub nog?

Regel 1: Gebruik geen ARIA

Oké, oké, de zin was nog niet af. Maar zoals ik eerder al zei, het liefst gebruik je gewoon helemaal geen ARIA. De volledige zin is name­lijk: Gebruik geen ARIA waar je native HTML kunt gebruiken. De specificatie wordt name­lijk niet door alle browsers en hulpsoftware ondersteund. De huidige HTML standaard, HTML5, bevat voor de meest gangbare functies wel een element. Met CSS pas je vervolgens het uiter­lijk aan, zodat je knoppen, links en lijsten helemaal binnen jouw huisstijl passen. Het is dus in de meeste gevallen écht niet nodig om zelf te gaan zitten knutselen met divjes en spannetjes. Je loopt véél meer risico op een ontoeganke­lijke website als je geen gebruikt maakt van de functies die native HTML je biedt. Wees ook altijd selectief met het gebruik van ARIA-attributen en test je werk het liefst in meerdere browsers en met minimaal één screenreader. Maar daarnaast loert er nog een gevaar: met ARIA maak je, als je niet oppast, van iets wat al toeganke­lijk was iets ontoeganke­lijks.

Regel 2: Pas de betekenis van native HTML niet aan

Een ARIA-attribuut overschrijft name­lijk de semantische waarde van native HTML elementen en attributen. Van een <button> maak je met role=img iets waar je bezoekers die een screenreader gebruiken niets meer van snappen. Een native HTML-element heeft van zichzelf al een rol, daar hoef jij helemaal niets meer aan te doen en je moet al zéker niet zelf gaan lopen knutselen met ARIA-rollen. Voor je het weet ben je qua toeganke­lijkheid nog veel verder van huis.

Regel 3: Zorg dat interactieve elementen toetsenbordtoeganke­lijk zijn

Met ARIA pas je zoals gezegd de informatie in de accessibility tree aan. Maar je voegt er géén functionaliteit mee toe. Je zelf-geknutselde knop is niet ineens toeganke­lijk door er role=button aan toe te voegen. Door ARIA attributen te gebruiken, doe je eigen­lijk een belofte aan de bezoeker op je website. Nee, ik weet dat dit geen native HTML-knop is, maar hij werkt wél echt, beloofd! Zorg er dus voor dat wat je gemaakt hebt er niet alleen uit ziet als een knop en met de muis werkt, maar ook met het toetsenbord.

Regel 4: Maak zichtbare interactieve elementen nooit onzichtbaar voor hulpsoftware

Met ARIA voeg je geen functionaliteit toe, maar technisch gezien kan je er wel functionaliteit mee wégnemen. De attributen role=presentation en aria-hidden=true hebben beiden als resultaat dat content niet meer beschikbaar is voor hulpsoftware. Is je knop zichtbaar en interactief voor ziende gebruikers die een muis gebruiken? Dan moet je knop óók zichtbaar en interactief zijn voor gebruikers die een screenreader gebruiken en met het toetsenbord navigeren.

Regel 5: Geef alle interactieve elementen een toeganke­lijke naam

Stel je eens voor dat je op een website bent en een formulier moet invullen, bijvoorbeeld om je verhuizing door te geven aan de gemeente. Alle formuliervelden hebben de naam ‘formulierveld’, alle checkboxes de naam ‘checkbox’ en onder het formulier staan een paar grote knoppen waar alleen maar ‘knop’ op staat. Succes met invullen en versturen! Zo ziet die pagina er uit voor hulpsoftwaregebruikers als elementen geen toeganke­lijke naam hebben. Van ieder interactief element moet het niet alleen visueel duide­lijk zijn wat het doet, maar ook ‘onder water’ moet beschreven worden waar het element voor is.

Duizelt het je een beetje? Dat is gelukkig nergens voor nodig. Zolang je de eerste regel maar goed in je achterhoofd houdt, ben je al een heel end op weg. Wil je je verder inlezen in ARIA? Het W3C, het World Wide Web Consortium, heeft richtlijnen opgesteld voor WAI-ARIA. Het juiste gebruik van deze specificatie brengt je weer een stap dichterbij een toeganke­lijke website.