Förstå vad ARIA är – och inte är
Ta reda på vad ARIA är och vad det inte är. Tommy ger dig en närmare förklaring om vad du som webbutvecklare bör tänka på när du överväger att använda ARIA.
1. ARIA är inget självändamål
Grundprincipen för webbutveckling är att använda semantisk html överallt där det är möjligt, och ta till ARIA i de få fall där html inte räcker till. ARIA ska vara undantaget, inte regeln. Det framgår tydligt av självaste ARIA-specifikationen. Att använda mycket ARIA på en webbplats gör den inte automatiskt mer tillgänglig.
ARIA-specifikationen på W3Cs webbplats (på engelska)
2. ARIA bara lovar, men gör inget
ARIA består av ett antal attribut som du kan använda på html-element. Ibland efter vissa ganska komplicerade regler.
Dessa attribut gör ingen som helst skillnad för användare utan hjälpmedel. Deras uppgift är framför allt att förmedla information till hjälpmedel (främst skärmläsare).
Många gånger består informationen av löften, som utvecklaren måste se till att uppfylla.
ARIA-roller komplicerar
Det viktigaste ARIA-attributet är role, som ger ett löfte om att ett element har en annan roll än den elementet normalt sett har i html. Notera att det bara är ett löfte. Det påverkar inte grammatikreglerna i html och det påverkar inte hur webbläsaren visar eller hanterar elementet. Det enda webbläsaren gör är att förmedla rollen till ett programmeringsgränssnitt som hjälpmedel kommunicerar med.
En <div role=”button”> är fortfarande en <div> som
- ska följa html-reglerna för var en <div> får förekomma och vilket innehåll och vilka attribut den får ha
- inte går att nå med tangentbordet om man inte också lägger till tabindex=”0”
- inte reagerar på musklick eller tangenttryckningar som en knapp gör
- inte ser ut som en knapp förrän utvecklaren själv, med CSS och JavaScript, lagt till presentationen och interaktionen.
Vissa attribut som är tillåtna för html-elementet <button> (till exempel disabled) är inte tillåtna för en <div>, även om den har role=”button”. För att förmedla att denna låtsasknapp är inaktiv måste man använda aria-disabled=”true” och sedan själv göra den icke-fokuserbar (tabindex=”-1”), ändra utseendet med CSS och se till att händelselyssnarna inte reagerar på musklick och tangenttryckningar.
Det här är raka motsatsen till progressiv förbättring, eftersom ”knappen” inte kommer att se ut som en knapp utan CSS och inte kommer att fungera över huvud taget utan JavaScript.
3. Hängslen eller livrem, inte både och
När ARIA var nytt fanns rekommendationer om att använda dubbla attribut, till exempel både required och aria-required. Det berodde på att äldre webbläsare inte hade stöd för required och därmed inte förmedlade det till hjälpmedel. I dag finns inte det problemet, och rekommendationen är nu att använda enbart html-attributen för riktiga html-element och ARIA-attributen för hemmagjorda komponenter. Det finns också en stark rekommendation om att inte använda role-attributet med den roll som ett html-element har som default, till exempel <button role=”button”>.
Arbeta vidare med ARIA
ARIA ger alltså enbart löften om funktion. Använd i första hand semantisk html-kod. Det är upp till dig som utvecklare att säkerställa att det även fungerar som utlovat genom att se till att funktionalitet finns där. Om du använder ARIA kan du som utvecklare testa att det fungerar som tänkt genom att använda skärmläsare.
Att använda ARIA på en webbplats betyder inte automatiskt att den blir mer tillgänglig. Tvärtom kan det bli det motsatta, när det inte fungerar som utlovat.
I Hanna Fredholms artikel kan du fördjupa dig i hur ARIA kan användas: Så skapar du som utvecklare tillgängliga webbplatser med WAI-ARIA
