Standarder · WCAG 2.2
WCAG 2.2-framgångskriterier
Alla 86 framgångskriterier i WCAG 2.2 — 31 på nivå A, 24 på AA, 31 på AAA. 9 tillkom i 2.2; 17 i 2.1; 60 förs över från 2.0. Varje post har en sammanfattning i klarspråk, råd för att uppfylla kriteriet och de fel vi oftast ser i granskningar i produktion.
1. Möjlig att uppfatta
Information och gränssnittskomponenter måste presenteras för användarna på sätt som de kan uppfatta.
- 1.1.1 A
Innehåll utan text
Varje bild, ikon, diagram, ljudfil och annat innehåll utan text måste ha ett textalternativ som fyller samma syfte — så att skärmläsare, punktskrift och kontaktbrytare ger samma information som seende användare får.
- 1.2.1 A
Enbart ljud och enbart video (förinspelat)
Förinspelat ljud behöver ett texttranskript. Förinspelad tyst video behöver antingen en textbeskrivning eller ett ljudspår som förmedlar samma information — så att användare som inte kan höra eller se ändå får ta del av innehållet.
- 1.2.2 A
Undertexter (förinspelat)
Varje förinspelad video med ljud behöver synkroniserade undertexter som täcker dialog, talaridentifiering och meningsfulla icke-verbala ljud — så att döva och hörselskadade användare får samma information från ljudspåret som alla andra.
- 1.2.3 A
Syntolkning eller mediaalternativ (förinspelat)
Förinspelad video behöver antingen ett syntolkningsspår eller ett fullständigt textalternativ för visuell information som inte förmedlas av ljudspåret — så att blinda användare får samma innehåll som seende tittare.
- 1.2.4 AA
Undertexter (direktsänt)
Direktsänt ljud i synkroniserade media — webbseminarier, liveströmmar, virtuella evenemang — måste ha realtidsundertexter. Automatiska undertexter kan räcka om noggrannheten är tillräckligt hög, men professionell CART-textning är det säkra valet.
- 1.2.5 AA
Syntolkning (förinspelat)
Förinspelad video behöver ett syntolkningsspår som berättar viktig visuell information under naturliga pauser i dialogen. På AA-nivå räcker ett texttranskript ensamt inte längre — beskrivningen måste vara i ljudform.
- 1.2.6 AAA
Teckenspråk (förinspelat)
Förinspelat ljud i synkroniserade media får en teckenspråkstolkning. Undertexter är inget substitut — många döva användare har teckenspråk som förstaspråk och skriftspråket som andraspråk.
- 1.2.7 AAA
Utökad syntolkning (förinspelat)
När pauser i dialogen inte är tillräckligt långa för en vanlig syntolkning måste videon pausas för att låta den utökade beskrivningen spelas upp — så att blinda användare får full visuell kontext även i tätt, snabbt innehåll.
- 1.2.8 AAA
Mediealternativ (förinspelat)
Förinspelat synkroniserat media — och förinspelat enbart video — behöver ett fullständigt textalternativ som förmedlar all samma information. Det går längre än undertexter och syntolkning: ett komplett fristående dokument.
- 1.2.9 AAA
Enbart ljud (direktsänt)
Direktsänt innehåll med enbart ljud — radioströmmar, ljudkonferenser, livepoddar — behöver ett realtidstextalternativ, till exempel direkttextning, så att döva och hörselnedsatta användare får innehållet i realtid.
- 1.3.1 A
Information och relationer
Information och relationer som förmedlas visuellt — rubriker, listor, tabeller, formuläretiketter, grupperingar — måste också uttryckas i koden, så att hjälpmedelsteknik kan återge dem. Visuell stil räcker inte.
- 1.3.2 A
Meningsfull ordningsföljd
När läsordningen spelar roll för förståelsen måste DOM-ordningen matcha den visuella ordningen. CSS-positionering och float som rör om i sekvensen bryter skärmläsare och tangentbordsnavigering.
- 1.3.3 A
Sensoriska egenskaper
Instruktioner får inte enbart förlita sig på form, storlek, placering, orientering, ljud eller färg. "Klicka på den gröna knappen till höger" utesluter användare som inte kan se layouten eller skilja på färger.
- 1.3.4 AA
Orientering
Innehåll får inte låsas till en enda orientering — stående eller liggande — om inte den orienteringen är nödvändig. Användare monterade i en rullstol eller som håller telefonen i ett fast grepp kan inte rotera enheten.
- 1.3.5 AA
Identifiera inmatningssyfte
Formulärfält som samlar in vanlig personlig information — namn, e-post, telefon, adress, kreditkort — måste deklarera sitt syfte programmatiskt via HTML-attributet autocomplete. Det möjliggör automatisk ifyllning och anpassade gränssnitt i hjälpmedelsteknik.
- 1.3.6 AAA
Identifiera syfte
Bortom formulärfält måste syftet med UI-komponenter, ikoner och regioner vara programmatiskt identifierbart — så att adaptiv teknik kan byta ut symboler, förenkla sidan eller dölja icke-väsentliga delar.
- 1.4.1 A
Användning av färg
Färg får inte vara det enda sättet att förmedla information. Obligatoriska fält, felmeddelanden, länkmarkeringar och diagramserier behöver alla ett andra ledtråd — text, ikon, understrykning eller mönster — så att färgblinda användare får samma information.
- 1.4.2 A
Ljudkontroll
Ljud som spelas upp automatiskt i mer än tre sekunder måste ha en paus-, stopp- eller volymkontroll oberoende av systemvolymen — så att det inte dränker skärmläsarens tal.
- 1.4.3 AA
Kontrast (minimum)
Brödtext måste ha ett kontrastförhållande på minst 4,5:1 mot sin bakgrund. Stor text (18pt+, eller 14pt+ fet) kräver 3:1. Logotyper och dekorativ text är undantagna.
- 1.4.4 AA
Ändra textstorlek
Text måste förbli läsbar och användbar när den zoomas upp till 200 % utan att innehåll eller funktionalitet går förlorad. Undertexter och bilder av text är undantagna.
- 1.4.5 AA
Bilder av text
Text bör implementeras som riktig text och inte som en rasterbild, om inte bilden är väsentlig (en logotyp, en skärmdump av ett gränssnitt) eller helt anpassningsbar av användaren.
- 1.4.6 AAA
Kontrast (utökad)
AAA-nivå för kontrast: 7:1 för brödtext, 4,5:1 för stor text. Strängare krav än 1.4.3, avsett för användare med betydande nedsatt syn som behöver högre kontrast för att läsa bekvämt.
- 1.4.7 AAA
Svagt eller inget bakgrundsljud
För förinspelat ljud som primärt består av tal måste bakgrundsljud vara minst 20 dB lägre än förgrundstalet, eller frånvarande, eller möjligt att stänga av separat — så att användare med hörselnedsättning kan följa dialogen.
- 1.4.8 AAA
Visuell presentation
För textblock måste användare kunna styra förgrunds- och bakgrundsfärg, radlängd (max 80 tecken), justering (inte marginaljustering), radavstånd (1,5x) och styckeavstånd (1,5x radhöjd) — utan horisontell rullning vid 200 % zoom.
- 1.4.9 AAA
Bilder av text (utan undantag)
AAA-nivå: bilder av text är inte tillåtna alls, utom logotyper och väsentliga fall (en skärmdump som demonstrerar typografi). Undantaget om anpassningsbarhet i 1.4.5 tas bort.
- 1.4.10 AA
Omflöde
Innehåll måste flöda om till en enda kolumn vid 320 CSS-pixlar bredd (vertikalt rullande innehåll) eller 256 pixlar höjd (horisontellt rullande) utan att information eller funktionalitet går förlorad. Ingen tvåriktningsrullning.
- 1.4.11 AA
Kontrast för icke-text
UI-komponenter (knappkanter, formulärfältsomfattningar, fokusindikatorer, enbart-ikon-kontroller) och meningsfulla grafiska element (diagramserier, statusikoer) måste ha minst 3:1 kontrast mot intilliggande färger.
- 1.4.12 AA
Textavstånd
När användare åsidosätter textavstånd — radavstånd 1,5x, styckemellanrum 2x teckenstorlek, bokstavsavstånd 0,12em, ordavstånd 0,16em — får sidan inte förlora innehåll eller funktionalitet.
- 1.4.13 AA
Innehåll vid hovring eller fokus
Verktygstips, popovers och annat innehåll som visas vid hovring eller fokus måste kunna stängas, vara hoverbart (så att användare kan flytta pekaren in i det) och vara beständigt (det försvinner inte förrän användaren stänger det eller utlösaren förlorar fokus).
2. Hanterbar
Gränssnittskomponenter och navigering måste vara hanterbara för alla.
- 2.1.1 A
Tangentbord
Varje funktion på sidan måste kunna hanteras med enbart tangentbord — utan krav på musrörelser, dra-och-släpp eller specifika tidsintervall. Skärmläsare, switch- och röstanvändare är alla beroende av denna grundnivå.
- 2.1.2 A
Ingen tangentbordsfälla
Om tangentbordsfokus kan flytta till en komponent måste fokus även kunna flytta bort från den med enbart tangentbord. Modaler, inbäddade resurser och anpassade widgetar är de vanliga syndarna.
- 2.1.3 AAA
Tangentbord (utan undantag)
Samma som 2.1.1 Tangentbord, men utan undantaget för banoberoende indata. Varje funktion — inklusive frihandsteckning och signaturinsamling — måste ha ett tangentbordsmanöverbart alternativ.
- 2.1.4 A
Kortkommandon med enskilda tecken
Kortkommandon med enskilda tecken (en bokstav, siffra eller symbol) måste kunna stängas av, mappas om, eller vara aktiva endast när relevant komponent har fokus. Skyddar röststyrnings- och dikteringsanvändare från oavsiktliga triggers.
- 2.2.1 A
Justerbar tid
Varje tidsgräns som innehållet ställer in måste kunna stängas av, justeras till minst tio gånger standardvärdet, eller förlängas av användaren med minst 20 sekunders varning. Sessionstimeouts och frågesportstimers är de främsta målen.
- 2.2.2 A
Pausa, stoppa, dölj
Rörligt, blinkande, rullande eller automatiskt uppdaterat innehåll som varar mer än fem sekunder måste kunna pausas, stoppas eller döljas av användaren. Täcker karuseller, löptextstavar, nyhetstickets, animerade annonser och automatiskt uppdaterade flöden.
- 2.2.3 AAA
Ingen tidsbegränsning
Tidsbegränsningar är inte alls en del av innehållet, utom för icke-interaktiva realtidshändelser. Striktare än 2.2.1 — det finns inget alternativ med varning och förlängning.
- 2.2.4 AAA
Avbrott
Avbrott — pop-ups, notifieringar, varningar, automatiska uppdateringar — måste kunna skjutas upp eller undertryckas av användaren, utom de som rör en nödsituation.
- 2.2.5 AAA
Ny autentisering
När en autentiserad session löper ut måste användaren kunna fortsätta utan att förlora data som redan matats in. Sessionen avslutas, men pågående arbete gör det inte.
- 2.2.6 AAA
Timeouts
Användare måste varnas om inaktivitetstimeouts som kan orsaka dataförlust, såvida inte data bevaras i mer än 20 timmars inaktivitet.
- 2.3.1 A
Tre blixtar eller under tröskelvärdet
Inget på sidan får blinka mer än tre gånger per sekund, såvida inte blixten är under definierade storleks- och kontrasttrösklar. Utformat för att förhindra ljuskänsliga anfall.
- 2.3.2 AAA
Tre blixtar
Inget innehåll på sidan får blinka mer än tre gånger per sekund — utan undantag. Storleks- och tröskelundantagen i 2.3.1 gäller inte här.
- 2.3.3 AAA
Animering från interaktioner
Rörelseanimationer som utlöses av interaktion måste kunna stängas av av användaren, såvida animationen inte är nödvändig. Respektera mediafrågan `prefers-reduced-motion`.
- 2.4.1 A
Hoppa förbi block
Erbjud tangentbords- och skärmläsaranvändare ett sätt att hoppa förbi innehåll som upprepas på varje sida — vanligtvis sidhuvudet, primärnavigeringen och hjälplänkar — så att de kan nå huvudinnehållet utan att tabba igenom dussintals länkar.
- 2.4.2 A
Sidrubrik
Varje sida måste ha ett `<title>` som beskriver dess ämne eller syfte. Titeln är vad skärmläsare meddelar vid sidinläsning och vad användare ser i flikar, bokmärken, historik och sökresultat.
- 2.4.3 A
Fokusordning
När användare tabbar sig igenom en sida måste fokusordningen följa en sekvens som bevarar mening och användbarhet — vanligtvis den visuella läsordningen. En rörig tabbordning är funktionellt trasig även om varje enskild kontroll fungerar.
- 2.4.4 A
Länkens syfte (i kontext)
Syftet med varje länk måste framgå av länktexten, eller av länktexten i kombination med dess omgivande kontext — meningen, listobjektet, tabellcellen eller stycket den finns i. Skärmläsaranvändare hör ofta länkar utan kontext, i en länklista.
- 2.4.5 AA
Flera sätt
Användare måste ha mer än ett sätt att hitta en sida inom en uppsättning — typiskt en kombination av navigeringsmeny, sökning, webbplatskarta, innehållsförteckning eller lista med relaterade sidor. Undantag är sidor som är steg i en process (betalning, flerstegformulär).
- 2.4.6 AA
Rubriker och etiketter
Rubriker och formuläretiketter måste beskriva ämnet eller syftet med det innehåll de introducerar. De behöver inte vara unika, men de måste vara informativa — en rubrik som lyder 'Information' eller en etikett som lyder 'Fält' uppfyller inte detta framgångskriterium.
- 2.4.7 AA
Fokus synligt
Alla tangentbordsoperabla gränssnitt måste ha en synlig fokusindikator på det aktuellt fokuserade elementet. Om en användare inte kan se var tangentbordsfokus är, kan de inte använda webbplatsen med tangentbord. Ett av de mest citerade framgångskriterierna i granskningar.
- 2.4.8 AAA
Plats
Användare måste kunna avgöra var de befinner sig inom en uppsättning sidor — typiskt via brödsmulor, en aktuell-sida-indikator i navigeringen, eller en webbplatskarta som markerar det aktiva avsnittet.
- 2.4.9 AAA
Länkens syfte (länk enbart)
Den strängare AAA-versionen av 2.4.4: länktexten ensam — utan omgivande kontext — måste identifiera destinationen. 'Läs mer' underkänns även om meningen ovanför förklarar. Utformad för skärmläsaranvändare som navigerar via länklistan.
- 2.4.10 AAA
Avsnittsrubriker
Använd rubriker för att organisera innehållet. Där en sida har distinkta avsnitt behöver varje avsnitt ett verkligt rubrikelement (`<h1>`–`<h6>`) — inte formaterade stycken som bara ser ut som rubriker.
- 2.4.11 AA Nytt 2.2
Fokus inte dolt (minimum)
När ett element får tangentbordsfokus får det inte vara helt dolt bakom ett annat UI-element — klistriga sidhuvuden, cookiebanners, chattwidgetar, klistriga sidfötter. Nytt i WCAG 2.2 och omformar hur team bygger klistrig sidkrom.
- 2.4.12 AAA Nytt 2.2
Fokus inte dolt (utökat)
Striktare AAA-version av 2.4.11: när ett element får fokus får ingen del av det vara dolt bakom annat innehåll. Nytt i WCAG 2.2.
- 2.4.13 AAA Nytt 2.2
Fokusutseende
Tangentbordsfokusindikatorn måste uppfylla en mätbar visuell nivå: minst 2 CSS-pixlar tjock runt omkretsen, minst 3:1 kontrast mot det tidigare ofokuserade tillståndet, och inte dold. Nytt i WCAG 2.2; den mest konkreta fokusstyleringsregeln specifikationen någonsin publicerat.
- 2.5.1 A
Pekarens gester
Varje funktion som använder en flerpunkts- eller sökvägsbaserad gest — nyp-zoom, tvåfingersrotation, svep för att ta bort — måste också kunna aktiveras med en enpunktsaktivering som inte kräver en sökväg.
- 2.5.2 A
Pekarannullering
Funktioner som utlöses av ett enda pekarklick måste aktiveras vid upp-händelsen, inte ned-händelsen — så att användare kan dra bort fingret för att avbryta. Avbryt, ångra eller förhandsaktivering måste vara möjligt, om inte omedelbar aktivering är nödvändig.
- 2.5.3 A
Etikett i namn
När ett kontrollelement har synlig text måste exakt den texten ingå i kontrollens tillgängliga namn, helst i början. Annars kan röstkontrollanvändare som säger vad de ser inte aktivera kontrollen.
- 2.5.4 A
Rörelseaktivering
Funktioner som utlöses av enhetsrörelse eller användarrörelse — skaka, luta, gestikulera framför en kamera — måste även vara användbara via vanliga gränssnittskontroller, och rörelseutlösning måste gå att inaktivera.
- 2.5.5 AAA
Målstorlek (förbättrad)
Interaktiva mål bör vara minst 44×44 CSS-pixlar. Det här är AAA-nivåns förbättrade krav på målstorlek; AA-nivåns golv i 2.5.8 är 24×24.
- 2.5.6 AAA
Parallella inmatningsmetoder
Webbinnehåll får inte begränsa användningen av inmatningsmetoder som finns tillgängliga på plattformen — utom när begränsningen är nödvändig, krävs för att skydda innehållet eller krävs för att respektera användarens inställningar.
- 2.5.7 AA Nytt 2.2
Dragningsrörelser
Alla funktioner som kräver en dragningsrörelse måste även kunna utföras med ett enkelt pekarklick utan dragning — vanligtvis ett tryck eller klick. Nytt i WCAG 2.2.
- 2.5.8 AA Nytt 2.2
Målstorlek (minimum)
Interaktiva mål — knappar, länkar, formulärkontroller — måste vara minst 24×24 CSS-pixlar, om inte ett likvärdigt mål på samma sida är tillräckligt stort eller målet befinner sig i en mening. Nytt i WCAG 2.2.
3. Begriplig
Information och hanteringen av gränssnittet måste vara begriplig.
- 3.1.1 A
Sidans språk
Ange det mänskliga standardspråket för varje sida programmatiskt — vanligtvis med lang-attributet på html-elementet. Skärmläsare, punktskriftsdisplayer och översättningsverktyg använder detta för att välja uttalregler, röstprofiler och teckenmappningar.
- 3.1.2 AA
Språk för delar
När ett stycke eller en fras på sidan är på ett annat språk än sidans standardspråk måste det markeras med ett lang-attribut på sitt element, så att skärmläsare byter röst och uttal för det fragmentet.
- 3.1.3 AAA
Ovanliga ord
Tillhandahåll en mekanism för att identifiera definitioner av ord som används på ett ovanligt eller begränsat sätt — fackjargong, idiom, tekniska termer. En ordlista, infogade definitioner eller länkade förklaringar uppfyller alla detta AAA-kriterium.
- 3.1.4 AAA
Förkortningar
Tillhandahåll en mekanism för att identifiera den utskrivna formen eller innebörden av förkortningar. Att skriva ut vid första förekomst, ett abbr-element med title, eller en länkad ordlista uppfyller alla detta AAA-kriterium.
- 3.1.5 AAA
Läsnivå
När innehåll kräver läsförmåga utöver lägre gymnasienivå måste ett enklare alternativ erbjudas — en klarspråksversion, en sammanfattning eller kompletterande material som illustrationer eller ljud.
- 3.1.6 AAA
Uttal
När ett ords betydelse beror på dess uttal och rätt uttal inte framgår av sammanhanget, måste en mekanism finnas som visar uttalet — fonetisk stavning, ljud eller en länkad guide.
- 3.2.1 A
Vid fokus
När ett gränssnittselement tar emot fokus får det inte initiera en kontextändring — ingen automatisk sidnavigering, inget nytt fönster, ingen stor omorganisering av innehållet. Fokus är till för orientering, inte för att utföra åtgärder.
- 3.2.2 A
Vid inmatning
Att ändra inställningen för ett gränssnittselement får inte automatiskt orsaka en kontextändring om inte användaren har varnat i förväg. Att välja ett värde ska inte tyst navigera, skicka eller omstrukturera sidan.
- 3.2.3 AA
Konsekvent navigering
Navigeringsmekanismer som upprepas på flera sidor — primär nav, sidfot, brödsmulor, sök — måste visas i samma relativa ordning på varje sida där de förekommer. Användare som förlitar sig på muskelminne ska inte behöva återupptäcka layouten varje gång.
- 3.2.4 AA
Konsekvent identifiering
Komponenter med samma funktion på en webbplats måste identifieras konsekvent — samma etikett, samma ikon, samma tillgängliga namn. Två knappar som gör samma sak ska inte heta Sök på en sida och Hitta på en annan.
- 3.2.5 AAA
Ändring på begäran
Kontextändringar sker bara när användaren begär dem, eller så kan användaren stänga av den automatiska ändringen. Inga automatiska omdirigeringar, inga överraskande uppdateringar, inga karuseller som byter innehåll under markören.
- 3.2.6 A Nytt 2.2
Konsekvent hjälp
Om en sida erbjuder hjälpmekanismer — kontaktuppgifter, en hjälplänk, en chattbot, ett självbetjäningsformulär — måste de visas i samma relativa ordning på varje sida där de förekommer. Nytt i WCAG 2.2.
- 3.3.1 A
Felidentifiering
När användaren gör ett formulärfel som automatiskt detekteras måste felet identifieras och beskrivas för användaren i text — inte enbart med färg, inte enbart med en ikon, inte med tystnad.
- 3.3.2 A
Etiketter eller instruktioner
Varje formulärkontroll som kräver användarinmatning måste ha en etikett eller instruktion som talar om vad användaren ska ange. Fält med enbart platshållartext, inmatningar med enbart ikon och nakna rutor räcker inte.
- 3.3.3 AA
Felförslag
När ett inmatningsfel detekteras och en korrigering är känd för systemet måste systemet erbjuda ett förslag till användaren — om inte det äventyrar säkerheten eller ogiltigförklarar inmatningens syfte.
- 3.3.4 AA
Felförebyggande (juridiskt, ekonomiskt, data)
Vid inlämningar med juridiska åtaganden, ekonomiska transaktioner eller väsentliga ändringar av användardata måste användaren kunna ångra inlämningen, få den kontrollerad för fel med möjlighet att korrigera, eller bekräfta den uttryckligen innan den verkställs.
- 3.3.5 AAA
Hjälp
Kontextkänslig hjälp finns tillgänglig för formulär och användarinmatningar som kräver det. Hjälp kan inkludera formatexempel, ledtrådar på sidan, länkad vägledning eller en kontaktmekanism.
- 3.3.6 AAA
Felförebyggande (alla)
Vid all inmatning – inte bara juridiska, ekonomiska eller dataändrande transaktioner – måste användaren kunna ångra, granska eller bekräfta innan åtgärden träder i kraft. AAA-generaliseringen av 3.3.4.
- 3.3.7 A Nytt 2.2
Redundant inmatning
Information som användaren redan lämnat i samma session ska inte krävas in igen – den ska fyllas i automatiskt eller kunna väljas från en lista, om inte ny inmatning är nödvändig (t.ex. lösenordsbekräftelse). Nytt i WCAG 2.2.
- 3.3.8 AA Nytt 2.2
Tillgänglig autentisering (minimum)
Autentisering får inte kräva ett kognitivt funktionstest – att minnas, transkribera eller identifiera objekt – om inte ett alternativ eller hjälpmedel erbjuds. Lösenord, bild-CAPTCHA och kod-via-e-post är vanliga fel. Nytt i WCAG 2.2.
- 3.3.9 AAA Nytt 2.2
Tillgänglig autentisering (utökad)
Autentisering får inte kräva något kognitivt funktionstest alls, inte ens igenkänning av objekt eller identifiering av personligt innehåll. AAA-uppgraderingen av 3.3.8 – lösenordsnycklar, biometri och enhetsbundna autentiseringsuppgifter är de praktiska vägarna. Nytt i WCAG 2.2.
4. Robust
Innehållet måste vara robust nog att tolkas på ett tillförlitligt sätt av en mängd olika användarprogram, inklusive hjälpmedelsteknik.
- 4.1.2 A
Namn, roll, värde
Varje UI-komponent måste programmässigt exponera ett namn, en roll och – där tillämpligt – ett värde och tillstånd. Utan detta kan skärmläsare, röststyrning och switchenheter varken identifiera eller manövrera kontrollen.
- 4.1.3 AA
Statusmeddelanden
Statusmeddelanden – bekräftelser, fel, förloppsuppdateringar, antal sökresultat – måste annonseras av hjälpmedelsteknik utan att fokus flyttas. Använd role=status, role=alert eller aria-live på en region som redan finns i DOM:en.
Inga framgångskriterier matchar dina filter.