Toegankelijkheid: WAI ARIA's noodzaak

Naast webontwikkeling in het algemeen (denk aan HTTP/2, AMP, Critical Path CSS, responsive webdesign, font gebruik), staat ook de ontwikkeling van web toegankelijkheid niet stil. WAI ARIA is hier een voorbeeld van, waar semantiek echter altijd de voorkeur zou moeten krijgen.

WAI ARIA specificatie

Voor de frontend programmeurs onder ons, zal het gebruik van aria-attributen het bekendst zijn. Dit is een onderdeel van WAI ARIA, een specificatie ontwikkeld door het W3C. De afkorting staat voor "Web Accessibility Initiative - Accessible Rich Internet Applications" en geeft programmeurs handvaten om hun websites en webapplicaties toegankelijk te maken, waar de puur semantische HTML variant van een webpagina niet voorziet in volledige toegankelijkheid ervan.

ARIA rollen

Middels rollen, kun je aangeven wat de relatie is van een element. Er zijn verschillende soorten rollen:

  • Abstracte rollen, zoals role="section";
  • Widget rollen, zoals role="alert" of role="button", bijvoorbeeld op elementen dat semantisch geen button is, maar wel button-functionaliteit toegeschreven heeft gekregen. Een toepassing voor tooltips, is role="tooltip";
  • Document structuur, zoals role="article", role="list" of role="note";
  • Live region roles, zoals role="timer" of role="alert". De laatste is in bijvoorbeeld in de Bootstrap documentatie omtrent alerts terug te vinden;
  • En de meest bekende: Landmarks. Denk aan role="main", role="navigation", role="search".

ARIA attributen

De ARIA specificatie kent ook vele aria-attributen die je kunt benutten om content te verrijken of doelen te verduidelijken voor screenreaders. Je kunt denken aan:

  • aria-hidden="true", om aan te geven dat de content niet zichtbaar hoeft te zijn voor screenreaders (wordt dan ook vooral in combinatie met iconen-sets gebruikt);
  • aria-label, om juist extra beschrijving mee te geven waar de werkelijke content niet volstaat.
    Probeer echter gebruik te maken van de title-attribuut indien aanvullende content ook zichtbaar mag zijn voor bezoekers die geen gebruik maken van screenreaders;
  • aria-disabled="true", om aan te geven dat een element inactief is en niet benut kan worden.
    Gebruik echter in het geval van formulier-velden de native disabled-attribuut. Dit voegt immers voor alle bezoekers functionaliteit toe en maakt de inzet van aria-disabled daarmee overbodig. Hetzelfde geldt voor (aria-)readonly en (aria-)checked;
  • aria-haspopup, om aan te geven dat dit element een dropdown bevat, bijvoorbeeld in combinatie met aria-expanded (voorzien van een boolean value) om aan te geven of die popup is ingeklapt of uitgeklapt;
  • aria-labelledby, wanneer er geen HTMLlabel-element als referentie is;

Een meer volledige lijst is terug te vinden op w3.org.

Contact opnemen Kennis bekijken

Noodzaak van WAI ARIA

De komst van JavaScript frameworks als ook toename in gebruik van AJAX binnen websites en applicaties, dwingt instanties (W3C) om specificaties omtrent toegankelijkheid van HTML en daarmee websites door te ontwikkelingen. Er worden namelijk websites gemaakt met toepassingen als formulieren, waarbij de velden niet werkelijk formuliervelden zijn. Visueel kunnen ze wel zo in beeld worden gebracht in een gemiddelde browser, maar dit kan in praktijk niet toereikend zijn voor screenreader gebruikers en kan de toegankelijkheid dus in de weg zitten.

Dit gat, kan gevuld worden door de inzet van rollen en aria-attributen waar frameworks niet in voorzien en waar de oorspronkelijke attributen voor gebruikte HTML elementen te kort schieten. Echter, rollen als ook ARIA attributen voegen semantisch niets toe aan een document. Het geeft een document geen aanvullende waarde buiten screenreaders om. Uiteraard kun je ze voor styling-doeleinden benutten, maar wanneer mogelijk, zou je primair de semantische equivalenten in moeten zetten.

Semantiek op de eerste plek

Ga dan ook te allen tijde primair semantisch te werk, om vervolgens na te gaan hoe je ontbrekende aanwijzingen kunt aanvullen middels bovenstaande methoden. Door je HTML semantisch op te zetten, hoeven veel rollen vaak niet eens toegepast te worden om de content toegankelijk te maken.

Denk aan:

  • Het gebruik van h1 tot en met h6, om kopteksten en vooral hierarchie aan te geven, in plaats van role="heading" in combinatie met aria-level="1";
  • nav, header, main en form in plaats van respectievelijk role="navigation", role="banner", role="main" en role="form"

Doordat in voorgangers van HTML5 bepaalde elementen nog niet geadopteerd waren, is het gebruik van rollen soms reeds geadopteerd, waarbij bij transitie van XHTML of HTML4 naar HTML5, zowel semantische elementen als ook rollen zijn toegepast. Alhoewel niet per definitie conflicterend, is deze werkwijze wel overbodig.

Geen reacties

Er is nog niet gereageerd op dit nieuwsbericht. U kunt de eerste zijn: