ARIA er en forkortelse for Accessible Rich Internet Applications. ARIA er en standard som kan gjøre nettinnhold og applikasjoner mer tilgjengelige (universelt utformet), spesielt dynamisk innhold og avanserte kontroller. ARIA kan være nødvendig for å imøtekomme WCAG-krav, men i The 2024 report on the accessibility of the top 1,000,000 home pages skrives det følgende:

Nettsider som bruker ARIA har gjennomsnittlig 34,2 % flere oppdagede feil enn de uten ARIA – man kan forvente å finne ytterligere 15 potensielle barrierer på hjemmesider med ARIA.

Økt ARIA-bruk på sider var forbundet med flere tilgjengelighetsfeil. Jo flere ARIA-attributter, desto flere tilgjengelighetsfeil kunne forventes. Dette betyr ikke nødvendigvis at ARIA introduserte disse feilene (disse sidene er mer komplekse), men sidene hadde vanligvis flere feil når ARIA ble brukt.

Husk at: ingen ARIA er bedre enn dårlig ARIA.

Nedenfor finner du fem regler du skal følge når du vurderer å bruke ARIA.

Regel 1: Ikke bruk ARIA, bruk HTML

Bruk HTML-elementer og attributter når du kan. ARIA kan vurderes hvis HTML ikke har den semantikken som trengs.

Hvis du for eksempel skal ha et avmerkingsfelt skal du bruke HTML:
<input type="checkbox">

Ikke bruk:
<div role="checkbox">

Med et HTML-avmerkingsfelt formidles semantikken (altså at det er et avmerkingsfelt) automatisk til tilgjengelighetslaget. Hjelpeteknologi (skjermlesere etc.) trenger derfor ikke å gjøre noe ekstra.

Vurder ARIA:

Regel 2: Ikke endre native semantikk, med mindre du absolutt må

ARIA brukt på et element med semantisk betydning endrer elementets native semantikk. Nesten alle HTML-elementer har en semantisk betydning, og denne semantikken skal ikke endres hvis det ikke er veldig viktig. Et eksempel kan være en overskrift som også skal være en fane (tab):

<div role=tab><h2>Faneoverskrift</h2></div>

Ikke bruk:
<h2 role=tab>Faneoverskrift</h2>

Regel 3: Alle interaktive ARIA-kontroller skal kunne brukes med tastatur

ARIA legger til semantikk, ikke tastaturstøtte. Brukes egenutviklede kontroller må derfor tastaturstøtte legges til og være tilsvarende det som brukes i native kontroller.

Har du for eksempel en knapp <div role="button"> må du både sørge for at knappen kan nås med tastatur og at den fungerer med mellomrom og enter.

Regel 4: Ikke bruk role="presentation" eller aria-hidden="true" på et fokuserbart element

role="presentation" eller role="none" fjerner semantikken fra tilgjengelighetstreet, og elementet som har role="none" er ikke interaktivt. På samme måte er aria-hidden attributtet ment å skjule innholdet eller elementet fra tilgjengelighets-API'ene. Elementer med aria-hidden="true" er heller ikke ment å være interaktive. Brukes disse attributtene på interaktive elementer vil noen fokusere på «ingenting».

Eksempler på riktig koding:
<button role="presentation" tabindex="-1">Ikke trykk her</button>
<button style="display: none">Ikke trykk her</button>

Ikke bruk:
<button role="presentation">Trykk her</button>
eller
<button aria-hidden="true">Trykk her</button>

Regel 5: Alle interaktive elementer skal ha et tilgjengelig navn

Alle interaktive elementer (lenker, knapper, tekstfelt, kombinasjonsbokser, alternativknapper, avmerkingsbokser osv.) på en nettside skal ha et tilgjengelig navn. Uten et tilgjengelig navn forstår ikke hjelpeteknologier hva kontrollen handler om. For å gi det tilgjengelige navnet er det ulike teknikker, og de varierer fra kontroll til kontroll. Her er noen eksempler:

Dette feltet har en synlig ledetekst, men ikke et tilgjengelig navn:
Navn <input type=”text”>

Feltet nedenfor har derimot et tilgjengelig navn som opprettes ved hjelp av id’en:
<label for=”id-navn”>Navn</label>
<input type=”text” id=”id-navn”>