WCAG 2.2-adoptionsrate: hvor anbefalingen har og ikke har fundet vej til lovgivning, udbud og revisionsprocesser — en undersøgelse fra 2026
W3C offentliggjorde WCAG 2.2 som en anbefaling den 5. oktober 2023. To et halvt år senere er det den version, enhver seriøs revisor bruger som benchmark, og den version, ethvert større designsystem mindst delvist har absorberet — men endnu ikke den version, som de fleste af verdens tilgængelighedslove faktisk citerer. Forsinkelsen viser sig ni bestemte steder: de ni nye succeskriterier. Denne feltguide katalogiserer dem alle.
De foregående dele af denne serie kortlagde det juridiske referencebillede oppefra og ned — jurisdiktion for jurisdiktion, lov for lov. Det perspektiv er nyttigt for complianceansvarlige og udbudsledere. Det er mindre nyttigt for udvikleren, designeren eller produktchefen, der skal levere det konkrete udbedringsbarbejde. Denne guide anlægger det modsatte perspektiv: den arbejder fra succeskriteriet og udad.
Hver post nedenfor er et af de ni nye WCAG 2.2-succeskriterier — de præcise ændringer, arbejdsgruppen foretog i forhold til den foregående anbefaling. For hvert beskrives, hvad kriteriet kræver på klart dansk, hvor ofte feltet rent faktisk fanger fejlen i 2026-revisioner, den produktionsmekanisme, der udløser det, og den tekniske løsning. Hver post følger den samme anatomi i samme rækkefølge, så kataloget kan læses fra top til bund eller via direkte hop.
9 nye succeskriterier · rangeret efter hyppighed af revisionsfejl i 2026
| ID | Mønster (SC + titel) | Niveau | Fejlrate ved revision |
|---|---|---|---|
| E·01 | 2.4.13 Fokussynlighed | AAA | >70% |
| E·02 | 2.5.8 Målstørrelse (minimum) | AA | Hyppigste AA-fejl |
| E·03 | 3.3.8 Tilgængelig godkendelse (min.) | AA | Størst AA-konsekvens |
| E·04 | 2.4.11 Fokus ikke skjult (min.) | AA | Top-5 AA |
| E·05 | 2.5.7 Trækbevægelser | AA | Smal overflade |
| E·06 | 3.3.7 Redundant indtastning | A | Serversiderettelse |
| E·07 | 3.2.6 Konsistent hjælp | A | Redaktionel |
| E·08 | 2.4.12 Fokus ikke skjult (forb.) | AAA | Strengere variant af E·04 |
| E·09 | 3.3.9 Tilgængelig godkendelse (forb.) | AAA | Strengere variant af E·03 |
Beskrivelser af fejlrater er samlet fra uafhængige revisionsrapporter udsendt frem til Q1 2026; metoderne varierer på tværs af virksomheder, så tallene er vejledende snarere end præcise. Fem af ni kriterier befinder sig på niveau AA — det regulatorisk bindende niveau — og det er disse rækker, som udbudsklausuler skal håndtere først.
Hvor forsinkelsen rent faktisk viser sig
Juridisk indlejring af WCAG sker ved versionspinning. En forordning siger ikke “aktuel WCAG”; den siger WCAG 2.0 eller WCAG 2.1 med et niveau og en dato. At opdatere pinnet er en lovgivningsmæssig ændring. Pr. midt-2026 er verdens vigtigste tilgængelighedsforordninger fortsat fordelt på tre versioner: USA’s Section 508 på 2.0; EU’s EN 301 549 V3.2.1 på 2.1; UK’s PSBAR på 2.1 (med en lukket februar 2026-høring verserende). Det pragmatiske midtvejskompromis — “WCAG 2.1 AA som minimum, med VPAT 2.5-rapportering mod 2.2, hvor leverandørens svar tillader det” — er blevet standard udbudsformulering.
Udbud bevæger sig hurtigere end loven. ITI’s VPAT 2.5 / ACR-skabelon, udgivet januar 2025, tilføjede rapporteringskolonner for hvert af de ni nye kriterier; enhver VPAT udstedt efter den dato mod WCAG-versionen af skabelonen rapporterer mod 2.2. Store teknologivirksomheders designsystemadoption er gået hurtigst af alt — Microsoft, Apple HIG, Material 3, Adobe Spectrum og Meta har alle tilpasset sig til 2.2 i løbet af 2024–25. Det katalog, der følger, er det tekniske modstykke: de ni specifikke ændringer, arbejdsgruppen foretog, og hvad de rent faktisk afdækker i produktion.
Fem af de ni nye succeskriterier er AA — det er disse, der er regulatorisk bindende, og de rækker, som en udbudsklausul fra 2026 ikke kan komme uden om.
Fokusindikatorer var arbejdsgruppens første bekymring i 2.2-briefen. To kriterier handler om, hvorvidt fokusrammen nogensinde skjules af forfatterindhold; et tredje specificerer selve indikatoren. Tilsammen afdækker de den mest oversete underflade i enhver tastaturrejse.
Fokussynlighed — 2.4.13 AAA
Når en brugergrænseflade-komponent modtager tastatursfokus, skal fokusindikatoren have et minimumskontrastratio på 3:1 i forhold til tilstødende farve og dække mindst omkredsen af en 2 CSS-pixel solid ramme rundt om det fokuserede element eller et tilsvarende indikatorareal. Kriteriet er et af de få WCAG-tilføjelser, der specificerer målbar geometri snarere end adfærd.
Standardbrowserens fokusramme, som designere brugte femten år på at tilsidesætte af æstetiske årsager, fejler denne måling på de fleste reviderede produktionswebsteder. Brugerdefinerede fokusstile bruger typisk 1px-rammer eller accentfarver med lav kontrast, der ser korrekte ud i designværktøjer, men scorer under 3:1 mod baggrunden for det faktisk fokuserede element.
Tallet er vigtigt, selv om kriteriet er AAA: det indikerer, hvad der ville ske, hvis en fremtidig regulator pinnede til WCAG 2.2 niveau AAA, eller hvis en udbudskontrakt løftede netop dette kriterium.
Sæt en 2 CSS-pixel ramme i en farve, der scorer mindst 3:1 mod elementets baggrund; verificer med et kontrasttjekværktøj frem for med øjet. Hvor designsystemet tilsidesætter browserens fokus, eksponer et fokus-stil-token, som designere ikke utilsigtet kan sænke under kontrasttærsklen.
Målstørrelse (minimum) — 2.5.8 AA
Berøringsmålet for hvert pegerinput skal være mindst 24 gange 24 CSS-pixel, undtagen hvor målet er inline i en sætning, hvor det er dimensioneret af brugeragenten, hvor et tilsvarende mål er tilgængeligt, eller hvor målets funktion er essentiel. Kriteriet måler berøringsmålet, ikke det synlige ikon.
Kriteriet rammer et specifikt UI-mønster: tætte ikonværktøjslinjer, særligt i editorer, dashboards og datatabelshoveder. De fleste ikonknap-biblioteker anvender som standard 16×16 eller 20×20 visuelle ikonstørrelser indeni et lidt større berøringsmål. Hvor berøringsmålet også er under 24×24, fejler kriteriet — og værktøjslinjedesignere strammer løbende mellemrummene for at få flere ikoner ind i begrænset vandret plads.
Sæt et minimum-berøringsmål-token på 24 gange 24 CSS-pixel i designsystemet, anvendt via padding frem for ikonets egne dimensioner. Hvor værktøjslinjer ikke kan rumme gulvet, tilføj tilstrækkelig afstand, så tilstødende mål ikke er inden for kriteriets overlapsundtagelse. Tilbyd et indstillingsniveau-ækvivalent (en større menu) til de reelt trængte overflader.
Tilgængelig godkendelse (minimum) — 3.3.8 AA
Godkendelsestrinnet på et websted eller en app må ikke bygge på en kognitiv funktionstest — løse en opgave, transskribere et forvrænget billede, genkende objekter i et gitter — medmindre en alternativ godkendelsesmetode tilbydes, en hjælpemekanisme er tilgængelig, eller en objektgenkendelsesundtagelse finder anvendelse. At huske en adgangskode tæller som en kognitiv funktionstest, hvilket er grunden til, at adgangskodeadministratorer udtrykkeligt imødekommes.
De fleste billedbaserede CAPTCHA’er fejler dette på stedet. Det samme gælder “klik på felterne med trafiklys”-udfordringer, forvrænget tekst-transskriptionstests og ethvert flow, der indsætter en engangskode i et felt men deaktiverer indsæt-interaktionen. Mønsteret er koncentreret i login-, nulstilling-af-adgangskode- og kontooprettes-flows — netop de højindsats-punkter, hvor det koster mest at blive udelukket.
Godkendelsesflows er også det område, hvor kriteriets bid er skarpest, fordi fejlen ikke forringer oplevelsen — den afslutter den.
Erstat kognitive CAPTCHA’er med et ikke-kognitivt alternativ — enhedsbaseret attestering, magiske links, adgangsnøgler eller usynlig risikovurdering. Tillad udfyldelse via adgangskodeadministrator. Sørg for, at kopier-og-sæt-ind virker i engangskodefelter. Hvor en CAPTCHA skal bevares, tilbyd et lydalternativ, der ikke i sig selv kræver transskription af forvrænget tale.
AA-niveauet er den aktive ledning
Fem af de ni nye kriterier befinder sig på niveau AA: 2.4.11 Fokus ikke skjult (min.), 2.5.7 Trækbevægelser, 2.5.8 Målstørrelse (min.), 3.3.8 Tilgængelig godkendelse (min.) og (parret med 3.3.8 på AAA, 3.3.9). Det er disse kriterier, en udbudsklausul ikke kan undgå, og de rækker, hvor forskellen mellem WCAG 2.1 AA-overensstemmelse og WCAG 2.2 AA-overensstemmelse er mest målbar. De to A-niveau-tilføjelser (3.2.6 Konsistent hjælp, 3.3.7 Redundant indtastning) er lettere gevinster. De to AAA-tilføjelser (2.4.12 og 3.3.9) er ambitiøse stramninger af AA-parrene.
Fokus ikke skjult (minimum) — 2.4.11 AA
Når en brugergrænseflade-komponent modtager tastatursfokus, må det fokuserede element ikke være fuldstændig skjult af forfatterskabt indhold. Delvis okklusion er tilladt på dette niveau (en sticky-header, der overlapper den øverste halvdel af et fokuseret felt, er tilladt); total okklusion er ikke.
Den hyppigste kollision er en sticky-header — undertiden et cookiebanner eller flydende chat-widget — der overlapper det fokuserede formularfelt, når en tastaturbruger taber ind i det. Produktionswebsteder, der lagde en sticky-header oven på en eksisterende formular under redesign-perioden 2020–22, overså rutinemæssigt fokus-og-scroll-adfærden, fordi den originale formular var forfattet, inden sticky-elementer eksisterede.
Sæt scroll-margin-top (eller scroll-padding-top på scroll-beholderen) lig med højden af enhver sticky-overlay. Test, at tabulering gennem en lang formular ruller det fokuserede element helt ind i synsfeltet under enhver header. Par dette med fokus-synlige stilarter, så brugeren kan se, hvor fokus faktisk landede.
Den motoriske tilgængelighedsbrief i WCAG 2.2 reduceredes til to kriterier, begge AA. Det ene rammer listesorteringsgrænseflader, der kræver et vedvarende træk; det andet (E·02 ovenfor) rammer tætte ikonværktøjslinjer. De deler en fælles årsag — designsystemer, der antager en præcis peger.
Trækbevægelser — 2.5.7 AA
Funktionalitet, der bruger en trækbevægelse, skal også kunne betjenes via en enkelt-peger-handling — et tryk, et klik eller et tilsvarende, der ikke kræver vedvarende pegerbevægelse. Træk-og-slip-interaktioner er ikke forbudt; de kan simpelthen ikke være den eneste tilgængelige vej til funktionen.
Listesortering og kanban-stil-grænseflader leveres ofte kun med drag-sortering. Det samme gælder skyderkontroller implementeret som trækbare tommelfingre uden tilhørende spinbutton eller tekstinput, og billedbeskærings-grænseflader, der kræver et træk for at angive grænser. Kriteriet rammer disse hver gang.
Til enhver trækinteraktion, lever et tilsvarende tryk/klik-alternativ — “flyt op”- og “flyt ned”-knapper ved siden af trækbare listeelementer, et numerisk input ved siden af en skyder, en klik-for-at-angive-grænser-tilstand i beskæringsværktøjet. Hvor alternativet er skjult i en kontekstmenu, sørg for, at det er tilgængeligt via tastaturet.
De resterende fire kriterier falder i to par: de to A-niveau redaktionelle tilføjelser (Redundant indtastning og Konsistent hjælp) og de to AAA-stramninger (Fokus ikke skjult forbedret, Tilgængelig godkendelse forbedret). Tilsammen afrunder de 2.2-briefen om kognitiv-belastningstilgængelighed.
Redundant indtastning — 3.3.7 A
Inden for den samme autentificerede proces, kræv ikke, at brugeren indtaster de samme oplysninger to gange — medmindre genindsendelse er essentiel, den foregående indtastning ikke længere er gyldig, eller oplysningerne involverer sikkerhed (en adgangskode-genindtastning under kontooprettelse er den kanoniske undtagelse). Auto-udfyldning eller valg fra tidligere indtastede værdier opfylder begge kriteriet.
Flertrins-checkout-flows, flersidede ansøgningsformularer og visum- og tilladelsesansøgninger beder rutinemæssigt om den samme adresse, navn eller kontaktoplysninger i to separate trin, fordi trinnene blev bygget af forskellige teams og aldrig forenet. Brugerens tidligere indtastede værdier opbevares ikke i en session, der deles på tværs af trinnene.
Bevar bruger-indtastede værdier på tværs af trin i en enkelt proces; forudfyld matchende felter i efterfølgende trin; eller eksponer en enkelt-klik-kontrol “brug samme adresse”. Mønsteret opdages normalt under proceskortkortlægning snarere end under front-end-revision, så en tværgående flowgennemgang er det praktiske udbedringsskidt.
Konsistent hjælp — 3.2.6 A
Hvis der tilbydes en hjælpemekanisme — et kontaktlink, et hjælpelink, en chat-widget, et supporttelefonnummer, et selvhjælpslink — skal den fremgå på det samme relative sted på tværs af sider, hvor den tilbydes. Kriteriet kræver ikke, at der er hjælp til stede; kun at, hvor den er til stede, er dens placering konsistent.
Kriteriet er ligetil i princippet og rammer et snævert sæt af websteder, der har et “Kontakt os”-link i headeren på visse sider, i en footer på andre og inde i en flydende chat-widget på en tredje gruppe sider — ofte et resultat af, at flere webstedsafsnit ejes af forskellige teams med separate skabeloner.
Revidér placeringen af hjælpemekanismer på tværs af skabeloner; afgør en enkelt kanonisk placering (header, vedvarende footer eller flydende widget) og forlig eventuelle afvigere. Rettelsen er sjældent teknisk; det er et indhold-og-skabelon-styringstrin.
Fokus ikke skjult (forbedret) — 2.4.12 AAA
AAA-varianten af 2.4.11: når en brugergrænseflade-komponent modtager tastatursfokus, må det fokuserede element slet ikke skjules af forfatterskabt indhold. Delvis okklusion er forbudt på dette niveau — en sticky-header, der dækker en del af det fokuserede felt, fejler.
De samme sticky-overlay-kollisioner, der driver 2.4.11-fejl, fortsætter ved 2.4.12. Websteder, der indførte scroll-margin-top for at opfylde minimumskriteriet, har typisk stadig et par CSS-pixel overlap ved edge-case viewport-højder. På AAA er det overlap fejlen.
Indstil scroll-margin-top til komfortabelt at overstige højden af enhver forfatterskabt overlay, herunder dynamiske (cookiebanners, der vises ved første besøg, chat-widgets, der udvides ved hover). Tilføj eksplicitte regressionstest for tab-ind-i-formular-adfærd ved almindelige viewport-størrelser.
Tilgængelig godkendelse (forbedret) — 3.3.9 AAA
AAA-varianten af 3.3.8: godkendelse må under ingen omstændigheder bygge på en kognitiv funktionstest. De undtagelser for objektgenkendelse og personligt indhold, der gælder på AA, gælder ikke her. Hukommelsestest, transskriptionstest og billedgenkendelsesudfordringer fejler alle på dette niveau.
Selv websteder, der erstattede traditionelle CAPTCHA’er med objektgenkendelsesudfordringer (AA-undtagelsen), fejler 3.3.9. Kriteriet er arbejdsgruppens signal om, hvor godkendelse bør bevæge sig hen: væk fra kognitive udfordringer helt og holdent, og mod enhedsattestering eller biometrisk verifikation.
Anvend adgangsnøgler (WebAuthn) som den primære godkendelsesmekanisme; betragt adgangskode-plus-adgangsnøgle som en overgangstilstand snarere end en destination. Hvor billedgenkendelse er bibeholdt til risikovurdering, kør den server-side fra adfærdssignaler snarere end som en brugervendingudfordring.
2.2-tilføjelserne er ikke der, hvor tilgængelighedsproblemerne er sværest. De er der, hvor de hyppigste og mest målbare produktionsfejl findes — hvilket er præcis det, de blev valgt for.
Hvad de ni har til fælles
Læst som et katalog deler de ni nye kriterier en fælles redaktionel holdning. De er ikke nye fejlmodi, som arbejdsgruppen opfandt; de er de fejlmodi, der har vist sig mest konsekvent i de år, der er gået siden WCAG 2.1 blev offentliggjort. Arbejdsgruppen behandlede dem som huller, der skulle lukkes: tætte værktøjslinjer (2.5.8), sticky-overlays (2.4.11 / 2.4.12), CAPTCHA-lignende godkendelse (3.3.8 / 3.3.9), standardfokusramme (2.4.13), gentag-adressen-checkout-mønstre (3.3.7), kun-træk-listesorteringer (2.5.7) og hjælpelink-placerings-inkonsistensen, der frustrerede fortalere for kognitiv tilgængelighed (3.2.6).
Det juridiske referencebillede halter, fordi versionspinning-mekanismen er langsom. EN 301 549 V4 — den største verserende begivenhed — ville kaskade WCAG 2.2 på tværs af EU’s webtilgængelighedsdirektiv, EAA’s overensstemmelsesreference og enhver national webtilgængelighedslov, der peger på den harmoniserede europæiske standard. En offentliggørelse i 2026 er arbejdsantagelsen inden for ETSI JTC HF; et slip til 2027 er den mere forsigtige. UK’s PSBAR-ændring, efter den lukkede februar 2026-høring, forventes inden årets udgang. USA’s Section 508-opdatering er fortsat den langsomstbevægende store brik — selv 2.1-opdateringen er stadig verserende i 2026; en 2.2-opdatering er realistisk set et instrument fra slutningen af 2020’erne.
Til 2026-planlægningsformål er WCAG 2.2 den standard, der vil blive citeret i lovgivning og udbud resten af årtiet. WCAG 3 (Silver) er fortsat i Working Draft og er ikke på et nærtforestående Recommendation-spor; det seneste offentlige udkast i 2025 klargjorde, at Recommendation-publikation ikke forventes før 2028. Versionspinning-praksis i forordninger betyder, at 2.2 vil forblive refereret i år efter, at 3.0 offentliggøres. Den pragmatiske udbudsklausul — kræv WCAG 2.2 på niveau AA som overensstemmelsesmål, kræv en VPAT 2.5 ACR dateret inden for de seneste 12 måneder, kræv at leverandøren identificerer ethvert af de ni nye kriterier, hvor overensstemmelse endnu ikke er opnået — virker under enhver jurisdiktion, hvis underliggende lov stadig pinner til 2.0 eller 2.1, fordi intet i disse love forhindrer en køber i at indgå kontrakt om mere.
Din 2.2-parathedscheckliste
Udbudsformulering (gør dette nu)
- Kræv WCAG 2.2 på niveau AA som overensstemmelsesmål i nye kontrakter
- Kræv en VPAT 2.5 ACR dateret inden for de seneste 12 måneder fra alle leverandører
- Kræv, at leverandører identificerer ethvert af de ni nye kriterier, hvor overensstemmelse endnu ikke er opnået, plus en dokumenteret udbedringskøreplan
- Behandl “WCAG 2.1 AA som minimum, med rapportering mod 2.2, hvor leverandørens svar tillader det” som gulvet — ikke loftet
Tekniske regressionstest (fang de fem AA-kriterier, inden revisionen gør det)
- Tab-ind-i-formular-adfærd ved almindelige viewport-størrelser med alle overlays åbne (2.4.11)
- Berøringsmål-dimensioner i ikonværktøjslinjer, dashboards og datatabelshoveder (2.5.8)
- Enkelt-peger-alternativer til alle trækinteraktioner — listesortering, skydere, beskæringsværktøjer (2.5.7)
- Login-, tilmeldings- og adgangskode-nulstillings-flows fri for kognitive funktionstest; sæt-ind aktiveret i OTP-felter (3.3.8)
- Tværgående trins-persistens: intet felt bedt om to gange i den samme autentificerede proces (3.3.7)
Redaktionel / IA-gennemgang (de to A-niveau-tilføjelser)
- Enkelt kanonisk placering af hjælpemekanismer på tværs af skabeloner (3.2.6)
- Tværgående flowgennemgang for enhver flertrinsproces ejet af mere end ét team (3.3.7)
2026-udsigt — punkter at følge
- EN 301 549 V4-offentliggørelse — udløser WCAG 2.2 på tværs af EU’s webtilgængelighedslov
- UK’s PSBAR-ændring — den første store anglofoniske jurisdiktion til at pinne til 2.2
- USA’s Section 508 ICT-opdatering — 2.1 stadig verserende; 2.2 er et instrument fra slutningen af 2020’erne
- VPAT 2.5-kadence — enhver ACR dateret 2025 eller senere bør rapportere mod 2.2
WCAG 2.2-overgangen er strukturelt to overgange, der kører på forskellige ure. Lovovergangen er langsom, afhængig af et lille antal standardorganer — ETSI JTC HF frem for alt — og vil fortsætte frem til 2026–27. Praktikerovergangen er i vid udstrækning allerede sket: revisorer scorer mod 2.2, designsystemer flugter med det, leverandører indgiver VPAT 2.5 ACR’er med rapportering mod det, og de ni nye kriterier er nu det etablerede vokabular for tilgængelighedsrevisioner. Det interessante analytiske spørgsmål er ikke længere, om WCAG 2.2 er den gældende standard — det er den — men om de regulatoriske referencer vil indhente det, inden WCAG 3 begynder at trække opmærksomheden fremad.
MetodeFejlrate-beskrivelser aggregeret fra uafhængige revisionsrapporter udsendt frem til Q1 2026 på tværs af SaaS-, e-handels- og offentlige sektors revisionscyklusser. Kvalitative beskrivelser bruges, hvor firmaer offentliggør ordinale snarere end præcise rater.
OmfangKun de ni nye WCAG 2.2-succeskriterier. SC 4.1.1 Parsing, udfaset i WCAG 2.2, er uden for omfanget. WCAG 2.1-fortsatte kriterier er uden for omfanget.
KilderW3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation 5. oktober 2023 — w3.org/TR/WCAG22; W3C AG WG, What’s New in WCAG 2.2 — w3.org/WAI/standards-guidelines/wcag/new-in-22; ETSI, EN 301 549 V3.2.1 (2021) og JTC HF V4-udkast; US Access Board ICT Standards (Section 508 Refresh, 2017); US DOJ, Final Rule — Title II web accessibility, 28 C.F.R. Part 35 (april 2024); UK Cabinet Office, PSBAR 2018 og 2025–26-høring; ITI, VPAT 2.5 / ACR, januar 2025 — itic.org/policy/accessibility/vpat; EU-direktiv 2016/2102 og 2019/882; W3C, WCAG 3.0 Working Draft — w3.org/TR/wcag-3.0. Læs mere om nationale tilgængelighedsforordninger, Toolkit for praktikere, den fulde WCAG 2.2 succeskriterier-reference, forklaring af overholdelse, overensstemmelse og tilgængelighed, køberguide til overvågning, en gratis WCAG 2.2-basisscan og den bredere 2026-rapporteringsrekord.