Hur du åtgärdar de 6 vanligaste WCAG-felen på vilken webbplats som helst

Öppna vilken som helst av de en miljon största webbplatserna just nu och det är 96 av 100 chans att du hittar ett WCAG-brott som en automatiserad skanner kan upptäcka på några sekunder. På en miljon startsidor upptäcktes 56 114 377 distinkta tillgänglighetsfel — i genomsnitt 56,1 fel per sida. Det som gör detta särskilt anmärkningsvärt är att 96% av alla upptäckta fel faller inom bara sex kategorier, och dessa sex vanligaste feltyper har varit desamma de senaste sju åren. Det betyder att om man åtgärdar ett fåtal väl förstådda problem skulle det dramatiskt förbättra tillgängligheten på hela webben — och det börjar med din webbplats.

Varför samma sex fel fortsätter att dyka upp

Du kanske undrar hur, i en era med sofistikerade utvecklingsverktyg och växande juridisk granskning, samma fel kan bestå i stor skala år efter år. Svaret är systemiskt. Denna fel­täthet speglar hur djupt otillgänglighet har byggts in i webbutvecklingspraxis. Mallproblem multipliceras över varje sida. Komponentfel upprepas genom hela sajter. Utan medveten uppmärksamhet på tillgänglighet producerar standardiserade utvecklingsflöden systematiskt otillgängliga resultat.

Det finns också en falsk känsla av framsteg som drivs av automatisering. Automatiserad testning fångar bara 30–40% av potentiella WCAG-fel. Webbplatser som klarar automatiska tester kan fortfarande ha betydande problem med tangentbordsnavigering, skärmläsare eller kognitiv tillgänglighet. Det innebär att även den lilla andel webbplatser som verkar följa reglerna på papper sannolikt brister i praktiken.

De juridiska riskerna är verkliga och växande. Enligt Seyfarth Shaw lämnades 8 800 federala stämningar enligt ADA Title III in 2024, varav cirka 2 452 specifikt riktade in sig på webbtillgänglighet. E-handelswebbplatser löper oproportionerligt stor risk — 77% av stämningarna om webbtillgänglighet riktas mot onlinehandel. Efterlevnad är inte längre något trevligt att ha. Det är en fråga om affärskontinuitet.

Den uppmuntrande baksidan? Denna koncentration har praktiska konsekvenser. Organisationer kan åtgärda majoriteten av sina tillgänglighetsproblem genom att fokusera på ett fåtal problemtyper. Fullständig WCAG-efterlevnad kräver uppmärksamhet på alla 78 kriterier, men de mest effektfulla förbättringarna kommer från att fixa dessa vanliga fel. Så låt oss gå igenom vart och ett, med praktiska lösningar du kan implementera idag.

Fel #1 — Text med låg kontrast (WCAG 1.4.3)

Text med låg kontrast — text som inte har tillräcklig färgskillnad mot sin bakgrund — förekommer på 83,6% av de studerade startsidorna. Detta är det vanligaste WCAG-felet och påverkar mer än fyra av fem webbplatser. WCAG 1.4.3 (Minimikontrast) är brutalt rakt på sak: normal text måste uppnå en kontrastkvot på minst 4,5:1 mot sin bakgrund, och stor text (18pt eller 14pt fet) måste nå minst 3:1.

Kontrastfel beror ofta på designbeslut som prioriterar estetik framför läsbarhet. Ljusgrå text på vit bakgrund ser sofistikerad ut för designers med perfekt syn. För användare med nedsatt syn, äldre användare eller någon som läser på en skärm med bländning är den oläslig. Sekundära etiketter, formulär­platshållare, sidfotstext och inaktiverade knapp­tillstånd är de vanligaste bovarna — de stylas för att se subtila ut och blir i stället osynliga för en betydande del av din publik.

Lösningen är nästan alltid en CSS-justering. Kör dina färgpar genom ett kontrastverktyg som WebAIMs kontrastverktyg eller webbläsarens DevTools-panel för tillgänglighet, och justera sedan förgrunds- eller bakgrundsvärdet tills det godkänns. Här är ett vanligt mönster som underkänns och hur man korrigerar det:

/* Underkänns — kvot ungefär 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Godkänns — kvot ungefär 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

För platshållartext, kom ihåg att WCAG behandlar den som riktig text — inte en dekorativ hint — så den måste också uppfylla gränsen 4,5:1. Undvik att enbart förlita dig på platshållartext för att förmedla instruktioner; kombinera den med ett synligt <label>-element oavsett. Om du använder bilder av text kan du inte fixa kontrast med CSS — du måste återskapa dessa bilder, vilket är ännu en anledning att föredra levande HTML-text framför text inbakad i grafik.

Fel #2 — Saknad alternativtext för bilder (WCAG 1.1.1)

Bilder utan alternativtext förekommer på 58,2% av startsidorna. När bilder saknar alt-text möter skärmläsaranvändare antingen tystnad eller meningslösa filnamn där meningsfullt innehåll borde finnas. Detta problem är inte nytt. Alt-text har varit ett grundläggande tillgänglighetskrav sedan WCAG 1.0 år 1999. Tjugofem år senare misslyckas de flesta webbplatser fortfarande med att implementera det konsekvent.

Anledningen till att det består är ett arbetsflödesgap, inte ett kunskapsgap. Denna felfrekvens pekar på systematiska brister i innehållsarbetsflöden. Skribenter och redaktörer vet ofta inte att alt-text behövs. Innehållshanteringssystem uppmanar inte alltid till det. Kvalitetssäkring upptäcker inte avsaknaden. Lösningen har därför två lager: ett tekniskt och ett processrelaterat.

På den tekniska sidan behöver varje meningsfull bild ett alt-attribut som förmedlar samma information som bilden förmedlar. Dekorativa bilder — rent visuella utsmyckningar som inte tillför någon information — ska få ett tomt alt="" så att skärmläsare hoppar över dem helt. Att få denna distinktion rätt är minst lika viktigt som att lägga till attributet överhuvudtaget. En stor andel bilder har saknad eller felaktig alt-text. Vissa meningsfulla bilder saknar beskrivningar helt, medan dekorativa bilder ofta behandlas som meningsfullt innehåll. Båda problemen bryter mot WCAG-efterlevnad för uppfattningsbart innehåll.

<!-- Meningsfull bild: beskriv vad den förmedlar -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- Dekorativ bild: tom alt, ingen roll behövs -->
<img src='wave-divider.svg' alt='' />

<!-- Länkad bild: beskriv destinationen, inte bilden -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

På processidan, uppdatera dina CMS-mallar så att alt-fältet blir obligatoriskt för innehållsbilder, och utbilda alla som laddar upp material. Automatiserade verktyg som Accsible kan upptäcka bilder med saknad eller tom alt-text på hela webbplatsen och ge ditt team en reviderbar lista att arbeta igenom systematiskt.

Fel #3 — Saknade etiketter för formulärfält (WCAG 1.3.1, 3.3.2)

48,6% av webbplatserna har saknade etiketter för formulärfält. Detta fel är särskilt skadligt eftersom formulär är där användare faktiskt gör saker — registrerar sig, checkar ut, tar kontakt, skickar supportförfrågningar. Många formulär saknar tillgängliga etiketter, förlitar sig enbart på platshållare, exponerar inte instruktioner och felmeddelanden eller stöder inte tangentbordsanvändning. Eftersom formulär är avgörande för de flesta digitala upplevelser skapar dessa fel allvarliga användbarhetsbarriärer.

Det vanligaste misstaget är att använda platshållartext som ersättning för ett <label>. Platshållare försvinner när användaren börjar skriva, vilket lämnar alla med nedsatt korttidsminne — eller helt enkelt någon som blir distraherad mitt i formuläret — utan aning om vad fältet är till för. Skärmläsare varierar i hur de hanterar platshållare, och inget av tillvägagångssätten är lika tillförlitligt som en korrekt etikettkoppling.

Det korrekta mönstret är att använda ett <label>-element kopplat till sitt fält via matchande for- och id-attribut. Om en synlig etikett inte är möjlig av designskäl, använd aria-label eller aria-labelledby — men ta inte till ARIA när du bara skulle kunna använda ett <label>.

<!-- Korrekt: explicit koppling mellan etikett och fält -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Fel: enbart platshållare -->
<input type='email' placeholder='Email address' />

<!-- Godtagbart när etiketten måste vara visuellt dold -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

Felmeddelanden måste också vara programmatiskt kopplade. När ett formulär valideras och hittar ett fel ska meddelandet kopplas till fältet med aria-describedby, och fokus bör helst flyttas till det första ogiltiga fältet. Valideringsfel i formulär ska vara effektiva, intuitiva och tillgängliga — felet måste identifieras tydligt, snabb åtkomst till det problematiska elementet tillhandahållas, och användaren måste enkelt kunna rätta felet och skicka in formuläret igen.

Fel #4 — Tomma länkar och knappar (WCAG 2.4.4, 4.1.2)

44,6% av webbplatserna har tomma hyperlänkar. Tomma knappar hittades på nästan 30% av sidorna, och denna siffra ökade från föregående år. Det betyder att blinda eller synsvaga användare inte kommer att förstå syftet med knappar som skicka, återställ, filtrera eller sök. Tillsammans utgör tomma länkar och knappar en av de mest frustrerande upplevelserna för skärmläsaranvändare — att stöta på interaktiva element utan namn är som att trycka på ett dörrhandtag utan etikett och utan att ha en aning om vart det leder.

Tomma länkar uppstår oftast när en ikon eller bild är det enda barnet till en <a>-tagg och ingen textalternativ tillhandahålls. Tomma knappar uppstår när ikon­endast-knappar — hamburgermenyer, stäng-ikoner, knappar för delning i sociala medier — saknar något tillgängligt namn. Båda är enkla att åtgärda.

<!-- Tom länk — underkänns -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Fixad med aria-label -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Tom knapp — underkänns -->
<button><svg>...</svg></button>

<!-- Fixad med visuellt dold text -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

Observera aria-hidden='true' på SVG:n i varje fixat exempel. När du tillhandahåller ett textalternativ via aria-label eller visuellt dold text vill du dölja SVG:n från tillgänglighetsträdet — annars kan skärmläsare läsa upp både etiketten och SVG:ns egen titel eller beskrivning, vilket skapar en förvirrande dubbeluppläsning. Tvetydig länktext — fraser som "click here", "read more" eller "learn more" — är ett relaterat fel. Andra hyperlänksproblem som tvetydig länktext hittades på nästan 14% av startsidorna, en ökning från föregående år. Hyperlänkar med korrekt text är viktiga så att användare vet vart en länk kommer att ta dem. Varje länks tillgängliga namn ska vara begripligt ur sitt sammanhang eftersom skärmläsaranvändare ofta navigerar genom att ta fram en lista över alla länkar på en sida.

Fel #5 — Saknat dokumentspråk (WCAG 3.1.1)

Detta kan verka litet jämfört med kontrast eller alt-text, men ungefär 16% av sidorna saknar angivet dokumentspråk — och effekten på skärmläsaranvändare är omedelbar och skakande. Om en skärmläsaranvändare har det specifika språkpaketet installerat kommer innehållet att läsas upp korrekt. Annars kommer det att låta som en dålig accent och kanske inte vara begripligt.

Lösningen är ett enda HTML-attribut — bokstavligen en rad kod — och det finns ingen ursäkt för att missa det. Lägg till attributet lang i ditt <html>-element med lämplig BCP 47-språkkod. Om delar av din sida är på ett annat språk än sidan som helhet, lägg till ett lang-attribut på just dessa element också.

<!-- Saknas: inget lang-attribut -->
<html>

<!-- Korrekt: engelsk sida -->
<html lang='en'>

<!-- Korrekt: fransk sida -->
<html lang='fr'>

<!-- Språkbyte inline på en sida -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

Om du använder ett CMS eller en statisk sajtgenerator bör lang-attributet sättas i din basmall. Kontrollera din mall en gång, fixa den en gång, och varje sida på din webbplats är omedelbart korrigerad. Detta är kanske den åtgärd på hela listan som ger högst avkastning i förhållande till insats — en enda malländring eliminerar problemet på hela din domän.

Fel #6 — Otillgänglig tangentbordsnavigering och fokus­hantering (WCAG 2.1.1, 2.4.7)

Tangentbordstillgänglighet är där gapet mellan automatiserad testning och verklig användbarhet är som störst. Automatiska verktyg kan upptäcka vissa tangentbordsfel — som interaktiva element byggda av icke-semantiska taggar — men de kan inte simulera tabb-ordning, fokusfällor eller upplevelsen av att navigera i en rullgardinsmeny enbart med piltangenter. Webbplatser tar ofta bort standardfokusindikatorer utan att tillhandahålla alternativ, vilket gör tangentbordsnavigering nästan omöjlig. Detta påverkar inte bara användare med motoriska funktionsnedsättningar utan även alla som föredrar tangentbordsnavigering, avancerade användare och personer som använder switch-enheter.

De vanligaste tangentbordsfelen är: anpassade interaktiva komponenter byggda av <div>- eller <span>-taggar som aldrig får fokus; CSS-regler som tar bort webbläsarens standardfokusring med outline: none eller outline: 0 utan att ersätta den med något lika synligt; modala dialoger som inte fångar fokus (så att tangentbordsanvändare kan tabba bakom överlägget); och karuseller eller dragspel som inte kan användas utan mus.

<!-- Tangentbordsotillgänglig anpassad knapp — underkänns -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- Korrekt: använd en riktig knapp -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- Ta bort fokusstilar — bryter mot WCAG 2.4.7 -->
* {
  outline: none; /* gör aldrig detta globalt */
}

<!-- Bättre: styla fokus synligt och bevara estetiken -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

:focus-visible-pseudoklassen är din bästa vän här. Den visar fokusstilar när en användare navigerar med tangentbord, men döljer dem vid musklick — vilket ger dig ren estetik utan att offra tillgänglighet. För modaler och sidopaneler, använd ett fokusfångande hjälpverktyg som begränsar tabb-navigering till dialogen medan den är öppen och återför fokus till det utlösande elementet när den stängs. Pop-ups dyker ofta upp utan korrekt fokushantering, utan etiketter eller utan stöd för tangentbordsnavigering. Detta orsakar betydande störningar, särskilt i kritiska användarflöden som registrering, inloggning och kassaprocesser.

Utöver enskilda komponenter bör du överväga att lägga till en länk för att hoppa över navigation — en visuellt dold länk som blir synlig vid fokus och låter tangentbordsanvändare hoppa förbi upprepad navigation till huvudinnehållet. Hopplänkar som låter användare hoppa över upprepad navigation saknas på de flesta webbplatser. Det är tre rader HTML och ett litet CSS-snippet, och det gör en djupgående skillnad för alla som navigerar en innehållsrik sida med tangentbord.

<!-- Placera detta som det allra första elementet inuti <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Sedan i din CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

En kommentar om ARIA: använd det varsamt

Många team tar till ARIA (Accessible Rich Internet Applications)-attribut som en snabb lösning på tillgänglighetsluckor. Data tyder på att detta oftare slår tillbaka än hjälper. Ungefär 79% av de utvärderade startsidorna använde ARIA, en ökning från föregående år. Startsidor med ARIA hade mer än dubbelt så många fel som sidor utan ARIA. ARIA i sig är inte problemet — det är oftast felanvändning eller felaktig ARIA. Många välmenande utvecklare tror att de gör innehåll mer tillgängligt genom att lägga till ARIA, när de i själva verket ofta gör det mindre tillgängligt.

Den vägledande principen är enkel: använd semantisk HTML först. Ett <button> är bättre än ett <div role='button'>. Ett <nav> är bättre än ett <div role='navigation'>. Inbyggda HTML-element kommer med inbyggt tangentbordsbeteende, fokushantering och implicita ARIA-roller som anpassad markup kräver att du återskapar manuellt — och det är i den manuella återskapningen som felen smyger sig in. Reservera ARIA för fall där HTML verkligen inte kan uttrycka den semantik du behöver, såsom liveområden, komplexa sammansatta widgets eller dynamiska tillståndsändringar.

Bygg in tillgänglighet i ditt arbetsflöde

Att åtgärda befintliga överträdelser är nödvändigt, men att förhindra att nya uppstår är det som skiljer mogna tillgänglighetsprogram från engångsinsatser för efterlevnad. Tillgänglighet är inte en engångslösning. Varje innehållsuppdatering, designändring eller kodutskick kan introducera nya problem. De sex felkategorier som behandlas i denna guide tenderar att vara mallnivåproblem — fixa sidhuvud, sidfot och delade komponenter så eliminerar du problemet på hundratals sidor samtidigt.

Integrera automatiserad skanning i din CI/CD-pipeline så att överträdelser fångas innan de når produktion. Verktyg som axe-core kan bäddas in i enhetstester och end-to-end-testsviter. Kombinera det med periodiska manuella tangentbordsgenomgångar och skärmläsartestning — VoiceOver på macOS och iOS, NVDA på Windows — eftersom automatiserad testning kan upptäcka vanliga tillgänglighetsfel, men manuell testning hjälper till att fylla luckorna. För team som behöver en snabbare start kan en tillgänglighets-overlay-widget som Accsible lyfta fram och åtgärda en betydande klass av problem i renderingslagret medan mer långsiktiga kodnivåfixar planeras och implementeras.

Avslutningsvis, ta itu med den största hävstångspunkten i din kodbas: dina mallar. De flesta webbplatser använder mallar — ett sidhuvud, en sidfot, navigation och sidlayout som upprepas på varje sida. Problem i dessa mallar multipliceras över hela din webbplats. Fixa dem först för maximal effekt. En enda korrigerad basmall kan förvandla 10 000 WCAG-fel till noll med en enda driftsättning.

Viktiga slutsatser

• Sex typer av problem dominerar landskapet. Text med låg kontrast, saknad alt-text, oetiketterade formulärfält, tomma länkar och knappar, saknat dokumentspråk och trasig tangentbordsnavigering står för den överväldigande majoriteten av WCAG-fel. Att åtgärda dessa sex kategorier ger oproportionerligt stora resultat i förhållande till insatsen.
• De flesta åtgärder är CSS- eller enradiga HTML-ändringar. Att lägga till lang='en' i din <html>-tagg, ersätta outline: none med :focus-visible-stilar och koppla etiketter till fält handlar om timmar, inte månader — ändå eliminerar de fel som påverkar varje användare med funktionsnedsättning som besöker din webbplats.
• Mallar är den plats där åtgärder ger störst hävstång. Tillgänglighetsbuggar i delade komponenter och sidmallar replikeras över hela din webbplats. Granska ditt sidhuvud, din sidfot, navigation och dina formulär först — fixar du dem där, fixar du dem överallt.
• ARIA är ett verktyg i sista hand, inte första åtgärd. Webbplatser som förlitar sig tungt på ARIA utan en stark grund i semantisk HTML tenderar att ha betydligt fler tillgänglighetsfel, inte färre. Föredra inbyggda HTML-element när det är möjligt.
• Automatiserad skanning fångar mindre än hälften av de verkliga problemen. Komplettera dina verktyg med manuella tangentbordsgenomgångar och skärmläsartestning för att hitta de fel som inga skannrar kommer att avslöja, inklusive fokusfällor, problem med logisk tabb-ordning och dynamiskt innehåll som misslyckas med att annonsera ändringar.