Vad är ARIA? Roller, landmärken och live-regioner

Vad ARIA är — och vad det inte är

ARIA står för Accessible Rich Internet Applications. Det är en uppsättning attribut definierade av W3C:s Web Accessibility Initiative (WAI) som låter utvecklare kommunicera betydelsen och tillståndet hos användargränssnittselement till hjälpmedelsteknik som skärmläsare.

Den viktigaste regeln om ARIA är också den som oftast ignoreras: använd inte ARIA när HTML:s inbyggda element klarar jobbet. Ett <button>-element annonserar sig redan som en knapp och reagerar på tangentbordshändelser. Ett <nav>-element kommunicerar redan navigeringslandmärket till skärmläsare. Att lägga role="button" på en <div> och sedan skripta dess beteende är svårare att underhålla, lättare att förstöra och oftast sämre för tillgängligheten än att använda rätt element från början.

ARIA gör inte följande:

Gör innehåll synligt eller interaktivt — det ändrar bara vad hjälpmedelsteknik annonserar
Reparerar trasig tangentbordsåtkomst — du behöver fortfarande tabindex och händelselyssnare
Ersätter välstrukturerad semantisk HTML

Där ARIA genuint hjälper är när HTML saknar ett element för det du bygger: en datumväljare, en banner för live-aviseringar, en anpassad combobox, en trädvy. I sådana fall låter ARIA dig kommunicera den semantik som HTML inte kan.

ARIA-roller

En roll talar om för hjälpmedelstekniken vilken typ av element den har att göra med. Varje interaktivt element har en implicit roll som härleds från dess HTML-tagg. Elementet <a> har rollen link. Elementet <input type="checkbox"> har rollen checkbox. Elementet <h2> har rollen heading.

När du bygger ett anpassat element som saknar HTML-motsvarighet tilldelar du det en explicit roll:

<!-- En anpassad växlare byggd av en div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Mörkt läge
</div>

Skärmläsaren annonserar nu detta som en växlingskontroll och läser upp dess ikryssade tillstånd. Utan rollen skulle det annonseras som vanlig text och användaren skulle inte ana att det är interaktivt.

Vanliga roller och när du ska använda dem

Widgetroller beskriver interaktiva kontroller:

Roll	Använd när
`button`	Ett anpassat klickbart element utan bättre HTML-tagg
`checkbox`	Anpassad växlare för flerval
`combobox`	Ett textfält kombinerat med en listbox-rullgardin
`dialog`	Ett modalt överlägg (endast när det inbyggda `<dialog>`-elementet inte används)
`listbox`	En anpassad rullgardinslista
`slider`	En anpassad intervallkontroll
`switch`	En på/av-växlare
`tab`, `tablist`, `tabpanel`	Ett flikgränssnitt
`tooltip`	En kort beskrivning som visas vid hovring eller fokus

Roller för dokumentstruktur beskriver icke-interaktivt innehåll:

article — ett fristående innehållsstycke
figure — en bild med bildtext
list, listitem — när listsemantik behövs på element som inte är listor
presentation / none — tar bort ett elements implicita roll (använd sällan och med försiktighet)

Ett kritiskt misstag: att lägga till roller utan beteende

Varje roll bär med sig ett kontrakt som skärmläsare och tangentbordsanvändare förväntar sig ska hållas. En role="button" måste svara på både Enter och blanksteg. En role="checkbox" måste växla med blanksteg. En role="link" måste navigera med Enter.

Om du lägger till rollen men inte motsvarande beteende vilseleder du aktivt användare av hjälpmedelsteknik. De hör en kontroll annonseras, försöker interagera med den via den förväntade tangentbordsgenvägen, och ingenting händer. Det är sämre än ingen ARIA alls.

ARIA-landmärken

Landmärken är sidans navigeringsskelett. De låter skärmläsaranvändare hoppa mellan större regioner utan att läsa allt däremellan — motsvarigheten till en seende användares blick som snabbt skannar sidlayouten.

HTML5 introducerade semantiska element som mappar direkt till landmärkesroller. Använd dem så får du landmärkena gratis:

HTML-element	Landmärkesroll	Syfte
`<header>`	`banner`	Webbplatsövergripande sidhuvud (endast när det är sidhuvudet på översta nivån, inte inuti `<article>`)
`<nav>`	`navigation`	En navigeringsmeny
`<main>`	`main`	Sidans huvudsakliga innehåll
`<aside>`	`complementary`	Sekundärt innehåll relaterat till huvudinnehållet
`<footer>`	`contentinfo`	Webbplatsövergripande sidfot
`<form>`	`form`	Ett formulär (endast när det har ett tillgängligt namn)
`<section>`	`region`	Ett namngivet avsnitt (endast när det har ett tillgängligt namn via `aria-label` eller `aria-labelledby`)

Du behöver inte lägga till role="main" på ett <main>-element — det är överflödigt. ARIA:s landmärkesroller behövs bara när du inte kan använda det semantiska HTML-elementet, till exempel i en äldre kodbas som genererar <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Relaterade artiklar">
  <!-- innehåll i sidofältet -->
</div>

Att märka landmärken när du har fler än ett

När en sida har flera instanser av samma landmärke — två <nav>-element, två <section>-element med role="region" — måste var och en ha ett unikt tillgängligt namn så att användarna kan skilja dem åt:

<nav aria-label="Huvudnavigering">...</nav>
<nav aria-label="Navigering i sidfoten">...</nav>

Utan etiketter annonserar en skärmläsare båda helt enkelt som “navigering”. Med etiketter hör användarna “Huvudnavigering, navigeringslandmärke” och “Navigering i sidfoten, navigeringslandmärke” och kan välja rätt från en landmärkeslista.

ARIA live-regioner

En live-region är ett område på sidan vars innehåll uppdateras dynamiskt, och där dessa uppdateringar automatiskt ska annonseras för skärmläsaranvändare utan att de behöver flytta fokus.

Kärnattributet är aria-live. Det accepterar tre värden:

off — uppdateringar annonseras inte (standard för alla element)
polite — uppdateringar annonseras när användaren avslutat sin pågående uppgift
assertive — uppdateringar avbryter omedelbart det skärmläsaren håller på att säga

<!-- Ett område för statusmeddelanden som fylls efter att ett formulär skickats -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Ditt meddelande har skickats.';
</script>

När textinnehållet ändras väntar en skärmläsare med aria-live="polite" på en paus i uppläsningen och annonserar sedan det nya innehållet. Använd polite för de allra flesta dynamiska uppdateringar. Reservera assertive enbart för kritiska fel — ett betalningsfel, en varning om att sessionen håller på att gå ut — där informationen är brådskande nog att motivera att användaren avbryts.

Rollgenvägar för live-regioner

Två roller paketerar aria-live-semantiken i ett enda attribut:

role="status" — motsvarar aria-live="polite". Använd för bekräftelsemeddelanden, laddningstillstånd och icke brådskande uppdateringar.
role="alert" — motsvarar aria-live="assertive" och innebär också aria-atomic="true". Använd för felmeddelanden och kritiska fel.

<!-- Fel som annonseras omedelbart och avbryter pågående uppläsning -->
<div role="alert" id="payment-error"></div>

<!-- Statusuppdatering som annonseras artigt efter pågående uppläsning -->
<div role="status" id="cart-count">3 varor i varukorgen</div>

Vanliga misstag med live-regioner

Att lägga in innehåll innan elementet finns i DOM:en. Webbläsaren registrerar live-regionen när elementet först tolkas. Om du injicerar elementet och sätter dess textinnehåll samtidigt missar vissa skärmläsare annonseringen helt. Ha alltid med behållaren för live-regionen i den ursprungliga HTML:en och uppdatera dess innehåll via JavaScript senare.

Att använda assertive för allt. Assertiva live-regioner avbryter vad användaren än gör, inklusive andra annonseringar. En räknare för sökträffar som uppdateras medan användaren skriver motiverar inte role="alert". Överanvändning av assertive skapar en fientlig upplevelse för skärmläsaranvändare.

Att uppdatera live-regionen för ofta. Om en förloppsindikator uppdaterar sin live-region var 100:e millisekund svämmar talkön över och användarna hör ingenting användbart. Uppdatera live-texten bara vid meningsfulla milstolpar — 25 %, 50 %, 75 %, klart — eller fördröj (debounce) uppdateringarna med en timer.

Att glömma aria-atomic. Som standard annonseras bara den ändrade textnoden inuti en live-region. Om du vill att hela regionen ska läsas om (inte bara det ändrade fragmentet) lägger du till aria-atomic="true":

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

Utan aria-atomic kan en skärmläsare annonsera enbart “2” när antalet ändras från 3 till 2. Med attributet läses hela frasen “2 objekt kvar” upp, vilket nästan alltid är vad du vill.

Andra viktiga ARIA-attribut

aria-label — ger ett tillgängligt namn när ingen synlig text är lämplig:

<button aria-label="Stäng dialogruta">✕</button>

aria-labelledby — pekar på ett annat element vars text fungerar som det tillgängliga namnet. Föredras framför aria-label när etikettexten redan är synlig på sidan:

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

aria-describedby — pekar på kompletterande text som beskriver ett element utöver dess namn:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Måste vara minst 12 tecken och innehålla en symbol.</p>

aria-expanded — anger om ett hopfällbart element (rullgardin, dragspel, meny) är öppet eller stängt. Uppdatera det i JavaScript varje gång tillståndet ändras:

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

aria-hidden="true" — tar bort ett element från tillgänglighetsträdet. Använd för dekorativa ikoner, duplicerad text eller visuella element som bara skulle skapa brus för skärmläsaranvändare:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 av 5 stjärnor</span>

aria-disabled="true" — markerar en kontroll som inaktiverad utan att ta bort den ur fokusordningen. Användbart när du vill att användarna ska upptäcka att kontrollen finns och förstå varför den inte är tillgänglig, i stället för att den tyst hoppas över:

<button aria-disabled="true">Skicka (fyll i alla fält först)</button>

Att testa ARIA i praktiken

Att skriva ARIA-attribut är enkelt. Att få dem rätt kräver testning. Automatiserade skannrar fångar tydligt trasiga mönster — en role="button" utan tillgängligt namn, en aria-labelledby som pekar på ett obefintligt ID, en live-region med ett ogiltigt aria-live-värde. De kan inte tala om för dig om den annonserade texten är begriplig i sitt sammanhang, eller om en komplex anpassad widget beter sig korrekt när den navigeras med enbart tangentbord.

För verklighetsnära testning bör du kombinera minst två kombinationer av skärmläsare och webbläsare:

NVDA + Chrome på Windows — gratis, brett använt, ligger nära den verkliga skärmläsarpopulationen
VoiceOver + Safari på macOS eller iOS — inbyggt, oumbärligt för mobil tillgänglighetstestning
JAWS + Chrome eller Edge på Windows — betalprodukt, men den mest använda skärmläsaren i företagsmiljöer

Navigera dina interaktiva komponenter med enbart tangentbordet. Lyssna noga på vad som annonseras när du öppnar en meny, skickar ett formulär med ett valideringsfel eller utlöser en uppdatering av en live-region. Om annonseringen är tvetydig eller vilseledande är ARIA-implementeringen fel — oavsett vad något automatiserat verktyg rapporterar.

Regeln som täcker allt

ARIA-specifikationen innehåller fem regler för utvecklare. Den första är den viktigaste:

Om du kan använda ett inbyggt HTML-element eller -attribut som redan har den semantik och det beteende du behöver, i stället för att återanvända ett element och lägga till en ARIA-roll, ett tillstånd eller en egenskap för att göra det tillgängligt, så gör det.

Bygg med semantisk HTML. Ta till ARIA först när HTML tar slut. Testa med en riktig skärmläsare. Det täcker nästan varje situation du kommer att stöta på.

För en praktisk kontroll av hur ARIA-attribut är implementerade på hela din webbplats inkluderar våra manuella tillgänglighetsgranskningar skärmläsartestning av personer som använder hjälpmedelsteknik varje dag och kan upptäcka subtila ARIA-problem som automatiserade verktyg missar.