ARIA staat voor "Accessible Rich Internet Applications". Net als de Web Content Accessibility Guidelines is ARIA een W3C specificatie. Ze definieert een reeks attributen die de semantiek van een webtoepassing verbeteren. Deze ARIA-attributen hebben geen invloed op de layout en ze veranderen niet hoe browsers met het element omgaan. Het enige wat ARIA-attributen doen, is informatie toevoegen voor de software waarmee personen met een handicap hun computer bedienen (voornamelijk screenreaders).
Met ARIA-attributen kunt u:
- componenten toegankelijk maken waarvoor in HTML geen element bestaat, zoals een tabpaneel.
- een status aangeven die visueel duidelijk is maar niet voor screenreadergebruikers, bijvoorbeeld is een submenu in- of uitgeklapt?
- een screenreader laten melden dat er informatie is bijgekomen of gewijzigd in een webpagina via een live region.
- onderdelen van een webpagina of webtoepassing duidelijker benoemen voor blinden die het scherm niet zien.
Browser informeert screenreader via accessibility tree
Een screenreader is software die de tekst van het scherm voorleest aan blinde computergebruikers. Dat lukt goed voor tekst, tabellen, formulieren en andere standaard-toepassingen van websites, maar screenreaders hebben het moeilijker met componenten, overlays en andere dynamische updates die met Javascript zijn geprogrammeerd omdat de functionaliteit niet voorzien is in HTML.
Om hun werk te kunnen doen, zijn hulpmiddelen zoals een screenreader afhankelijk van de informatie die ze van de browser krijgen. Kort gezegd, bouwt een browser een accessibility tree met de informatie uit de webpagina en de scripts. Het is deze accessibility tree die de screenreader gebruikt om informatie voor te lezen en aan te kondigen aan de gebruiker. In de accessibility tree heeft elke component een rol, een naam, een status en eigenschappen. Standaard HTML-componenten vullen die impliciet in. De <button>Search</button> vult de accessibility tree met een element met:
- Rol: button,
- Naam: Search,
- Status: unselected.
- Eigenschap: focusable
In de gevallen die afwijken van standaard HTML/CSS, vb. overlays, tabsystemen, uitklapmenu's en bepaalde interactieve elementen in HTML5 heeft de browser onvoldoende gegevens om de accessibility tree te vullen en kan een screenreader dus niet alles aankondigen.
De informatie die ontbreekt in de accessibility tree kunnen we aanvullen met ARIA-attributen die expliciet de rol, naam, status en/of eigenschappen toevoegen. ARIA-attributen kunnen ook informatie in de accessibility tree overschrijven maar dit moet met zorg gebeuren.
Gebruik zoveel mogelijk standaard HTML-elementen
Bij gebruik van standaard HTML-elementen voorzien browsers standaardgedrag en geven alle informatie ook door aan screenreaders en de andere hulpmiddelen die mensen met een handicap gebruiken. Bijvoorbeeld voor een select-element voorziet de browser automatisch dat je ernaar toe kunt tabben, dat je met de pijltoetsen een keuze kunt maken en dat je door de eerste letter in te typen meteen naar de optie gaat die met die letter begint. Ook gebruikers (her)kennen dit en kunnen het zonder uitleg gebruiken. Een screenreader zal het conssistent als keuzelijst aankondigen enz.
Als er een HTML-element bestaat voor de functie die je nodig hebt, gebruik dat dan. Het is bijvoorbeeld veel gemakkelijker om knoppen altijd met button te maken. Als je div onclick gebruikt dan is dat element aanklikbaar met de muis, maar het gedraagt zich voor de rest niet als een knop. Het standaardgedrag dat browsers aan een knop geven, moet je nu zelf voorzien.
|
|
|---|---|
| Browsers, hulpmiddelen, zoekmachines herkennen het als knop | Semantisch gezien is het geen knop (dus ook niet in de accessibility tree) |
| Screenreader zegt "Pauze knop" | Screenreader zegt "Pauze" |
| Zelfs zonder CSS herkenbaar als knop; visueel duidelijk dat men erop kan klikken | Zonder CSS niet herkenbaar als knop; zelfs onMouseOver is er standaard geen aanduiding dat het klikbaar is |
| Bereikbaar met tabtoets | Niet bereikbaar met tabtoets |
| Activeerbaar met Enter en Spatie | Niet activeerbaar met toetsenbord (want niet bereikbaar) |
| Zichtbare outline | Geen outline |
Als je een div in plaats van een button-element gebruikt, moet je alle zaken in de rechterkolom zelf voorzien:
- Als je het ARIA-attribuut
role="button"aan dedivtoevoegt, lost dat alleen de eerste twee zaken op: de component is in de accessibility tree een knop geworden. Een screenreader zal het nu ook als knop aankondigen, maar met deze ARIA-role los je niet de overige zaken op. - Het ziet er visueel nog niet als een knop uit.
- De screenreader zegt nu wel dat het een knop is, maar de gebruiker kan hem nog niet activeren door op enter te drukken.
- Toetsenbordgebruikers kunnen er nog niet naartoe tabben.
Dit is op te lossen met het tabindex-attribuut en Javascript events die reageren op de Enter- en spatietoets, maar dit alles is veel ingewikkelder dan een standaardcomponent te gebruiken. Zie ook JavaScript OnClick? Gebruik dan a of button
Wat zijn de mogelijkheden en regels om de rol, status en eigenschappen en de naam van een component in de accessibility tree te beïnvloeden?
Wanneer ARIA gebruiken?
- Gebruik ARIA alleen als er informatie ontbreekt in de accessibility tree of als die informatie niet correct is.
- Als je een toolkit of UI framework gebruikt, is ARIA soms al ingebouwd of via een plugin toe te voegen.
- Als je zelf componenten bouwt die je met HTML en CSS niet toegankelijk kunt maken, pas dan ARIA toe. Volg daarbij altijd de authoring patterns. Deze beschrijven hoe de component moet werken en wat je allemaal moet voorzien zodat verschillende gebruikers de component goed kunnen gebruiken. Voor een tabsysteem hebben we dit uitgeschreven.
- Als je ARIA-attributen toevoegt, moet je goed weten wat je doet. Verkeerde of overbodige ARIA-attributen kunnen een component onbruikbaar maken.
Ondersteuning
Om ARIA goed te laten werken, moet zowel de browser als de screenreader het ondersteunen. Als die ondersteuning ontbreekt, worden alle ARIA-attributen genegeerd: een div role="button" wordt terug een
div.
Hoe recenter de versie van de browser en de screenreader, hoe beter de ondersteuning. Er zitten verschillende bugs in oudere versies. Veel mensen werken echter niet met de meest recente versies. Daarom pleiten we ervoor om ARIA enkel te gebruiken als het niet anders kan.
Sommige ARIA-roles forceren de screenreader in een andere interactiemodus. Veel gebruikers zijn hier nog niet mee vertrouwd en kunnen denken dat ze iets fout hebben gedaan of dat de website vreemd reageert. Dit is iets om bewust van te zijn, maar als ontwikkelaar kan je enkel de standaarden volgen. Zo is de ervaring voor de gebruiker zo consistent mogelijk en zo zullen ze er het snelst vertrouwd mee raken.
Testen
Als je ARIA gebruikt, dan moet je je implementatie testen met verschillende screenreaders en andere computerhulpmiddelen omdat ARIA in eerste instantie bedoeld is als ondersteuning voor deze hulpmiddelen.
Onthoud dat ARIA geen impact heeft op toegankelijkheid voor toetsenbordgebruikers. Je moet je componenten dus ook testen met het toetsenbord want het is niet omdat je een div een role="button" of role="tab" geeft dat je er naartoe kunt tabben. Dit moet je zelf voorzien door het tabindex-attribuut te managen.
Samengevat
- Met ARIA-attributen wijzig je informatie in de accessibility tree of je vult ontbrekende informatie aan.
- De informatie in de accessibility tree wordt enkel gebruikt door screenreaders en andere hulpmiddelen die mensen met een handicap gebruiken.
- ARIA verandert dus niets aan de toegankelijkheid voor mensen die deze hulpmiddelen niet gebruiken. Toegankelijkheid met het toetsenbord moet je blijven testen, los van het ARIA-gebruik.
- Als er een HTML-element of -attribuut bestaat voor de functie die je nodig hebt, gebruik dat dan.
- Een role verandert enkel hoe de component wordt aangekondigd door de screenreader. Roles toevoegen, volstaat dus niet. Je moet ook in Javascript de functionaliteit programmeren.
- Als je het role-attribuut gebruikt, krijgt dat voorrang, ongeacht aan welk element het is toegevoegd. ARIA wint!
- Verkeerde of overbodige ARIA-attributen is meestal erger dan geen ARIA. Een aantal roles zijn niet bedoeld voor wat hun naam doet vermoeden. Gebruik geen
role="menu"voor navigatie en Gebruik geen role="application" - Het is goed dat we met ARIA extra informatie kunnen geven aan screenreadergebruikers, maar overdrijf niet.
Reacties
Reageer als eerste