Så skapar du som utvecklare tillgängliga webbplatser med WAI-ARIA

Författare: Hanna Fredholm

Tillgänglighetsexpert och frontendutvecklare

Publicerat 3 augusti 2023

Lästid 6 minuter

Les artikkelen på norsk

Artikel

Som utvecklare kan det vara en utmaning att få en webbplats fullt tillgänglig enligt standarden Web Content Accessibility Guidelines (WCAG). Men genom att använda WAI-ARIA-attribut kan vi förmedla information till hjälpmedel och komma ett steg närmare till att uppfylla standarden.

Det kan vara en utmaning att utveckla robust kod som är tillgänglig för alla användare enligt WCAG. Många utvecklare är heller inte medvetna om vad som krävs för att uppfylla lagkraven om digital tillgänglighet. En viktig del i den här utmaningen är kunskapen om WAI-ARIA.

Nedan introducerar vi målgruppen WAI-ARIA är till för och ger en förklaring av vad det är. Det är viktigt att komma ihåg att WAI-ARIA aldrig ska ersätta HTML-kod. Semantiskt innehåll bör alltid kodas med HTML i första hand

Möt Sara, hon är 26 år gammal med starkt nedsatt syn. Sara använder ett hjälpmedel som kallas skärmläsare. Det är en programvara som tolkar det synliga innehållet på en skärm till talsyntes eller punktskrift. För att Sara ska kunna förstå och använda en webbplats är hon beroende av att webbplatser kompletteras med WAI-ARIA.

WAI-ARIA i korta drag

WAI-ARIA består av en rad olika HTML-attribut som skärmläsare kan använda. Attribut som aria-hidden, aria-expanded, aria-haspopup med fler, ger information till skärmläsare och hjälper personer med vissa funktionsnedsättningar att interagera med dynamiskt innehåll på webbplatsen. WAI-ARIA kompletterar HTML-element genom att lägga till roller, tillstånd och egenskaper till koden.

Roller

Roller är indelade i sex olika grupperingar. Nedanför visar vi grupperna med några exempel av varje typ:

• Abstrakta-roller (dessa roller bör inte användas av innehållsförfattare, eftersom de är grunden för WAI-ARIA-ontologin)
• Widget-roller (t.ex. button, link, menuitem)
• Dokumentstrukturroller (t.ex. article, feed, list, table)
• Landmärksroller (t.ex. banner, navigation, main, complementary)
• Live region-roller (t.ex., alert, log, timer)
• Fönsterroller (t.ex, alertdialog, dialog)

Ett exempel på en roll som hjälper skärmläsaranvändare att navigera till en sökfunktion är role=search. Rollen ökar också förståelsen för att det just är ett sökfält som användaren har kommit fram till.

Tillstång och egenskaper

Tillstånd används vanligtvis tillsammans med roller för att definiera funktionsstatusen. Tillstånd fungerar på samma sätt som egenskaper, men ändras som oftast medan en applikation eller widget används. Till exempel ändras status på aria-checked mellan true och false. Egenskaper ändras vanligtvis inte. Här behåller för exempel aria-labelledby samma värde. Tillstånd och egenskaper är alla ”aria-” prefix (det vill säga att de börjar med ordet ”aria”), till skillnad från roller.

Likheten mellan egenskaper och tillstånd är hur de båda används tillsammans med roller. Till skillnad från tillstånd som ändrar sig, har egenskaper en tendens att vara de samma (även om detta inte är en regel). Du kan intuitivt lägga märke till den skiftande karaktären till ovannämnda tillstånd, och den statiska karaktären hos egenskaperna. Rollen får dock aldrig ändras. Skal du ändra rollen, måste du skapa ett nytt element med den nya rollen och ta bort det gamla elementet.

Tillstånd och egenskaper i ett aria-attribut berättar till skärmläsare om status och relationer till komponenten och interaktioner. Se exempel nedanför hur aria-expanded används på en rullgardinsmeny, för att förklara att det är en knapp som fäller ut ett område.

Hur du validerar WAI-ARIA

Det finns olika sätt att validera WAI-ARIA. Man kan använda automatiserade tillgänglighetskontroller som Axe eller WAVE medan du kör koden i en webbläsare. Tillgänglighetsverktyg som Axe för Visual Studio Code eller ESlint för JSX-element kontrollerar koden medan du skriver.

Testa din kod genom att lyssna på den med en skärmläsare. Innan du skickar i väg koden, bör du alltid testa den i en webbläsare för att säkerställa att den fungerar. Att använda en skärmläsare kan ge dig samma typ av verifiering. Det finns gratis skärmläsare att tillgå

• NVDA finns i Windows
• VoiceOver finns inbyggt i Mac och iPhone
• Talkback är inbyggt i Android-telefoner.

Testa gärna med verkliga användare som har en eller flera funktionsvariationer. Vi rekommenderar att alla större organisationer med en budget för tillgänglighet utför den här typen av test.

Att testa med faktiska användare kan ge dig och ditt team värdefull insikt i hur användare navigerar på din webbplats. Användare av skärmläsare, som i vårt exempel med Sara, kan ge dig insikt i om implementeringen av WAI-ARIA fungerar på ett bra sätt.

Var kan du börja?

Det kan vara svårt att veta hur du ska börja när du börjar att jobba med WAI-ARIA. Ett tips är att börja kontrollera de tre mest använda egenskaperna: aria-label (för att ge komponenten ett tillgängligt namn), aria-live (för att informera om dynamiska uppdateringar) och aria-expanded. Om du implementerar dessa på rätt sätt kommer du att kunna förbättra användarupplevelsen av webbplatsen avsevärt. Detta kommer också att göra webbplatsen mer tillgänglig för användare som Sara.

Kom ihåg! Aria-attribut kan aldrig ersätta HTML. Använd därför alltid HTML först. Vi ser ofta aria-roller som lagts till på semantiske HTML-element, till exempel: <nav role=”navigation”>. Elementet <nav> är ett semantiskt element i HTML som redan är tillgängligt och beskriver innehållet för webbläsaren att det är en navigering, vilket ger samma funktionalitet som aria-rollen, role=”navigation”. Därmed är det onödigt att lägga till aria-roller när du använder ett semantiskt HTML-element. Använd därför WAI-ARIA med försiktighet.