WCAG 2.2: Web Content Accessibility Guidelines

Hvad er WCAG, og hvem står bag

WCAG står for Web Content Accessibility Guidelines og er en samling retningslinjer for, hvordan webindhold gøres mere tilgængeligt for mennesker med handicap. "Webindhold" skal her forstås bredt: tekst, billeder, lyd, video, kode og markup, altså alt det, en bruger møder i en browser eller via hjælpeteknologi som skærmlæsere, forstørrelsessoftware eller alternativ input. Formålet er at gøre indhold brugbart for et bredt spektrum af funktionsnedsættelser, herunder syn, hørelse, motorik og kognition, og samtidig gøre indhold mere anvendeligt for alle brugere generelt.

Standarden udgives af World Wide Web Consortium (W3C), den samme organisation, der står bag de grundlæggende web-standarder som HTML og CSS. Arbejdet foregår konkret i Accessibility Guidelines Working Group (AG WG) under W3C's Web Accessibility Initiative (WAI). WCAG er et konsensusdokument fra W3C, udarbejdet af en international arbejdsgruppe med deltagere fra industri, handicaporganisationer, forskning og offentlige myndigheder.¹

WCAG 2.2 er en W3C Recommendation. I W3C's proces er "Recommendation" det højeste, mest modne stadie et dokument kan nå: det har været igennem offentlig høring, implementeringstest og bred konsensus, og det anses for stabilt og klar til udbredt brug. Derfor kan du trygt bruge WCAG som testgrundlag. Dokumentet ændrer sig ikke under fødderne på dig fra uge til uge, sådan som et udkast ville gøre. WCAG 2.2 blev første gang publiceret som Recommendation i 2023, og den aktuelle udgave er dateret 12. december 2024.¹²

WCAG hører til en større familie af standarder fra WAI. Ved siden af selve retningslinjerne findes bl.a. ATAG (for værktøjer, der producerer indhold) og ARIA (for tilgængelig rig interaktion i webapplikationer). Rundt om WCAG 2.2 har W3C desuden udgivet en stor mængde understøttende materiale, nemlig dokumenterne "Understanding WCAG 2.2" og "Techniques for WCAG 2.2". De er ikke en del af den normerende standard, men forklarer intentionen bag hvert succeskriterium og giver konkrete teknikker til at opfylde det. Når du slår op, står selve kravene i WCAG 2.2-dokumentet, mens teknikkerne kun er eksempler på, hvordan man kan leve op til dem.¹

WCAG er den fælles, neutrale definition af, hvad tilgængeligt digitalt indhold vil sige. Fordi den er standardiseret og udbredt, kan en designer i København, en udvikler i Berlin og en indkøber i en offentlig myndighed henvise til nøjagtig de samme krav og forstå det samme ved dem, uanset om de skal bygge, teste eller bestille en løsning.

Sådan er WCAG bygget op: POUR, succeskriterier og niveau A, AA og AAA

WCAG er struktureret i tre lag, som du med fordel kan lære udenad, fordi de går igen overalt: principper, retningslinjer og succeskriterier. Øverst ligger fire principper, i midten 13 retningslinjer, og nederst de konkrete, testbare succeskriterier. Jo længere ned du kommer, jo mere præcist og efterprøvbart bliver kravet.¹³

De fire principper kaldes ofte POUR efter deres engelske forbogstaver: Perceivable, Operable, Understandable og Robust (på dansk opfattelig, betjenbar, forståelig og robust). Perceivable betyder, at information og brugerflade skal kunne opfattes af brugeren og ikke må være usynlig for alle sanser. Det er her krav om alternativ tekst til billeder, undertekster og tilstrækkelig farvekontrast hører hjemme. Operable betyder, at brugeren skal kunne betjene og navigere brugerfladen, herunder med tastatur alene. Understandable betyder, at både indhold og betjening skal være til at forstå og forudsige. Robust betyder, at indholdet skal være robust nok til at kunne fortolkes pålideligt af mange forskellige brugeragenter, inklusive hjælpeteknologier. Hvis et af de fire principper bryder sammen, kan brugere med handicap i praksis ikke bruge siden.¹

Under principperne ligger de 13 retningslinjer. Retningslinjerne er ikke i sig selv testbare. De er overordnede mål, som sætter rammen, for eksempel "Gør det lettere for brugere at se og høre indhold" eller "Gør tekstindhold læsbart og forståeligt". De samler de konkrete krav i meningsfulde grupper og hjælper både udviklere og designere med at forstå de bredere hensyn bag de enkelte krav.¹

Det er i det tredje lag, succeskriterierne, at det bliver operationelt. Hvert succeskriterium er formuleret som et testbart udsagn: det kan afgøres, om en given side opfylder det eller ej, og afgørelsen skal så vidt muligt være uafhængig af, hvem der tester. Testbarheden gør WCAG anvendelig som kravgrundlag i kontrakter og lovgivning, fordi man kan blive enige om et resultat. Hvert succeskriterium har et nummer (for eksempel 1.4.3 for kontrast eller 2.4.7 for synligt fokus), som du kan slå direkte op på, og det er dette nummer, du ofte vil se refereret i audits og fejlrapporter.¹

Endelig er hvert succeskriterium tildelt ét af tre niveauer: A, AA eller AAA. Niveau A er det laveste og dækker de mest grundlæggende krav, som har størst betydning, og som normalt er nemmest at opfylde; hvis de ikke er på plads, vil nogle grupper være helt afskåret fra indholdet. AA er det mellemste niveau og lægger yderligere krav oveni; det er det niveau, der i praksis oftest bruges som mål, både i branchen og i lovgivning. AAA er det højeste niveau med de mest ambitiøse krav; W3C anbefaler ikke AAA som et generelt krav for hele websteder, fordi det ikke altid er muligt at opfylde alle AAA-kriterier for alt indhold.¹

Niveauerne er kumulative. Når man taler om at overholde "niveau AA", betyder det, at både alle A- og alle AA-succeskriterier er opfyldt, ikke kun dem, der er mærket AA. Tilsvarende omfatter AAA alle tre niveauer. Det er en almindelig kilde til misforståelser. Når du læser en tilgængelighedserklæring eller stiller krav i et udbud, er det derfor niveauet, du skal kigge efter, fordi det afgør hele omfanget af, hvilke krav der gælder.¹

Hvad er nyt i WCAG 2.2: de ni nye succeskriterier

WCAG 2.2 er en videreudvikling af 2.1 og 2.0, ikke en omskrivning. Den grundlæggende arkitektur med de fire POUR-principper, retningslinjerne, succeskriterierne og de tre niveauer er den samme, og næsten alle eksisterende krav fra 2.0 og 2.1 er videreført uændret. Det nye er ni ekstra succeskriterier plus fjernelsen af ét enkelt gammelt kriterium. Talt i selve standarden har WCAG 2.2 dermed 86 gældende succeskriterier: 31 på niveau A, 24 på niveau AA og 31 på niveau AAA.²³¹

De ni nye succeskriterier i WCAG 2.2 er: 2.4.11 Focus Not Obscured (Minimum) på niveau AA; 2.4.12 Focus Not Obscured (Enhanced) på niveau AAA; 2.4.13 Focus Appearance på niveau AAA; 2.5.7 Dragging Movements på niveau AA; 2.5.8 Target Size (Minimum) på niveau AA; 3.2.6 Consistent Help på niveau A; 3.3.7 Redundant Entry på niveau A; 3.3.8 Accessible Authentication (Minimum) på niveau AA; og 3.3.9 Accessible Authentication (Enhanced) på niveau AAA.²¹

De nye kriterier falder i tre temaer. Det første er fokus og tastaturbetjening: Focus Not Obscured (2.4.11/2.4.12) kræver, at det element, der har tastaturfokus, ikke skjules helt bag for eksempel en fast header eller en cookie-banner, mens Focus Appearance (2.4.13) stiller krav til, hvor tydelig selve fokusindikatoren skal være. Brugere, der navigerer uden mus, skal hele tiden kunne se, hvor de befinder sig på siden.²

Det andet tema er motorik og pegehandlinger, som især er relevant på touch og for brugere med nedsat finmotorik. Dragging Movements (2.5.7) kræver, at funktioner, der bygger på at trække (for eksempel en skyder eller et kort, du panorerer), også kan betjenes med en enkelt pegehandling uden træk. Target Size (Minimum) (2.5.8) stiller krav til, at interaktive mål som knapper og links har en tilstrækkelig størrelse, så de er nemme at ramme.²

Det tredje tema er kognition og det at komme igennem opgaver uden unødig hukommelsesbelastning. Consistent Help (3.2.6) kræver, at hjælpemuligheder som kontaktinfo eller support placeres konsekvent på tværs af siderne, så de er til at finde igen. Redundant Entry (3.3.7) begrænser, hvor ofte brugeren skal indtaste de samme oplysninger flere gange i samme flow. Accessible Authentication (3.3.8/3.3.9) betyder, at login ikke må kræve en kognitiv funktionstest som at løse en gåde eller huske og genskrive en kode, hvis der ikke findes et alternativ. For eksempel skal det være tilladt at indsætte adgangskoder fra en password-manager.²

Ud over tilføjelserne er ét succeskriterium fjernet: 4.1.1 Parsing er blevet forældet og taget ud af WCAG 2.2. Kravet stammede fra en tid, hvor browsere håndterede fejl i markup meget forskelligt; moderne browsere og hjælpeteknologier fortolker i dag HTML mere ensartet, og de tilgængelighedsproblemer, kriteriet oprindeligt skulle fange, dækkes nu af andre kriterier. Fjernelsen betyder, at indhold ikke længere kan dumpe på netop dette punkt.²¹

Vigtigst for planlægningen er, at WCAG 2.2 er bagudkompatibel. W3C fastslår, at indhold, der opfylder WCAG 2.2, også opfylder WCAG 2.1 og WCAG 2.0. Har du allerede arbejdet efter 2.1, skal du ikke starte forfra. For at nå 2.2 skal du først og fremmest forholde dig til de ni nye kriterier, og fjernelsen af Parsing gør listen en anelse kortere.¹²

Sådan bruger du WCAG i praksis

WCAG er skrevet til at blive slået op i, ikke læst fra ende til anden. I det daglige arbejde bruger du den som en tjekliste og en ordbog. Den mest effektive indgang er nummeret på et succeskriterium: møder du i en audit eller et testværktøj en henvisning til for eksempel "1.4.3", kan du slå det op direkte i WCAG 2.2-dokumentet og få den præcise, normerende ordlyd. Derefter kan du gå videre til det tilhørende "Understanding"-dokument for at forstå intentionen og til "Techniques" for konkrete løsningsforslag.¹

Skal du teste et produkt, er en pragmatisk fremgangsmåde at tage udgangspunkt i det niveau, du sigter efter (typisk AA), og gennemgå de relevante succeskriterier ét ad gangen. En stor del kan afgøres med en kombination af manuelle tjek og hjælpeteknologi: naviger hele siden med tastatur alene og se, om fokus altid er synligt og aldrig skjult; slå en skærmlæser til og lyt, om billeder, knapper og formularfelter er meningsfuldt annonceret; kontrollér farvekontrast med et kontrastværktøj; forstør siden til 200 % og se, om indholdet stadig kan bruges. Automatiske testværktøjer kan hjælpe, men fanger kun en delmængde af kriterierne. Mange krav, især dem om mening og sammenhæng, kræver menneskelig vurdering.¹

Når du taler om at "overholde WCAG", skal du kende begrebet conformance, som er præcist defineret i standarden. Conformance handler ikke om en enkelt komponent, men om hele sider og hele processer. For at en side kan siges at overholde et niveau, skal samtlige succeskriterier på det pågældende niveau være opfyldt for hele siden. Du kan ikke opfylde et krav delvist og runde op. Og hvor indhold indgår i et flow, for eksempel en betaling eller en tilmelding, skal alle trin i processen leve op til niveauet, for at processen som helhed er konform. Derfor er punktvise rettelser sjældent nok, for ét utilgængeligt trin kan bryde konformansen for hele forløbet.¹

WCAG lægger op til, at man dokumenterer resultatet i en konformanserklæring, der angiver hvilken version og hvilket niveau der er opfyldt, samt hvilke sider den dækker. I mange sammenhænge, ikke mindst i offentlige projekter, vil du møde en tilgængelighedserklæring, hvor version (WCAG 2.2) og niveau (fx AA) skal fremgå. Når du læser eller skriver sådan en erklæring, er de to oplysninger det første, du skal kigge efter, fordi de tilsammen definerer det fulde sæt af krav.¹

Selve standarden ligger frit tilgængelig på w3.org, og det samme gør de understøttende "Understanding"- og "Techniques"-dokumenter. Brug altid den primære kilde på w3.org frem for tredjeparts opsummeringer, når det gælder den præcise ordlyd af et krav. Sekundære kilder er fine til overblik, men det er den normerende tekst, der afgør en tvist. Materialet er gratis og offentligt, så du kan slå det nøjagtige krav op på få sekunder i stedet for at gætte.¹

WCAG, conformance og forholdet til lovgivning

WCAG er en teknisk standard og ikke i sig selv en lov. WCAG 2.2 er en W3C Recommendation, altså et normerende, men frivilligt teknisk dokument udgivet af en standardiseringsorganisation. Det pålægger ikke i sig selv nogen at gøre noget. Det, der giver WCAG juridisk vægt, er, at lovgivere og myndigheder rundt om i verden vælger at henvise til standarden i deres regler og dermed gør den til det tekniske indhold i en retlig forpligtelse.¹

Fordi loven peger på en ekstern teknisk standard, giver det mening at kende WCAG uafhængigt af den konkrete lovgivning. Standarden er den fælles, stabile kerne; lovgivningen omkring den varierer fra land til land og ændrer sig over tid. Ofte er det niveau AA, der bruges som målestok, når tilgængelighed skal gøres til et krav, men det præcise omfang (hvilken version, hvilket niveau, hvilke typer indhold og hvilke frister) afgøres af den enkelte lov eller standard, ikke af WCAG selv.¹

Brug derfor WCAG til at forstå og teste selve tilgængeligheden, men slå de juridiske forpligtelser op i den lovgivning, der gælder for dit projekt og din organisation. Denne side beskriver standarden, ikke retstilstanden. Du bør ikke udlede specifikke lovkrav af WCAG-dokumentet, for eksempel hvilke organisationer der er omfattet, hvilke frister der gælder, eller hvilke sanktioner der kan komme på tale. De oplysninger hører hjemme i lovteksten og hos den relevante myndighed.¹

WCAG er skrevet til at kunne bære en juridisk henvisning. Fordi succeskriterierne er formuleret testbart og teknologineutralt, kan de bruges som et objektivt kravgrundlag: to parter kan blive enige om, hvorvidt et krav er opfyldt, uden at det afhænger af smag. Det gør også standarden brugbar i kontrakter og udbud. Vil du stille tilgængelighed som krav til en leverandør, så henvis til en konkret WCAG-version og et konkret niveau, for eksempel WCAG 2.2 niveau AA, frem for løse formuleringer om "tilgængelighed".¹

Hold de to lag adskilt. WCAG fortæller dig, hvordan tilgængeligt indhold ser ud og kan testes. Lovgivningen fortæller dig, om og hvornår du er forpligtet til at leve op til det. Husk den skelnen, både når du bygger, når du bestiller, og når nogen påstår, at "WCAG er lovpligtigt".¹

Ofte stillede spørgsmål

Kilder

1. Web Content Accessibility Guidelines (WCAG) 2.2W3C · Selve standarden. W3C Recommendation, aktuel udgave dateret 12. december 2024. Primær kilde til principper, niveauer, conformance og bagudkompatibilitet. Optalt af UX Indeks i oktober 2026: 86 gældende succeskriterier (31 A, 24 AA, 31 AAA) plus 4.1.1 Parsing markeret som "Obsolete and removed".
2. What's New in WCAG 2.2W3C / Web Accessibility Initiative (WAI) · Oversigt over de ni nye succeskriterier og fjernelsen af 4.1.1 Parsing.
3. WCAG 2 OverviewW3C / Web Accessibility Initiative (WAI) · WAI's introducerende overblik over WCAG-familien og dens dokumenter: WCAG 2.2 har 13 retningslinjer, tilføjer 9 succeskriterier, og 4.1.1 Parsing er forældet (opdateret 17. september 2026).