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 — kort sagt 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). At det er W3C, der står bag, er en væsentlig del af WCAG's autoritet: det er ikke et enkelt firmas eller en enkelt konsulents holdning til god praksis, men et konsensusdokument udarbejdet af en international arbejdsgruppe med deltagere fra industri, handicaporganisationer, forskning og offentlige myndigheder.¹

Den formelle status er vigtig at forstå. 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. Det er grunden til, at du trygt kan 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 — dokumenterne "Understanding WCAG 2.2" og "Techniques for WCAG 2.2" — som ikke er en del af den normerende standard, men forklarer intentionen bag hvert succeskriterium og giver konkrete teknikker til at opfylde det. Det er en vigtig skelnen, når du slår op: selve kravene står i WCAG 2.2-dokumentet, mens teknikkerne kun er eksempler på, hvordan man kan leve op til dem — ikke de eneste gyldige måder.¹

For dig som praktiker er den korte version: 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. Det er den egenskab — fælles, testbart sprog — der gør WCAG værd at kende, uanset om du selv skal bygge, teste eller bestille en løsning.

Sådan er WCAG bygget op: POUR, succeskriterier og niveauer

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 kan de gengives som opfattelig, betjenbar, forståelig og robust. Perceivable betyder, at information og brugerflade skal kunne opfattes af brugeren — den må ikke 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. De fire principper er fundamentet: hvis noget af det 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". Deres funktion er organisatorisk: 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. Netop testbarheden er det, der gør WCAG anvendelig som kravgrundlag i kontrakter og lovgivning — 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: AA er ikke et alternativ til A, men bygger ovenpå det. Når du læser en tilgængelighedserklæring eller stiller krav i et udbud, er det derfor niveauet du skal kigge efter — det afgør hele omfanget af, hvilke krav der gælder.¹

Hvad er nyt i WCAG 2.2

WCAG 2.2 er en videreudvikling af 2.1 og 2.0, ikke en omskrivning. Den grundlæggende arkitektur — 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, der er nyt, er ni ekstra succeskriterier plus fjernelsen af ét enkelt gammelt kriterium.²

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.²¹

Retningsmæssigt afspejler de nye kriterier tre tydelige 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. For brugere, der navigerer uden mus, er det afgørende hele tiden at 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 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. Og Accessible Authentication (3.3.8/3.3.9) adresserer et meget konkret problem: login må ikke 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 indsætning af adgangskoder fra en password-manager være tilladt.²

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 altså ikke starte forfra — du skal først og fremmest forholde dig til de ni nye kriterier og kan lade fjernelsen af Parsing lette listen en anelse. Det gør opgraderingen til 2.2 til en overskuelig, additiv øvelse frem for en migrering.¹²

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 vil du sjældent læse hele standarden; i stedet 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 — og derefter 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", er det værd at 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. Det er derfor, punktvise rettelser sjældent er nok: ét utilgængeligt trin kan bryde konformansen for hele forløbet.¹

En anden ting, du bør vide, er hvordan man dokumenterer resultatet. WCAG lægger op til, at man kan afgive 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 netop 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.¹

Endelig et praktisk råd om, hvor du henter dokumenterne. 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. Fordi materialet er gratis og offentligt, er der ingen god grund til at gætte: du kan slå det nøjagtige krav op på få sekunder.¹

WCAG, conformance og forholdet til lovgivning

Et vigtigt punkt at have helt skarpt: WCAG er en teknisk standard — 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.¹

Denne konstruktion — at loven peger på en ekstern teknisk standard — er netop grunden til, at det giver 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.¹

Derfor er det bedste råd også det mest nøgterne: brug WCAG til at forstå og teste selve tilgængeligheden, men slå de juridiske forpligtelser op i den gældende lovgivning, der gælder for netop dit projekt og din organisation. Denne side beskriver standarden, ikke retstilstanden, og du bør ikke udlede specifikke lovkrav — hvilke organisationer der er omfattet, hvilke frister der gælder, eller hvilke sanktioner der kan komme på tale — af WCAG-dokumentet. De oplysninger hører hjemme i lovteksten og hos den relevante myndighed.¹

Når det er sagt, er der en praktisk pointe i, at 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 er den samme egenskab, der gør standarden brugbar i kontrakter og udbud. Vil du stille tilgængelighed som krav til en leverandør, er det mest præcise, du kan gøre, at henvise til en konkret WCAG-version og et konkret niveau — for eksempel WCAG 2.2 niveau AA — frem for løse formuleringer om "tilgængelighed".¹

Kort sagt: 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. De to hænger tæt sammen i praksis, men de er ikke det samme — og præcis den skelnen er værd at holde fast i, 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.
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.