Förstå ARIA-etiketter och alt-texter
Sidor med ARIA har i snitt dubbelt så många tillgänglighetsfel. Inte för att ARIA är dåligt, utan för att det används fel. Här är hur du undviker fällorna.
Varje element på en webbsida har, eller borde ha, ett namn. Inte det namn du ser i koden, utan det namn som en skärmläsare läser upp för användaren. Det kallas accessible name, och det är grunden för hur personer med synnedsättning navigerar webben. Problemet är att många utvecklare blandar ihop verktygen som skapar dessa namn. Resultatet syns i statistiken: WebAIM Million 2025 visar att sidor som använder ARIA i snitt har dubbelt så många tillgänglighetsfel som sidor utan. Inte för att ARIA är dåligt, utan för att det används fel.
Det tillgängliga namnet och hur det beräknas
När en skärmläsare stöter på ett element, till exempel en knapp, behöver den veta vad knappen gör. Svaret hämtas genom en process som W3C kallar Accessible Name and Description Computation. Det låter tekniskt, men logiken är enkel: webbläsaren letar efter ett namn i en bestämd ordning och stannar vid den första träffen.
Prioritetsordningen ser ut så här. Först kontrolleras om elementet har ett aria-labelledby-attribut som pekar på ett annat element vars text blir namnet. Om det saknas kollar webbläsaren efter aria-label. Därefter kommer elementspecifika mekanismer: alt för bilder, <label> för formulärfält, textinnehåll för knappar och länkar. Sist i ordningen finns title, men det attributet bör du i praktiken aldrig förlita dig på för tillgänglighet. Det fungerar inte på touchskärmar, det visas inte för tangentbordsanvändare, och skärmläsare hanterar det inkonsekvent. title är en kvarleva som inte hör hemma i modern tillgänglighetspraxis.
Den här ordningen är viktig att förstå, för den innebär att ett aria-labelledby alltid trumfar allt annat. Om en knapp har texten “Skicka” men samtidigt ett aria-labelledby som pekar på en rubrik som säger “Kontaktformulär” kommer skärmläsaren att säga “Kontaktformulär” och ignorera “Skicka”. Det kan vara exakt rätt i vissa fall, och helt förvirrande i andra.
Alt-texter: specifikt för bilder
alt-attributet hör hemma på <img>-element och ingenstans annars. Det beskriver bildens innehåll eller funktion, och det finns tre typiska situationer.
En informativ bild ska ha en alt-text som förmedlar samma information som bilden ger en seende användare. Om bilden visar ett enkelt cirkeldiagram kan alt-texten beskriva fördelningen direkt: “Cirkeldiagram: 60% utveckling, 25% drift, 15% support.” Att skriva “Diagram” eller “Bild av data” ger ingen användbar information. Men för komplexa diagram och visualiseringar blir en alt-text snabbt för lång. En skärmläsaranvändare som råkar tabba förbi en bild vill inte lyssna på tre meningar med data. I sådana fall är det bättre att ge bilden en kort alt-text som sammanfattar poängen och sedan använda aria-describedby för att peka på en längre beskrivning, exempelvis en tabell eller ett textstycke under bilden som innehåller all data.
En funktionell bild, som en ikon i en klickbar knapp, ska beskriva funktionen snarare än utseendet. En förstoringsglasikon i en sökknapp behöver alt-texten “Sök”, inte “Förstoringsglas”.
En dekorativ bild, som en bakgrundsgradient eller ett rent estetiskt foto, ska ha en tom alt-text: alt="". Det tomma attributet signalerar till skärmläsaren att bilden inte bär information och kan hoppas över. Att utelämna alt-attributet helt är däremot ett fel, för då försöker skärmläsaren ofta läsa upp filnamnet, vilket sällan är upplysande.
ARIA-etiketter: när HTML inte räcker
ARIA, Accessible Rich Internet Applications, är ett komplement till HTML:s inbyggda semantik. W3C formulerade fem regler för ARIA-användning, och de två första är värda att memorera.
Första regeln: använd inte ARIA om du kan lösa problemet med nativ HTML. En <button> behöver inget role="button". Ett <input> med en kopplad <label> behöver inget aria-label.
Andra regeln: ändra inte nativ semantik om du kan undvika det. Att sätta role="button" på en <a>-tagg skapar förvirring. En länk aktiveras med Enter, en knapp med både Enter och Space. Skärmläsaren annonserar elementet som knapp, men webbläsaren beter sig fortfarande som en länk. Användaren trycker Space och ingenting händer, eller sidan scrollar. Om något ska vara en knapp, använd <button>. Om det ska vara en länk, använd <a>.
Men ibland räcker inte HTML. Om du bygger en komponent som saknar en HTML-motsvarighet, exempelvis en anpassad slider eller en trädvy, behövs ARIA-roller och attribut för att skärmläsaren ska förstå vad komponenten är och hur den beter sig. Och om ett element saknar synlig text, som en ikonknapp utan etikett, behövs aria-label för att ge det ett namn.
Skillnaden mellan aria-label och aria-labelledby är var namnet kommer ifrån. aria-label tar en textsträng direkt: aria-label="Stäng dialogruta". aria-labelledby pekar på id:t hos ett annat element och använder dess textinnehåll som namn. Det gör aria-labelledby särskilt användbar när det redan finns en synlig rubrik eller etikett på sidan, för då slipper du upprepa texten och riskerar att den hamnar ur synk.
Varför “no ARIA is better than bad ARIA”
WebAIM har i sin årliga granskning av en miljon startsidor upprepade gånger visat att sidor med ARIA i snitt har fler tillgänglighetsfel. I 2025 års rapport hade sidor med ARIA dubbelt så många uppmätta fel jämfört med sidor utan. Samtidigt ökade antalet aria-hidden="true" med 16 procent jämfört med föregående år, och antalet role="button" med 16 procent.
Sambandet är inte att ARIA orsakar felen. Det är att ARIA ofta används som plåster på dålig HTML. En <div> med role="button" och aria-label="Skicka" ser tillgänglig ut i koden, men utan tabindex="0" och tangentbordslyssnare för Enter och Space är den oanvändbar för alla som inte har en mus. Nativ <button> ger allt det gratis.
Ett annat vanligt misstag är att aria-label skriver över synlig text utan att utvecklaren inser det. WCAG 2.5.3, Label in Name, kräver att det tillgängliga namnet ska innehålla den synliga texten. Om en knapp visar “Skicka” men har aria-label="Skicka in ansökningsformulär" fungerar det, för “Skicka” ingår i det tillgängliga namnet. Men om knappen visar “Skicka” och har aria-label="Submit form" bryts kopplingen. En person som använder röststyrning och säger “klicka Skicka” får inget svar, för skärmläsaren ser bara “Submit form”.
I praktiken: en beslutsmodell
Innan du lägger till ett ARIA-attribut, ställ dig tre frågor. Finns det ett HTML-element som redan löser problemet? Om ja, använd det. Har elementet redan synlig text som fungerar som etikett? Om ja, behövs sannolikt inget ARIA-attribut alls, eller möjligen ett aria-labelledby som pekar på texten. Saknar elementet helt synlig text eller en HTML-baserad namngivning? Först då är aria-label rätt val.
Den modellen hjälper dig att undvika den vanligaste fällan: att reflexmässigt lägga till ARIA “för säkerhets skull”. Varje ARIA-attribut du lägger till är ett löfte till webbläsaren om att du har gjort jobbet. Om du sätter role="menu" på ett element lovar du att det beter sig som en meny, med piltangennavigering och rätt fokushantering. Levererar du inte på det löftet skapar du en sämre upplevelse, inte en bättre.
W3C:s ARIA Authoring Practices Guide, APG, innehåller referensimplementationer för vanliga mönster som modaler, flikar, menyer och trädvyer. Börja där i stället för att uppfinna hjulet. Det sparar tid och minskar risken för fel som bara syns med skärmläsare.