Hvad er nyt i WCAG 2.2? De 9 nye kriterier forklaret enkelt

En person, der bruger tastaturet, tabber sig igennem din checkout. Fokus lander på knappen »Betal nu«, men et fastgjort cookiebanner ligger oven på, så vedkommende kan ikke se, hvor fokus er. Efter WCAG 2.1 kunne siden stadig bestå. Efter WCAG 2.2 dumper den.

Det er den slags huller, opdateringen til 2.2 lukker. Nedenfor får hvert nyt succeskriterie samme behandling: hvad det siger, hvem det hjælper, en hurtig test og den typiske løsning. De fire principper og niveauerne samlet på én side finder du i vores reference til WCAG 2.2.

Hvad er WCAG 2.2?

WCAG 2.2 er den aktuelle version af Web Content Accessibility Guidelines, retningslinjerne for tilgængeligt webindhold, den W3C-standard, som de fleste tilgængelighedslove og kontrakter henviser til. Den blev W3C-anbefaling 5. oktober 2023 (åbner i en ny fane), blev opdateret 12. december 2024 (åbner i en ny fane) og blev godkendt som ISO/IEC 40500:2025 (åbner i en ny fane) i oktober 2025.

WCAG består af testbare udsagn, der kaldes succeskriterier, og hvert kriterie har et niveau: A (minimum), AA (det, lovene typisk kræver) eller AAA (det strengeste). »Vi skal opfylde WCAG 2.2 AA« betyder alle kriterier på niveau A og AA i version 2.2. Ifølge specifikationen »bygger 2.2 videre på og er bagudkompatibel med WCAG 2.1«, så den tilføjer krav til 2.1 i stedet for at erstatte den.

Hvad ændrede sig fra WCAG 2.1 til 2.2?

WCAG 2.2 tilføjer ni succeskriterier og fjerner ét. Seks af de nye ligger på niveau A eller AA og tæller derfor med i det almindelige AA-mål: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 og 3.3.8. De sidste tre er AAA. Det fjernede kriterie er 4.1.1 Parsing, som W3C nu beskriver som forældet. Den autoriserede danske oversættelse dækker WCAG 2.1, ikke 2.2, så vi bruger de engelske navne på de nye kriterier.

4.1.1 Parsing tjekkede for fejl i koden, f.eks. dobbelte id'er. W3C's ofte stillede spørgsmål om WCAG 2 (åbner i en ny fane) forklarer, at de problemer nu hører under andre kriterier, f.eks. 4.1.2 Navn, rolle, værdi. Én faldgrube: hvis en kontrakt stadig kræver WCAG 2.0 eller 2.1, »kan det være nødvendigt fortsat at teste og rapportere 4.1.1«.

Focus Not Obscured og Focus Appearance: kan tastaturbrugere se, hvor de er?

Disse kriterier sørger for, at elementet med tastaturfokus er synligt. På niveau AA (2.4.11) må et fokuseret link eller en knap ikke være helt skjult af indhold, du selv har tilføjet, f.eks. en fastgjort topmenu, et cookiebanner eller en chatboble. På niveau AAA må intet dække nogen del af elementet (2.4.12), og fokusrammen skal være stor og have tydelig kontrast (2.4.13).

• Hvem det hjælper: seende personer, der bruger tastatur i stedet for mus, ofte på grund af et bevægelseshandicap. Kan de ikke se fokus, må de gætte.
• Hurtig test: åbn en lang side, hvor cookiebanner, fastgjort topmenu og chatwidget alle er synlige, og tryk på Tab mange gange. Forsvinder fokus helt bag noget, er det en fejl mod 2.4.11.
• Typisk løsning: tilføj CSS-egenskaben scroll-padding svarende til højden på din fastgjorte topmenu eller sidefod, så browseren ruller fokuserede elementer fri af den. W3C nævner det som en tilstrækkelig teknik (åbner i en ny fane). Et banner kan også bestå, hvis det er modalt og skal lukkes først.

Focus Appearance (2.4.13) kræver en indikator, der er mindst lige så stor som en 2 CSS-pixels tyk ramme om komponenten, med en kontrastændring på mindst 3:1 mellem fokuseret og ikke-fokuseret tilstand. Kriteriet er AAA, men en fuldt optrukket ramme på 2 pixels i en kraftig farve rækker som regel. Vores guide til farvekontrast forklarer, hvordan du måler 3:1.

Dragging Movements og Target Size: kan hjemmesiden bruges uden præcis pegning?

De to kriterier på niveau AA hjælper personer, der har svært ved at styre markøren præcist. 2.5.7 siger, at alt, hvad du kan gøre ved at trække, også skal kunne gøres med enkelte klik eller tryk. 2.5.8 siger, at klikflader skal være mindst 24 × 24 CSS-pixels eller placeret, så en cirkel på 24 pixels centreret på hver flade ikke rører en anden flade.

2.5.7 Dragging Movements (trækbevægelser)

Tænk på en prisskyder i webshoppens filtre eller en ønskeliste, du sorterer ved at trække. For en person med rystelser, eller en, der styrer med hovedet, kan tryk-hold-flyt-slip være meget svært.

Hurtig test: gennemfør hver trækopgave kun med klik eller tryk. Typisk løsning: lad brugeren klikke hvor som helst på skyderens bane, tilføj felter til »min« og »maks« ved siden af, eller tilføj knapperne »Flyt op« og »Flyt ned« i lister, der kan sorteres. Tastaturunderstøttelse alene er ikke nok: W3C's forklarende dokument (åbner i en ny fane) siger, at et tastaturalternativ »ikke automatisk opfylder dette succeskriterie«.

2.5.8 Target Size (Minimum) (målstørrelse)

De typiske fejl er små »×«-knapper på pop op-vinduer, tætsiddende sidetal, stjernebedømmelser og rækker af ikoner til sociale medier. At ramme forkert er irriterende for alle og en reel barriere for personer med nedsat fingerfærdighed.

• Undtagelser: links inde i en sætning, flader med en tilsvarende kontrol et andet sted på siden, der opfylder størrelseskravet, kontroller, hvis størrelse browseren bestemmer, og som du ikke har ændret stylingen på, og tilfælde, hvor en bestemt størrelse er afgørende eller lovpligtig.
• Hurtig test: prøv alle små ikoner og knapper på en telefon; vil du måle en af dem, kan du inspicere den i browserens udviklerværktøjer.
• Typisk løsning: tilføj padding. Det klikbare område vokser, selv om ikonet ser uændret ud. Og betragt 24 pixels som et minimum: det ældre AAA-kriterie 2.5.5 Målstørrelse kræver 44 × 44.

Consistent Help og Redundant Entry: skal folk lede eller gentage sig selv?

Begge ligger på niveau A. 3.2.6 Consistent Help siger, at hvis hjælp som kontaktoplysninger, en chat eller et link til ofte stillede spørgsmål optræder på flere sider, skal den stå i samme rækkefølge i forhold til resten af siden hver gang. 3.3.7 Redundant Entry siger, at brugeren ikke skal skrive oplysninger igen, som vedkommende allerede har givet i samme forløb.

Consistent Help forpligter dig ikke til at tilbyde hjælp overhovedet. Kriteriet siger kun, at hvis telefonnummeret står i toppen på produktsiderne, må det ikke flytte ned i sidefoden i checkout, hvor folk har mest brug for det. Personer med hukommelses- eller koncentrationsbesvær har størst gavn af det. Løsningen er som regel en fælles skabelon i stedet for at placere hjælpen side for side.

Redundant Entry handler om formularer med flere trin. En bookingformular, der spørger efter din e-mailadresse i trin 1 og igen i trin 3, dumper, og det gør en checkout, der får dig til at skrive en identisk faktureringsadresse igen, også. Udfyld feltet automatisk, eller lad brugeren vælge oplysningen, f.eks. med afkrydsningsfeltet »Faktureringsadressen er den samme som leveringsadressen«. Undtagelserne: når det er nødvendigt at indtaste oplysningen igen, når det kræves af sikkerhedshensyn, eller når den tidligere oplysning ikke længere er gyldig.

Accessible Authentication: kan man logge ind uden en hukommelsestest?

Succeskriterie 3.3.8 (niveau AA) siger, at intet trin i et login må afhænge af en kognitiv funktionstest, som at huske en adgangskode, skrive forvrængede tegn af eller løse en gåde, medmindre du tilbyder et alternativ eller noget, der hjælper. I praksis: lad adgangskodeadministratorer udfylde felterne, tillad indsættelse, og tilbyd en metode, der ikke afhænger af hukommelsen.

WCAG definerer en kognitiv funktionstest som »en opgave, der kræver, at brugeren husker, bearbejder eller skriver information af«. At indtaste sit navn, sin e-mailadresse eller sit telefonnummer tæller ikke, fordi det er personlige oplysninger, der er de samme overalt. Et logintrin består på niveau AA, hvis det tilbyder mindst én af disse muligheder:

• Et alternativ uden kognitiv test, f.eks. en adgangsnøgle (passkey) eller et login-link på e-mail.
• En mekanisme, der hjælper, f.eks. understøttelse af adgangskodeadministratorer eller kopiér og indsæt, så en engangskode ikke skal skrives af.
• Genkendelse af objekter, f.eks. »vælg billederne med en cykel«.
• Personligt indhold, f.eks. at genkende et billede, du selv har uploadet.

AAA-versionen, 3.3.9, fjerner de to sidste muligheder, så en billed-CAPTCHA kan bestå på AA, men ikke på AAA. Typiske fejl: adgangskodefelter, der blokerer indsættelse eller adgangskodeadministratorer, felter til engangskoder, der går i stykker, når du indsætter, og en tekst-CAPTCHA uden alternativ. Personer med ordblindhed eller nedsat hukommelse får mest ud af det, men alle, der er blevet låst ude efter en lang dag, kender problemet.

Er WCAG 2.2 et lovkrav?

Det afhænger af, hvor du er, og hvem du er. Love nævner sjældent en WCAG-version direkte, og flere henviser stadig til WCAG 2.1 AA. Fordi WCAG 2.2 er bagudkompatibel, opfylder du også 2.1 AA, når du opfylder 2.2 AA, bortset fra det fjernede 4.1.1. Sigter du efter 2.2, dækker du altså begge. Står der en bestemt version i en kontrakt, så følg kontrakten.

• Den Europæiske Union: efter European Accessibility Act formodes overensstemmelse, når du opfylder den harmoniserede standard EN 301 549. Ifølge AccessibleEU (åbner i en ny fane) bygger version 4.1.1, der blev udgivet i september 2026, på WCAG 2.2, men den er endnu ikke den juridiske reference; indtil henvisningen er offentliggjort i EU-Tidende, gælder v3.2.1 (baseret på WCAG 2.1 AA). Vores gennemgang af European Accessibility Act forklarer, hvem loven gælder for.
• Storbritannien: regeringens vejledning (åbner i en ny fane) siger, at hjemmesider og apps i den offentlige sektor skal opfylde WCAG 2.2 AA. Den vejledning gælder offentlige myndigheder, ikke private virksomheder.
• USA: justitsministeriets regel for delstater og lokale myndigheder bruger WCAG 2.1 AA, og fristerne blev udskudt i april 2026 (åbner i en ny fane) til 26. april 2027 og 26. april 2028. For private virksomheder siger ministeriets vejledning fra 2022 (åbner i en ny fane), at ADA gælder for deres hjemmesider, men den fastsætter ingen bestemt teknisk standard.

Hvad med WCAG 3?

WCAG 3 er et udkast, så ingen kan leve op til den endnu. W3C udgav opdaterede udkast i september 2026 og skriver, at WCAG 3 ikke ventes at blive en færdig standard »før om nogle år«. WCAG 2 bliver ikke udfaset før flere år efter det, så det er 2.2, du skal arbejde efter nu.

Hvordan tjekker du de nye kriterier på 15 minutter?

De fleste fejl mod de seks kriterier på niveau A og AA kan du finde på cirka 15 minutter med et tastatur, en telefon og din egen login-side. Det erstatter ikke en fuld audit eller test med personer med handicap, men det viser, hvor du skal begynde, og giver en udvikler en konkret liste at arbejde ud fra.

1. Gå igennem forsiden, en produktside og checkout med Tab-tasten, mens alle bannere er synlige. Kan du altid se fokus? (2.4.11)
2. Gennemfør alle skydere og træk-og-slip-opgaver kun med klik eller tryk. (2.5.7)
3. Prøv alle lukkeknapper, sidetal og små ikoner på en telefon. (2.5.8)
4. Sammenlign, hvor hjælp og kontaktoplysninger står på tre slags sider. (3.2.6)
5. Gennemfør et køb eller en booking, og notér hvert spørgsmål, du svarer på to gange. (3.3.7)
6. Log ind med en adgangskodeadministrator, og indsæt derefter en adgangskode og en engangskode. Har hver CAPTCHA et alternativ? (3.3.8)

For resten af WCAG gennemgår vores guide til hvordan du tester din hjemmesides tilgængelighed gratis værktøjer og manuelle tjek, og vores tjekliste for webtilgængelighed gør de mest almindelige fejl til en to do-liste. Det, du ikke kan rette endnu, hører hjemme i din tilgængelighedserklæring.

En bemærkning om widgets, vores egen medregnet: ingen af disse kriterier kan opfyldes med et panel, som den besøgende styrer. En stor markør gør det lettere at ramme små flader, men den gør dem ikke 24 pixels brede, og fremhævet fokus flytter ikke et fastgjort banner af vejen. Hvert nyt kriterie handler om, hvordan dine sider er bygget, så løsningen ligger i dine skabeloner og din kode.