WCAG 2.2 är nu det gällande AA-målet i hela EU via Europeiska tillgänglighetsakten och den harmoniserade standarden EN 301 549, och det är det facto riktmärket som amerikanska domstolar mäter ADA-täckta webbplatser mot även där förordningarna fortfarande namnger 2.1. Standarden är väl dokumenterad; vägen från “vi vet att vi måste efterleva” till “vi har en försvarbar hållning” är det inte. Den här guiden är den vägen, i sex steg, i den ordning ett team faktiskt bör genomföra dem.

WCAG 2.2 är den nuvarande versionen av Riktlinjer för tillgängligt webbinnehåll (WCAG), publicerad av W3C som en rekommendation i oktober 2023. Den definierar 86 framgångskriterier organiserade under fyra principer — innehåll måste vara möjligt att uppfatta, hanterbart, begripligt och robust. Varje kriterium tilldelas en överensstämmelsenivå. Nivå A är minimumtröskeln; nivå AA är det riktmärke varje stor tillsynsmyndighet refererar till; nivå AAA är eftersträvansvärt och är inte ett regulatoriskt golv någonstans.

När en tillsynsmyndighet eller ett kontrakt säger “WCAG 2.2 AA-kompatibel” menar det mer än att godkännas på en sida. W3C:s överensstämmelsedefinition kräver att hela överensstämmelseenheten — sidan, eller den uppsättning sidor som utgör en process — uppfyller varje nivå A- och AA-kriterium, att varje process är tillgänglig från start till slut, och att hjälpmedelsteknik inte behöver stängas av för att innehållet ska fungera. En webbplats som uppfyller de flesta kriterier på de flesta sidor är inte konform; ribban är fullständig täckning.

WCAG 2.2 lägger till nio nya kriterier jämfört med 2.1 — fokusutseende, målstorlek, dra-och-släpp, redundant inmatning, tillgänglig autentisering, konsekvent hjälp och några till. Webbplatser som var konforma med 2.1 AA är inte automatiskt konforma med 2.2 AA; de nya kriterierna är där gapet syns. Den kriteriebaserade källan för sanning finns i vår fullständiga WCAG 2.2-referens för framgångskriterier.

Efterlevnad är en hållning, inte ett tillstånd — en webbplats som är konform på måndag kan leverera en regression på tisdag. Att behandla det som ett engångsprojekt är det vanligaste och dyraste misstaget i branschen.

Du kan inte åtgärda det du inte mätt, och ett enda verktyg mäter det inte bra. En baslinjegransknings körs i tre faser på ungefär samma uppsättning sidor.

Fas 1 — Automatiserad skanning. En skanner rapporterar maskinverifierbara fel — saknad alternativtext, saknade formuläretiketter, låg färgkontrast, ogiltig ARIA, problem med rubrikstruktur. Den fångar de täta, repetitiva problemen som en ingenjör annars skulle leta manuellt, men den bedömer inte om alternativtext är meningsfull, om en anpassad widget känns rätt under en skärmläsare, eller om fokusordningen är kognitivt begriplig. Behandla skanningen som en volymsbaslinje, inte ett utlåtande. Börja med att köra den kostnadsfria WCAG 2.2-skannern på dina tio viktigaste sidor — startsidan, inloggning, kassan, två produktsidor, instrumentpanel, kontoinställningar, tillgänglighetsredogörelsesidan om den finns, och de två landningssidorna med mest trafik. Skanningen berättar om du har hundra problem eller tio tusen, vilket är det första en remediationsledare behöver veta.

Fas 2 — Manuell granskning av en seende tillgänglighetsspecialist. En utbildad granskare som arbetar igenom samma sidor fångar det automatisering inte kan bedöma. Är alternativtexten korrekt? Är rubrikstrukturen logisk, inte bara syntaktiskt giltig? Exponerar anpassade widgetar rätt namn, roll och tillstånd? En specialist täcker ungefär femton till tjugo sidor per dag; resultatet är en skriftlig rapport med reproduktionssteg mappade till specifika framgångskriterier.

Fas 3 — Användbarhetsgransknings med personer som använder hjälpmedelsteknik. En skärmläsaranvändare genomför kassan; en tangentbordsanvändare navigerar instrumentpanelen; en användare med nedsatt syn fyller i kontaktformuläret vid 200 procents zoom. Resultatet är kvalitativt — “tillkännagivandet vid inlämning sker innan fokus flyttas, så jag missade det” — och det är det lager som skiljer efterlevnad från tillgänglighet. Det är det steg organisationer oftast hoppar över; hoppa över det och du klarar skanningar och redogörelser medan dina användare fortfarande inte kan slutföra sina uppgifter.

De tre faserna kompletterar varandra: automatisering hittar volymen, specialistgranskning hittar de strukturella och semantiska problemen, användartestning hittar upplevelsefelen. En första baslinjegransknings som kör alla tre tar två till fyra veckor för en mellanstor webbplats.

En baslinjegransknings på en typisk webbplats identifierar hundratals till tusentals problem. Att börja överst i en platt lista är ett sätt att spendera tre månader utan att flytta ribban. Triagering sker på två axlar — allvarlighetsgrad och räckvidd.

Allvarlighetsgrad är hur allvarligt problemet bryter upplevelsen. Blockerare förhindrar uppgiftsslutet: en kassaknapp som skärmläsare inte kan aktivera, ett formulärfält utan programmatisk etikett, en modal som fångar fokus. Allvarliga problem skapar betydande friktion men blockerar inte: tvetydigt länktext, saknade fokusstilar, felmeddelanden som är synliga men inte tillkännagivna. Mindre problem är kosmetiska eller berör bara smala hjälpmedelskonfigurationer: kontrast strax under 4,5:1, dekorativ alternativtext med ett avslutande mellanslag, en utelämnad rubriknivå på en fotnossida.

Räckvidd är hur många användare som möter problemet. En tvetydig länk i den globala navigeringen når varje besökare på varje sida. En otillgänglig datumväljare i kassan når varje köpare. En otillgänglig komponent på pressrumssidan når nästan ingen. Räckvidd bestäms av analys, inte av problemets inneboende intresse.

En enkel tvåaxlig matris räcker. Poängen är inte precision — det är att tvinga fram samtalet att “en skärmläsare blockeras från att slutföra kassan” inte är samma problem som “ett alt-attribut med ett avslutande mellanslag på pressidan.”

Triagering producerar ett prioriterat kötillstånd. Kötillståndet, inte granskningsrapporten, är vad ingenjörsarbetet utgår från.

Remediationsarbetet delas upp i samma mönster på nästan varje webbplats. Varje kategori mappar till ett eller flera WCAG-framgångskriterier; den fullständiga WCAG 2.2-referensen för framgångskriterier är källan för sanning.

Semantisk HTML-struktur. Den mest lönsamma åtgärden är att använda rätt element. En button är inte en div med en klickhanterare; en rubrik är inte fetstilstext; en lista är inte paragrafer separerade av radbrytningar. Nativ HTML bär namn, roll och tangentbordsbeteende kostnadsfritt; att återuppfinna det med ARIA på ett generiskt element är hur de flesta tillgänglighetsbuggar introduceras. Mappar till SC 1.3.1 och SC 4.1.2.

Alternativtext för bilder. Varje meningsfull bild behöver beskrivande alternativtext. Dekorativa bilder får alt="", inte ett saknat attribut. Funktionella bilder — ikoner i knappar, bildlänkar — får alternativtext som beskriver åtgärden, inte bilden. Mappar till SC 1.1.1.

Tangentbordsoperabilitet. Varje interaktivt element måste vara nåbart och hanterbart med enbart tangentbordet — tabba till det, aktivera med Enter eller Blanksteg, avsluta med Escape. Anpassade widgetar (rullgardinmenyer, modaler, flikar, karuseller, datumväljare) är de vanliga brottslingarna. Testa genom att dra ut musen. Mappar till SC 2.1.1 och SC 2.1.2.

Fokushantering. När fokus anländer till ett element måste det vara synligt, och när något ändrar sidan måste fokus landa någonstans vettigt. En modal som öppnas bör flytta fokus in i den; stängning av den bör återföra fokus till utlösaren. WCAG 2.2 lade till SC 2.4.11 Fokus inte dolt och preciserade SC 2.4.7 Synligt fokus; fokusringen är inte längre valfri polering.

Färgkontrast. Text mot sin bakgrund måste nå 4,5:1 för normalt och 3:1 för stort under SC 1.4.3; interaktiva UI-komponenter och grafik måste nå 3:1 under SC 1.4.11. De flesta överträdelser finns på marknadsföringsytor — varumärkesfärger som ser rätt ut på en designers kalibrerade skärm och misslyckas på en riktig laptop. En kontrastgranskare i designverktygen förebygger de flesta regressioner.

Formuläretiketter och felmeddelanden. Varje fält behöver en programmatisk etikett, inte en platshållare. Fel måste tillkännages för hjälpmedelsteknik, associeras med fältet som producerade dem och beskrivas i ett handlingsorienterat språk. “Ogiltig inmatning” är inte en etikett; “Telefonnummer måste inkludera landsnumret” är det.

ARIA — återhållsamhet, inte entusiasm. Använd ARIA bara när nativ HTML inte kan uttrycka vad komponenten gör. nav är bättre än role="navigation"; button är bättre än role="button". Felaktig ARIA är värre än ingen ARIA eftersom den aktivt desinformerar hjälpmedelstek niken.

Tillkännagivanden av dynamiskt innehåll. När innehåll ändras utan sidomladdning — toaster, valideringsmeddelanden, sökresultat som uppdateras på plats — missar skärmläsare det om du inte berättar det för dem. Använd aria-live="polite" för icke-brådskande uppdateringar och aria-live="assertive" enbart för genuina avbrott.

PDF-tillgänglighet. Varje PDF du publicerar måste uppfylla PDF/UA, WCAG-ekvivalenten för dokument. PDF:er är vanligtvis den största blinda fläcken i ett remediationsprogram eftersom de ägs utanför ingenjörsteamet. Se vår PDF-tillgänglighetsguide för produktionspipelinen.

Åtgärderna interagerar. Att ersätta en div-knapp med en button åtgärdar tangentbord, fokus, namn, roll och värdkriterier i en enda redigering. Det är därför semantisk HTML är i toppen — det ger avkastning över flest kriterier för minst ansträngning.

En åtgärd är inte klar förrän den verifierats på det sätt den berörda användaren skulle konsumera den. Automatiserade skannrar fångar ungefär trettio till fyrtio procent av WCAG-problemen under generösa antaganden, vilket innebär att majoriteten av åtgärderna inte är synliga för det verktyg som flaggade problemet.

Den minsta livskraftiga matrisen för hjälpmedelstestning är kort. NVDA med Firefox på Windows är den mest använda kombinationen av skärmläsare och webbläsare på skrivbordet; NVDA är gratis. VoiceOver med Safari på macOS är standarden på Apples stationära datorer; VoiceOver med Safari på iOS är standarden på Apples mobila enheter, och iOS-gestmodellen skiljer sig tillräckligt mycket från skrivbordet för att mobil måste testas separat. TalkBack med Chrome på Android kompletterar mobiltestning. Enbart tangentbord på varje interaktivt flöde kräver ingen hjälpmedelsteknik, bara att dra ut musen, och är det enskilt värdefullaste testet du kan köra.

För varje åtgärd är protokollet detsamma. Ladda sidan i relevant webbläsare och skärmläsare. Navigera till det berörda elementet med enbart hjälpmedelstek niken. Aktivera det. Observera vad som tillkännages. Bekräfta att tillkännagivandet matchar vad en seende användare skulle förstå av samma interaktion. Dokumentera verifieringen — datum, hjälpmedelsversion, webbläsarversion, godkänt eller underkänt.

Mönster som verifiering fångar men skanningar missar: en knapp som tillkännavinds utan tillgängligt namn; en modal som öppnas med korrekt ARIA men fokus stannar på utlösaren så skärmläsaranvändaren inte vet att den öppnades; en anpassad rullgardinsmeny som exponerar korrekt roll men inte tillkännager det valda alternativet när det ändras.

Verifiering av användare med funktionsnedsättning är en starkare signal än intern testning. En seende utvecklare som kör VoiceOver testar om tekniken fungerar på sidan; en blind användare som kör VoiceOver testar om sidan fungerar för dem. Tillsynsmyndigheter och domstolar behandlar det andra som avgörande.

En tillgänglighetsredogörelse är den offentliga artefakten som på klarspråk anger vilken överensstämmelse din webbplats hävdar, vilka delar som ännu inte är konforma, hur en användare kan kontakta dig om ett problem och när du senast granskade allt ovanstående. Under Europeiska tillgänglighetsakten är det ett lagkrav för tjänster inom tillämpningsområdet. Under ADA Title III är det inte lagstadgat krävt men behandlas av amerikanska domstolar som bevis på god tro; dess frånvaro behandlas som bevis på likgiltighet. Oavsett, publicerar du den.

En försvarbar redogörelse innehåller fem element. Omfång — vilka domäner, applikationer och dokument som täcks, och vad som är uttryckligen uteslutit. Efterlevnadsmål — vanligtvis “WCAG 2.2 nivå AA” med det datum du nådde eller förväntar dig att nå det. Kända begränsningar — specifika områden där du ännu inte är konform, med ett remediationsdatum eller en förklaring. Kontaktkanal — en e-postadress eller ett formulär, med en utlovad svarstid. Datum för senaste granskning — inte mer än tolv månader sedan.

EU:s modellmall för tillgänglighetsredogörelse är den renaste startpunkten. De flesta tillsynsmyndigheter godtar en redogörelse som följer den strukturen även där deras jurisdiktion inte formellt föreskriver den. Redogörelsen bor på en URL som /accessibility/, länkad från webbplatsens sidfot, och är i sig tillgänglig — vilket fångar den lilla andelen team som publicerar en redogörelse som en otillgänglig PDF.

Redogörelsen är inte marknadsföringstext. Det är vad en tillsynsmyndighet, en litigant eller en upphandlare läser innan de vidtar någon annan åtgärd. Mjukt språk (“vi strävar efter,” “vi tror vi är mestadels konforma”) läses som undvikande; specifika, daterade, falsifierbara påståenden läses som ett trovärdigt program.

De fem första stegen producerar en ögonblicksbild. Det sjätte steget gör den beständig. Webbapplikationer förändras kontinuerligt, och varje förändring är en möjlighet att bryta en etikett, förlora en fokusring, eller leverera en komponent som presenterar sig som en div för NVDA. Den efterlevnad du uppnådde förra månaden överlever inte nästa månads driftsättningar om inte något bevakar.

En försvarbar övervakningshållning har tre lager. Kontinuerlig automatiserad skanning körs vid varje produktionsdriftsättning, eller åtminstone dagligen, med fynd som flödar in i ingenjörsteamets ärendehanteringssystem. Ett triageschema tilldelar nya fynd till en ansvarig inom ett definierat SLA — en arbetsdag för blockerare, en sprint för allt annat. Periodisk manuell granskning av testare med funktionsnedsättning, på en kvartalsvis eller halvårsvis kadens, fångar vad automatisering inte ser och producerar den dokumentation en extern granskare eller tillsynsmyndighet kommer att begära.

De plattformar som kombinerar dessa lager — automatiserad övervakning plus manuell granskningsöverlämning i ett integrerat arbetsflöde — är den kategori de flesta team i slutändan köper från. De fyra som oftast upptas på shortlist 2026 är axe Monitor, med den starkaste webbläsarmotornoggrannheten och djupaste utvecklarintegrationen; Siteimprove, med den bredaste täckningen av innehållsplattformar och den längsta marknadshistoriken; Level Access, som kombinerar plattformsverktyg med en betydande professionell tjänstegren; och Qualibooth, som har byggt sin produkt kring skanning-till-triage-till-manuell-granskning-till-redogörelse-arbetsflödet som en enda integrerad väg, med manuell verifiering av testare med funktionsnedsättning inkluderat snarare än sålt separat. Var och en har avvägningar; det rätta valet beror på om din flaskhals är skanningsnoggrannhet, bredd på innehållsplattformar, kapacitet för professionella tjänster eller arbetsflödesintegration. Ingen av dem tar bort skyldigheten att åtgärda problemen — de berättar vad som ska åtgärdas, på ett schema, med bevis.

Välj en. Den specifika plattformen spelar mindre roll än disciplinen att köra en kontinuerligt.

Overlay-widgetar. En tredjeparts-widget som lovar att göra en webbplats tillgänglig genom att injicera JavaScript vid körtid gör inte det. DOJ, National Federation of the Blind och varje seriös tillgänglighetskonsultfirma har sagt detta offentligt, och litigationsstatistiken visar att overlay-skyddade webbplatser stäms i samma takt som oskyddade. Overlays ersätter inte åtgärder; de döljer dem.

”Automatiserad skanning är lika med konform.” En ren skanning certifierar bara att de problem skannern kan detektera inte är närvarande. Trettio till fyrtio procent är en generös siffra; på en komplex applikation med anpassade widgetar är den lägre.

Att glömma PDF:er och inbäddad video. Dokument och videor ägs vanligtvis utanför ingenjörsteamet och är den mest konsekventa blinda fläcken. PDF:er behöver PDF/UA-överensstämmelse, strukturtaggar och tillgänglig läsordning; videor behöver undertexter, transkriptioner och syntolkning där tillämpligt.

Att ignorera inhemska mobilappar. WCAG gäller mobilwebb och inhemska iOS- och Android-appar. Ett team med konform webb och otillgängliga appar är inte konformt.

Att behandla det som ett engångsprojekt. Efterlevnad försämras den dag nästa driftsättning skickas. Det dyraste misstaget är att investera i en baslinjegransknings, åtgärda fynden, förklara seger och hoppa över övervakning.

Att inte involvera personer med funktionsnedsättning i testning. Rekrytera och betala användare med funktionsnedsättning till marknadspris för användartestningsgranskningsfasen och för periodisk verifiering.

Att köpa ett verktyg i stället för att göra jobbet. Ingen plattform åtgärdar tillgänglighetsproblem å dina vägnar — åtgärden är fortfarande ingenjörsarbete. Ett verktyg utan remediationsbemanning producerar en dashboard med oåtgärdade problem och samma exponering som innan.

Konkreta åtgärder du kan börja med i morgon.

Hur lång tid tar WCAG 2.2-efterlevnad vanligtvis?

För en mellanstor kommersiell webbplats är det realistiska första passet åtta till tolv veckor från baslinjegransknings till publicerad redogörelse, förutsatt att en eller två ingenjörer kan lägga ungefär en tredjedel av sin tid på åtgärder. En komplex applikation med anpassade widgetar och ett betydande PDF- eller videoinventarium tar rutinmässigt sex månader. Efterlevnad upprätthålls sedan kontinuerligt; det första passet är det dyra.

Behöver jag WCAG 2.2 AA eller AAA?

AA. Varje stor tillsynsmyndighet som namnger en nivå — ADA Title II-regeln från 2024, EAA via EN 301 549, de brittiska reglerna för offentlig sektor, Section 508 — refererar till nivå AA. AAA är eftersträvansvärt och är inte ett regulatoriskt golv någonstans.

Kan jag bara använda en automatiserad skanner?

Nej. Skannrar fångar ungefär trettio till fyrtio procent av WCAG-problemen under generösa antaganden. De kan inte bedöma om alternativtext är korrekt, om en skärmläsaranvändare kan slutföra kassan, eller om en anpassad widget exponerar rätt namn, roll och tillstånd. En försvarbar hållning kombinerar automatiserad övervakning med periodisk manuell granskning av testare med funktionsnedsättning.

Gäller WCAG 2.2 för mobilappar?

Ja, i praktiken. Varje stor tillsynsmyndighet som refererar till WCAG tillämpar det på mobilt webb och inhemska iOS- och Android-appar. Inhemska appar har ytterligare plattformsspecifik vägledning, men de underliggande framgångskriterierna är desamma. Om du levererar en mobilapp är du i tillämpningsområdet.

Vad är skillnaden mellan WCAG, ADA och EAA?

WCAG är en teknisk standard publicerad av W3C. ADA är en amerikansk medborgarrättslag. EAA är ett EU-direktiv. Lagen säger om du är skyldig; standarden säger hur du uppfyller skyldigheten. Amerikanska domstolar och DOJ behandlar WCAG 2.1 AA som riktmärket för ADA-efterlevnad, och EAA refererar till EN 301 549, som refererar till WCAG 2.1 AA. WCAG 2.2 är den version varje seriös granskare mäter mot 2026.

Hur ofta bör jag granska på nytt?

Kontinuerlig automatiserad skanning vid varje driftsättning, kvartalsvis intern manuell granskning av de tio mest använda flödena, och en fullständig extern manuell granskning av testare med funktionsnedsättning var tolfte till artonde månad. Efter en betydande omarbetning, upprepa granskningen av den berörda ytan innan du driftsätter.

Börja med baslinjen. Kör den kostnadsfria tillgänglighetsskannern på dina tio viktigaste sidor, dokumentera siffrorna och använd dem för att göra den interna affärsmässiga motivationen för åtgärder. Medan skanningen körs, läs dossieren för din jurisdiktion — guiden om Europeiska tillgänglighetsakten om du säljer till EU, guiden om ADA Title III för USA. När baslinjen väl är på plats är det manuella gransknings- och löpande övervakningssteget det som de flesta team underinvesterar i; Qualibooth och alternativen som nämns i steg 6 är den kategori att utvärdera då.