Misschien ben je ARIA wel eens tegengekomen, mogelijk ben je er bekend mee, maar misschien denk je ook wel—waar gaat dit over. Als je wel eens met een CSS framework gewerkt hebt (Bootstrap, Foundation etcetera) dan kun je wel eens ARIA informatie zijn tegengekomen.

Bijvoorbeeld Bootstrap’s modal component. Deze component bevat verschillende roles (zoals role=“dialog”) en verschillende properties (zoals aria-labelledby=“modalLabel”). Roles en properties/states zijn onderdeel van de ARIA specificatie.

ARIA staat voor Accessible Rich Internet Applications en is een specificatie van de W3C (World Wide Web Consortium). Het W3C houdt zich bezig met open standaarden voor het web. Waaronder HTML, CSS, JSON+LD en vele anderen. ARIA is bedoeld om interface elementen te kunnen voorzien van context en werking om toegankelijkheid te verbeteren.

Met nette HTML kom je al een heel eind zonder ARIA te hoeven toepassen. Veel elementen in HTML geven al semantische waarde af die door screenreaders gebruikt kunnen worden. Bijvoorbeeld een <button>:

<button type="button">
    Pagina opslaan
</button>

We kunnen alsnog ARIA toepassen, maar het zal geen invloed hebben op de interpretatie door screenreaders:

<button type="button" role="button">
    Pagina opslaan
</button>

Een role is alleen nodig wanneer het element niet duidelijk kan maken wat het is. Laten we bijvoorbeeld kijken naar onderstaande voorbeeld:

<div role="button">
    Pagina opslaan
</div>

Voor mensen zonder visuele beperking kan het element worden opgemaakt als een knop (ronde hoekjes, verloopje, schaduw), maar een screenreader zal het interpreteren als standaard tekst en dus kan dit verwarring veroorzaken. Om aan te geven dat de <div> een knop is voegen we een role toe.

p.s. Ik raad je af om ooit een <div> te gebruiken als knop, maar voor nu ter illustratie.

De ARIA specificatie spreekt over twee onderdelen: ARIA roles en ARIA states/properties. Hieronder gaan we wat dieper in op wat deze betekenen.

ARIA roles

ARIA roles zijn er om duidelijk te maken wat voor type interface element iets is. We hebben hierboven met het voorbeeld van de knop al een ARIA role in actie gezien.

Roles vallen in verschillende categorieën:

1. Widget roles

Kleinere interface elementen. Hieronder vallen bijvoorbeeld de button, checkbox, radio, maar ook roles die niet met HTML zijn op te maken zoals menuitem.

2. Composite roles

Elementen die om widget roles heen liggen. Bijvoorbeeld menu die om menuitem’s heen vallen en radio group die een aantal radio buttons groepeert.

3. Document structure

Elementen om je document te structureren zoals de titel ook wel een beetje weggeeft. Hieronder vallen bijvoorbeeld heading, table, list, en article.

4. Landmark

Landmark roles zijn belangrijk voor screenreaders. Veel screenreader gebruikers gebruiken deze roles om snel te kunnen springen naar verschillende delen op de pagina (naast kopjes die ook vaak gebruikt worden).

• main = Om aan te geven welk deel van de pagina de belangrijkste informatie weergeeft. Bij een artikel plaats je deze bijvoorbeeld om de tekst van het artikel heen.
• navigation = Om aan te geven wat je navigatie is. Mogelijk heb je zelfs meerdere navigatie elementen.
• search = Om aan te geven waar gezocht kan worden.
• form = Formulieren op de pagina.
• complementary = Een deel van de pagina die complementair is aan de hoofdcontent op de pagina. Bij een artikel zou je bijvoorbeeld je auteur, categorieën, tags, publicatiedatums en dergelijke hierin kunnen groeperen.
• contentinfo = Geeft informatie weer over het document. Deze role wordt vaak toegepast (of is standaard toegepast) op <footer> elementen.

5. Live regions

Tot slot hebben we nog live regions. Dit zijn onderdelen die aan screenreaders duidelijk kunnen maken dat er iets dynamisch op de pagina is gewijzigd. Voor niet-screenreader gebruikers kan het meteen duidelijk zijn dat er een error/alert in beeld is gekomen. Screenreader-gebruikers merken hier niks van. Met live regions kunnen we aangeven dat er iets veranderd is en daarmee kunnen screenreaders dit duidelijk maken aan de gebruiker.

Voorbeelden van live regions zijn alert en log (bijvoorbeeld een chat).

ARIA states and properties

States en properties zijn er om roles te ondersteunen. Properties omschrijven vaak de relatie met andere elementen en states kunnen dynamisch aangeven in welke staat een element zich bevindt. Laten we er enkele bekijken:

aria-hidden

Deze gebruik ik vaak om elementen ‘onzichtbaar’ te maken voor screenreaders, maar wel visueel zichtbaar te houden. Dit zijn vooral decoratieve elementen zoals iconen (niet alle iconen zijn decoratief en ze moeten wel ondersteund worden door tekst) en afbeeldingen. Het komt voor dat we een knop hebben met een pijltje, bijvoorbeeld:

<button type="button">
    <svg class="icon" width="16">…</svg>
    Pagina opslaan
</button>

Het pijltje zegt in veel gevallen niet zoveel en voegt weinig toe voor screenreaders (bijvoorbeeld: “Pijltje naar rechts. Dit is mijn knop tekst”). Door aria-hidden toe te voegen op de SVG wordt deze niet meer geïnterpreteerd door screenreaders en blijft alleen de tekst over.

<svg class="icon" width="16" aria-hidden="true">…</svg>

aria-expanded

Dit geeft aan of het element, of een element die bestuurd wordt, is uitgeklapt. Deze kunnen we gebruiken bij dropdowns in de navigatiebalk of bijvoorbeeld een veelgestelde vragen accordion.

<button type="button" aria-expanded="false" aria-controls="collapse">
  Klap onderstaande blok open
</button>

<div id="collapse">
  Verborgen content
</div>

Nog vele anderen

Veel states en properties hebben hele specifieke doeleinden. Ik raad je aan om eens door de specificatie te gaan en/of te kijken naar bestaande toegankelijke componenten.

Net als bij roles en ons voorbeeld bovenaan met de <button>, is het vaak zo dat states en properties ook met ‘standaard’ HTML op te lossen zijn. We hebben bijvoorbeeld een aria-required attribuut, maar deze is voor screenreaders exact hetzelfde als required. Ga daarom ook niet rondstrooien met alle mogelijke ARIA attributen, maar kijk alleen wat essentieel is en voeg die toe.

Tot slot

ARIA is een mooie toevoeging op HTML om onze documenten beter toegankelijk te maken voor onder andere screenreaders. Daarbij moet je wel altijd opletten welke ARIA attributen je toepast. Probeer je altijd te behouden tot de meest noodzakelijke attributen en probeer het op te lossen met semantische HTML. Bij het verkeerd gebruiken van ARIA attributen kan je site juist minder toegankelijk worden, dat zou zonde zijn.

Voor sommige componenten (die je toegankelijk wil hebben) ontkom je er niet aan om ARIA te gebruiken. Kijk bijvoorbeeld naar een tab component, in HTML is hier geen equivalent voor. Er zijn verschillende sites die je op weg kunnen helpen met standaard componenten die al correct zijn opgemaakt met ARIA attributen zoals het A11Y Project.