Aria används för att göra webbplatser tillgängliga. Men de används ofta felaktigt, och gör därför webbplatsen otillgänglig istället. Här beskriver vi några vanliga fel med ARIA och hur du gör istället.
För att personer med hjälpmedel ska kunna ta del av webbplatser används ARIA-attribut som stöd i HTML-kod. Tyvärr används de ofta felaktigt eller saknas där det behövs, vilket leder till alla möjliga problem för hjälpmedel som skärmläsare, och gör webbplatsen otillgänglig. Men vi börjar från början, varför man behöver använda ARIA och hur det fungerar.
Varför används WAI-ARIA?
Många webbplatser bygger idag på grafiska komponenter och dynamiska interaktioner, såsom menyer, fält och rullgardinslistor, med möjlighet att välja, dra och släppa, ändra storlek, dölja och visa med mera. En person med bra syn klickar på en utfällbar meny och kan se att menyn är stängd eller öppen, medan en med nedsatt eller ingen syn behöver hjälp av en skärmläsare som kan tolka vad som händer. Med korrekt användning av WAI-ARIA kan en webbläsare översätta och tolka HTML-kod till en skärmläsare, som i sin tur läsa upp för användaren att en meny är öppen eller stängd eller att det visas ett pop-up meddelande när en knapp trycks ner.
Hur fungerar ARIA?
Man kan se ARIA som en serie fördefinierad HTML-attribut som delas i två kategorier, aria-roller och tillstånd & egenskaper. Du använder ARIA genom att en eller fler aria-attribut läggs i en HTML-element för att:
- lägga till ytterligare betydelse för HTML-element
- ändra den befintliga betydelsen av HTML-element
- lägga till ytterligare märkningar eller beskrivningar i HTML-element
- skapa relationer mellan HTML-element
- informera hjälpmedel om att uppdateringar har skett inom specifika områden på en HTML-sida.
Rollattribut gör det möjligt för hjälpmedel att tolka vilken typ av komponent eller widget det är. Se exempel nedan hur aria-roller ‘main’ används för att märka ut huvudinnehåll.
<div role=”main”> Det är huvudinnehåll </div>Tillstånds- och egenskapsattribut berättar för hjälpmedel status och relationer på komponenten och interaktioner. Se exempel nedanför hur aria-expanded används på en utfällbar meny.
<p>Klicka på knappen Meny för att öppna och stänga menylistan.</p>
<button aria-expanded="false">Meny</button>
<div hidden="" id="tooltip">
<ul>
<li><a href="http://example.com/link1.html">Länk 1</a></li>
<li><a href="http://example.com/link2.html">Länk 2</a></li>
<li><a href="http://example.com/link3.html">Länk 3</a></li>
</ul>
</div>Vanliga problem med ARIA
När vi granskar tillgängligheten på webbplatser är det tre problem som ofta återkommer – överflödiga ARIA, att kopplingen saknas mellan etikett eller beskrivning och att formulärfält samt att Aria används i fel HTML-element.
Överflödiga ARIA
Vi ofta ser att aria-roller läggs till i semantiska HTML-element, till exempel: <nav role=”navigation”>. <nav> är ett semantiskt element i HTML som redan är tillgänglig för hjälpmedel och beskriver innehållet för webbläsaren att det är en navigation, vilket ger samma funktioner som ARIA-roll navigation, role=”navigation”. Därför är det onödigt att lägga till ARIA-roller när ett semantiskt HTML-element används.
Ett annat exempel är där dubbelmarkeringar används på ett obligatoriskt fält med HTML-attributet required som har samma funktion som aria-required=”true”. Se exempel nedan:
<label for=”namn”>Namn</label>
<input id=”name” type=”text” required aria-required=”true”> Det är inget fel att använda ARIA-roller i semantiska HTML av samma funktion. I vissa fall kan detta leda till att hjälpmedel presenterar elementets tillstånd två gånger. Men för att det ska ge dig en renare och mer hanterbar kod så rekommenderar vi att använda semantiska HTML utan tilläggas ARIA-roller av samma funktion. Som <button role=”button”> är helt onödig att lägga till aria-roll knapp. I det fallet kan ARIA-attributet tas bort utan påverkan hos dina användare.
ARIA-roller är lämpligt att användas vid icke-semantiska element som <div> och <span> som inte anger vad elementet egentligen innehåller. Där behöver ARIA-roller användas för att förklara för skärmläsaren vad innehållet är. Koden nedan är ett korrekt exempel på hur ARIA ska användas. Koden talar om för skärmläsare att det är en navigationsmeny och denna meny är huvudmeny.
<div role="navigation" aria-label="huvudmeny">
<ul>
<li>meny 1</li>
<li>meny 2</li>
</ul>
</div> Om flera menyer används på en sida behövs det lägga till beskrivning med ARIA för att särskilja de olika menyerna:
<nav aria-label="huvudmeny"></nav>
<nav aria-label="sidormeny"></nav>Det saknas koppling mellan etiketter och inmatningsfält
När vi granskar formulär med automatiska verktyg så visas ofta felet att formulärfältet saknar etikett och beskrivning. Men när man tittar på gränssnittet så ser man att det finns en etikett i anslutning till inmatningsfältet. Det är därför alltid bäst att testa med en skärmläsare och sedan granska koden för att se vad är det som saknas. Anledning till att problemet visas är för att det saknar oftast koppling mellan etiketten och inmatningsfältet.
Rekommendation för exemplet ovan är att använda etikettelementet <label> för att markera vad ska fyllas i inmatningsfältet. Genom att använda for och id kopplar du ihop etiketten och inmatningsfältet. I det visuella gränssnittet syns ingen skillnad, men i koden är det skillnad för skärmläsaren. Det som är i <label> element läses upp av skärmläsare när inmatningsfältet har fokus. <span> ger inte skärmläsare någon information vad innehållet är. Det finns inte heller något koppling till inmatningsfältet därför när inmatningsfältet har fokus blir inte texten “Ditt namn” uppläst.
Aria används felaktigt
Vi ser ofta att det förekommer att en ARIA-roll heading läggs i HTML-element h1, se exempel nedan:
<h1 role=”heading”>rubrik</> <h1> element är semantisk HTML och det beskriver tydligt för hjälpmedel att det är en huvudrubrik. ARIA-roll heading talar bara om det är en rubrik. ARIA-rollen skriver över det semantiska elementets betydelse och funktion. Så i exemplet läser skärmläsare att det är en Rubrik, men inte vilken nivå. H1 som är huvudrubrik finns inte för skärmläsaren. Därför är det viktigt att alltid föredra semantiska HTML element och undvika ARIA om den inte behövs. Om ARIA inte används rätt kan det tillföra mer problem och gör webbplatsen mer otillgänglig. Se exemplet nedan hur ska exemplet åtgärdas för att bli rätt:
<h1>huvudrubrik</h1>
eller
<div role=”heading” aria-level=”1”>huvudrubrik</div>
men h1-element är alltid att föredra. Validera och granska för att minska problem med ARIA
Se till att regelbundet kontrollera att koden är giltig och validera med W3C-validator enligt kriteriet 4.1.1 i WCAG 2.1. Olika användare väljer olika webbläsare och genom att följa standarden ökar du sannolikheten att din webbplats ska fungera på de flesta. Giltig kod är en förutsättning för att hjälpmedel ska kunna tolka din webbplats korrekt för användare.
Du bör också använda en WCAG-validator. Oftast finns de som tillägg till webbläsare, exempel WAVE (tillägg till Chrome och Firefox) eller Axe (tillägg till Chrome). Med de verktyget kan du oftast se uppenbara fel med ARIA och även visa förslag på hur du kan åtgärda dem.
Tyvärr kan man inte bara följa webbstandarden och tro att din webbplats fungerar korrekt av alla hjälpmedel. Det finns olika sorters hjälpmedel som skärmläsare, punktskrifthjälpmedel och röststyrningsprogram och alla beter sig olika. En del beter sig även olika beroende på vilken webbläsare du använder.
Därför bör du alltid manuellt testa med en eller flera hjälpmedel du har tillgång till och kompletterar gärna med användartester om resurserna tillåter. Exempel på gratis skärmläsare är NVDA (för Windows), Narrator (inbyggd i Windows) och VoiceOver (finns inbyggd i OS X/ iOS).
Vill du ha hjälp med granskning?
Ibland finns inte tiden, kunskapen eller tekniken för att göra en komplett granskning. Vi gör en komplett granskning utifrån WCAG och ger en tydlig rapport där du enkelt ser vad som är fel och hur du åtgärdar det.
Tillgänglighetsgranskning – ja tack!