Hvordan utviklere kan lage tilgjengelige nettsteder med WAI-ARIA
Forfatter: Hanna Fredholm
Ekspert på universell utforming av ikt og frontend utvikler
hanna.fredholm@useit.se
Lesetid 6 minutter
ArtikkelSom utvikler kan det være en utfordring å få en nettside helt universelt utformet i henhold til Web Content Accessibility Guidelines (WCAG) standarden. Ved å bruke WAI-ARIA-attributter kan vi imidlertid formidle informasjon til hjelpemidler og komme ett skritt nærmere å møte standarden.
Det kan være en utfordring å utvikle robust kode som er tilgjengelige for alle brukere i henhold til WCAG. Til tross for dette er det mange utviklere som ikke er klar over hva som kreves for å oppfylle de nye lovkravene. En viktig del i denne utfordringen er kjennskapen til WAI-ARIA. Nedenfor følger en kort forklaring på hva WAI-ARIA er, spesielt for deg som jobber med utvikling. Det er imidlertid viktig å huske på at WAI-ARIA aldri skal erstatte HTML-kode. Semantisk innhold bør alltid kodes med HTML i utgangspunktet.
La oss snakke om Sara, hun er 26 år gammel og er sterkt svaksynt. Hun bruker en hjelpemiddelteknologi kalt skjermleser – en programvare som tolker det synlige innholdet på en skjerm til opplesning eller blindeskrift. For at Sara skal kunne forstå og bruke en nettside riktig, er hun avhengig av at de fleste nettsider bruker WAI-ARIA.
WAI-ARIA kort fortalt
WAI-ARIA består av en serie HTML-attributter som skjermlesere kan bruke. Attributter som aria-hidden, aria-expanded, aria-haspopup og flere gir viktig informasjon til skjermleserne og hjelper mennesker med enkelte nedsatte funksjonsevner til å samhandle med dynamisk innhold på siden. WAI-ARIA supplerer HTML-elementer ved å legge til roller, tilstander og egenskaper til koden.
Roller
Roller er delt inn i seks forskjellige grupperinger. Her er gruppene med noen få eksempler av hver type:
- Abstrakt-roller (disse rollene skal ikke brukes av forfattere i innhold, da de er grunnlaget for WAI-ARIA-ontologien)
- Widget-roller (f.eks.
button,link,menuitem) - Dokumentstruktur-roller (f.eks.
article,feed,list,table) - Landemerker-roller (f.eks.,
banner,navigation,main,complementary) - Live region-roller (f.eks.,
alert,log,timer) - Vindu-roller (f.eks,
alertdialog,dialog)
Et eksempel på en rolle som hjelper skjermleserbrukere med å navigere til en søkefunksjon er role=search. Rollen øker også forståelsen for at det er nettopp et søkefelt brukeren har kommet frem til.
Tilstander og egenskaper
Tilstander brukes vanligvis sammen med roller for å definere funksjonsstatusen. Tilstander fungerer på samme måte som egenskaper, men endres vanligvis mens en applikasjon eller widgets brukes. For eksempel endrer aria-checked statusen seg mellom true og false. Egenskaper endres vanligvis ikke, for eksempel beholder aria-labelledby samme verdi. Tilstander og egenskaper er alle "aria-"prefiks (det vil si at de begynner med ordet "aria"), i motsetning til roller.
Likheten mellom egenskaper og tilstander er hvordan begge brukes sammen med roller. Men i motsetning til tilstander som endrer seg, har egenskaper en tendens til å være de samme (selv om dette ikke er en regel). Du kan intuitivt legge merke til den skiftende naturen til tilstandene nevnt ovenfor, og den statiske karakteren til egenskapene. Rollen må imidlertid aldri endres. Hvis du vil endre roller, må du opprette et nytt element med den nye rollen og slette det gamle elementet.
Tilstands- og egenskaper i et aria-attributt forteller skjermleser status og relasjoner til komponenten og interaksjoner. Se eksempler nedenfor på hvordan aria-expanded brukes på en rullegardinmeny. For å forklare at det er en knapp som utvides.
Slik validerer du WAI-ARIA
Det finnes ulike måter å validere WAI-ARIA. Man kan bruke automatiserte tilgjengelighetskontroller som Axe eller WAVE-utvidelser mens du kjører koden i en nettleser. Tilgjengelighetsverktøy som Axe for Visual Studio Code eller ESLint for JSX-elementer vil sjekke koden din mens du skriver.
Test koden din ved å lytte til den med en skjermleser. Før du sender koden, bør du alltid teste den i en nettleser for å sikre at den fungerer. Å bruke en skjermleser kan gi deg samme type sjekk. NVDA er gratis for Windows, og VoiceOver er innebygd i Mac og iPhone. TalkBack er innebygd i Android-telefoner.
Test med faktiske brukere som har en eller flere nedsatte funksjonsevner. Jeg anbefaler at enhver større organisasjon med et budsjett for universell utforming utfører denne testingen. Testing med faktiske brukere kan gi deg og teamet ditt verdifull innsikt i hvordan brukere navigerer på nettstedet. Skjermleserbrukere, som Sara, kan også gi deg innsikt i om implementeringen av WAI-ARIA fungerer tilfredsstillende.
Hvor bør du begynne?
Det kan være vanskelig å vite hvor du skal begynne når du begynner å jobbe med WAI-ARIA. Et tips er å begynne å sjekke de tre mest brukte egenskapene: "aria-label" (for å gi komponenten et tilgjengelig navn), aria-live (for å informere om dynamiske oppdateringer) og aria-expanded. Hvis du implementerer disse på en korrekt måte, vil du kunne forbedre brukeropplevelsen av nettsiden betraktelig. Dette vil også gjøre nettsiden mer universelt utformet for brukere som Sara.
Husk! At aria-attributter aldri kan erstatte HTML. Bruk derfor alltid HTML først. Vi ser ofte aria-roller lagt til semantiske HTML-elementer, for eksempel: <nav role=”navigation”>. <nav> er et semantisk element i HTML som allerede er tilgjengelig for tilgjengelighet og beskriver innholdet til nettleseren at det er en navigasjon, og gir samme funksjonalitet som ARIA rollenavigasjon, role=”navigation”. Derfor er det unødvendig å legge til ARIA-roller når du bruker et semantisk HTML-element. Bruk derfor WAI-ARIA med forsiktighet.
