Vad är nytt i WCAG 2.2? De 9 nya kriterierna enkelt förklarade

Någon som använder tangentbordet tabbar sig igenom din kassa. Fokus hamnar på knappen ”Betala nu”, men en fast cookiebanner ligger ovanpå, så personen ser inte var hen är. Enligt WCAG 2.1 kunde den sidan fortfarande godkännas. Enligt WCAG 2.2 underkänns den.

Det är den sortens lucka som 2.2 täpper till. Nedan får varje nytt framgångskriterium samma genomgång: vad det säger, vem det hjälper, ett snabbtest och den vanliga lösningen. De fyra principerna och nivåerna på en och samma sida hittar du i vår referens för WCAG 2.2.

Vad är WCAG 2.2?

WCAG 2.2 är den aktuella versionen av Web Content Accessibility Guidelines, riktlinjerna för tillgängligt webbinnehåll, den W3C-standard som de flesta tillgänglighetslagar och avtal hänvisar till. Den blev W3C-rekommendation den 5 oktober 2023 (öppnas i en ny flik), uppdaterades den 12 december 2024 (öppnas i en ny flik) och godkändes som ISO/IEC 40500:2025 (öppnas i en ny flik) i oktober 2025.

WCAG består av testbara påståenden som kallas framgångskriterier, och varje kriterium har en nivå: A (miniminivån), AA (det lagar oftast kräver) eller AAA (den strängaste). ”Vi behöver WCAG 2.2 AA” betyder alla kriterier på nivå A och AA i version 2.2. Enligt specifikationen ”bygger 2.2 vidare på och är bakåtkompatibel med WCAG 2.1”, så den lägger till krav i stället för att ersätta 2.1.

Vad ändrades från WCAG 2.1 till 2.2?

WCAG 2.2 lägger till nio framgångskriterier och tar bort ett. Sex av de nya ligger på nivå A eller AA och räknas därför in i det vanliga AA-målet: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 och 3.3.8. De övriga tre är AAA. Det borttagna kriteriet är 4.1.1 Parsing, som W3C numera beskriver som föråldrat. Det finns ingen auktoriserad svensk översättning av WCAG 2.2, så vi använder kriteriernas engelska namn.

4.1.1 Parsing kontrollerade fel i koden, till exempel dubblerade id-attribut. W3C:s vanliga frågor om WCAG 2 (öppnas i en ny flik) förklarar att de problemen nu fångas av andra kriterier, till exempel 4.1.2 Namn, roll, värde. En hake: om ett avtal fortfarande kräver WCAG 2.0 eller 2.1 kan du ”behöva fortsätta att testa och rapportera 4.1.1”.

Focus Not Obscured och Focus Appearance: ser tangentbordsanvändare var de är?

De här kriterierna ser till att elementet med tangentbordsfokus syns. På nivå AA (2.4.11) får en fokuserad länk eller knapp inte vara helt dold av innehåll som du har lagt till, till exempel en fast sidhuvudsmeny, en cookiebanner eller en chattbubbla. På nivå AAA får ingenting täcka någon del av den (2.4.12), och fokusramen måste vara stor och ha tydlig kontrast (2.4.13).

• Vem det hjälper: seende personer som använder tangentbord i stället för mus, ofta på grund av en rörelsenedsättning. Ser de inte fokus får de gissa.
• Snabbtest: öppna en lång sida där cookiebannern, den fasta menyn och chattwidgeten syns samtidigt och tryck på Tab många gånger. Försvinner fokus helt bakom något är det ett fel mot 2.4.11.
• Vanlig lösning: lägg till CSS-egenskapen scroll-padding med samma höjd som ditt fasta sidhuvud eller din fasta sidfot, så att webbläsaren rullar fram fokuserade element i synfältet. W3C anger detta som en tillräcklig teknik (öppnas i en ny flik). En banner kan också godkännas om den är modal och måste stängas först.

Focus Appearance (2.4.13) kräver en fokusmarkering som är minst lika stor som en 2 CSS-pixlar tjock ram runt komponenten, med en kontrastförändring på minst 3:1 mellan fokuserat och ofokuserat läge. Kriteriet ligger på nivå AAA, men en heldragen ram på 2 pixlar i en stark färg räcker oftast. Vår guide om färgkontrast förklarar hur du mäter 3:1.

Dragging Movements och Target Size: går webbplatsen att använda utan precis pekning?

De här två kriterierna på nivå AA hjälper personer som har svårt med finmotorisk kontroll av pekaren. 2.5.7 säger att allt du kan göra genom att dra också måste fungera med enkla klick eller tryck. 2.5.8 säger att klickytor måste vara minst 24 × 24 CSS-pixlar, eller placerade så att en cirkel på 24 pixlar centrerad på varje yta inte nuddar någon annan yta.

2.5.7 Dragging Movements (dragrörelser)

Tänk på ett prisreglage i butikens filter eller en önskelista som du sorterar genom att dra. För någon med tremor, eller någon som styr med huvudet, kan tryck-håll-flytta-släpp vara mycket svårt.

Snabbtest: gör klart varje dragmoment med bara klick eller tryck. Vanlig lösning: låt användaren klicka var som helst på reglagets bana, lägg till fält för ”min” och ”max” bredvid, eller lägg till knapparna ”Flytta upp” och ”Flytta ned” i sorterbara listor. Stöd för tangentbord räcker inte ensamt: W3C:s förklarande dokument (öppnas i en ny flik) säger att tangentbordsalternativ ”inte automatiskt uppfyller det här framgångskriteriet”.

2.5.8 Target Size (Minimum) (klickytans storlek)

De vanliga felen är små ”×”-knappar på popup-fönster, tätt placerade sidnummer, betygsstjärnor och rader av ikoner för sociala medier. Att träffa fel är irriterande för alla och ett verkligt hinder för personer med nedsatt fingerfärdighet.

• Undantag: länkar inne i en mening, ytor som har en likvärdig kontroll någon annanstans på sidan som uppfyller storleken, kontroller vars storlek styrs av webbläsaren och som du inte har stylat om, och fall där en viss storlek är nödvändig eller lagstadgad.
• Snabbtest: prova varje liten ikon och knapp på mobilen; vill du mäta en av dem kan du inspektera den i webbläsarens utvecklarverktyg.
• Vanlig lösning: lägg till padding. Den klickbara ytan växer även om ikonen ser likadan ut. Se 24 pixlar som ett minimum: det äldre AAA-kriteriet 2.5.5 kräver 44 × 44.

Consistent Help och Redundant Entry: får folk leta eller upprepa sig?

Båda ligger på nivå A. 3.2.6 Consistent Help säger att om hjälp, till exempel kontaktuppgifter, en chatt eller en länk till vanliga frågor, finns på flera sidor ska den ligga i samma ordning i förhållande till resten av sidan varje gång. 3.3.7 Redundant Entry säger att användaren inte ska behöva skriva in uppgifter som hen redan har lämnat i samma process en gång till.

Consistent Help tvingar dig inte att erbjuda hjälp över huvud taget. Kriteriet säger bara att om telefonnumret sitter i sidhuvudet på produktsidorna ska det inte flytta ner till sidfoten i kassan, där folk behöver det mest. Personer med minnes- eller koncentrationssvårigheter har mest nytta av det. Lösningen är oftast en gemensam mall i stället för att placera hjälpen sida för sida.

Redundant Entry gäller formulär i flera steg. Ett bokningsformulär som frågar efter din e-postadress i steg 1 och igen i steg 3 underkänns, och det gör också en kassa som tvingar dig att skriva in en identisk fakturaadress. Fyll i fältet automatiskt eller låt användaren välja uppgiften, till exempel med kryssrutan ”Fakturaadressen är samma som leveransadressen”. Undantagen: när det är nödvändigt att skriva in uppgiften igen, när det krävs av säkerhetsskäl eller när den tidigare uppgiften inte längre gäller.

Accessible Authentication: går det att logga in utan minnestest?

Framgångskriterium 3.3.8 (nivå AA) säger att inget steg i inloggningen får bygga på ett kognitivt funktionstest, som att komma ihåg ett lösenord, skriva av förvrängda tecken eller lösa ett pussel, om du inte erbjuder ett alternativ eller något som hjälper. I praktiken: låt lösenordshanterare fylla i fälten, tillåt inklistring och erbjud en metod som inte hänger på minnet.

WCAG definierar ett kognitivt funktionstest som ”en uppgift som kräver att användaren minns, bearbetar eller skriver av information”. Att ange ditt namn, din e-postadress eller ditt telefonnummer räknas inte, eftersom de uppgifterna är personliga och desamma överallt. Ett inloggningssteg godkänns på nivå AA om det erbjuder minst ett av följande:

• Ett alternativ utan kognitivt test, till exempel en passkey eller en inloggningslänk via e-post.
• En mekanism som hjälper, till exempel stöd för lösenordshanterare, eller kopiera och klistra in så att en engångskod inte behöver skrivas av.
• Igenkänning av objekt, till exempel ”välj bilderna med en cykel”.
• Personligt innehåll, till exempel att känna igen en bild som du själv har laddat upp.

AAA-versionen, 3.3.9, stryker de två sista alternativen, så en bild-CAPTCHA kan godkännas på AA men inte på AAA. Typiska fel: lösenordsfält som blockerar inklistring eller lösenordshanterare, rutor för engångskoder som slutar fungera när du klistrar in, och en text-CAPTCHA utan alternativ. Personer med dyslexi eller nedsatt minne har störst nytta av kriteriet, men alla som blivit utelåsta efter en lång dag känner igen problemet.

Är WCAG 2.2 ett lagkrav?

Det beror på var du finns och vem du är. Lagar nämner sällan en WCAG-version direkt, och flera hänvisar fortfarande till WCAG 2.1 AA. Eftersom WCAG 2.2 är bakåtkompatibel uppfyller du också 2.1 AA när du uppfyller 2.2 AA, med undantag för det borttagna 4.1.1. Siktar du på 2.2 täcker du alltså båda. Anger ett avtal en viss version gäller avtalet.

• Europeiska unionen: enligt tillgänglighetsdirektivet (European Accessibility Act) presumeras överensstämmelse när du uppfyller den harmoniserade standarden EN 301 549. Enligt AccessibleEU (öppnas i en ny flik) bygger version 4.1.1, som publicerades i september 2026, på WCAG 2.2 men är ännu inte den rättsliga referensen; tills hänvisningen har offentliggjorts i EU:s officiella tidning gäller v3.2.1 (som bygger på WCAG 2.1 AA). Vår genomgång av tillgänglighetsdirektivet förklarar vem lagen gäller för.
• Storbritannien: regeringens vägledning (öppnas i en ny flik) säger att webbplatser och appar i offentlig sektor måste uppfylla WCAG 2.2 AA. Den vägledningen gäller offentliga organ, inte privata företag.
• USA: justitiedepartementets regel för delstater och kommuner använder WCAG 2.1 AA, och tidsfristerna flyttades i april 2026 (öppnas i en ny flik) till den 26 april 2027 och den 26 april 2028. För privata företag säger departementets vägledning från 2022 (öppnas i en ny flik) att ADA gäller deras webbplatser, men den anger ingen specifik teknisk standard.

Hur blir det med WCAG 3?

WCAG 3 är ett utkast, så ingen kan uppfylla den ännu. W3C publicerade uppdaterade utkast i september 2026 och skriver att WCAG 3 inte väntas bli en färdig standard ”på några år till”. WCAG 2 kommer inte att fasas ut förrän flera år efter det, så det är 2.2 du ska arbeta mot nu.

Hur kontrollerar du de nya kriterierna på 15 minuter?

De flesta fel mot de sex kriterierna på nivå A och AA hittar du på ungefär 15 minuter med ett tangentbord, en mobil och din egen inloggningssida. Det ersätter inte en fullständig granskning eller tester med personer med funktionsnedsättning, men det visar var du ska börja och ger en utvecklare en konkret lista att arbeta efter.

1. Tabba dig igenom startsidan, en produktsida och kassan med alla banners synliga. Ser du alltid fokus? (2.4.11)
2. Gör klart varje reglage och varje dra-och-släpp-moment med bara klick eller tryck. (2.5.7)
3. Prova varje stängknapp, sidnummer och liten ikon på mobilen. (2.5.8)
4. Jämför var hjälp och kontaktuppgifter syns på tre typer av sidor. (3.2.6)
5. Gå igenom ett köp eller en bokning och anteckna varje fråga som du svarar på två gånger. (3.3.7)
6. Logga in med en lösenordshanterare och klistra sedan in ett lösenord och en engångskod. Har varje CAPTCHA ett alternativ? (3.3.8)

För resten av WCAG går vår guide om hur du testar webbplatsens tillgänglighet igenom gratisverktyg och manuella kontroller, och vår checklista för webbtillgänglighet gör om de vanligaste felen till en att göra-lista. Det du inte kan åtgärda ännu hör hemma i din tillgänglighetsredogörelse.

Ett ord om widgetar, vår egen inräknad: inget av de här kriterierna kan uppfyllas med en panel som besökaren styr. En stor pekare gör det lättare att sikta på små ytor, men den gör dem inte 24 pixlar breda, och att markera fokus flyttar inte undan en fast banner. Varje nytt kriterium handlar om hur dina sidor är byggda, så lösningen finns i dina mallar och din kod.