Accessible Rich Internet Applications (ARIA)

ARIA staat voor "Accessible Rich Internet Applications". Net als de Web Content Accessibility Guidelines is ARIA een W3C specificatie. Ze definiëert 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:

  • widgets 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 widgets, 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 code <button>Search</button> vult de accessibility tree met een component 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 u nodig heeft, gebruik dat dan. U maakt het zichzelf bijvoorbeeld veel gemakkelijker door knoppen altijd met button te maken. Als u 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 u nu zelf voorzien.

Twee manieren om een knop te programmeren

<button>Pauze</button>

<div onclick="..." class="pauzeknop">Pauze</div>
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 u een div in plaats van een button-element gebruikt, moet u alle zaken in de rechterkolom zelf voorzien:

  • Als u het ARIA-attribuut role="button" aan de div toevoegt, 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 lost u 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 doet het role-attribuut?

Een belangrijk ARIA-attribuut is role. Het role-attribuut kunt u toevoegen aan om het even welk (X)HTML(5)-element, maar hou rekening met de volgende regels:

  • Als de component nog geen rol heeft in de accessibility tree, dan voegt het role-attribuut die toe.
  • Als de component al wel een rol heeft in de accessibility tree, dan overschrijft het role-attribuut deze bestaande rol.
  • Dit is het enige wat het role-attribuut doet. Het voegt geen gedrag, status of eigenschappen toe.

Overschrijft semantiek

Als u een ARIA role toevoegt, overschrijft u de native role semantics van het element. Voeg een role dus in principe enkel toe aan elementen die nog geen semantiek hebben zoals een div.

Slecht voorbeeld:

<ul role="navigation">
 ...
 </ul>

De semantiek van het lijst-element wordt hier overschreven door role="navigation". In de accessibility tree is er dus geen lijst meer. De screenreader zal wel aankondigen dat hier de navigatie begint maar zal niet meer melden dat er een lijst van x items is.

Goed voorbeeld:

<nav role="navigation">
 <ul>
 ...
 </ul>
</nav>

ARIA-roles toevoegen, moet zorgvuldig gebeuren want een element kan maar 1 rol hebben. Als u het role-attribuut gebruikt, krijgt dat voorrang, ongeacht aan welk element het is toegevoegd. ARIA wint!

Voegt geen gedrag, status of eigenschappen toe

Als u een role-attribuut toevoegt, verandert er niets aan het gedrag, de status of de eigenschappen van de component.

<div role="heading" aria-level="1">Tekst</div>

wordt in de accessibility tree:

<h1>Tekst</h1>

Screenreaders zullen het als kop voorlezen maar visueel (en ook voor zoekmachines) is er echter niets veranderd.

Zoals eerder gezegd, volstaat het ook niet om role="button" aan een div toe te voegen. De screenreader zal wel zeggen dat het een knop is maar de knop zal niets doen.

Het toevoegen van ARIA-roles is dus meestal niet voldoende.

Welke roles?

Er bestaan een zeventigtal waarden voor het role-attribuut. Een eerste groep zijn de landmark roles. Deze zijn nuttig om te gebruiken in elke moderne website want ze helpen screenreader- en toetsenbordgebruikers vlotter te navigeren door een pagina. De speciale landmark role="application" mag u daarentegen bijna nooit gebruiken.

Een aantal roles zijn niet bedoeld voor wat hun naam doet vermoeden. Zo is het niet de bedoeling dat u role="menu" gebruikt voor de navigatie van uw website. De menu role is bedoeld voor knoppenbalken maar niet voor een opsomming van links, ook al hebben die een submenu. Meer voorbeelden in het artikel How Not To Misuse ARIA States, Properties and Roles

Het toevoegen van de verkeerde ARIA-roles kan zaken helemaal ontoegankelijk maken. Een role creëert een bepaalde verwachting bij de hulpmiddelengebruiker. Als u aan een element een role="checkbox" geeft, zal de gebruiker proberen die te activeren met de spatiebalk. Als het niet om een aankruisvakje gaat zoals de role doet vermoeden, dan is er een groot probleem.

Status en eigenschappen

In de accessibility tree hebben elementen, naast een rol, ook een status en eigenschappen. Ook deze waarden kunt u in de accessibility tree toevoegen of wijzigen via ARIA-attributen. Deze beginnen altijd met "aria-".

Een voorbeeld van een eigenschap is aria-haspopup="true". Als u deze status toevoegt in de accessibility tree voor een link die een submenu heeft, zal de screenreader dit ook kunnen aankondigen aan de blinde gebruiker. ARIA biedt dus een manie rom informatie te geven die visueel duidelijk is maar die niet waarneembaar is door screenreadergebruikers.

Een voorbeeld van een status is aria-expanded="true". Daarmee geeft u aan dat het submenu op dit moment is uitgeklapt. Het verschil met een eigenschap is dat een status vaker verandert. Als het submenu dichtklapt, moet u ook in de accessibility tree deze status aanpassen naar aria-expanded="false". How to toggle ARIA values with Javascript?

Naam

Componenten in de accessibility tree hebben tenslotte ook een naam nodig. HTML-elementen vullen deze weer impliciet in. Voorbeelden van namen van componenten zijn de alt-tekst voor een afbeelding, de linktekst voor een link en de inhoud van het value-attribuut voor een knop.

Er zijn twee ARIA-attributen die in de accessibility tree namen van componenten toevoegen of wijzigen: aria-label en aria-labelledby. De eerste krijgt als waarde een gewone tekst; de tweede verwijst naar een id-waarde en kan dus tekst herhalen die elders staat.

Aandachtspunten

  • Let op de dubbele "l" in labelledby
  • Een aria-label(ledby)-attribuut op een span of div heeft geen effect, want die component bestaat niet in de accessibility tree.
  • Als de component al een naam had, dan wordt die overschreven door aria-label(ledby). Doe dus niet <a aria-label="Externe link" href="http://www.anysurfer.be">AnySurfer</a> want de linktekst "AnySurfer" zal verloren gaan en vervangen worden door "externe link".
  • Hou er rekening mee dat ARIA-labels enkel bekend zijn binnen de accessibility tree.
<a href="/en" aria-label="English version">EN</a>

Bovenstaande code is een link naar de Engelse versie van een website: de linktekst "EN" is misschien niet voor iedereen even betekenisvol. Via het aria-label werd die linktekst in de accessibility tree vervangen door "English version". Dit lijkt een goed idee: screenreaders lezen nu "English version" als linktekst, maar op het scherm staat nog steeds EN:

  • De screenreadergebruiker weet niet dat hij een andere linktekst te horen krijgt dan wat er op het scherm staat. Dat kan verwarrend zijn voor iemand die meekijkt op het scherm.
  • Iemand die dicteersoftware gebruikt zoals dragon naturally speaking zal het spraakcommando "klik EN" geven want dat is wat hij op het scherm ziet. Dit commando zal niet werken, want voor Dragon is de linktekst "English version" geworden. De gebruiker van de dicteersoftware kan dat niet weten.

Wanneer ARIA gebruiken?

  • Gebruik ARIA alleen als er informatie ontbreekt in de accessibility tree of als die informatie niet correct is.
  • Als u een toolkit of UI framework gebruikt, is ARIA soms al ingebouwd of via een plugin toe te voegen.
  • Als u zelf widgets bouwt die u met HTML en CSS niet toegankelijk kunt maken, pas dan ARIA toe. Volg daarbij altijd de design patterns van de WAI-ARIA Best Practices. Deze beschrijven hoe de component moet werken en wat u allemaal moet voorzien zodat verschillende gebruikers de component goed kunnen gebruiken. Voor een tabsysteem hebben we dit uitgeschreven.
  • Als u ARIA-attributen toevoegt, moet u goed weten wat u 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. Een slideshow of lightbox kan ook toegankelijk zijn zonder ARIA.

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 kunt u 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 u ARIA gebruikt, dan moet u uw 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. U moet uw widgets dus ook testen met het toetsenbord want het is niet omdat u een div een role="button" of role="tabpanel" geeft dat je er naartoe kunt tabben. Dit moet u zelf voorzien door met Javascript het tabindex-attribuut te manipuleren.

Samengevat

  • Met ARIA-attributen wijzigt u informatie in de accessibility tree of u 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 u blijven testen, los van het ARIA-gebruik.
  • Als er een HTML-element of -attribuut bestaat voor de functie die u nodig heeft, gebruik dat dan.
  • Een role verandert enkel hoe de component wordt aangekondigd door de screenreader. Roles toevoegen, volstaat dus niet. U moet ook in Javascript de functionaliteit programmeren.
  • Als u het role-attribuut gebruikt, krijgt dat voorrang, ongeacht aan welk element het is toegevoegd. ARIA wint!
  • Een aantal roles zijn niet bedoeld voor wat hun naam doet vermoeden. Gebruik geen role="menu" en "menuitem" voor navigatie. Het dient voor menu's zoals in desktop software.
  • Gebruik geen role="application"
  • Verkeerde of overbodige ARIA-attributen is meestal erger dan geen ARIA.
  • Het is goed dat we met ARIA extra informatie kunnen geven aan screenreadergebruikers, maar let erop dat u niet overdrijft.

Bronnen