WCAG 2.2: Komplett guide till de 9 nya framgångskriterierna

10/13/2025

15 min read

A11yied Team

Två år efter lanseringen i oktober 2023 har WCAG 2.2 blivit standarden för efterlevnad av webbtillgänglighet—särskilt efter European Accessibility Act (EAA) tidsfrist i juni 2025. Om du fortfarande arbetar med WCAG 2.1 är det dags att uppgradera.

Denna omfattande guide förklarar alla 9 nya framgångskriterier som introducerades i WCAG 2.2, vem de hjälper och hur man implementerar dem korrekt. Oavsett om du är en utvecklare som fixar fokusstilar eller en produktchef som planerar efterlevnadsarbete, kommer du att lämna med handlingsbar kunskap för att göra dina digitala produkter mer tillgängliga.

Vad förändrades i WCAG 2.2?

WCAG 2.2 bygger på version 2.1 genom att lägga till 9 nya framgångskriterier fokuserade på tre nyckelområden:

Fokussynlighet - Göra tangentbordsnavigering tydligare
Mobiltillgänglighet - Förbättra storleken på pekområden och dra-interaktioner
Kognitiv tillgänglighet - Minska minnesbördan och autentiseringsfriktionen

WCAG 2.1 vs 2.2: Snabb jämförelse

Aspekt	WCAG 2.1	WCAG 2.2
Lanseringsdatum	Juni 2018	Oktober 2023
Totalt antal framgångskriterier	78	87
Nya kriterier	17 (vs 2.0)	9 (vs 2.1)
Fokusområden	Mobil, nedsatt syn, kognitiv	Fokusutseende, autentisering, mobilgester
Nivå A-kriterier	30	32
Nivå AA-kriterier	20	24
Nivå AAA-kriterier	28	31
Borttagna kriterier	0	1 (4.1.1 Parsing - föråldrad)

Viktig slutsats: WCAG 2.2 ersätter inte 2.1—den utökar den. Alla WCAG 2.1-krav gäller fortfarande.

De 9 nya framgångskriterierna förklarade

Förbättringar av fokussynlighet (3 kriterier)

2.4.11 Fokusutseende (Minimum) - Nivå AA

Vad det kräver: När en UI-komponent får tangentbordsfokus måste fokusindikatorn vara synlig och uppfylla specifika storlek- och kontrastkrav:

Minsta area: Minst lika stor som en 2 CSS-pixel tjock omkrets runt komponenten
Kontrastförhållande: Minst 3:1 mot angränsande färger
Tydliga förändringar: Det fokuserade tillståndet måste se märkbart annorlunda ut från det ofokuserade tillståndet

Vem som gynnas:

Tangentbordsanvändare som inte kan använda mus på grund av motoriska funktionsnedsättningar
Avancerade användare som föredrar tangentbordsnavigering för effektivitet
Användare av skärmförstorare som behöver tydliga visuella signaler om fokusets placering

Vanliga överträdelser:

<!-- ❌ Dåligt: Fokusindikator för subtil -->
<button style="outline: 1px dotted #ccc;">
  Submit
</button>

<!-- ❌ Dåligt: Fokusindikator helt borttagen -->
<a href="/page" style="outline: none;">
  Read more
</a>

<!-- ✅ Bra: Tydlig fokusindikator med hög kontrast -->
<button style="outline: 2px solid #0066cc; outline-offset: 2px;">
  Submit
</button>

Verklig påverkan: En studie av WebAIM fann att 68% av tangentbordsanvändare har svårt med webbplatser som har dåliga fokusindikatorer. Detta kriterium gör tangentbordsnavigering möjlig för miljontals användare.

2.4.12 Fokus inte dolt (Minimum) - Nivå AA

Vad det kräver: När en UI-komponent får tangentbordsfokus får den inte vara helt gömd av annat innehåll. Åtminstone en del av det fokuserade elementet måste förbli synligt.

Vem som gynnas:

Tangentbordsanvändare som behöver se var fokus finns
Användare med kognitiva funktionsnedsättningar som kan tappa bort fokus om det försvinner
Användare av skärmförstorare som navigerar genom gränssnitt

Vanliga scenarion:

Fasta rubriker som täcker fokuserade element vid scrollning
Modala dialoger som inte fångar fokus korrekt
Fasta navigeringsfält som överlappar formulärfält
Cookie-medgivande-banners som döljer fokuserat innehåll

Problemet: Föreställ dig att tabbas genom ett formulär, bara för att se ditt fokus försvinna bakom en fast rubrik. Du vet att fokus flyttades—men vart? Detta skapar förvirring och bryter navigeringsflödet.

Lösningen: Implementera scroll-into-view-beteende när element får fokus, för att säkerställa att de alltid är synliga över fasta UI-element.

2.4.13 Fokusutseende (Förbättrat) - Nivå AAA

Vad det kräver: En strängare version av 2.4.11 med högre standarder:

Minsta area: Minst 2 CSS-pixlar tjock runt hela komponentens omkrets
Kontrastförhållande: Minst 4.5:1 (matchar textkontrastkrav)
Inga undantag: Gäller alla interaktiva element utan undantag

Vem som gynnas: Användare med nedsatt syn som behöver maximal visuell tydlighet för att uppfatta fokusindikatorer.

När att implementera: Om du bygger regeringssystem, hälsovårdsapplikationer eller produkter specifikt utformade för tillgänglighet, sikta på denna AAA-standard. Även om det inte krävs för de flesta efterlevnadsarbeten, representerar det bästa praxis.

Mobil- och motortillgänglighet (2 kriterier)

2.5.7 Dra-rörelser - Nivå AA

Vad det kräver: All funktionalitet som använder dra-rörelser måste också kunna uppnås genom enkla pekåtgärder (som att klicka eller trycka) utan att kräva dragning.

Vem som gynnas:

Användare med skakningar eller begränsad finmotorik som inte kan utföra precis dragning
Mobilanvändare med handfunktionsnedsättningar
Användare av hjälpmedel med alternativa inmatningsenheter

Påverkade interaktioner:

Dra-och-släpp filuppladdningar → Tillhandahåll en "Bläddra filer"-knapp
Sorterbara listor → Tillhandahåll upp/ner-pilknappar
Intervallskjutreglage → Tillhandahåll nummerinmatning eller +/- knappar
Bildbeskärare → Tillhandahåll förinställda beskärningsförhållanden eller koordinatinmatningar

Exempelscenarier:

<!-- ❌ Dåligt: Endast dra-och-släpp tillgängligt -->
<div class="dropzone">
  Drag files here to upload
</div>

<!-- ✅ Bra: Dra-och-släpp PLUS alternativ -->
<div class="dropzone">
  Drag files here to upload
</div>
<button type="button">Or browse files</button>

<!-- ✅ Bra: Skjutreglage med alternativ inmatning -->
<div>
  <input type="range" min="0" max="100" value="50" aria-label="Volume">
  <input type="number" min="0" max="100" value="50" aria-label="Volume (numeric)">
</div>

Viktigt undantag: Om dragning är väsentligt för funktionaliteten (som en rit- eller signaturapplikation), gäller inte detta kriterium—men överväg om det finns något sätt att tillhandahålla alternativ.

2.5.8 Pekområdesstorlek (Minimum) - Nivå AA

Vad det kräver: Interaktiva element måste vara minst 24×24 CSS-pixlar, vilket säkerställer att de är tillräckligt stora för att aktiveras utan att av misstag träffa angränsande mål.

Vem som gynnas:

Användare med motoriska funktionsnedsättningar som har svårt med precisa rörelser
Mobilanvändare som trycker med fingrar på små skärmar
Äldre vuxna med minskad fingerfärdighet
Alla som använder en enhet i rörelse (går, åker kollektivtrafik)

Undantag (du behöver inte 24×24 pixlar om):

Avstånd: Målet är mindre men har tillräckligt avstånd (24px) från andra mål
Inline: Målet är i en mening eller textblock
Användaragentkontrollerat: Webbläsaren kontrollerar storleken (som standardformulär)
Väsentligt: En viss storlek krävs juridiskt eller funktionellt

Vanliga överträdelser:

Sociala medier-ikoner under 24×24px
Pagineringslänkar med små klickområden
Stängningsknappar på modaler
Ikoner-endast-knappar utan tillräcklig utfyllnad

Snabb granskning: Använd webbläsarens utvecklarverktyg för att mäta interaktiva element. Om du ser width: 20px; height: 20px; på en knapp, är du under tröskeln.

Kognitiv tillgänglighet och inmatning (4 kriterier)

3.2.6 Konsekvent hjälp - Nivå A

Vad det kräver: Om hjälpmekanismer förekommer på flera sidor måste de vara i samma relativa ordning på varje sida.

Exempel på hjälpmekanismer:

Kontaktinformation (telefon, e-post, adress)
Live-chattwidgetar
Självhjälpsalternativ (FAQ-länkar)
Kontaktformulär

Vem som gynnas:

Användare med kognitiva funktionsnedsättningar som förlitar sig på förutsägbara mönster
Användare med minnesnedsättningar som har svårt att komma ihåg var hjälpen finns
Alla i en stressig situation som behöver snabb tillgång till support

Problemet: Föreställ dig att leta efter kundtjänstkontaktinfo. På startsidan finns den i sidfoten. På produktsidan finns den i rubriken. På kassasidan finns den i en sidopanel. Denna inkonsekvens skapar onödig kognitiv belastning.

Lösningen: Välj en plats och håll dig till den. Om din sidfot har "Kontakta oss → FAQ → Live chatt" på en sida, behåll exakt den ordningen genom hela webbplatsen.

Viktig notering: Detta betyder inte att hjälp måste visas på varje sida—endast att när den visas, är den konsekvent placerad.

3.3.7 Redundant inmatning - Nivå A

Vad det kräver: Information som tidigare matats in av användaren i samma process måste antingen auto-fyllas eller vara tillgänglig för val—användare ska inte behöva mata in samma information två gånger.

Vem som gynnas:

Användare med kognitiva funktionsnedsättningar som har svårt att komma ihåg tidigare inmatad information
Användare med motoriska funktionsnedsättningar för vilka skrivning är fysiskt ansträngande
Mobilanvändare som hanterar små tangentbord

Vanliga scenarier:

Frakt- och faktureringsadresser som är identiska
E-postbekräftelsefält
Flerstegsformulär som frågar efter samma data
Betalningsinformation över kassaksteg

Acceptabla lösningar:

Auto-ifyllning: Fyll i fält automatiskt med tidigare inmatad data
Val: Låt användare välja från tidigare inmatade alternativ (kryssrutor som "Samma som fraktadress")
Sessionspersistens: Kom ihåg data över formulärsteg

Undantag: Du kan fråga efter samma information två gånger om:

Det är väsentligt för säkerhet (lösenordsbekräftelse)
Tidigare information är inte längre giltig
Återinmatning bekräftar användarens avsikt

Exempel i praktiken: E-handelskasstflöden bör erbjuda kryssrutor för "Använd fraktadress för fakturering" snarare än att tvinga användare att skriva adresser två gånger.

3.3.8 Tillgänglig autentisering (Minimum) - Nivå AA

Vad det kräver: Autentiseringsprocesser får inte kräva att användare löser kognitiva funktionstester (som att memorera lösenord eller lösa pussel) om inte ett alternativ tillhandahålls.

Acceptabla autentiseringsmetoder:

Lösenordshanterare (låt användare klistra in lösenord)
E-post/SMS-verifieringskoder som användaren kan kopiera från en annan applikation
Biometrisk autentisering (fingeravtryck, Face ID)
Personlig information tillgänglig för användaren (användarnamn, e-postadress)
Objektigenkänning (välj objekt från ett personligt bildbibliotek)

Oacceptabelt utan alternativ:

Memorera lösenord utan inklistringsfunktionalitet
Transkribera tecken från bilder (förvrängda CAPTCHAs)
Komma ihåg och skriva säkerhetsfrågor från minnet

Vem som gynnas:

Användare med kognitiva funktionsnedsättningar som har svårt med minnesuppgifter
Användare med dyslexi som har svårt att transkribera text
Användare med intellektuella funktionsnedsättningar som tycker pussel är utmanande

CAPTCHA-problemet: Traditionella förvrängda text-CAPTCHAs misslyckas med detta kriterium. Acceptabla alternativ inkluderar:

reCAPTCHA v3 (osynlig beteendeanalys)
hCaptcha Accessibility-cookie (kringgår utmaningar för verifierade användare)
Enhetsbaserad autentisering
E-postverifieringslänkar

Kodövervägande:

<!-- ❌ Dåligt: Lösenordsfält som blockerar inklistring -->
<input
  type="password"
  onpaste="return false;"
  autocomplete="off"
>

<!-- ✅ Bra: Tillåt inklistring och autokomplettering -->
<input
  type="password"
  autocomplete="current-password"
>

Verklig påverkan: Många användare förlitar sig på lösenordshanterare på grund av minnesnedsättningar. Att blockera inklistringsfunktionalitet skapar en oöverstiglig barriär för dessa användare.

3.3.9 Tillgänglig autentisering (Förbättrat) - Nivå AAA

Vad det kräver: En strängare version av 3.3.8 som helt eliminerar kognitiva funktionstester, även för objektigenkänningsuppgifter.

Skillnaden från 3.3.8: På nivå AA kan du använda objektigenkänning (som "välj alla bilder som innehåller trafikljus"). På nivå AAA är inte ens detta tillåtet om inte objekten tillhandahålls av användaren själv.

Acceptabelt på AAA-nivå:

Lösenordslös autentisering (magiska länkar via e-post)
Endast biometrisk autentisering
Hårdvarusäkerhetsnycklar (YubiKey, etc.)
Autentiseringsappar (Google Authenticator, Authy) som användaren väljer

Vem som gynnas: Användare med allvarliga kognitiva funktionsnedsättningar som inte kan slutföra någon form av kognitiv utmaning.

När att implementera: Hälsovårdsapplikationer, regeringstjänster och finansiella system som betjänar sårbara befolkningar bör överväga denna standard.

Hur A11yied testar WCAG 2.2-kriterier

A11yieds webbläsarbaserade valideringsmotor implementerar automatiserade kontroller för de testbara WCAG 2.2-kriterierna:

Automatisk detektering

2.4.11 Fokusutseende (Minimum):

Mäter faktiska fokusindikatorsdimensioner med hjälp av webbläsarens beräknade stilar
Beräknar kontrastförhållanden mellan fokustillstånd och angränsande färger
Validerar att konturens tjocklek uppfyller 2px minimum
Rapporterar specifika kontrastvärden i fynd

2.5.8 Pekområdesstorlek (Minimum):

Mäter interaktiva elements avgränsningsrutor i verklig webbläsarkontext
Beräknar avstånd mellan angränsande klickbara mål
Identifierar element under 24×24px-tröskeln
Ta hänsyn till undantag (inline-textlänkar, avståndregler)

3.2.6 Konsekvent hjälp:

Skannar flera sidor för att identifiera hjälpmekanismer
Jämför relativ ordning av hjälpelement över sidor
Flaggar inkonsekvenser i hjälpplacering
Validerar krav på samma ordning över webbplatsen

3.3.7 Redundant inmatning:

Analyserar flerstegsformulär för upprepade inmatningsförfrågningar
Kontrollerar autokompletera-attribut på formulärfält
Validerar auto-ifyllningsmekanismer
Flaggar dubbletter av informationsförfrågningar

3.3.8 Tillgänglig autentisering:

Upptäcker lösenordsfält med inklistring inaktiverad
Kontrollerar saknade autokompletera-attribut
Identifierar traditionella CAPTCHA-implementeringar
Validerar att alternativa autentiseringsvägar finns

Manuell granskningsvägledning

Vissa kriterier kräver mänsklig bedömning:

2.4.12 Fokus inte dolt: A11yied flaggar fast-positionerade element som kan dölja fokus men kräver manuell tangentbordstestning för att bekräfta faktiska döljanscenarier.

2.4.13 Fokusutseende (Förbättrat): Automatiserade kontroller för förbättrad 4.5:1-kontrast med rekommendationer för manuell verifiering.

2.5.7 Dra-rörelser: Identifierar dra-interaktioner genom händelselyssnare men kräver manuell bekräftelse att alternativ finns.

3.3.9 Tillgänglig autentisering (Förbättrat): Flaggar autentiseringsmönster som kräver kognitiva tester med rekommendationer för lösenordslösa alternativ.

Migreringsguide: Flytta från WCAG 2.1 till 2.2

Steg 1: Granska nuvarande tillstånd (Vecka 1)

Kör en A11yied-skanning för att identifiera befintliga överträdelser mot WCAG 2.2-kriterier. Fokusera på:

Fokusindikatorer: Kontrollera varje interaktivt element
Pekområden: Mät knappar, länkar och kontroller
Formulär: Granska flerstegsprocesser för redundant inmatning
Autentisering: Testa inloggnings- och registreringsflöden

Förväntade fynd: De flesta webbplatser kommer att ha problem med fokusutseende och pekområdesstorlek.

Steg 2: Prioritera efter påverkan (Vecka 1-2)

Hög prioritet (påverkar daglig användarupplevelse):

2.5.8 Pekområdesstorlek (Minimum) - AA
2.4.11 Fokusutseende (Minimum) - AA
3.3.7 Redundant inmatning - A

Medel prioritet (kräver kodändringar):

2.5.7 Dra-rörelser - AA
3.3.8 Tillgänglig autentisering - AA
2.4.12 Fokus inte dolt - AA

Lägre prioritet (ofta redan efterlevd):

3.2.6 Konsekvent hjälp - A (många webbplatser gör redan detta)

Ambitionellt (AAA-kriterier):

2.4.13 Fokusutseende (Förbättrat)
3.3.9 Tillgänglig autentisering (Förbättrat)

Steg 3: Implementera ändringar (Veckor 2-6)

Snabba vinster (1-2 veckor):

Uppdatera global CSS för fokusstilar:

/* Add to your base stylesheet */
*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Öka minimistorlekar för knappar:

/* Update button base styles */
button, .btn {
  min-height: 44px;
  min-width: 44px;
  padding: 8px 16px;
}

Medelinsats (2-3 veckor):

Lägg till alternativa inmatningar för dra-interaktioner
Implementera scroll-into-view för fokushantering
Lägg till autokompletera-attribut till formulär
Ta bort inklistringsblockeringar på lösenordsfält

Större omarbetningar (3-6 veckor):

Omdesigna autentiseringsflöden
Konsolidera hjälpmekanismers platser
Implementera sessionsbaserad formulärpersistens
Uppdatera komponentbibliotek med nya standarder

Steg 4: Kontinuerlig övervakning

Integrera A11yied i CI/CD: Fånga regressioner innan de når produktion. Sätt upp automatiserade skanningar på pull requests för att säkerställa att ny kod upprätthåller WCAG 2.2-efterlevnad.

Kvartalsvisa granskningar: Kör omfattande skanningar varje kvartal för att fånga problem som introducerats av nya funktioner.

Utbildning: Utbilda ditt team om de nya kriterierna så att efterlevnad blir en del av din utvecklingskultur, inte en eftertanke.

Vanliga migreringutmaningar

Utmaning 1: Fokusstilar bryter designsystemet

Problem: Designteam motstår framträdande fokusindikatorer och hävdar att de är "fula" eller "inkonsekventa med varumärket."

Lösning:

Visa designers exempel från stora varumärken (Google, Microsoft, Apple) som använder tydliga fokusstilar
Demonstrera att 3:1-kontrast tillåter varumärkesfärger—kräver bara genomtänkt implementering
Använd outline-offset för att skapa utrymme mellan kontur och element
Överväg :focus-visible för att visa konturer endast för tangentbordsanvändare

Utmaning 2: Små pekområden i täta UI:n

Problem: Datatabeller, kalendrar och mobilnavigering har många små interaktiva element.

Lösning:

Använd avståndsundantaget: mindre element med 24px mellanrum är efterlevda
Överväg responsiv design: mindre på skrivbord, större på mobil
Utvärdera om alla element behöver vara interaktiva (visa kanske detaljer vid radklick, inte cellklick)

Utmaning 3: Dra-och-släpp-komponenter

Problem: Befintliga sorterbara listor och filuppladdare stöder endast dragning.

Lösning:

Lägg till tangentbordskontroller (piltangenter + modifierare för omordning)
Tillhandahåll "Flytta upp/ner"-knappar för mus- och touchanvändare
För filuppladdningar, inkludera alltid en traditionell filindataknapp

Utmaning 4: Autentiseringssystem

Problem: Tredjepartsautentiseringsleverantörer kanske inte uppfyller 3.3.8-standarder.

Lösning:

Prioritera leverantörer med lösenordslösa alternativ (magiska e-postlänkar)
Aktivera OAuth/SSO (Google, Microsoft, Apple) som alternativ
Om du använder CAPTCHA, implementera hCaptcha Accessibility eller reCAPTCHA v3
Säkerställ att lösenordsfält tillåter inklistring och har korrekt autokomplettering

Vanliga frågor

Måste jag efterleva WCAG 2.2 omedelbart?

I Europa: Ja. European Accessibility Act (EAA) kräver WCAG 2.2 Nivå AA-efterlevnad från och med juni 2025.

I USA: Section 508 refererar fortfarande till WCAG 2.0, men bästa praxis är att implementera 2.2. ADA specificerar inte en WCAG-version, men domstolar förväntar sig alltmer nuvarande standarder.

Globalt: WCAG 2.2 är den internationellt erkända standarden. De flesta tillgänglighetsprofessionella granskar nu mot 2.2.

Kan jag göra anspråk på WCAG 2.1-efterlevnad istället?

Tekniskt ja, men det rekommenderas inte. WCAG 2.2 bygger på 2.1, och de nya kriterierna adresserar kritiska tillgänglighetsbarriärer. Att stanna på 2.1 betyder att ignorera kända problem som påverkar verkliga användare.

Är WCAG 2.1 och 2.2 ömsesidigt uteslutande?

Nej—WCAG 2.2 är helt bakåtkompatibel. Om du efterlever WCAG 2.2, efterlever du automatiskt WCAG 2.1. Att efterleva 2.1 betyder dock inte att du efterlever 2.2.

Vad hände med WCAG 2.1-kriteriet 4.1.1 Parsing?

Det togs bort i WCAG 2.2 eftersom moderna webbläsare hanterar HTML-parsningsfel elegant. Ogiltig HTML är inte längre en efterlevnadsbarriär, även om giltig HTML fortfarande är bästa praxis.

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

För de flesta organisationer:

Små webbplatser (< 50 sidor): 2-4 veckor
Medelstora webbplatser (50-200 sidor): 4-8 veckor
Stora webbplatser (200+ sidor): 8-16 veckor
Komplexa applikationer: 3-6 månader

Tidslinjer beror starkt på befintlig teknisk skuld och teamets förtrogenhet med tillgänglighet.

Måste jag testa varje kriterium manuellt?

Nej. A11yied automatiserar testning för de flesta kriterier, men vissa kräver manuell verifiering:

2.4.12 Fokus inte dolt behöver tangentbordstestning
2.5.7 Dra-rörelser behöver interaktionstestning
Kognitiva kriterier behöver användarflödesanalys

Kombinera automatiserade A11yied-skanningar med riktad manuell testning för bästa resultat.

Vad händer med WCAG 3.0?

WCAG 3.0 (tidigare kallad Silver) är fortfarande i utkast och förväntas inte bli en rekommendation förrän 2026 eller senare. Fokusera på WCAG 2.2-efterlevnad nu—det kommer att förbli standarden i många år framöver.

Hur påverkar AAA-kriterier efterlevnaden?

Nivå AAA-kriterier (2.4.13, 3.3.9) krävs inte för allmän WCAG 2.2 AA-efterlevnad. De representerar dock bästa praxis och kan krävas för:

Regeringswebbplatser i vissa jurisdiktioner
Hälsovårdsapplikationer
Utbildningsinstitutioner
Organisationer med specifika tillgänglighetsåtaganden

Starta din WCAG 2.2-efterlevnadsresa

WCAG 2.2 representerar meningsfulla framsteg mot en mer tillgänglig webb. De 9 nya framgångskriterierna adresserar verkliga barriärer som användare med funktionsnedsättningar möter varje dag—från otydliga fokusindikatorer till otillgängliga autentiseringsflöden.

Agera idag:

Granska din webbplats: Kör en omfattande A11yied-skanning för att identifiera WCAG 2.2-överträdelser
Fixa snabba vinster: Uppdatera fokusstilar och pekområdesstorlekar i din globala CSS
Planera migreringar: Prioritera förbättringar av autentisering och formulär
Utbilda ditt team: Dela denna guide med designers, utvecklare och produktchefer

A11yied gör WCAG 2.2-efterlevnad uppnåelig genom att tillhandahålla specifik, handlingsbar vägledning för varje kriterium. Vår webbläsarbaserade validering fångar problem som statiska analysatorer missar, vilket ger dig förtroende för att dina fixar faktiskt fungerar.

Redo att säkerställa att din webbplats uppfyller WCAG 2.2-standarder? Starta din gratis A11yied-skanning idag och få en omfattande rapport som visar exakt vilka kriterier som behöver uppmärksamhet—komplett med kodexempel och fixrekommendationer.

Senast uppdaterad: Oktober 2025. Skriven av A11yied-teamet baserat på den officiella WCAG 2.2-rekommendationen publicerad den 5 oktober 2023 av W3C.

Tillbaka till bloggen