Vad är en tillgänglighetsgranskning? Så kontrollerar du om din webbplats följer WCAG

Enligt den senaste WebAIM Million-rapporten upptäcktes 56 miljoner distinkta tillgänglighetsfel på en miljon startsidor — i genomsnitt 56 fel per sida. Det betyder att den stora majoriteten av webbplatser aktivt sviker användare med funktionsnedsättning varje dag. Om du är webbplatsägare, utvecklare eller compliance-ansvarig och undrar om din webbplats är WCAG-kompatibel, innebär svaret nästan säkert att du behöver genomföra en ordentlig tillgänglighetsgranskning. Frågan är: vad betyder det egentligen, och hur gör man det på rätt sätt?

Varför tillgänglighetsgranskningar har blivit oundvikliga

Webbtillgänglighet har rört sig långt bortom området för goda intentioner. Det är nu ett lagkrav i ett växande antal jurisdiktioner, och konsekvenserna av bristande efterlevnad är konkreta och mätbara. Över 4 000 webbtillgänglighetsstämningar väcktes i USA under 2024, och trenden fortsätter uppåt. Domstolar i USA har konsekvent slagit fast att webbplatser för företag som är öppna för allmänheten måste vara tillgängliga enligt ADA Title III. Samtidigt blev European Accessibility Act verkställbar i alla EU:s medlemsstater i juni 2025, och utvidgade kraven bortom offentliga webbplatser till att omfatta bankappar, e-handelsplattformar, SaaS-produkter och mer.

Siffrorna ger en tydlig bild. Runt 16% av världens befolkning — ungefär 1,3 miljarder människor — lever med någon form av funktionsnedsättning. Enbart i USA har ungefär en av fyra vuxna en funktionsnedsättning. Det här är inte användare i marginalen. Det är kunder, anställda, studenter och medborgare som möter hinder på webbplatser som de flesta utvecklare aldrig ens tänker på.

Utöver den juridiska risken finns ett mätbart affärsargument. Tillgängliga webbplatser presterar bättre i sökmotorer, eftersom samma strukturella tydlighet som hjälper skärmläsare — semantiska rubriker, beskrivande alt-text, ren markup — också hjälper crawlers. Inkluderande design förbättrar konsekvent användbarheten för alla: undertexter gynnar personer i bullriga miljöer, hög kontrast hjälper personer i starkt solljus, och tangentbordsnavigering gynnar avancerade användare. En tillgänglighetsgranskning är första steget mot att ta tillvara alla dessa fördelar.

Ytterligare en viktig förändring: ADA Title II kräver nu uttryckligen webbtillgänglighet för delstatliga och lokala myndigheter i USA, där DOJ har antagit WCAG 2.1 nivå AA som teknisk standard. Aktörer som betjänar befolkningar på 50 000 eller fler står inför en efterlevnadsfrist den 26 april 2026. Om du arbetar med offentliga kunder eller verkar i reglerade branscher är granskning inte längre valfri — den är akut.

Vad är egentligen en WCAG-tillgänglighetsgranskning?

En webbtillgänglighetsgranskning är en systematisk utvärdering av din webbplats efterlevnad av Web Content Accessibility Guidelines (WCAG) — den internationellt erkända tekniska standarden för digital tillgänglighet, utvecklad av W3C. I praktiken identifierar en granskning specifika hinder som hindrar användare med funktionsnedsättning från att uppfatta, förstå, navigera och interagera med ditt innehåll. Den kartlägger dessa hinder mot WCAG:s framgångskriterier, tilldelar allvarlighetsnivåer och tar fram en åtgärdsplan.

WCAG är för närvarande i version 2.2, publicerad i slutet av 2023 och formellt bekräftad av W3C i maj 2025 som den högsta standarden för webbtillgänglighet. Den innehåller nio nya framgångskriterier jämfört med WCAG 2.1, som täcker områden som synlighet för tangentbordsfokus, minsta storlek på touch-mål, alternativ till drag-rörelser och konsekventa hjälpmekanismer. Viktigt är att WCAG 2.2 är bakåtkompatibel — uppfyller du 2.2 uppfyller du också 2.1 och 2.0.

WCAG är organiserad kring tre nivåer av överensstämmelse. Nivå A omfattar de mest kritiska hindren — brister på denna nivå gör innehåll helt oanvändbart för vissa användare. Nivå AA är målet som föreskrivs i de flesta tillgänglighetslagar världen över, inklusive ADA, European Accessibility Act och Section 508. Nivå AAA representerar den högsta ribban och är vanligtvis mer aspirerande än juridiskt krav. När någon säger att deras webbplats är ”WCAG-kompatibel” menar de nästan alltid WCAG 2.1 eller 2.2, nivå AA.

WCAG bygger på fyra grundprinciper, ofta ihågkomna med akronymen POUR: innehåll måste vara Perceivable (användare kan uppfatta det), Operable (användare kan interagera med det), Understandable (användare kan förstå det) och Robust (det fungerar tillförlitligt med hjälpmedelsteknik). Varje framgångskriterium kopplas till en av dessa fyra principer, och en grundlig granskning kontrollerar efterlevnad mot dem alla.

De vanligaste felen som granskningar avslöjar

Ungefär 96% av alla upptäckta tillgänglighetsfel faller inom bara sex kategorier. Att veta vad du ska leta efter är det snabbaste sättet att prioritera din granskningsinsats:

• Text med låg kontrast. Detta är konsekvent det vanligaste felet. Nästan 84% av startsidorna har text som ligger under WCAG 2 AA:s kontrastgräns på 4,5:1 för normal text. Granskare kontrollerar förgrunds- och bakgrundsfärgers kontrastförhållande med verktyg som TPGi Colour Contrast Analyser.
• Saknad alternativtext. Över 16% av alla bilder på startsidor saknar alt-attribut, vilket lämnar skärmläsaranvändare utan möjlighet att förstå bildinnehållet. Länkade bilder utan alt-text är särskilt skadliga — de blir meningslösa navigationsmål.
• Tomma länkar. Länkar som inte innehåller någon synlig text och inget tillgängligt namn skapar återvändsgränder för tangentbords- och skärmläsaranvändare, som inte kan avgöra vart länken leder.
• Saknade formuläretiketter. Formulär utan programmatiskt associerade etiketter är oanvändbara för skärmläsaranvändare. Detta inkluderar både synliga etiketter och dolda etiketter med aria-label eller aria-labelledby.
• Tomma knappar. Knappar som bara består av ikoner utan ett tillgängligt namn — vanliga i navigation och sliders — gör att icke-visuella användare inte kan identifiera vad knappen gör.
• Saknat dokumentspråk. Attributet lang på elementet <html> talar om för skärmläsare vilket språk som ska användas. Om det saknas leder det till felaktigt uttal och desorientering för användare som förlitar sig på text-till-tal.

Granskningar visar konsekvent att de mest skadliga felen också är de enklaste att åtgärda. Låg kontrast, saknad alt-text och oetiketterade formulärfält kan ofta åtgärdas på dagar, inte månader.

Utöver dessa sex kommer en grundlig granskning också att upptäcka saknade länkar för att hoppa över navigation (som tvingar tangentbordsanvändare att tabba genom varje rubrikelement på varje sida), felaktig rubrikhierarki, otillgängliga modaler och dialoger som hanterar fokus felaktigt, videor utan undertexter, PDF:er utan taggad struktur och anpassade JavaScript-widgets som inte exponerar tillgängliga roller och tillstånd via ARIA.

Hur man genomför en tillgänglighetsgranskning: steg för steg

En ordentlig tillgänglighetsgranskning är inte en enstaka skanning — det är en flerstegsprocess som kombinerar automatiska verktyg med kvalificerad mänsklig bedömning. Så här närmar du dig det systematiskt:

Steg 1: Definiera omfattningen

Innan du kör ett enda test måste du bestämma vad du ska granska. För en stor webbplats är det opraktiskt att testa varje sida. Använd istället WCAG-EM (Website Accessibility Conformance Evaluation Methodology) som utvecklats av W3C: definiera ett representativt urval som täcker alla unika sidmallar, alla viktiga användarresor och alla distinkta innehållstyper. Ett urval för en e-handelswebbplats kan inkludera startsidan, en kategorisida, en produktsida, varukorgen, checkout-flödet, inloggning, kontaktformulär och ett blogginlägg. Se till att dynamiska tillstånd ingår — öppna menyer, felmeddelanden i formulär, modala dialoger och inlästa sökresultat måste alla utvärderas.

Steg 2: Kör automatiska skanningar

Automatiska verktyg är grunden i varje effektiv granskning. De skannar ditt HTML snabbt, flaggar otvetydiga regelbrott och ger dig en grundläggande lista över problem. Viktiga verktyg inkluderar:

• axe DevTools (webbläsartillägg eller CLI) — allmänt använt, låg andel falska positiva, kan integreras i CI/CD-pipelines
• WAVE (WebAIM) — annoterar sidor visuellt med felikoner, vilket gör det intuitivt för icke-tekniska teammedlemmar
• Lighthouse (inbyggt i Chrome DevTools) — ger ett tillgänglighetsbetyg tillsammans med prestanda- och SEO-mått
• Colour Contrast Analyser (TPGi) — plockar vilken färg som helst på skärmen och kontrollerar den mot WCAG-gränser
• PAC 2024 — dedikerat PDF-tillgänglighetsverktyg för nedladdningsbara dokument

En kritisk begränsning: automatiska verktyg kan bara upptäcka mellan 30% och 40% av WCAG-problemen. De är utmärkta på att flagga regelbaserade fel som saknade attribut, ogiltiga ARIA-roller och kontrastförhållanden. Men de kan inte bedöma om alt-text är meningsfull, om ett formulär är logiskt strukturerat eller om en användare faktiskt kan slutföra en uppgift. Det är därför automatisering är steg 2, inte hela granskningen.

Steg 3: Manuell expertgranskning

Manuell testning av en kunnig person — eller helst ett team — avgör hur djup granskningen blir. Detta inkluderar:

• Navigering enbart med tangentbord. Koppla bort musen och försök slutföra varje central användarresa med enbart Tab, Shift+Tab, Enter, Space och piltangenter. Kan du nå varje interaktivt element? Är fokusindikatorn alltid synlig? Försvinner fokus någonsin in i en komponent?
• Testning med skärmläsare. Använd NVDA med Chrome eller Firefox på Windows, och VoiceOver med Safari på macOS och iOS. Navigera via rubriker, landmärken, länkar och formulär. Är sidan begriplig utan visuellt sammanhang? Annonseras alla interaktiva element korrekt?
• Visuell och kognitiv genomgång. Kontrollera rubrikhierarkin för logisk struktur, verifiera att felmeddelanden är beskrivande och kopplade till rätt fält, bekräfta att tidsbaserade medier har undertexter och transkriptioner, och se över att instruktioner inte enbart förlitar sig på färg, form eller position.
• Kodgranskning. Gå igenom HTML-semantik, ARIA-användning, fokushantering i anpassade widgets och landmärkesregioner. En modal som inte fångar fokus, eller en ARIA live-region som triggas vid varje tangenttryckning, upptäcks bara på denna nivå.

Steg 4: Testning med hjälpmedelsteknik tillsammans med riktiga användare

Guldstandarden — och ofta den mest avslöjande fasen — är att testa med faktiska användare som dagligen förlitar sig på hjälpmedelsteknik. Personer som använder skärmläsare, switch-enheter eller röststyrningsprogram navigerar på sätt som även erfarna manuella testare inte fullt ut återskapar. Att inkludera personer med funktionsnedsättning i din utvärdering synliggör friktion i verkliga situationer som verktyg och checklistor helt enkelt inte kan förutse.

Steg 5: Dokumentera och prioritera fynd

En rå lista med fel är inte en granskningsrapport — det är en startpunkt. Ett användbart granskningsdokument bör ange: berörd URL eller komponent, vilket WCAG-framgångskriterium som bryts, allvarlighetsgrad (kritisk, hög, medel, låg), påverkan på berörda användare och specifik vägledning för åtgärd med kodexempel där det är relevant. Prioritet bör tilldelas utifrån användarpåverkan först, inte teknisk bekvämlighet. En trasig formuläretikett som hindrar checkout är mer akut än en mindre optimal rubriknivå i en bloggsidokolumn.

Steg 6: Åtgärda, validera och övervaka

När åtgärder har genomförts ska de valideras — utgå inte från att de fungerade. Testa om varje åtgärd med samma kombination av verktyg och manuella kontroller som användes under den ursprungliga granskningen. När du uppnått en grundläggande nivå av efterlevnad, inför kontinuerlig övervakning. Nytt innehåll, CMS-uppdateringar och tredjepartsskript kan när som helst introducera regressioner. Behandla tillgänglighet som säkerhet: något du upprätthåller, inte något du uppnår en gång och sedan glömmer.

Automatiska skanningar vs. fullständiga granskningar: förstå skillnaden

Denna skillnad är enormt viktig, särskilt i ett juridiskt sammanhang. En automatisk skanning kör en regelbaserad kontroll mot ditt renderade HTML. Det tar sekunder eller minuter och returnerar en lista över upptäckta överträdelser. Den är utmärkt för att fånga uppenbara, frekventa problem och för att integreras i CI/CD-arbetsflöden för att förhindra att nya regressioner släpps. Många overlay- och widgetprodukter — inklusive tillgänglighetsverktyg — erbjuder automatiska skanningspaneler som en del av sin funktionalitet, och dessa är verkligen användbara för löpande övervakning.

En fullständig granskning, däremot, utvärderar din webbplats mot alla tillämpliga WCAG-framgångskriterier med en kombination av automatisk skanning, manuell expertgranskning, testning med skärmläsare och navigering enbart med tangentbord. En omfattande granskning som kombinerar automatiska och manuella metoder kan identifiera över 90% av tillgänglighetsproblemen, jämfört med taket på 30–40% för enbart automatisering. Om du står inför ett juridiskt kravbrev, ett upphandlingskrav eller en tillsynsförfrågan är det bara en fullständig granskning som ger den dokumentation du behöver.

Många organisationer använder en praktisk hybridstrategi: automatiska skanningar körs kontinuerligt i CI/CD för att fånga regressioner tidigt, medan en fullständig manuell granskning genomförs årligen eller efter större omdesign av webbplatsen. Detta balanserar noggrannhet med effektivitet och gör efterlevnad hanterbar över tid.

Inget verktyg kan ensamt avgöra om en webbplats uppfyller tillgänglighetsstandarder. Kunnig mänsklig utvärdering krävs för att avgöra om en webbplats verkligen är tillgänglig. — W3C Web Accessibility Initiative

Vad du gör med granskningsresultaten: planering av åtgärder

En genomförd granskning är bara värdefull om den leder till handling. Hur du prioriterar åtgärdsarbetet är minst lika viktigt som att identifiera problemen från början. En praktisk modell för prioritering av åtgärder ser ut så här:

1. Kritisk (åtgärda omedelbart): Problem som helt blockerar användare från att slutföra centrala uppgifter — ett trasigt checkout-formulär, en otillgänglig inloggningsmodal, en navigationsmeny som inte kan nås med tangentbord. Dessa innebär högst juridisk risk och störst påverkan på användare.
2. Hög (åtgärda inom pågående sprint eller releasecykel): Problem som avsevärt försämrar användbarheten för användare med funktionsnedsättning men inte helt blockerar dem — saknad alt-text på produktbilder, låg kontrast på brödtext, oetiketterade ikonknappar genom hela gränssnittet.
3. Medel (planerad åtgärd): Problem som skapar friktion men har lösningar — inkonsekventa fokusindikatorer, saknade hoppa-över-länkar, mindre optimal rubrikhierarki.
4. Låg (backlog med utsedd ansvarig): Problem som är best practice-förbättringar men som sannolikt inte påverkar användbarheten i de flesta fall — förbättringar på AAA-nivå, mindre justeringar av ARIA-verbositet.

Dokumentera din åtgärdsplan och tidslinje, även innan alla åtgärder är genomförda. Tillsynsmyndigheter och domstolar ser i allmänhet positivt på dokumenterade, pågående och seriösa förbättringar jämfört med passivitet. Om du får ett kravbrev står du betydligt starkare med en granskningsrapport plus en åtgärdsplan än utan någon dokumentation alls.

Overlay-widgets och SDK-verktyg — som det som erbjuds av Accsible — kan spela en meningsfull roll i åtgärdsfasen. De kan möjliggöra omedelbara förbättringar för en betydande del av vanliga problem (särskilt visuella preferenser som kontrast, textstorlek och radavstånd) medan ditt utvecklingsteam arbetar med djupare åtgärder i koden. Nyckeln är att förstå vad overlays löser bra och att använda dem som en del av en lagerbaserad strategi, inte som ersättning för kodnivååtgärder av kritiska hinder.

Hur ofta bör du genomföra en tillgänglighetsgranskning?

En engångsgranskning är en ögonblicksbild av din webbplats en viss dag. Webbplatser är levande produkter — innehåll ändras, tredjepartsskript uppdateras, komponenter byts ut och nya funktioner lanseras. Var och en av dessa händelser kan introducera nya tillgänglighetshinder. Ett hållbart tillgänglighetsprogram ser typiskt ut så här:

• Kontinuerlig automatisk skanning integrerad i din CI/CD-pipeline eller via en övervakningspanel, som fångar regressioner innan de når produktion
• Kvartalsvisa manuella stickprov på sidor med hög trafik och hög risk (checkout, inloggning, kontaktformulär, viktiga landningssidor)
• Årlig fullständig granskning genomförd av kvalificerade tillgänglighetsexperter, särskilt efter större omdesign eller plattformsbyten
• Granskning i designfasen för varje ny större funktion eller omdesign — tillgänglighet är avsevärt billigare att bygga in än att eftermontera

Det mest kostnadseffektiva tillvägagångssättet är att flytta tillgänglighet ”vänsterut” — att integrera den i design- och utvecklingsprocessen från dag ett istället för att behandla den som en efterhandskontroll för efterlevnad. Utvecklare som förstår WCAG-kraven fångar problem vid källan. Designers som känner till färgkontrast och storlek på touch-mål gör tillgängliga val som standard. En granskning blir då en kvalitetskontroll snarare än en akutinsats.

Viktiga slutsatser

• De flesta webbplatser misslyckas med WCAG. Över 95% av startsidorna har upptäckbara tillgänglighetsfel, och de sex vanligaste felen — låg kontrast, saknad alt-text, tomma länkar, saknade formuläretiketter, tomma knappar och saknat dokumentspråk — står för den stora majoriteten. Alla dessa går att åtgärda.
• Automatiska verktyg är nödvändiga men inte tillräckliga. Automatiska skannrar fångar som bäst 30–40% av WCAG-problemen. En komplett granskning kräver tangentbordstestning, testning med skärmläsare och kvalificerad mänsklig granskning av kod och UX-flöden.
• WCAG 2.2 nivå AA är målet. Det är standarden som refereras i ADA, European Accessibility Act, Section 508 och de flesta andra tillgänglighetsramverk världen över. Om du siktar på 2.2 AA täcker du automatiskt alla lägre versioner.
• Åtgärder kräver en prioriteringsmodell. Börja med problem som helt blockerar centrala användarresor, och arbeta dig sedan igenom problem med hög påverkan och hög frekvens. Dokumentera allt — din granskningsrapport och åtgärdsplan är ditt bästa juridiska försvar.
• Tillgänglighet är pågående, inte något du gör en gång. Kombinera kontinuerlig automatisk övervakning med periodiska manuella granskningar och flytta in tillgänglighet i din design- och utvecklingsprocess från början. En overlay-widget som Accsible kan överbrygga gap medan djupare åtgärder pågår.