# ARIA ## Hva det er ARIA, med fullt navn WAI-ARIA, er en W3C-spesifikasjon for HTML-attributter som forteller hjelpemiddelteknologi hva et element på en nettside er, hva det heter og hvilken tilstand det er i, der HTML alene sier for lite. Bokstavene står for Accessible Rich Internet Applications, og WAI i det fulle navnet viser til Web Accessibility Initiative i W3C. Gjeldende anbefaling er versjon 1.2. Attributtet `role` sier hva slags ting elementet er: en kontroll som `button` eller `tab`, en del av strukturen som `list`, en av de åtte rollene for landemerker som `navigation` eller `main`, eller en live-region som `status`, der skjermleseren leser opp endringene uten at noen ber om det. `aria-*`-attributtene deler seg deretter i egenskaper, som `aria-labelledby`, og tilstander, som `aria-expanded`, som skifter mens brukeren arbeider. Nettleseren oversetter alt sammen til operativsystemets tilgjengelighets-API, og det er der en skjermleser eller et program for stemmestyring henter opplysningene sine. ARIA endrer hva som blir lest opp, og bare det. En `div` med `role="button"` leses opp som en skjermknapp, men den får ikke fokus, og Enter og mellomrom gjør ingenting før et `tabindex` og et skript sørger for begge deler. Derfor lyder den første regelen for bruk av ARIA i W3C-veiledningen Using ARIA omtrent slik: Når et innebygd HTML-element eller attributt allerede har den semantikken og oppførselen du trenger, bruker du det, i stedet for å gi et annet element ny mening og legge ARIA oppå. ```html
Send
``` Den andre halvdelen er det tilgjengelige navnet, ordene en skjermleser sier for en kontroll. Accessible Name and Description Computation 1.2 fastsetter rekkefølgen: først `aria-labelledby`, så `aria-label`, så vertsspråkets egen etikett (et `label`-element, en `alt`, en `title` i SVG), deretter elementets tekstinnhold for roller som henter navnet sitt derfra, og til slutt attributtet `title`. Et `aria-label` på en knapp erstatter dermed de synlige ordene i stedet for å legge noe til dem. ## Hvorfor det er viktig Valget ARIA legger foran et team, er om det skal bygge selv eller bruke det som allerede finnes. Suksesskriterium 4.1.2 i WCAG 2.2, Name, Role, Value, krever at hver komponent i et brukergrensesnitt gjør navnet og rollen sin tilgjengelig for programvare, lar tilstander og verdier som brukeren kan endre, settes programmatisk, og melder fra når de endres. En innebygd `button`, `select` eller `details` oppfyller dette uten videre. En hjemmelaget fanerad, kombinasjonsboks eller trestruktur oppfyller det bare gjennom ARIA og skriptet som holder ARIA-verdiene sanne. Dermed blir en hjemmelaget kontroll en løpende kostnad: tastaturhåndtering, fokusstyring, tilstander som følger hver handling, og testing i mer enn én skjermleser ved hver redesign. Vurder et komponentbibliotek etter hvilket mønster fra ARIA Authoring Practices Guide (APG) hver kontroll følger, og etter om mønsterets tastaturoppførsel er på plass når musen er lagt bort. Det rettslige presset når nå også private virksomheter. Webdirektivet, (EU) 2016/2102, dekker nettsteder og apper i offentlig sektor. Tilgjengelighetsdirektivet, direktiv (EU) 2019/882, kjent som European Accessibility Act (EAA), gjelder i EU fra 28. juni 2025 for en rekke produkter og tjenester til forbrukere, bl.a. netthandel og banktjenester, mens mikroforetak som leverer tjenester, er unntatt. Begge lener seg på den harmoniserte standarden EN 301 549, der kravene til web er WCAG på nivå AA. Name, Role, Value ligger på nivå A, så en kontroll der navnet eller rollen aldri når frem til skjermleseren, stryker allerede på det laveste nivået en revisjon sjekker. I Norge skal ikt-løsninger være universelt utformet, og ifølge Uutilsynet gjelder kravet både private og offentlige virksomheter. Endringene som fulgte av webdirektivet, gjelder fra 1. februar 2023. Tilgjengelighetsdirektivet trådte i kraft i EU 28. juni 2025, men i EØS-landene er gjennomføringen forsinket, og Norge er i ferd med å innlemme det i nasjonalt regelverk. ## Slik ser det ut i praksis Malene bak dette nettstedet bruker ARIA sparsomt. Topplinjen på hver underside er en `div` med `role="banner"` og ikke det vanlige `header`-elementet. Kommentaren i malen forklarer hvorfor: stilarket gjør et nakent `header`-element til forsidens store toppfelt i full høyde, så elementet ville tatt med seg den geometrien til hver underside, mens rollen gir landemerket og ingenting mer. Det er rollen som plasserer merkevaresymbolet, lenken hjem, inne i et landemerke, og det er nettopp det smale tilfellet den første regelen åpner for. Menyen går motsatt vei: den er et par av `details` og `summary`, som overlater åpen eller lukket tilstand, knappesemantikken og `aria-expanded` til nettleseren. Menyens `nav` og bunntekstens `nav` har hver sin `aria-label`, fordi to navigasjonslandemerker med samme navn bryter regelen om entydige navn i regelmotoren, og tilgjengelighetssjekken på nettstedet slipper bare gjennom null funn. Filteret på porteføljesiden melder antallet treff gjennom en region med `role="status"`, som holder seg stille til leseren begynner å skrive. Siden om hvordan nettstedet nådde [WCAG 2.2 nivå AA](/nb/portfolio/took-wcag-2-2-level-aa-across-the-whole-site-130/) gir den andre halvdelen av historien om topplinjen. Da reglene for beste praksis ble slått på i en regelmotor for universell utforming, feilet én av dem med en gang, fordi merkevaresymbolet på hver underside lå utenfor alle landemerker. Samme side oppgir blant begrensningene sine at det ikke er testet med ekte hjelpemiddelteknologi. Gjennomgangen av [elleve feil](/nb/portfolio/fixed-11-accessibility-defects-the-browser-called-healthy-131/) som nettleseren kalte friske, viser hvor langt oppmerkingen står fra opplevelsen. Alle elleve lå i hvordan siden ble gjengitt, og ikke i hva oppmerkingen sa, og oppmerkingen er det eneste ARIA berører. Åtte lenker i bunnteksten ble værende i tabulatorrekkefølgen etter at en stilregel hadde slått av pekerinteraksjon med dem og latt alt annet være: samme mønster som `aria-hidden` på et element som kan få fokus, der skjermleseren mister elementet mens tastaturet beholder det. Dessuten var bare sytti av regelmotorens hundre og fem regler slått på, og regelen som fanger et manglende landemerke, var blant dem som sto av. Den siste siden viser det samme problemet på en plattform der ARIA ikke spiller noen rolle. Siden om de [sytten ikonene](/nb/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/) som fikk navn for skjermlesere, handler om en SwiftUI-app uten HTML og uten et eneste `aria-`-attributt. Tilgjengelighetsetiketten der hører til SwiftUI selv, som det innebygde motstykket til `aria-label` og ikke en variant av det. Kontroller tegnet med systemsymboler ble lest opp med symbolets interne navn, så sendeknappen ble lest opp som «arrow up circle, button», og sytten rene ikonkontroller beskrev grafikken sin i stedet for funksjonen. Hver av dem fikk en etikett som navngir handlingen og følger tilstanden der det betyr noe, og en linter krever nå en etikett innenfor åtte linjer fra konstruksjonen som lager en ren ikonkontroll, så en attende kontroll slipper bare inn med etikett. Siden sier selv hvor grensen går, og den gjelder like mye for `aria-label`: sjekken bekrefter at det finnes en etikett i nærheten, mens bare et menneske som lytter, kan avgjøre om den er den riktige. ## Hvor det går galt **En rolle lover en kontroll som tastaturet aldri når frem til.** En `div` får `role="button"` og en klikkhandler. Skjermleseren sier «knapp», men Tab hopper over den, og Enter gjør ingenting. Den tredje regelen for bruk av ARIA krever at alle interaktive ARIA-kontroller kan betjenes med tastaturet. Bruk det innebygde elementet, eller bygg hele tastaturmodellen fra APG-mønsteret og test med musen koblet fra. **Fokus lander på noe skjermleseren regner som fraværende.** `aria-hidden="true"` sitter på et element som kan få fokus, eller på et overordnet element, f.eks. en skuffemeny utenfor skjermen. Tab fører fortsatt dit, og brukeren hører stillhet. Den fjerde regelen for bruk av ARIA utelukker nettopp dette. Ta skjult innhold ut av tabulatorrekkefølgen også, med `hidden`, `display: none` eller `inert`, og spar `aria-hidden` til pynt som aldri får fokus. **Et navn havner på et element som avviser navn.** Et `aria-label` på en `div`, `span` eller `p` er ment som en forklaring, men WAI-ARIA 1.2 forbyr å gi rollene `generic` og `paragraph` et navn, og skjermlesere overser det eller leser det opp ujevnt. På en kontroll erstatter etiketten de synlige ordene, og når de to er forskjellige, bommer en bruker av stemmestyring som sier det som står på skjermen. Gi navn til elementer som kan bære et, og la hvert `aria-label` begynne med de synlige ordene, slik WCAG 2.5.3, Label in Name, ber om. **To roller sier imot hverandre.** En eksplisitt rolle erstatter elementets egen. En lenke med `role="button"` leses opp som en knapp, men ruller siden ved trykk på mellomrom; `role="tab"` på en `h2` fjerner den fra listen over overskrifter; `role="navigation"` på en `ul` visker ut listen og antallet punkter. Den andre regelen for bruk av ARIA er å endre innebygd semantikk bare når du må, og ARIA in HTML lister opp hvilke roller hvert element kan få. **En live-region snakker i ett kjør.** `aria-live="assertive"` eller `role="alert"` sitter på et antall treff eller en nedtelling som endres ved hvert tastetrykk eller hvert sekund, og skjermleseren avbryter brukeren for hver nye verdi. Bruk høflige oppdateringer, som `role="status"` gir per definisjon, meld fra først når inntastingen har roet seg, og hold regionen stille når siden lastes. ## Les mer - [WAI-ARIA 1.2](https://www.w3.org/TR/wai-aria-1.2/) — alle roller, tilstander og egenskaper, hvilke attributter hver rolle støtter, og hvilke roller som ikke kan få navn. - [ARIA in HTML](https://www.w3.org/TR/html-aria/) — rollene og attributtene hvert HTML-element kan ha, og hvilke av dem som er overflødige. - [Using ARIA](https://www.w3.org/TR/using-aria/) — den praktiske veiledningen fra W3C, med reglene for bruk av ARIA og et eksempel på hver. - [Accessible Name and Description Computation 1.2](https://www.w3.org/TR/accname-1.2/) — algoritmen som avgjør hva en skjermleser sier at en kontroll heter. - [Understanding Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html) — hva suksesskriterium 4.1.2 i WCAG 2.2 krever av hver komponent, med teknikker og typiske feil. - [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — oppmerking og tastaturoppførsel for hvert vanlige kontrollmønster, med eksempler som virker.