WCAG 2.2 vs WCAG 2.1: Vad är nytt och vad du behöver uppdatera

Mer än 96% av alla startsidor misslyckas fortfarande med grundläggande WCAG-krav, enligt WebAIMs tillgänglighetsanalys för 2024 — och det är mot en standard som redan var fem år gammal. Den 5 oktober 2023 publicerade W3C WCAG 2.2 som en officiell webbstandard, vilket höjde ribban med nio nya framgångskriterier och avvecklade ett kriterium som blivit föråldrat. Om du ansvarar för en webbplats, bygger digitala produkter eller övervakar regelefterlevnad är den här uppdateringen inget du kan skjuta upp på obestämd tid. Regleringar i EU, Storbritannien och i allt högre grad amerikanska delstater är redan på väg att referera till WCAG 2.2 som sin måttstock.

En snabb historik: Från WCAG 2.1 till WCAG 2.2

Web Content Accessibility Guidelines har utvecklats stadigt sedan WCAG 2.0 lanserades i december 2008. WCAG 2.1 kom i juni 2018 och lade till 17 nya framgångskriterier med särskilt fokus på mobilanvändare och personer med nedsatt syn eller kognitiva funktionsnedsättningar. I fem år fungerade den som de facto-referens för efterlevnad av lagar som ADA, Section 508 och EU:s webbtillgänglighetsdirektiv.

WCAG 2.2 tar vid exakt där 2.1 slutade. W3C initierade den med det uttryckliga målet att fortsätta förbättra tillgänglighetsvägledningen för tre huvudgrupper: användare med kognitiva eller inlärningssvårigheter, användare med nedsatt syn och användare med funktionsnedsättningar på mobila enheter. Den här utvecklingslinjen är viktig eftersom den innebär att uppdateringen är evolutionär, inte revolutionerande — men den är ändå tillräckligt betydelsefull för att kräva åtgärder från din sida.

En av de viktigaste sakerna att förstå strukturellt är att WCAG 2.2 är fullt bakåtkompatibel med WCAG 2.1. Att uppfylla WCAG 2.2 innebär automatiskt att du också uppfyller WCAG 2.1 och WCAG 2.0. Om din organisation för närvarande följer WCAG 2.1 AA behöver du bara hantera de nya kriterier som införts i 2.2 — du börjar inte om från början. W3C rekommenderar också att även om WCAG 2.0 och 2.1 förblir giltiga rekommendationer, bör organisationer använda WCAG 2.2 för att maximera den framtida tillämpbarheten av sitt tillgänglighetsarbete.

WCAG 2.2 förväntas också i stor utsträckning bli den sista punktversionen i WCAG 2.x-familjen. Nästa huvudversion, WCAG 3.0, är något helt annat — en total omarbetning av hur tillgänglighetsriktlinjer struktureras. Det gör WCAG 2.2 till den definitiva slutpunkten för en utvecklingslinje som sträcker sig tillbaka till 2008, och den version du behöver få rätt nu.

Siffrorna: Vad som faktiskt ändrades

Låt oss vara precisa kring förändringens omfattning. WCAG 2.1 innehöll 78 framgångskriterier över tre efterlevnadsnivåer (A, AA och AAA). WCAG 2.2 lägger till nio nya framgångskriterier och tar bort ett — framgångskriterium 4.1.1 Parsing — vilket lämnar det totala antalet på 86 aktiva kriterier. Av dessa nio tillägg är två på nivå A, fyra på nivå AA och tre på nivå AAA.

För den stora majoriteten av organisationer som siktar på efterlevnad på nivå AA — nivån som refereras i de flesta lagar och regleringar — innebär den praktiska effekten sex nya kriterier att implementera. De tre tilläggen på nivå AAA betraktas som bästa praxis och rekommenderas ofta för offentlig sektor och vårdsammanhang, men de är inte ett hårt juridiskt krav i de flesta jurisdiktioner idag.

De nya kriterierna adresserar främst fyra problemområden som återkommande hade flaggats som underbetjänade av den befintliga standarden i tillgänglighetsgranskningar i verkliga miljöer: synlighet för tangentbordsfokus, touch- och pekarinteraktioner, kognitiv tillgänglighet och autentiseringshinder. Det här är inte teoretiska frågor. Det är den typen av hinder som regelbundet hindrar personer med funktionsnedsättningar från att slutföra vardagliga uppgifter som att logga in, fylla i ett formulär eller navigera på en sida med en klistrig header.

De nio nya framgångskriterierna förklarade

Här är en genomgång av varje nytt kriterium, vad det kräver och varför det spelar roll i praktiken. Kriterierna presenteras efter efterlevnadsnivå så att du kan prioritera ditt åtgärdsarbete.

Nivå A (Minimum — krävs för alla)

• 2.4.11 Focus Not Obscured (Minimum): När en UI-komponent får tangentbordsfokus får den inte vara helt dold av innehåll som skapats av utvecklaren. De vanligaste bovarna här är klistriga headers, flytande cookie-banners och livechatt-widgets som ligger ovanpå sidan. Om en användare som trycker på Tab hamnar på en knapp som är helt täckt av din klistriga navigationsrad bryter du mot det här kriteriet. Observera att delvis skymd är acceptabelt på nivå A — elementet får bara inte vara 100% dolt.
• 2.5.7 Dragging Movements: All funktionalitet som kräver en dragrörelse — tänk drag-and-drop-filuppladdningar, sorteringsbara listelement eller reglagekontroller — måste också kunna användas med en enda pekaråtgärd (som ett klick eller en tryckning) utan dragning. Detta är avgörande för användare med motoriska funktionsnedsättningar som inte pålitligt kan utföra kontrollerade dragrörelser. Kravet gäller innehåll som skapats av utvecklaren; inbyggda webbläsarbeteenden är undantagna.

Nivå AA (Krävs för standardefterlevnad)

• 2.4.12 Focus Not Obscured (Enhanced): En striktare version av 2.4.11. På nivå AA får ingen del av fokusindikatorn vara dold av innehåll som skapats av utvecklaren när ett element får tangentbordsfokus. Detta stänger kryphålet i versionen på nivå A och kräver att fokuserade element är fullt synliga — inte bara delvis.
• 2.5.8 Target Size (Minimum): Det klickbara eller tryckbara området för interaktiva element måste vara minst 24×24 CSS-pixlar, med specifika undantag för inline-textlänkar, element som styrs av användaragenten och fall där ett motsvarande 24×24-mål finns i närheten. Detta är en betydande förändring från WCAG 2.1, där en målstorlek på 44×44 pixlar endast rekommenderades på AAA-nivå. Nu är en miniminivå verkställbar på AA. Observera att även om 24×24 px är golvet, rekommenderar AAA-kriteriet (2.5.5) fortfarande 44×44 px, och det förblir guldstandarden för touchvänlig design.
• 3.2.6 Consistent Help: Om en webbplats tillhandahåller några hjälpmekanismer — kontaktuppgifter till en människa, självhjälpsverktyg, automatiserad chatt eller ett kontaktformulär — och dessa mekanismer förekommer på flera sidor, måste de visas på samma relativa position på dessa sidor. Användare som behöver hjälp, särskilt de med kognitiva funktionsnedsättningar, ska alltid kunna hitta den på samma plats utan att behöva leta.
• 3.3.7 Redundant Entry: Information som en användare redan har angett i ett tidigare steg i samma process måste antingen fyllas i automatiskt åt dem eller vara tillgänglig att välja, så att de inte behöver skriva in den igen. Tänk på flerstegskassor som frågar efter en faktureringsadress och sedan frågar igen efter en leveransadress — användare ska erbjudas ett sätt att kopiera det de redan angivit. Undantag är tillåtna när återinmatning av information är avgörande för säkerheten (som att bekräfta ett lösenord) eller när tidigare angivna uppgifter inte längre är giltiga.
• 3.3.8 Accessible Authentication (Minimum): Kognitiva funktionstester — såsom att lösa ett pussel, memorera ett lösenord eller skriva av tecken från en bild-CAPTCHA — får inte krävas som det enda sättet att autentisera sig. En alternativ metod måste finnas tillgänglig, eller en mekanism måste hjälpa användaren (till exempel att en lösenordshanterare tillåts, eller att kopiera-klistra in tillåts i lösenordsfältet). Det här kriteriet förbjuder inte CAPTCHAs helt, men kräver att de aldrig är det enda alternativet för användare som inte kan slutföra dem.

Nivå AAA (Förbättrad — rekommenderas men är inte obligatorisk för de flesta)

• 2.4.13 Focus Appearance: När tangentbordsfokusindikatorn är synlig måste den uppfylla specifika minimikrav för storlek och kontrast: fokusområdet måste vara minst lika stort som en 2 CSS-pixlar tjock kontur runt elementet, och det måste finnas en kontrast på minst 3:1 mellan fokuserat och ofokuserat läge. Detta kriterium var ursprungligen planerat för nivå AA men flyttades till AAA på grund av sin komplexitet. Det innebär att det för enbart AA-efterlevnad fortfarande inte finns någon normativt definierad minimistorlek för en fokusindikator — bara att en sådan måste vara synlig.
• 2.5.9 Dragging Movements (Enhanced): Vänta — det finns ingen 2.5.9 i den här versionen. Förbättringen av dragrörelser på AAA-nivå fångas upp i 3.3.9 nedan.
• 3.3.9 Accessible Authentication (Enhanced): En striktare version av 3.3.8. På nivå AAA är även objektigenkänning och tester med personligt innehåll (som ”klicka på alla trafikljus” eller ”välj foton från ditt konto”) förbjudna, inte bara de undantag som definieras på nivå AA. Endast två undantag återstår i stället för fyra.

Vad som togs bort: 4.1.1 Parsing

WCAG 2.2 tar bort ett framgångskriterium som funnits på plats sedan WCAG 2.0: 4.1.1 Parsing. Detta kriterium krävde ursprungligen att HTML skulle vara välformad, med kompletta start- och sluttaggar, korrekt nästning och inga duplicerade attribut. Avsikten var att säkerställa att webbläsare och hjälpmedel pålitligt kunde tolka markup och presentera innehåll korrekt för användare.

Borttagandet är inte kontroversiellt — det speglar en verklig förändring i den tekniska miljön. Sedan 2008 har webbläsare blivit oerhört bra på att hantera felaktig HTML på ett graciöst sätt, genom att följa en konsekvent, standardiserad felkorrigeringsalgoritm. Hjälpmedel som skärmläsare förlitar sig nu på webbläsarens Document Object Model (DOM), inte på rå HTML-källkod. W3C drog slutsatsen att kriteriet inte längre ger någon meningsfull tillgänglighetsnytta i dagens miljö. Tillgänglighetsproblem som tidigare fångades av 4.1.1 täcks fortfarande av mer specifika kriterier som 1.3.1 (Info and Relationships) och 4.1.2 (Name, Role, Value).

De praktiska konsekvenserna för ditt team: om dina automatiserade testverktyg har flaggat fel relaterade till 4.1.1 Parsing är dessa inte längre WCAG 2.2-problem. Du kan se en minskning av rapporterade fel enbart på grund av versionsuppgraderingen, inte för att något faktiskt åtgärdats. Med det sagt är det fortfarande en stark bästa praxis att skriva giltig, välstrukturerad HTML — det är bara inte längre ett efterlevnadskrav i sig.

Regulatoriska och juridiska konsekvenser

Att förstå de nya kriterierna är en sak. Att förstå vad de innebär för din juridiska exponering är en annan. Den korta slutsatsen är: WCAG 2.2 håller på att bli den gällande standarden i flera jurisdiktioner, och tidslinjen rör sig snabbare än många organisationer inser.

I Storbritannien är offentliga organ redan skyldiga att uppfylla WCAG 2.2 nivå AA enligt Public Sector Bodies Accessibility Regulations. I Europeiska unionen håller EN 301 549 — den tekniska standard som ligger till grund för European Accessibility Act — på att anta WCAG 2.2 som sin baslinje. Själva EAA har en tillsynsdeadline i juni 2025 för de flesta privata organisationer som erbjuder produkter och tjänster i EU. Flera amerikanska delstater, inklusive Colorado, har också uttryckt avsikt att uppdatera sina delstatliga tillgänglighetslagar från WCAG 2.1 till WCAG 2.2.

I USA refererar ADA Title II för närvarande till WCAG 2.1 AA som den tekniska standarden för statliga och lokala myndigheters webbplatser. Amerikanska domstolar har dock i allt högre grad hänvisat till WCAG 2.2 i tillgänglighetsmål, och utvecklingen är tydlig. Att vänta på ett formellt federalt mandat innan man agerar är en efterlevnadsstrategi som innebär växande juridisk risk, särskilt för e-handel, finansiella tjänster och vårdorganisationer som är attraktiva mål för tillgänglighetsrelaterade stämningar.

Även om din organisation ännu inte är juridiskt skyldig att följa WCAG 2.2 kommer det att säkerställa att du ligger före både förändrade regleringar och, viktigare, de verkliga tillgänglighetshinder som dina användare möter idag, om du uppfyller de nya framgångskriterierna förr snarare än senare.

Hur du granskar och uppdaterar din webbplats

Om du redan följer WCAG 2.1 AA är uppgraderingsvägen till WCAG 2.2 hanterbar. Här är en praktisk ram för hur du kan närma dig den.

Börja med en riktad granskning av de sex nya kriterierna på nivå AA. Det är dessa som har juridisk tyngd för de flesta organisationer. Fokusera särskilt på 2.4.11 och 2.4.12 (focus obscured), 2.5.8 (target size), 3.2.6 (consistent help), 3.3.7 (redundant entry) och 3.3.8 (accessible authentication). En skicklig tillgänglighetsingenjör kan vanligtvis granska dessa kriterier manuellt på några timmar för en webbplats med måttlig komplexitet.

Granska dina klistriga/fasta element först. Kriterierna för skymt fokus (2.4.11 och 2.4.12) bryts av några av de vanligaste UI-mönstren på webben — klistriga headers, flytande åtgärdsknappar, cookie-samtyckesrader och chatt-widgets. Gå igenom hela din webbplats med enbart Tab-tangenten och observera om något fokuserat element någonsin försvinner under ett fast lager. En CSS-åtgärd är vanligtvis enkel:

/* Förhindra att klistrig header täcker fokuserade element */
:focus {
  scroll-margin-top: 80px; /* matcha höjden på din klistriga header */
}

Granska alla interaktiva elements tryckmålstorlek. Detta är ofta en snabb vinst både vad gäller efterlevnad och användarupplevelse. Knappar, länkar, formulärkontroller och ikoner behöver alla minst 24×24 CSS-pixlar. Många designsystem överstiger redan denna tröskel, men små ikonknappar — stängningsikoner, knappar för delning i sociala medier och inline-åtgärdslänkar — är vanliga problem. Inspektera dina komponenter och lägg till padding eller justera dimensioner där det behövs.

Granska dina autentiseringsflöden noggrant. SC 3.3.8 (Accessible Authentication) har verklig tyngd. Om du använder en CAPTCHA som inte kan kringgås eller lösas via en alternativ metod är du sannolikt inte kompatibel. Utvärdera om dina inloggnings-, registrerings- och tvåfaktorsautentiseringsflöden tillåter lösenordshanterare att fylla i automatiskt, tillåter kopiera-klistra in, erbjuder en alternativ verifieringsmetod (som en magisk länk eller engångskod) eller ger någon annan anpassning för användare som inte kan slutföra ett kognitivt test.

Granska flerstegsformulär för redundant inmatning. Kartlägg alla processer som sträcker sig över flera steg — kassor, onboardingflöden, ansökningar — och identifiera varje tillfälle där en användare ombeds lämna information de redan har angett. Lägg till logik för autofyll eller en ”samma som ovan”-växel där det är relevant. Detta är vanligtvis en förändring i backend eller hantering av formulärstatus snarare än en komplex arkitektonisk ombyggnad.

Verifiera att hjälpmekanismer är konsekvent placerade. Om du har en chatt-widget, en hjälplänk eller ett telefonnummer som visas i en sidfot eller sidopanel på flera sidor, kontrollera att dess relativa position inte skiftar. Detta är vanligtvis ett mall- eller layoutproblem snarare än ett problem sida för sida — åtgärda det i ditt komponentbibliotek eller din CMS-mall så sprids det överallt.

Använd automatiserade verktyg för initial upptäckt, men stanna inte där. Automatiska skannrar kan upptäcka ungefär 40% av WCAG 2.2-problem — de är användbara för att fånga överträdelser av målstorlek och uppenbara fokusproblem, men de kan inte bedöma om en CAPTCHA är det enda autentiseringsalternativet eller om en hjälpmekanism är konsekvent placerad. Manuell testning, inklusive navigering enbart med tangentbord och testning med skärmläsare, är fortfarande avgörande. Testning med verkliga användare med funktionsnedsättningar kommer att upptäcka problem som inget automatiserat verktyg någonsin kommer att hitta.

WCAG 2.2 och overlay-widgets: Vad du bör veta

Tillgänglighets-overlays och SDK:er — verktyg som Accsible — kan ge meningsfull hjälp med att identifiera och åtgärda vissa kategorier av tillgänglighetsproblem, särskilt för användare som behöver justeringar i realtid som ökad teckenstorlek, kontraständringar eller förbättrad tangentbordsnavigering. Det är värt att ha en klar bild av vad overlays kan och inte kan göra i samband med WCAG 2.2-efterlevnad.

Overlays kan hjälpa till att hantera vissa problem med fokus-synlighet, tillhandahålla alternativa navigeringslägen och erbjuda användarsidig anpassning som kompenserar för vissa brister på designnivå. De är ett användbart lager i tillgänglighetsstacken, särskilt för team som behöver förbättra användarupplevelsen snabbt medan mer långsiktigt åtgärdsarbete pågår. Men de är inte en ersättning för att åtgärda den underliggande koden. De nya WCAG 2.2-kriterierna — särskilt kring autentisering (3.3.8), redundant inmatning (3.3.7) och dragrörelser (2.5.7) — kräver strukturella förändringar i hur din applikation är byggd, inte bara hur den presenteras.

Det mest effektiva angreppssättet kombinerar en väl implementerad overlay för användarorienterad anpassningsbarhet med korrekta kodnivåfixar för de nya 2.2-kriterierna. Tänk på en overlay-SDK som en kraftmultiplikator: den utökar din räckvidd, förbättrar upplevelsen för fler användare och fyller luckor — men grunden måste fortfarande vara solid.

Viktigaste slutsatserna

• WCAG 2.2 lägger till nio nya framgångskriterier och tar bort en föråldrad regel (4.1.1 Parsing). Den är fullt bakåtkompatibel med 2.1, så ditt befintliga efterlevnadsarbete är inte bortkastat — du behöver bara lägga till det som är nytt.
• För efterlevnad på nivå AA, fokusera på sex specifika nya kriterier: Focus Not Obscured (2.4.11 och 2.4.12), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) och Accessible Authentication (3.3.8). Det är dessa som är juridiskt relevanta för de flesta organisationer.
• Regulatoriskt införande accelererar. Den offentliga sektorn i Storbritannien tillämpar redan WCAG 2.2, EU övergår till den under European Accessibility Act, och amerikanska domstolar hänvisar i allt högre grad till den. Vänta inte på ett formellt mandat i din jurisdiktion innan du agerar.
• Automatiserade verktyg fångar bara omkring 40% av WCAG 2.2-problem — manuell testning, genomgångar med enbart tangentbordsnavigering och testning med verkliga användare är avgörande för att uppnå genuin efterlevnad, särskilt för de nya kriterierna kring autentisering och kognitiv tillgänglighet.
• De vanligaste snabba vinsterna är att fixa klistriga headers som skymmer fokuserade element, förstora små tryckmål och granska dina inloggnings-/autentiseringsflöden för beroende av CAPTCHA. Dessa förändringar är ofta relativt enkla men har stor effekt — en bra startpunkt för din WCAG 2.2-åtgärdssprint.