Vanliga tillgänglighetsproblem att undvika

Varför samma tillgänglighetsproblem fortsätter att dyka upp

De flesta tillgänglighetshinder är inte exotiska. År efter år avslöjar automatiserade och manuella granskningar samma korta lista med misstag: saknad alt-text, låg kontrast, omärkta formulärfält, tangentbordsfällor och trasig struktur. De återkommer eftersom de introduceras i tysthet — en utvecklare lanserar en ny komponent, en marknadsförare laddar upp en bild, en designer väljer en varumärkesfärg — och inget i det normala arbetsflödet flaggar problemet. Det visuella resultatet ser bra ut för någon som använder en mus och ett par skarpa ögon, så hindret lanseras.

Den här katalogen går igenom de vanligaste WCAG 2.2-felen vi ser i verkliga granskningar. För vart och ett hittar du varför det är viktigt, vem det påverkar, det relevanta framgångskriteriet och en konkret före/efter-lösning. Tillsammans står dessa problem för den överväldigande majoriteten av de hinder som blockerar användare med funktionsnedsättning — och den överväldigande majoriteten av de juridiska klagomål som lämnas in enligt European Accessibility Act, ADA och Section 508.

En sak måste klargöras innan vi börjar med listan: automatiserade verktyg kan inte hitta alla dessa problem. Oberoende forskning visar konsekvent att även de bästa skannrarna tillförlitligt upptäcker endast 30–40 % av WCAG-problemen. De är utmärkta på att fånga saknade alt-attribut, programmatiska kontrastfel och frånvarande formuläretiketter, men de kan inte bedöma om alt-text är korrekt, om fokusordningen är logisk eller om en anpassad widget faktiskt fungerar med en skärmläsare. Det är därför varje trovärdigt program kombinerar skanning med manuell granskning. Vår programvara för tillgänglighetsskanning hanterar det automatiserbara lagret; manuella granskningar och granskningar utförda av personer med funktionsnedsättning täcker resten.

Ett snabbt sätt att hitta din egen startpunkt innan du läser vidare: visa sidan med bilder avstängda, läs varje ord som ett ostrukturerat stycke och försök slutföra varje uppgift med enbart ett tangentbord. Överallt där upplevelsen kollapsar har du hittat ett hinder.

Möjligt att uppfatta: innehåll människor inte kan se eller läsa

Saknad eller felaktig alt-text för bilder

Vem det påverkar: personer som är blinda eller har nedsatt syn och använder skärmläsare; alla med en långsam anslutning där bilder inte laddas.

WCAG-kriterium: 1.1.1 Icke-textuellt innehåll (nivå A).

Bilder utan ett alt-attribut är osynliga för hjälpmedelsteknik — användaren kanske inte ens vet att bilden finns. Värre än ett saknat attribut är ett felaktigt: filnamn som IMG_4821.jpg, generiska ord som “bild” eller strängar fyllda med sökord vilseleder aktivt lyssnaren.

Regeln är enkel men situationsberoende. Informativa bilder behöver en kortfattad beskrivning av sin betydelse, inte sitt utseende. Dekorativa bilder som inte tillför något bör ha ett tomt alt="" så att skärmläsare hoppar över dem. Funktionella bilder — en ikon som fungerar som en knapp — måste beskriva åtgärden, inte bilden. Komplexa visualiseringar som diagram behöver en kort alt plus en längre textmotsvarighet i närheten.

<!-- 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="">

Automatiserade verktyg upptäcker frånvaron av alt-text omedelbart. De kan inte tala om för dig om texten är korrekt — det kräver en människa som läser sidan i sitt sammanhang.

Otillräcklig färgkontrast

Vem det påverkar: personer med nedsatt syn, färgblindhet eller åldersrelaterad synförlust; alla som använder en skärm i starkt solljus.

WCAG-kriterium: 1.4.3 Kontrast (minimum), nivå AA; samt 1.4.11 Icke-textuell kontrast för UI-komponenter.

WCAG 2.2 kräver ett kontrastförhållande på minst 4.5:1 för normal text och 3:1 för stor text (ungefär 18pt, eller 14pt fet). Gränssnittskomponenter och meningsfull grafik — inputramar, fokusindikatorer, ikoner som förmedlar ett tillstånd — måste uppnå 3:1 mot sin omgivning. Kontrastfel hör till de vanligaste problemen som hittas i varje storskalig granskning, och de introduceras nästan alltid i designstadiet.

/* 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; }

Testa hela paletten, inte bara brödtexten: platshållartext, inaktiverade tillstånd som ändå behöver kunna läsas, felmeddelanden och text lagd över foton är vanliga syndare. Förlita dig aldrig på färg enbart för att förmedla betydelse (1.4.1) — en röd ram på ett ogiltigt fält måste kombineras med text eller en ikon.

Automatiskt spelande media och rörelse

Vem det påverkar: personer med vestibulära störningar, uppmärksamhets- eller kognitiva funktionsnedsättningar, skärmläsaranvändare vars ljudutmatning överröstas, och alla i ett tyst delat utrymme.

WCAG-kriterier: 1.4.2 Ljudkontroll (nivå A), 2.2.2 Pausa, stoppa, dölj (nivå A), 2.3.1 Tre blinkningar (nivå A) och 2.3.3 Animering från interaktioner (nivå AAA).

Ljud eller video som spelas upp automatiskt i mer än tre sekunder måste erbjuda ett tydligt sätt att pausa eller stänga av det. Rörligt, blinkande eller automatiskt uppdaterande innehåll som varar längre än fem sekunder — karuseller, animerade banners, marquees — behöver en tillgänglig pauskontroll. Innehåll som blinkar mer än tre gånger per sekund kan utlösa anfall och måste undvikas helt. Respektera användarens prefers-reduced-motion-inställning för att dämpa icke-väsentlig animering.

/* 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;
  }
}

Hanterbart: saker människor inte kan använda

Tangentbordsotillgänglighet och tangentbordsfällor

Vem det påverkar: personer med motoriska funktionsnedsättningar som inte kan använda en mus, skärmläsaranvändare (som navigerar med tangentbord) och personer som använder kontaktstyrning eller röststyrning.

WCAG-kriterier: 2.1.1 Tangentbord (nivå A) och 2.1.2 Ingen tangentbordsfälla (nivå A).

Varje interaktion — länkar, knappar, formulärfält, menyer, modaler, datumväljare, dra-och-släpp — måste vara fullt hanterbar med enbart tangentbordet. Den mest skadliga varianten är tangentbordsfällan: fokus hamnar i en komponent (ofta en modal eller en inbäddad widget) och kan inte ta sig ut, vilket strandar användaren på sidan. Specialbyggda widgetar är den vanliga boven eftersom inbyggda element som <button> och <a> är tangentbordshanterbara som standard, medan <div>-baserade imitationer inte är det.

<!-- 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>

Gå igenom dina viktigaste flöden med enbart Tab, Shift+Tab, piltangenter, Enter, blanksteg och Escape. Bekräfta att fokus alltid kan röra sig framåt och ut ur varje komponent, att Escape stänger överlägg och att inget kräver en pekare. Vår tjänst för skärmläsarutvärdering testar exakt dessa flöden så som verkliga användare av hjälpmedelsteknik upplever dem.

Saknade eller osynliga fokusindikatorer och ologisk fokusordning

Vem det påverkar: seende tangentbordsanvändare, användare med nedsatt syn och alla som har tappat bort var de befinner sig på sidan.

WCAG-kriterier: 2.4.7 Fokus synligt (nivå A) och 2.4.3 Fokusordning (nivå A); 2.4.11 Fokus inte dolt (nivå AA) i WCAG 2.2.

Ett vanligt “snyggt” misstag är att ta bort webbläsarens standardfokusring med outline: none och aldrig ersätta den. Tangentbordsanvändare lämnas utan en aning om vilket element som är aktivt. Lika skadligt är en fokusordning som inte följer den visuella och logiska läsordningen — vanligtvis orsakad av positiva tabindex-värden eller av en DOM-ordning som avviker från den renderade layouten.

/* 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 lägger till 2.4.11: när ett element får fokus får det inte vara helt dolt bakom fasta sidhuvuden, cookie-banners eller chattwidgetar. Öppna en modal, tabba igenom den och bekräfta att det fokuserade elementet aldrig är begravt.

Icke-beskrivande länkar och knappar

Vem det påverkar: skärmläsaranvändare som tar fram en lista över alla länkar för att skanna en sida, och personer med kognitiva funktionsnedsättningar.

WCAG-kriterier: 2.4.4 Länksyfte (i sammanhang), nivå A; 2.5.3 Etikett i namn, nivå A.

Skärmläsaranvändare navigerar ofta genom att hoppa mellan länkar utanför sammanhanget. En sida full av länkar som “klicka här”, “läs mer” och “lär dig mer” blir meningslös när den läses upp som en lista. Länktexten bör beskriva sin destination på egen hand. Detsamma gäller knappar med enbart ikon, som behöver ett tillgängligt namn.

<!-- 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>

Överbelastad navigering och inget sätt att hoppa över den

Vem det påverkar: skärmläsaranvändare, tangentbordsanvändare och personer med kognitiva funktionsnedsättningar.

WCAG-kriterium: 2.4.1 Hoppa över block (nivå A).

En megameny med dussintals länkar tvingar skärmläsar- och tangentbordsanvändare att vada genom hela listan på varje sida innan de når innehållet. En “Hoppa till huvudinnehåll”-länk som det första fokuserbara elementet låter dem hoppa direkt förbi upprepade block. Gruppera relaterade objekt, håll menyerna slimmade och se till att hopplänken blir synlig vid fokus.

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

Begripligt: innehåll som förvirrar

Omärkta eller felaktigt kopplade formulärfält

Vem det påverkar: skärmläsaranvändare, personer med kognitiva funktionsnedsättningar och röststyrningsanvändare som adresserar fält med namn.

WCAG-kriterier: 1.3.1 Information och relationer, 3.3.2 Etiketter eller instruktioner och 4.1.2 Namn, roll, värde (alla nivå A).

Inmatningsfält utan en programmatiskt kopplad <label> annonseras som “redigera text, tom” — användaren har ingen aning om vad som ska skrivas. Platshållartext är inget substitut: den försvinner vid inmatning och uppfyller vanligtvis inte kontrast. Obligatoriska fält, formateringsregler och valideringsfel måste också förmedlas i text, inte enbart genom färg eller position.

<!-- 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 felmeddelanden till sitt fält med aria-describedby, markera ogiltiga fält med aria-invalid och se till att inlämning av ett ofullständigt formulär flyttar fokus till det första felet.

Saknat sidspråk

Vem det påverkar: skärmläsaranvändare — fel språk får syntetiseraren att uttala allt fel.

WCAG-kriterier: 3.1.1 Sidans språk (nivå A) och 3.1.2 Språk för delar (nivå AA).

Ett enda saknat attribut förstör uttalet för en hel sida. Deklarera det primära språket på rotelementet och markera inline-passager på ett annat språk med sitt eget lang.

<!-- Before -->
<html>

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

Felaktig rubrikhierarki och saknade landmärken

Vem det påverkar: skärmläsaranvändare som navigerar efter rubriker och regioner, och alla som förlitar sig på dokumentstruktur.

WCAG-kriterium: 1.3.1 Information och relationer (nivå A).

Rubriker utgör sidans disposition. Skärmläsaranvändare hoppar från rubrik till rubrik för att snabbt hitta innehåll; när nivåer hoppas över, används enbart för teckenstorlek eller saknas, kollapsar den navigeringen. Varje sida bör ha en <h1> och en logisk, obruten sekvens av <h2>, <h3> och så vidare. Lika viktiga är landmärkesregioner — <header>, <nav>, <main>, <footer> — som låter användare hoppa mellan de viktigaste områdena. En sida som helt är byggd av <div>-element erbjuder ingen sådan karta.

<!-- 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: kod som hjälpmedelsteknik inte kan tolka

Otillgängliga anpassade widgetar och felanvänd ARIA

Vem det påverkar: skärmläsaranvändare framför allt, och all hjälpmedelsteknik som förlitar sig på ett korrekt tillgänglighetsträd.

WCAG-kriterium: 4.1.2 Namn, roll, värde (nivå A).

Anpassade rullgardinsmenyer, flikar, dragspel, kombinationsrutor, modaler och verktygstips byggda av <div> och <span> har ingen inneboende roll, tillstånd eller tangentbordsbeteende. Utvecklare tar till ARIA för att lappa detta, men ARIA beskriver bara — det tillför inget beteende, och felaktig ARIA är värre än ingen. Den första regeln för ARIA är att föredra ett inbyggt HTML-element när ett sådant finns. När du måste bygga en anpassad widget, implementera den fullständiga tangentbordsinteraktion som ARIA-författarmönstren föreskriver och håll aria-expanded, aria-selected och liknande tillstånd i linje med verkligheten.

<!-- 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>

Det här är precis de problem som automatiserade skannrar oftast missar. En skanner ser ett aria-expanded-attribut och godkänner det; bara en människa (eller en testare som använder en skärmläsare) kan bekräfta att värdet faktiskt växlar när menyn öppnas. Se vår guide för skärmläsartestning för hur du verifierar widget-beteende från början till slut.

En anmärkning om overlay-widgetar

Det är frestande att installera en “tillgänglighetswidget” eller overlay på en rad som lovar omedelbar efterlevnad. Dessa verktyg åtgärdar inte problemen ovan — alt-texten saknas fortfarande i källan, kontrasten misslyckas fortfarande, den anpassade widgeten fungerar fortfarande inte. Overlays kan inte åtgärda koden som orsakar hinder, de stör ofta användarnas egen hjälpmedelsteknik, och de har förekommit i ett växande antal tillgänglighetsrättegångar. Äkta digital tillgänglighet kommer från att åtgärda den underliggande HTML, CSS och beteendet, inte från att maskera det.

Stoppa dessa problem från att komma tillbaka

Att åtgärda en lista med buggar en gång är nödvändigt men inte tillräckligt; samma problem dyker upp igen vid nästa release om du inte ändrar hur saker lanseras. Den hållbara lösningen är att bygga in tillgänglighet i arbetsflödet:

Fånga de automatiserbara 30–40 % tidigt genom att koppla in skanningar i din pipeline. CI/CD-integration för tillgänglighet låter bygget misslyckas när en regression introduceras, innan den når produktion.
Täck resten med människor. Schemalägg manuella tillgänglighetsgranskningar och granskningar av personer med funktionsnedsättning, som avslöjar hinder som inget verktyg kan upptäcka.
Ge teamen rätt instrument. QualiBooth-tillgänglighetsverktygslådan och Agora hjälper designers och utvecklare att testa medan de arbetar.
Gör det till en process, inte ett projekt. Löpande tillgänglighetskonsultation och förbättring av tillgänglighetsprocessen förankrar vanorna så att kvaliteten håller över tid.

För en steg-för-steg-färdplan för åtgärder kan du börja med vår guide om hur du gör din webbplats WCAG-kompatibel.

Var du kan börja idag

Med över 1,3 miljarder människor världen över som lever med någon form av funktionsnedsättning är det affärsmässiga argumentet för tillgänglighet tydligt — och sedan juni 2025 gäller det även det juridiska argumentet enligt European Accessibility Act. Problemen i den här katalogen är de som granskas först i varje klagomål eller granskning.

Det snabbaste sättet att se var du står är att köra en gratis URL-skanning — ingen installation, ingen förpliktelse. När du är redo att gå bortom vad automatisering kan nå, begär en demo så visar vi dig hur ett kombinerat automatiserat-plus-manuellt program täpper till det återstående gapet.