Ingen ARIA er bedre enn feil ARIA

Skrevet av: Morten Tollefsen

Denne artikkelen er ikke en oversettelse av Top 5 Rules of ARIA, men innholdet er hentet fra artikkelen og delvis fra Using ARIA. Min erfaring med ARIA er at:

ArIA er ukjent for Relativt mange utviklere.
Når utviklere først får vite om ARIA brukes standarden for mye og ofte feil.
Når utviklere forstår ARIA brukes standarden mye mindre og riktigere.

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-amerkingsfelt formidles semantikken (altså at det er et avmerkingsfelt) automatisk til tilgjengelighetslaget. Hjelpeteknologi (skjermlesere etc) trenger derfor ikke å gjøre noe ekstra.

Vurder ARIA:

Hvis du har eksisterende nettsider som skal utbedres, og ARIA kan gjøre tilgjengelighetsforbedringer mindre ressurskrevende enn å skrive om all kode.
Hvis et element ikke kan styles kan du bruke et egendefinert element og bruke ARIA for å legge til semantikk.
Hvis språket som brukes (eks. HTML 5) mangler nødvendig semantikk kan ARIA brukes. Et eksempel er trestrukturer som ikke finnes i HTML 5.
Hvis brukeragenten ikke har støtte for et HTML 5.x element kan ARIA brukes for å formidle semantikk.

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

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="presentasjon" 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:

Lenker og knapper: teksten i knappen eller lenken blir det tilgjengelige navnet.
Tekstfelt: For å kunne angi det tilgjengelige navnet, må skjemakontroller knyttes til den synlige etiketten enten implisitt eller eksplisitt.
Egendefinerte kontroller: aria-label eller aria-labelledby kan brukes for å gi kontrollen et tilgjengelig navn.

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