aria-label i HTML: Sådan bruger du det korrekt
![]()
aria-label: Lille kode, stor effekt
Forestil dig, at du besøger en onlinebutik og kun ser et ikon for indkøbskurv. Seende brugere forstår straks bestillingsfunktionen. Men for brugere, der er afhængige af skærmlæsere, forbliver knappen utydelig. Først med en aria-label som "Tilføj til kurv" bliver den tydeligt beskrevet og tilgængelig.
Digital tilgængelighed starter i koden. Semantisk HTML er fundamentet, mens aria-label kun supplerer, hvor standardelementer ikke er nok. Dette gavner ikke kun institutioner, men også virksomheder – især onlinebutikker, hvor tydelige knapper og formularfelter sikrer en problemfri bestillingsproces.
Hvad er en arie-label?
Attributten aria-label er en del af ARIA-specifikationen (Accessible Rich Internet Applications) fra W3C (World Wide Web Consortium). W3C er det internationale organ, der udvikler åbne webstandarder, herunder Retningslinjer for tilgængelighed af webindhold (WCAG) .
aria-label tilføjer usynlige etiketter til HTML-elementer, som skærmlæsere meddeler, når synlige etiketter mangler eller er utydelige. Dette bygger bro mellem design og teknisk tilgængelighed, hvilket gør grænseflader forståelige for alle.
Hvorfor ARIA-attributter er vigtige
ARIA-attributter blev udviklet for at sikre tilgængelighed, hvor HTML når sine grænser. Moderne websteder med dynamisk indhold – såsom JavaScript-elementer, brugerdefinerede widgets eller komplekse visuelle designs – bringer deres egne udfordringer. Her sikrer en ARIA-attribut som aria-label, at selv disse grænseflader fortolkes korrekt af skærmlæsere.
Forskel fra synlige etiketter i brugergrænsefladen
En vigtig forskel mellem aria-label og visible labels ligger i deres målgruppe: synlige labels er tilgængelige for alle brugere, mens aria-label udelukkende er til hjælpeteknologier.
Synlige etiketter er de standardtekstbeskrivelser, der vises i brugerfladen – for eksempel teksten "E-mailadresse" over eller ved siden af et inputfelt:
<label for="email">E-mailadresse</label>
<input type="email" id="email" name="email">
Alle brugere genkender straks, hvad de skal indtaste i feltet, og skærmlæsere læser også teksten højt. Hvis en sådan synlig etiket mangler, kan en arie-etiket bruges i stedet. Den tilføjer usynligt en beskrivelse, som kun skærmlæsere kan genkende:
<input type="email" id="email" name="email" aria-label="E-mailadresse">
På denne måde forbliver feltet forståeligt og tilgængeligt, selv uden en synlig etiket.

Hvordan fungerer aria-label i HTML?
Skærmlæsere bestemmer det tilgængelige navn på et element i en fast rækkefølge:
aria-labelledby – refererer til synlig tekst i koden
aria-label – usynlig etiket
synlig <etiket> – for formularfelter
tekstindhold – f.eks. knaptekst
titelattribut – sidste reserve
En søgeknap genkendes ikke uden en yderligere beskrivelse. Med aria-label="Søg" , skærmlæseren læser "Søg" højt – tydeligt og brugbart.
Eksempel:
En knap med et forstørrelsesglasikon til søgning har ingen synlig tekst. Uden yderligere oplysninger ville den være meningsløs for skærmlæsere. Men hvis du tilføjer aria-label="Søg" , annoncerer skærmlæseren "Søg" og ignorerer alle andre mulige kilder.
Eksempler på aria-label til knapper og links
Et almindeligt anvendelseseksempel for aria-label er knapper, der kun indeholder et ikon. For seende brugere forstås et forstørrelsesglas umiddelbart som en søgefunktion, men for skærmlæsere har det ingen betydning. Med aria-label bliver knappen også forståelig for hjælpeteknologier:
<button aria-label="Start søgning">
<svg aria-hidden="true" width="24" height="24">…</svg>
</knap>
Et andet praktisk eksempel er lister. Mange onlinebutikker bruger ikonbaserede lister, såsom kategorilister med symboler. Skærmlæsere ville kun annoncere "Liste med 5 varer". Med aria-label="Produktkategorier" , bliver det tydeligt, hvad listen indeholder.
Links bør til gengæld tydeligt beskrive, hvor de fører hen. En vag sætning som "Læs mere" er ikke tilgængelig, fordi den forbliver uklar uden kontekst. aria-label kan forbedre dette:
<a href="/artikel/tilgængelighed"
aria-label="Læs artikel om digital tilgængelighed">
Læs artiklen om digital tilgængelighed
</a>
aria-label for formularelementer
Formularer er en central del af næsten alle websteder. For at gøre dem tilgængelige, bør hvert formularfelt have et tydeligt navn. Normalt gøres dette med et synligt navn. <etiket> element:
<label for="email">E-mailadresse</label>
<input type="email" id="email" name="email">
Fordelen: Alle brugere ser etiketten "E-mailadresse", og skærmlæsere læser den højt. Derudover kan brugerne klikke på etiketten for automatisk at fokusere feltet.
Nogle gange bruges der af designmæssige årsager ingen synlig etiket – for eksempel når der kun vises en pladsholder inde i feltet. For skærmlæserbrugere er dette problematisk, da pladsholdere ikke behandles som officielle etiketter. Det er her, aria-label hjælper:
<input type="e-mail"
aria-label="E-mailadresse"
pladsholder="eksempel@domæne.com">
Seende brugere ser feltet som normalt, men skærmlæserbrugere hører "E-mailadresse". Dette sikrer, at feltet forbliver forståeligt, selv uden en synlig etiket.
Et andet eksempel er inputfelter, der kræver yderligere instruktioner —såsom adgangskodefelter. Her er en simpel etiket ikke nok. Med arie-beskrevet af , kan feltet linkes til yderligere information:
<input type="adgangskode"
aria-label="Adgangskode"
aria-describedby="pwd-help">
<div id="pwd-help">Mindst 8 tegn, inklusive et tal</div>
I dette tilfælde læser skærmlæseren først "Adgangskode" efterfulgt af "Mindst 8 tegn, inklusive ét tal".
Vigtig: aria-label i formularer bør generelt forblive den undtagelse En synlig <etiket> er næsten altid den bedre løsning – den er tydelig for alle, nemmere at bruge og kræver mindre yderligere logik. aria-label bør primært fungere som en reserveløsning, når etiketter er skjult af design- eller layoutårsager.
ARIA-roller og deres interaktion med labels
ARIA-roller beskriver funktionen af et element, mens aria-label definerer dets navn. Denne kombination er især vigtig for brugerdefinerede widgets, der går ud over standardsemantikken i HTML:
<div role="button" aria-label="Abonner på nyhedsbrev" tabindex="0">
<svg>...</svg>
Tilmeld dig
</div>
For interaktive widgets såsom menuer er yderligere attributter relevante. aria-udvidet angiver, om en menu er udvidet, mens aria-haspopup signalerer, at et element udløser en pop op-menu eller menu:
<button aria-label="Åbn hovedmenu"
aria-udvidet="falsk"
aria-haspopup="sand"
aria-controls="hovedmenu">
☰
</knap>
<ul id="hovedmenu" rolle="menu" skjult>
<li role="menuitem"><a href="#home">Hjem</a></li>
<li role="menuitem"><a href="#about">Om os</a></li>
</ul>
Den første regel i ARIA gælder dog: brug native HTML, når det er muligt. En ægte <knap> element er altid at foretrække frem for et <div role="knap"> , da den allerede indeholder alle nødvendige funktioner.

aria-label vs. alt-tekst
En almindelig misforståelse er at forveksle aria-label med alt-tekst. Begge tjener tilgængelighed, men de har forskellige formål:
Alt-tekst er specifikt til billeder og beskriver det visuelle indhold. Det vises, når billedet ikke kan indlæses og læses højt af skærmlæsere.
aria-label kan derimod anvendes på næsten alle HTML-elementer og giver skærmlæsere ekstra information om funktionen eller betydningen af et element.
<!-- Korrekt: Alt-tekst til billeder -->
<img src="produkt.jpg"
alt="Bærbar computer med åben skærm">
<!-- Korrekt: aria-label for knap uden tekst -->
<button aria-label="Tilføj til kurv">
<svg aria-hidden="sand">...</svg>
</knap>
For billeder følger beregningen af tilgængelige navne et hierarki: aria-labelledby tilsidesættelser aria-label , hvilket igen tilsidesætter alt attribut. Men ved at bruge aria-label="Alternativ tekst" i stedet for en alt attribut anbefales ikke— alt bør altid være førstevalget til grafik.
Når du bruger SVG-ikoner, skal du være særlig opmærksom på:
Dekorative ikoner bør skjules for skærmlæsere med aria-skjult="sand" .
Funktionelle ikoner har brug for en meningsfuld arie-etiket.
Bedste fremgangsmåder for brug af aria-label
Effektiv brug af aria-label følger klare retningslinjer for at sikre både tilgængelighed og vedligeholdelsesvenlig kode. Udviklere bør huske på flere faktorer for at undgå forvirring for brugerne:
Brug aria-label sparsomt: Anvend det kun, når native HTML-elementer eller synlige etiketter ikke er tilstrækkelige. Elementer, der allerede har et beskrivende navn gennem tekstindhold eller attributter, behøver ikke en ekstra aria-label.
Skriv klare og præcise beskrivelser: Arie-mærket skal være selvforklarende og præcist beskrive elementets formål. Undgå tekniske termer eller interne navne, der ikke er meningsfulde for slutbrugerne.
Kombinér med semantisk HTML: ARIA supplerer HTML, men erstatter det ikke. Brug semantiske elementer som f.eks. <knap> , <navigation> , eller <hoved> som fundament og udvide dem med ARIA-attributter, når det er nødvendigt.
<!-- FORKERT: redundant arie-etiket -->
<button aria-label="Log ind">Log ind</button>
<!-- HØJRE: ingen arie-etiket nødvendig -->
<button>Log ind</button>
Overvej fokusstyring: For interaktive widgets er det afgørende at styre fokus korrekt. Pop op-vinduer og dialogbokse skal sætte det første fokus til det første fokuserbare element og returnere fokus til det udløsende element, når de lukkes.
Almindelige fejl i ARIA-mærkning
De hyppigste implementeringsfejl opstår på grund af manglende forståelse af ARIA-hierarkiet og forkert brug:
Modstridende etiketter: Hvis aria-label ikke matcher den synlige tekst, bliver brugere af stemmeinputsoftware forvirrede. For eksempel ser en person "Fornavn" som betegnelse, men skærmlæseren annoncerer "Fornavn". Stemmekommandoer mislykkes derefter.
Overdreven brug af ARIA: Tilføjelse af aria-label til hvert element reducerer tilgængeligheden. Brugere af skærmlæsere bliver overbelastet med overflødig information i stedet for at nå deres mål hurtigere.
Kunne ikke opdatere dynamisk indhold: For JavaScript-drevne elementer skal det sikres, at aria-label-værdier opdateres, når tilstande ændres. Dette er især vigtigt for widgets med dynamiske tilstande.
Unøjagtige etiketter: Etiketter, der ikke længere afspejler elementets aktuelle funktion, skaber falske forventninger og gør navigation vanskeligere.
Tjekliste for udviklere og designere
Tjek nødvendighed: Har elementet virkelig brug for en arie-label, eller er semantisk HTML tilstrækkelig?
Test med skærmlæsere: Brug NVDA (Windows), VoiceOver (Mac) eller andre skærmlæsere til verifikation.
Valider beregningen af det tilgængelige navn: Brug browserudviklerværktøjer til at kontrollere, hvilket navn der rent faktisk beregnes.
Sørg for konsistens: Brug ensartet formulering til lignende elementer på tværs af webstedet.
Dokument ARIA-implementeringer: Forklar i koden hvorfor og hvordan ARIA-attributter bruges.
Overvej alle inputmetoder: Sørg for, at widgets kan betjenes via både tastatur og berøring.
Gennemgangslister og navigation: Brug semantiske HTML-tags til lister og navigationslinks, og tilføj ARIA-attributter, hvor det er nødvendigt.
Konklusion: Sådan bruger du aria-label effektivt
Attributten aria-label er et værdifuldt værktøj til tilgængelige websteder, men den kræver gennemtænkt implementering. Den bygger bro mellem visuelt design og semantisk tilgængelighed, men bør altid ses som et supplement til semantisk HTML, ikke en erstatning.
Effektiviteten af aria-label er mest tydelig i ikonknapper, brugerdefinerede widgets og tilfælde, hvor synlige etiketter ville forstyrre det visuelle layout. Samtidig kræver juridiske krav som BFSG og WCAG 2.1 en systematisk tilgang til ARIA-etiketter.
Nøglen til en vellykket implementering af ARIA er at forstå, at webtilgængelighed er et vigtigt skridt mod digital inklusion for alle mennesker – uanset deres individuelle evner eller begrænsninger.
Ofte stillede spørgsmål
Skal aria-label altid bruges, eller kun når det er nødvendigt?
aria-label bør kun anvendes, når native HTML-elementer eller synlige etiketter ikke er tilstrækkelige. Overforbrug fører til overflødig information og en dårligere brugeroplevelse for skærmlæserbrugere.
Hvordan kan jeg teste om min aria-label virker?
Brug skærmlæsere som NVDA (Windows) eller VoiceOver (Mac/iOS) til realistiske tests. Browserudviklerværktøjer viser de beregnede egenskaber og det faktiske tilgængelige navn i fanen Tilgængelighed.
Hvilke skærmlæsere understøtter aria-label?
Moderne skærmlæsere som NVDA, JAWS, VoiceOver og TalkBack understøtter aria-label i bred forstand. Kompatibiliteten kan dog variere afhængigt af browser og version, så det anbefales at teste på tværs af forskellige opsætninger.
Hvad sker der, hvis et element ikke har en arie-label?
Skærmlæsere bruger det næste tilgængelige navn i hierarkiet for beregning af tilgængelige navne: aria-labelledby, synlig tekst eller titelattributten. Uden nogen etiket overhovedet kan interaktive elementer forblive uforståelige for hjælpeteknologier.
Tilgængelighed starter i koden: Med Eye-Able kan du kontrollere dine websteder og applikationer for korrekte ARIA-mærkninger og andre barrierer – juridisk kompatible og effektive.
Filter
:no_upscale():format(png))
:no_upscale():format(png))