Almindelige tilgængelighedsproblemer

Hvorfor de samme tilgængelighedsproblemer bliver ved med at dukke op

De fleste tilgængelighedsbarrierer er ikke eksotiske. År efter år afdækker automatiserede og manuelle audits den samme korte liste over fejl: manglende alt-tekst, lav kontrast, formularfelter uden labels, tastaturfælder og ødelagt struktur. De gentager sig, fordi de introduceres lydløst — en udvikler lancerer en ny komponent, en marketingmedarbejder uploader et billede, en designer vælger en brandfarve — og intet i det normale workflow markerer problemet. Det visuelle resultat ser fint ud for nogen, der bruger en mus og et par skarpe øjne, så barrieren bliver lanceret.

Dette katalog gennemgår de hyppigste WCAG 2.2-fejl, vi ser i rigtige audits. For hver enkelt finder du, hvorfor den har betydning, hvem den påvirker, det relevante succeskriterium og en konkret før/efter-løsning. Tilsammen udgør disse problemer det overvældende flertal af de barrierer, der blokerer brugere med handicap — og det overvældende flertal af de juridiske klager, der indgives under European Accessibility Act, ADA og Section 508.

Én ting skal slås fast, før vi går i gang med listen: automatiserede værktøjer kan ikke finde alle disse problemer. Uafhængig forskning viser konsekvent, at selv de bedste scannere pålideligt kun opdager 30-40 % af WCAG-problemerne. De er fremragende til at fange manglende alt-attributter, programmatiske kontrastfejl og fraværende formular-labels, men de kan ikke vurdere, om alt-tekst er nøjagtig, om fokusrækkefølgen er logisk, eller om en brugerdefineret widget faktisk virker med en skærmlæser. Derfor kombinerer ethvert troværdigt program scanning med manuel gennemgang. Vores software til tilgængelighedsscanning håndterer det automatiserbare lag; manuelle audits og audits udført af personer med handicap dækker resten.

En hurtig måde at finde dit eget udgangspunkt, før du læser videre: se siden med billeder deaktiveret, læs hvert ord som ét ustruktureret afsnit, og prøv at gennemføre hver opgave udelukkende med et tastatur. Overalt hvor oplevelsen bryder sammen, har du fundet en barriere.

Opfatteligt: indhold, folk ikke kan se eller læse

Manglende eller unøjagtig alt-tekst til billeder

Hvem det påvirker: personer, der er blinde eller svagtseende og bruger skærmlæsere; alle på en langsom forbindelse, hvor billeder ikke indlæses.

WCAG-kriterium: 1.1.1 Ikke-tekstuelt indhold (niveau A).

Billeder uden et alt-attribut er usynlige for hjælpeteknologi — brugeren ved måske ikke engang, at billedet findes. Værre end et manglende attribut er et unøjagtigt et: filnavne som IMG_4821.jpg, generiske ord som “billede” eller strenge fyldt med søgeord vildleder aktivt lytteren.

Reglen er enkel, men situationsbestemt. Informative billeder har brug for en kortfattet beskrivelse af deres betydning, ikke deres udseende. Dekorative billeder, der ikke tilføjer noget, bør have en tom alt="", så skærmlæsere springer dem over. Funktionelle billeder — et ikon, der fungerer som en knap — skal beskrive handlingen, ikke billedet. Komplekse visuals som diagrammer har brug for en kort alt plus en længere tekstækvivalent i nærheden.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Automatiserede værktøjer fanger fraværet af alt-tekst med det samme. De kan ikke fortælle dig, om teksten er korrekt — det kræver et menneske, der læser siden i kontekst.

Utilstrækkelig farvekontrast

Hvem det påvirker: personer med svagt syn, farveblindhed eller aldersbetinget synstab; alle, der bruger en skærm i skarpt sollys.

WCAG-kriterium: 1.4.3 Kontrast (minimum), niveau AA; samt 1.4.11 Ikke-tekstuel kontrast for UI-komponenter.

WCAG 2.2 kræver et kontrastforhold på mindst 4.5:1 for normal tekst og 3:1 for stor tekst (cirka 18pt eller 14pt fed). Interfacekomponenter og meningsfulde grafikker — inputkanter, fokusindikatorer, ikoner, der formidler en tilstand — skal opfylde 3:1 i forhold til deres omgivelser. Kontrastfejl er blandt de mest almindelige problemer, der findes i enhver storstilet audit, og de introduceres næsten altid i designfasen.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Test hele paletten, ikke kun brødteksten: pladsholdertekst, deaktiverede tilstande, der stadig skal kunne læses, fejlmeddelelser og tekst lagt over fotos er hyppige syndere. Stol aldrig på farve alene til at formidle betydning (1.4.1) — en rød kant på et ugyldigt felt skal kombineres med tekst eller et ikon.

Automatisk afspillende medier og bevægelse

Hvem det påvirker: personer med vestibulære lidelser, opmærksomheds- eller kognitive handicap, skærmlæserbrugere, hvis lydoutput overdøves, og alle i et stille fælles rum.

WCAG-kriterier: 1.4.2 Lydkontrol (niveau A), 2.2.2 Pause, stop, skjul (niveau A), 2.3.1 Tre blink (niveau A) og 2.3.3 Animation fra interaktioner (niveau AAA).

Lyd eller video, der afspilles automatisk i mere end tre sekunder, skal tilbyde en tydelig måde at sætte den på pause eller slå den fra. Bevægende, blinkende eller automatisk opdaterende indhold, der varer længere end fem sekunder — karruseller, animerede bannere, marquees — har brug for en tilgængelig pausefunktion. Indhold, der blinker mere end tre gange i sekundet, kan udløse anfald og skal undgås helt. Respektér brugerens prefers-reduced-motion-indstilling for at dæmpe ikke-essentiel animation.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Anvendeligt: ting, folk ikke kan bruge

Tastatutilgængelighed og tastaturfælder

Hvem det påvirker: personer med motoriske handicap, der ikke kan bruge en mus, skærmlæserbrugere (der navigerer med tastatur) og personer, der bruger kontaktbetjening eller stemmestyring.

WCAG-kriterier: 2.1.1 Tastatur (niveau A) og 2.1.2 Ingen tastaturfælde (niveau A).

Hver interaktion — links, knapper, formularfelter, menuer, modaler, datovælgere, træk-og-slip — skal være fuldt anvendelig med tastaturet alene. Den mest skadelige variant er tastaturfælden: fokus kommer ind i en komponent (ofte en modal eller en indlejret widget) og kan ikke komme ud igen, så brugeren bliver strandet på siden. Brugerdefinerede widgets er som regel synderen, fordi native elementer som <button> og <a> er tastaturanvendelige som standard, mens <div>-baserede efterligninger ikke er.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Gennemgå dine vigtigste forløb udelukkende med Tab, Shift+Tab, piletaster, Enter, mellemrum og Escape. Bekræft, at fokus altid kan bevæge sig fremad og ud af hver komponent igen, at Escape lukker overlays, og at intet kræver en peger. Vores tjeneste til skærmlæserevaluering tester præcis disse forløb, som rigtige brugere af hjælpeteknologi oplever dem.

Manglende eller usynlige fokusindikatorer og ulogisk fokusrækkefølge

Hvem det påvirker: seende tastaturbrugere, svagtseende brugere og alle, der har mistet overblikket over, hvor de er på siden.

WCAG-kriterier: 2.4.7 Fokus synlig (niveau A) og 2.4.3 Fokusrækkefølge (niveau A); 2.4.11 Fokus ikke tildækket (niveau AA) i WCAG 2.2.

En almindelig “pæn” fejl er at fjerne browserens standardfokusring med outline: none og aldrig erstatte den. Tastaturbrugere efterlades uden anelse om, hvilket element der er aktivt. Lige så skadelig er en fokusrækkefølge, der ikke følger den visuelle og logiske læserækkefølge — typisk forårsaget af positive tabindex-værdier eller af en DOM-rækkefølge, der afviger fra det viste layout.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 tilføjer 2.4.11: når et element får fokus, må det ikke være helt skjult bag faste headere, cookiebannere eller chatwidgets. Åbn en modal, tab igennem den, og bekræft, at det fokuserede element aldrig er begravet.

Ikke-beskrivende links og knapper

Hvem det påvirker: skærmlæserbrugere, der henter en liste over alle links for at scanne en side, og personer med kognitive handicap.

WCAG-kriterier: 2.4.4 Linkformål (i kontekst), niveau A; 2.5.3 Label i navn, niveau A.

Skærmlæserbrugere navigerer ofte ved at springe mellem links uden for kontekst. En side fuld af “klik her”-, “læs mere”- og “lær mere”-links bliver meningsløs, når den læses op som en liste. Linkteksten bør i sig selv beskrive sin destination. Det samme gælder knapper med kun et ikon, som har brug for et tilgængeligt navn.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Hvem det påvirker: skærmlæserbrugere, tastaturbrugere og personer med kognitive handicap.

WCAG-kriterium: 2.4.1 Spring blokke over (niveau A).

En megamenu med snesevis af links tvinger skærmlæser- og tastaturbrugere til at vade gennem hele listen på hver side, før de når indholdet. Et “Spring til hovedindhold”-link som det første fokuserbare element lader dem springe direkte forbi gentagne blokke. Gruppér relaterede elementer, hold menuerne slanke, og sørg for, at spring-linket bliver synligt ved fokus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Forståeligt: indhold, der forvirrer

Formularfelter uden labels eller med forkert tilknytning

Hvem det påvirker: skærmlæserbrugere, personer med kognitive handicap og stemmestyringsbrugere, der tiltaler felter ved navn.

WCAG-kriterier: 1.3.1 Information og relationer, 3.3.2 Labels eller instruktioner og 4.1.2 Navn, rolle, værdi (alle niveau A).

Inputfelter uden en programmatisk tilknyttet <label> annonceres som “rediger tekst, tom” — brugeren har ingen anelse om, hvad der skal skrives. Pladsholdertekst er ikke en erstatning: den forsvinder ved indtastning og opfylder som regel ikke kontrast. Obligatoriske felter, formateringsregler og valideringsfejl skal også formidles i tekst, ikke kun ved farve eller placering.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Knyt fejlmeddelelser til deres felt med aria-describedby, markér ugyldige felter med aria-invalid, og sørg for, at indsendelse af en ufuldstændig formular flytter fokus til den første fejl.

Manglende sidesprog

Hvem det påvirker: skærmlæserbrugere — det forkerte sprog får synthesizeren til at udtale alt forkert.

WCAG-kriterier: 3.1.1 Sidens sprog (niveau A) og 3.1.2 Sprog for dele (niveau AA).

Et enkelt manglende attribut ødelægger udtalen for en hel side. Deklarér det primære sprog på rodelementet, og markér inline-passager på et andet sprog med deres eget lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Forkert overskriftshierarki og manglende landmarks

Hvem det påvirker: skærmlæserbrugere, der navigerer efter overskrifter og regioner, og alle, der er afhængige af dokumentstruktur.

WCAG-kriterium: 1.3.1 Information og relationer (niveau A).

Overskrifter udgør sidens disposition. Skærmlæserbrugere springer fra overskrift til overskrift for hurtigt at finde indhold; når niveauer springes over, kun bruges til skriftstørrelse eller mangler, bryder den navigation sammen. Hver side bør have én <h1> og en logisk, ubrudt rækkefølge af <h2>, <h3> og så videre. Lige så vigtige er landmark-regioner — <header>, <nav>, <main>, <footer> — som lader brugere springe mellem de vigtigste områder. En side bygget udelukkende af <div>-elementer tilbyder ikke noget sådant kort.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robust: kode, hjælpeteknologi ikke kan fortolke

Utilgængelige brugerdefinerede widgets og misbrugt ARIA

Hvem det påvirker: skærmlæserbrugere frem for alt og enhver hjælpeteknologi, der er afhængig af et korrekt tilgængelighedstræ.

WCAG-kriterium: 4.1.2 Navn, rolle, værdi (niveau A).

Brugerdefinerede dropdowns, faner, harmonikaer, comboboxe, modaler og tooltips bygget af <div> og <span> har ingen iboende rolle, tilstand eller tastaturadfærd. Udviklere griber til ARIA for at lappe dette, men ARIA beskriver kun — det tilføjer ingen adfærd, og forkert ARIA er værre end ingen. Den første regel for ARIA er at foretrække et native HTML-element, når et sådant findes. Når du er nødt til at bygge en brugerdefineret widget, så implementér den fulde tastaturinteraktion, som ARIA-authoring-mønstrene foreskriver, og hold aria-expanded, aria-selected og lignende tilstande i overensstemmelse med virkeligheden.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Dette er præcis de problemer, som automatiserede scannere oftest overser. En scanner ser et aria-expanded-attribut og godkender det; kun et menneske (eller en tester, der bruger en skærmlæser) kan bekræfte, at værdien faktisk skifter, når menuen åbnes. Se vores guide til skærmlæsertest for, hvordan du verificerer widget-adfærd fra ende til anden.

En bemærkning om overlay-widgets

Det er fristende at installere en “tilgængelighedswidget” eller overlay på én linje, der lover øjeblikkelig compliance. Disse værktøjer retter ikke ovenstående problemer — alt-teksten mangler stadig i kilden, kontrasten fejler stadig, den brugerdefinerede widget virker stadig ikke. Overlays kan ikke udbedre den kode, der forårsager barrierer, de forstyrrer ofte brugernes egen hjælpeteknologi, og de har optrådt i et voksende antal tilgængelighedsretssager. Ægte digital tilgængelighed kommer fra at rette den underliggende HTML, CSS og adfærd, ikke fra at maskere den.

Stop disse problemer i at vende tilbage

At rette en liste over fejl én gang er nødvendigt, men ikke tilstrækkeligt; de samme problemer dukker op igen ved næste release, medmindre du ændrer, hvordan tingene lanceres. Den holdbare løsning er at indbygge tilgængelighed i workflowet:

Fang de automatiserbare 30-40 % tidligt ved at indbygge scanninger i din pipeline. CI/CD-integration af tilgængelighed lader builden fejle, når en regression introduceres, før den når produktion.
Dæk resten med mennesker. Planlæg manuelle tilgængelighedsaudits og audits udført af personer med handicap, som afdækker barrierer, intet værktøj kan opdage.
Giv teamene de rette instrumenter. QualiBooth-tilgængelighedsværktøjssættet og Agora hjælper designere og udviklere med at teste, mens de arbejder.
Gør det til en proces, ikke et projekt. Løbende tilgængelighedsrådgivning og forbedring af tilgængelighedsprocessen forankrer vanerne, så kvaliteten holder over tid.

For en trin-for-trin-køreplan til udbedring kan du starte med vores guide om hvordan du gør dit website WCAG-kompatibelt.

Hvor du kan begynde i dag

Med over 1,3 milliarder mennesker verden over, der lever med en form for handicap, er den forretningsmæssige begrundelse for tilgængelighed klar — og siden juni 2025 gælder det også den juridiske begrundelse under European Accessibility Act. Problemerne i dette katalog er dem, der undersøges først i enhver klage eller audit.

Den hurtigste måde at se, hvor du står, er at køre en gratis URL-scanning — ingen opsætning, ingen forpligtelse. Når du er klar til at gå ud over, hvad automatisering kan nå, så anmod om en demo, og vi viser dig, hvordan et kombineret automatiseret-plus-manuelt program lukker det resterende gab.