ARIA (Accessible Rich Internet Applications)

Vad är ARIA?

ARIA står för Accessible Rich Internet Applications. Det är en samling HTML-attribut definierade av W3C som berättar för hjälpmedel — som skärmläsare — vad ett interaktivt element gör. ARIA överbryggar klyftan mellan anpassade webbkomponenter och de verktyg som personer med funktionsnedsättningar förlitar sig på varje dag.^[1]

Varför finns ARIA?

Standard-HTML-element som <button> och <input> har redan inbyggd betydelse. Webbläsare skickar den informationen till skärmläsare automatiskt. Men moderna webbplatser använder anpassade widgetar — rullgardinsmenyer, modala dialoger, flikpaneler och autokompletteringsfält — som saknar inbyggd HTML-motsvarighet. Utan extra kod är dessa komponenter osynliga för hjälpmedel. ARIA fyller det gapet.

För organisationer med komplexa webbapplikationer — som nätbanker, offertverktyg för försäkring eller myndighetstjänster — är ARIA avgörande. Utan det kan inte skärmläsaranvändare utföra uppgifter som seende användare klarar på sekunder.

Hur fungerar ARIA?

ARIA använder tre typer av attribut:

• Roller — Berättar för hjälpmedel vad ett element är. Till exempel markerar role="dialog" en popup som en modal. role="tabpanel" markerar ett innehållsfält i ett flikgränssnitt.
• Egenskaper — Beskriver fasta drag. aria-label ger ett element ett tillgängligt namn. aria-required markerar ett formulärfält som obligatoriskt.
• Tillstånd — Visar vad som händer just nu. aria-expanded="true" betyder att en rullgardinsmeny är öppen. aria-checked="false" betyder att en kryssruta inte är ikryssad. Tillstånd ändras när användare interagerar med sidan.

Dessa attribut matar webbläsarens tillgänglighetsträd — en dold karta över sidan som hjälpmedel läser istället för den visuella layouten.^[2]

Vad är ARIA:s första regel?

W3C säger själva: om ett inbyggt HTML-element redan gör jobbet, använd det istället för att lägga till ARIA.^[3] En riktig <button> är alltid bättre än en <div> med role="button". Det inbyggda elementet har tangentbordsstöd och skärmläsarbeteende färdigt.

Felanvänd ARIA gör mer skada än ingen ARIA alls. Felaktiga roller, saknade underordnade element eller gamla tillståndsvärden får skärmläsare att läsa upp felaktig information. IT-team som bygger anpassade komponenter bör se ARIA som en sista utväg, inte ett första steg.

Hur hänger ARIA ihop med WCAG-efterlevnad?

Flera WCAG-regler är direkt beroende av korrekt ARIA-användning:

• WCAG 4.1.2 Namn, roll, värde (nivå A) — Varje interaktivt element måste visa sitt namn, sin roll och sitt aktuella tillstånd för hjälpmedel. Anpassade widgetar uppfyller denna regel genom ARIA-attribut.
• WCAG 4.1.3 Statusmeddelanden (nivå AA) — Statusuppdateringar — som "Ditt formulär har skickats" — måste läsas upp av skärmläsare utan att flytta fokus. ARIA live-regioner (role="status", role="alert") gör det möjligt.

För juridiska team och efterlevnadsansvariga innebär det att ARIA-fel inte bara är utvecklarbuggar. De är WCAG-brister som kan dyka upp i revisionsrapporter och myndighetstillsyn.

Vad är ARIA live-regioner?

Live-regioner löser ett specifikt problem: hur berättar man för en skärmläsare om innehåll som ändras utan sidladdning? Tänk dig ett chattmeddelande som anländer, ett valideringsfel som visas eller sökresultat som uppdateras medan du skriver.

Attributet aria-live och roller som role="alert" instruerar skärmläsare att läsa upp dessa ändringar automatiskt. Utan live-regioner missar användare kritiska uppdateringar helt.^[1]

För stora e-handels- eller banksajter med realtidsnotifikationer är live-regioner inte valfria — de är en central del av en tillgänglig upplevelse.

Vilken version av ARIA är aktuell?

WAI-ARIA 1.2 blev en W3C-rekommendation i juni 2023. Version 1.3 är under utveckling. Relaterade resurser inkluderar ARIA Authoring Practices Guide (APG), som erbjuder testade kodmönster för vanliga widgetar som menyer, flikar och dialoger.^[4]

Så hjälper Askem

För stora organisationer med hundratals sidor och specialbyggda komponenter är manuella ARIA-kontroller inte realistiska. Automatiserade verktyg för tillgänglighetsskanning ger team en helhetsbild av var ARIA-problem finns. Verktyg som Askem skannar varje sida och flaggar saknade eller felaktiga attribut. När en ny funktion lanseras med en trasig aria-label eller en saknad role fångar kontinuerlig övervakning det och varnar teamet innan en myndighetsgranskning eller ett användarklagomål hinner dyka upp.

Källor

1. W3C — Accessible Rich Internet Applications (WAI-ARIA) 1.2: https://www.w3.org/TR/wai-aria-1.2/
2. W3C — Accessibility Tree: https://www.w3.org/TR/accname-1.2/
3. W3C — Using ARIA (First Rule): https://www.w3.org/TR/using-aria/#rule1
4. W3C — ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/