Hvad er ARIA? Roller, landemærker og live-regioner

Hvad ARIA er — og hvad det ikke er

ARIA står for Accessible Rich Internet Applications. Det er et sæt attributter defineret af W3C’s Web Accessibility Initiative (WAI), som lader udviklere kommunikere betydningen og tilstanden af brugergrænsefladeelementer til hjælpeteknologi som skærmlæsere.

Den vigtigste regel om ARIA er også den, der oftest ignoreres: brug ikke ARIA, når native HTML kan klare opgaven. Et <button>-element annoncerer allerede sig selv som en knap og reagerer på tastaturhændelser. Et <nav>-element kommunikerer allerede navigationslandemærket til skærmlæsere. At tilføje role="button" til en <div> og derefter skrive dens adfærd i JavaScript er sværere at vedligeholde, lettere at ødelægge og som regel dårligere for tilgængeligheden end at bruge det rigtige element fra starten.

ARIA gør ikke følgende:

Gør indhold synligt eller interaktivt — det ændrer kun, hvad hjælpeteknologi annoncerer
Retter ødelagt tastaturadgang — du har stadig brug for tabindex og event-lyttere
Erstatter velstruktureret, semantisk HTML

Hvor ARIA reelt hjælper, er når native HTML ikke har noget element til det, du bygger: en datovælger, et banner med live-notifikationer, en brugerdefineret combobox, en trævisning. I de tilfælde lader ARIA dig kommunikere den semantik, HTML ikke kan.

ARIA-roller

En rolle fortæller hjælpeteknologi, hvilken slags element den har med at gøre. Ethvert interaktivt element har en implicit rolle afledt af sit HTML-tag. Elementet <a> har rollen link. Elementet <input type="checkbox"> har rollen checkbox. Elementet <h2> har rollen heading.

Når du bygger et brugerdefineret element, der ikke har nogen HTML-ækvivalent, tildeler du det en eksplicit rolle:

<!-- En brugerdefineret kontakt bygget af en div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Mørk tilstand
</div>

Skærmlæseren annoncerer nu dette som en kontakt og oplyser dens til/fra-tilstand. Uden rollen ville det blive annonceret som almindelig tekst, og brugeren ville ikke ane, at det er interaktivt.

Almindelige roller, og hvornår du bruger dem

Widget-roller beskriver interaktive kontroller:

Rolle	Bruges når
`button`	Et brugerdefineret klikbart element uden bedre HTML-tag
`checkbox`	Brugerdefineret til/fra-kontrol med flervalg
`combobox`	Et tekstinput kombineret med en listbox-rullemenu
`dialog`	En modal overlejring (kun når det native `<dialog>`-element ikke bruges)
`listbox`	En brugerdefineret rulleliste
`slider`	En brugerdefineret intervalkontrol
`switch`	En til/fra-kontakt
`tab`, `tablist`, `tabpanel`	En fanebladsgrænseflade
`tooltip`	En kort beskrivelse vist ved hover eller fokus

Roller for dokumentstruktur beskriver ikke-interaktivt indhold:

article — et selvstændigt stykke indhold
figure — et billede med en billedtekst
list, listitem — når listesemantik er nødvendig på elementer, der ikke er lister
presentation / none — fjerner et elements implicitte rolle (bruges sjældent og med omtanke)

En kritisk fejl: roller uden adfærd

Hver rolle bærer en kontrakt, som skærmlæsere og tastaturbrugere forventer bliver overholdt. En role="button" skal reagere på både Enter og mellemrum. En role="checkbox" skal skifte tilstand på mellemrum. En role="link" skal navigere på Enter.

Hvis du tilføjer rollen, men ikke den tilsvarende adfærd, vildleder du aktivt brugere med hjælpeteknologi. De hører en kontrol blive annonceret, forsøger at interagere med den ved hjælp af den forventede tastaturgenvej, og der sker ingenting. Det er værre end slet ingen ARIA.

ARIA-landemærker

Landemærker er sidens navigationsskelet. De lader skærmlæserbrugere springe mellem større regioner uden at læse alt derimellem — svarende til, at en seende bruger med et blik skanner sidens layout.

HTML5 introducerede semantiske elementer, der kortlægges direkte til landemærkeroller. Bruger du dem, får du landemærkerne gratis:

HTML-element	Landemærkerolle	Formål
`<header>`	`banner`	Sidehoved for hele sitet (kun når det er sidehovedet på øverste niveau, ikke inde i `<article>`)
`<nav>`	`navigation`	En navigationsmenu
`<main>`	`main`	Sidens primære indhold
`<aside>`	`complementary`	Sekundært indhold relateret til hovedindholdet
`<footer>`	`contentinfo`	Sidefod for hele sitet
`<form>`	`form`	En formular (kun når den har et tilgængeligt navn)
`<section>`	`region`	Et navngivet afsnit (kun når det har et tilgængeligt navn via `aria-label` eller `aria-labelledby`)

Du behøver ikke tilføje role="main" til et <main>-element — det er overflødigt. ARIA-landemærkeroller er kun nødvendige, når du ikke kan bruge det semantiske HTML-element, for eksempel i en ældre kodebase, der genererer <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Relaterede artikler">
  <!-- indhold i sidebjælken -->
</div>

Mærkning af landemærker, når du har mere end ét

Når en side har flere forekomster af samme landemærke — to <nav>-elementer, to <section>-elementer med role="region" — skal hvert af dem have et unikt tilgængeligt navn, så brugerne kan skelne dem fra hinanden:

<nav aria-label="Hovednavigation">...</nav>
<nav aria-label="Navigation i sidefod">...</nav>

Uden etiketter annoncerer en skærmlæser blot begge som “navigation”. Med etiketter hører brugerne “Hovednavigation, navigationslandemærke” og “Navigation i sidefod, navigationslandemærke” og kan vælge det rigtige fra en liste over landemærker.

ARIA live-regioner

En live-region er et område på siden, hvis indhold opdateres dynamisk, og hvor de opdateringer automatisk bør annonceres for skærmlæserbrugere, uden at de skal flytte fokus.

Kerneattributten er aria-live. Den accepterer tre værdier:

off — opdateringer annonceres ikke (standard for alle elementer)
polite — opdateringer annonceres, når brugeren har afsluttet sin aktuelle opgave
assertive — opdateringer afbryder straks det, skærmlæseren er i gang med at sige

<!-- Et statusbeskedområde, der udfyldes efter en formularindsendelse -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Din besked er sendt.';
</script>

Når tekstindholdet ændrer sig, venter en skærmlæser med aria-live="polite" på en pause i talen og annoncerer derefter det nye indhold. Brug polite til langt de fleste dynamiske opdateringer. Reservér assertive til kritiske fejl — en betalingsfejl, en advarsel om, at sessionen udløber — hvor informationen er presserende nok til at retfærdiggøre at afbryde brugeren.

Rollegenveje til live-regioner

To roller samler aria-live-semantikken i en enkelt attribut:

role="status" — svarer til aria-live="polite". Bruges til succesbeskeder, indlæsningstilstande og ikke-presserende opdateringer.
role="alert" — svarer til aria-live="assertive" og indebærer desuden aria-atomic="true". Bruges til fejlbeskeder og kritiske fejl.

<!-- Fejl annonceres straks og afbryder den aktuelle tale -->
<div role="alert" id="payment-error"></div>

<!-- Statusopdatering annonceres høfligt efter den aktuelle tale -->
<div role="status" id="cart-count">3 varer i kurven</div>

Almindelige fejl med live-regioner

Indhold tilføjes, før elementet er i DOM’en. Browseren registrerer live-regionen, når elementet parses første gang. Hvis du indsætter elementet og sætter dets tekstindhold samtidig, misser nogle skærmlæsere annonceringen fuldstændigt. Medtag altid live-region-beholderen i den oprindelige HTML og opdater dens indhold via JavaScript senere.

assertive bruges til alting. Assertive live-regioner afbryder det, brugeren er i gang med, inklusive andre annonceringer. Et antal søgeresultater, der opdateres, mens brugeren skriver, berettiger ikke til role="alert". Overforbrug af assertive giver en fjendtlig oplevelse for skærmlæserbrugere.

Live-regionen opdateres for hyppigt. Hvis en statuslinje opdaterer sin live-region hvert 100. millisekund, løber talekøen over, og brugerne hører intet brugbart. Opdater kun live-tekst ved meningsfulde milepæle — 25 %, 50 %, 75 %, færdig — eller debounce opdateringerne med en timer.

aria-atomic glemmes. Som standard annonceres kun den ændrede tekstknude inde i en live-region. Hvis du vil have hele regionen læst op igen (ikke bare det ændrede fragment), så tilføj aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> varer tilbage
</div>

Uden aria-atomic annoncerer en skærmlæser måske kun “2”, når tallet skifter fra 3 til 2. Med den bliver hele sætningen “2 varer tilbage” læst op, hvilket næsten altid er det, du vil have.

Andre essentielle ARIA-attributter

aria-label — giver et tilgængeligt navn, når ingen synlig tekst er passende:

<button aria-label="Luk dialogboks">✕</button>

aria-labelledby — peger på et andet element, hvis tekst fungerer som det tilgængelige navn. Foretrækkes frem for aria-label, når etiketteksten allerede er synlig på siden:

<h2 id="billing-heading">Faktureringsadresse</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — peger på supplerende tekst, der beskriver et element ud over dets navn:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Skal være mindst 12 tegn og indeholde ét symbol.</p>

aria-expanded — angiver, om et sammenklappeligt element (rullemenu, harmonika, menu) er åbent eller lukket. Opdater den i JavaScript, hver gang tilstanden ændrer sig:

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — fjerner et element fra tilgængelighedstræet. Bruges til dekorative ikoner, dublerende tekst eller visuelle elementer, der ville skabe støj for skærmlæserbrugere:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 ud af 5 stjerner</span>

aria-disabled="true" — markerer en kontrol som deaktiveret uden at fjerne den fra fokusrækkefølgen. Nyttigt, når du vil have brugerne til at opdage, at kontrollen findes, og forstå, hvorfor den er utilgængelig, i stedet for at den springes lydløst over:

<button aria-disabled="true">Send (udfyld alle felter først)</button>

Test af ARIA i praksis

Det er ligetil at skrive ARIA-attributter. At få dem rigtige kræver test. Automatiserede scannere fanger tydeligt ødelagte mønstre — en role="button" uden tilgængeligt navn, en aria-labelledby, der refererer til et ikke-eksisterende ID, en live-region med en ugyldig aria-live-værdi. De kan ikke fortælle dig, om den annoncerede tekst giver mening i sammenhængen, eller om en kompleks brugerdefineret widget opfører sig korrekt, når man navigerer i den med tastaturet alene.

Til test i den virkelige verden bør du kombinere mindst to par af skærmlæser og browser:

NVDA + Chrome på Windows — gratis, udbredt og tæt på den faktiske skærmlæserpopulation
VoiceOver + Safari på macOS eller iOS — indbygget, essentiel til test af mobiltilgængelighed
JAWS + Chrome eller Edge på Windows — betalt, men den mest udbredte skærmlæser i virksomhedsmiljøer

Navigér i dine interaktive komponenter udelukkende med tastaturet. Lyt nøje til, hvad der annonceres, når du åbner en menu, indsender en formular med en valideringsfejl eller udløser en opdatering af en live-region. Hvis annonceringen er tvetydig eller vildledende, er ARIA-implementeringen forkert — uanset hvad et automatiseret værktøj rapporterer.

Reglen, der dækker det hele

ARIA-specifikationen indeholder fem regler for udviklere. Den første er den vigtigste:

Hvis du kan bruge et native HTML-element eller en native HTML-attribut, der allerede har den semantik og adfærd, du har brug for, i stedet for at genanvende et element og tilføje en ARIA-rolle, -tilstand eller -egenskab for at gøre det tilgængeligt, så gør det.

Byg med semantisk HTML. Grib kun til ARIA, når HTML ikke rækker længere. Test med en rigtig skærmlæser. Det dækker næsten enhver situation, du kommer ud for.

Vil du have en praktisk kontrol af, hvordan ARIA-attributter er implementeret på tværs af dit site, omfatter vores manuelle tilgængelighedsaudits skærmlæsertest udført af folk, der bruger hjælpeteknologi hver dag og kan opdage subtile ARIA-problemer, som automatiserede værktøjer overser.