WCAG 2.2 på dansk: Alle krav på niveau A og AA forklaret
Sebastian Thiemann19. oktober 2026WCAG (Web Content Accessibility Guidelines) er de internationale retningslinjer for, hvordan hjemmesider, webshops og apps kan bruges af alle, også af folk, der ser dårligt, ikke kan bruge en mus eller bruger skærmlæser. Retningslinjerne kommer fra W3C. Den nyeste version er WCAG 2.2, og de fleste sigter efter niveau AA, som består af 55 krav.
Her får du WCAG 2.2 forklaret på dansk: hvordan retningslinjerne er bygget op, hvilken version du skal følge, hvad der er nyt i 2.2, alle krav på niveau A og AA i almindeligt sprog, de tal du skal kende, og hvordan du selv tester din hjemmeside. Vil du vide, hvad loven kræver af din webshop, så læs vores artikel om tilgængelighedsloven.
WCAG kort fortalt
- Hvad: internationale retningslinjer for tilgængeligt webindhold fra W3C.
- Nyeste version: WCAG 2.2 fra oktober 2023, opdateret i december 2024.
- Opbygning: 4 principper, 13 retningslinjer og 86 krav, der kaldes succeskriterier.
- Niveauer: A, AA og AAA. Niveau AA er det, de fleste sigter efter. Det er 55 krav i WCAG 2.2.
- Lov: WCAG er ikke i sig selv lov. Men den europæiske standard EN 301 549, som de danske regler peger på, bygger på WCAG.
- WCAG 3.0: er stadig et udkast og bliver først færdig om flere år.
Hvad er WCAG?
WCAG udgives af W3C (World Wide Web Consortium), den internationale organisation bag en række af nettets standarder, fx CSS. Retningslinjerne beskriver, hvad der skal til, for at indhold på nettet kan bruges af mennesker med forskellige behov: blinde og svagsynede, døve og hørehæmmede, folk med motoriske eller kognitive handicap, og alle os andre, der fx bruger telefonen i skarpt sollys eller har armen i gips.
WCAG er bygget op i fire lag:
- Principper: 4 overordnede principper. Indholdet skal være opfatteligt, anvendeligt, forståeligt og robust.
- Retningslinjer: 13 retningslinjer under principperne, fx 1.4 Adskillelig, der handler om at gøre det lettere at se og høre indhold.
- Succeskriterier: 86 konkrete krav, der kan testes. Det er dem, man måler efter.
- Teknikker: W3C's eksempler på, hvordan man kan opfylde kravene. De er vejledning, ikke krav.
Kravene har numre som 1.4.3. Det første tal er princippet, det andet retningslinjen og det tredje selve kravet. Den officielle danske oversættelse kalder dem succeskriterier, men i daglig tale siger de fleste bare krav. Det gør vi også her.
WCAG-versionerne: 2.0, 2.1, 2.2 og 3.0
| Version | Udgivet | Hvad den tilføjede | Status |
|---|---|---|---|
| WCAG 2.0 | December 2008 | De fire principper og opbygningen med succeskriterier, som stadig bruges | Gældende W3C-anbefaling. Var ISO-standard (ISO/IEC 40500:2012), som nu er erstattet af ISO/IEC 40500:2025 |
| WCAG 2.1 | Juni 2018, senest opdateret maj 2025 | 17 nye krav, især om mobil, svagsynede og kognitive handicap | Gældende. Grundlaget for EN 301 549 V3.2.1 |
| WCAG 2.2 | Oktober 2023, opdateret december 2024 | 9 nye krav om fokus, klikflader, trækbevægelser, hjælp, gentagen indtastning og login. Kravet 4.1.1 Parsing er fjernet | Nyeste version. Også ISO-standard (ISO/IEC 40500:2025, svarer til versionen fra oktober 2023) |
| WCAG 3.0 | Udkast, senest september 2026 | En ny model for at måle tilgængelighed | Ikke færdig. Forventes først om flere år |
Versionerne er bagudkompatible. W3C skriver, at indhold, der overholder WCAG 2.2, også overholder WCAG 2.1 og 2.0. WCAG 2.2 erstatter dog ikke formelt 2.1, og begge er stadig gyldige W3C-anbefalinger.
Skal du følge WCAG 2.1 eller 2.2?
Kort svar: WCAG 2.2. Her er hvorfor.
De danske regler henviser ikke direkte til WCAG, men til den europæiske standard EN 301 549, der bygger på WCAG. Den version, der gælder i dag, er EN 301 549 V3.2.1 fra 2021. Den henviser til WCAG 2.1 niveau AA, og det er den, offentlige myndigheder bruger til at vise, at de lever op til webtilgængelighedsloven.
I september 2026 udgav ETSI den nye version, EN 301 549 V4.1.1, som er opdateret til WCAG 2.2. Den forventes offentliggjort i EU-Tidende i slutningen af 2026. Den irske National Disability Authority nævner 16. december 2026, Digitaliseringsstyrelsen 30. november 2026. Indtil da er det V3.2.1, der gælder.
Fordi 2.2 er bagudkompatibel, er der ingen grund til at bygge efter 2.1 i dag. Opfylder du WCAG 2.2 niveau AA, opfylder du også 2.1 niveau AA, og du er klar, når den nye standard træder i kraft. Er du en offentlig myndighed, der rapporterer efter V3.2.1, kan du dog stadig skulle teste og rapportere 4.1.1 Parsing. Vores anbefaling: byg efter WCAG 2.2 niveau AA.
De fire principper
Alle krav i WCAG hører under et af fire principper. På engelsk kaldes de ofte POUR efter forbogstaverne.
| Princip | Hvad det betyder | Krav på A og AA |
|---|---|---|
| Opfattelig (Perceivable) | Alle skal kunne opfatte indholdet, også uden at se eller høre det. Fx tekstalternativer til billeder, undertekster til video og nok kontrast. | 20 |
| Anvendelig (Operable) | Alt skal kunne betjenes, også med tastatur og uden præcise musebevægelser. Fx tastaturbetjening, synligt fokus og nok tid. | 20 |
| Forståelig (Understandable) | Indhold og funktioner skal være til at forstå og forudsige. Fx ensartet navigation og hjælp, når man udfylder formularer forkert. | 13 |
| Robust (Robust) | Koden skal kunne læses korrekt af browsere og hjælpemidler som skærmlæsere. Fx at knapper og felter har navn og rolle i koden. | 2 |
Niveau A, AA og AAA
Hvert krav har et niveau, og niveauerne bygger oven på hinanden:
- Niveau A er minimum. Kravene fjerner de barrierer, der gør indhold helt umuligt at bruge for nogle.
- Niveau AA betyder, at alle krav på niveau A og AA er opfyldt. Det er det niveau, EN 301 549 henviser til, og det, de fleste sigter efter.
- Niveau AAA er det højeste. W3C anbefaler ikke at kræve AAA for hele hjemmesider, fordi nogle af kravene ikke kan opfyldes for alt indhold. Enkelte AAA-krav kan sagtens give mening, fx en tydeligere fokusmarkering.
| Antal krav | WCAG 2.1 | WCAG 2.2 |
|---|---|---|
| Niveau A | 30 | 31 |
| Niveau AA | 20 | 24 |
| A og AA i alt | 50 | 55 |
| Niveau AAA | 28 | 31 |
| Alle krav | 78 | 86 |
Tallene er talt op fra W3C's specifikation. I WCAG 2.2 er 4.1.1 Parsing ikke talt med, fordi kravet er fjernet.
Sådan måler man, om en side overholder WCAG
Ud over selve niveauet stiller W3C fire krav til overholdelse, som ofte bliver overset:
- Hele sider: En side overholder kun et niveau, hvis hele siden gør. Du kan ikke undtage fx en chat eller et cookiebanner.
- Hele processer: Er siden en del af en proces, fx et køb i flere trin, skal alle sider i processen overholde niveauet.
- Understøttet teknik: Indholdet skal virke med de browsere og hjælpemidler, brugerne faktisk bruger.
- Ingen forstyrrelse: Teknik, der ikke er tilgængelig, må ikke blokere for resten af siden.
Overholder siden alle krav bortset fra indhold fra en tredjepart, som du ikke har kontrol over, kan du højst erklære delvis overholdelse. Det er efter W3C's egen definition en erklæring om, at siden ikke overholder kravene.
De 9 nye krav i WCAG 2.2
WCAG 2.2 tilføjede 9 krav: 2 på niveau A, 4 på niveau AA og 3 på niveau AAA. Samtidig blev 4.1.1 Parsing fjernet, fordi det ikke længere er relevant for moderne browsere og hjælpemidler. Der findes ingen officiel dansk oversættelse af WCAG 2.2, så de danske navne her er vores egne.
2.4.11 Fokus ikke skjult (minimum), niveau AA
Når et element får fokus med tastaturet, må det ikke være helt skjult af noget, der ligger på siden. Typiske syndere er en fast header, et cookiebanner eller en chatknap, der dækker det felt eller den knap, man lige har tabbet til.
Sådan løser du det: Brug scroll-padding-top i CSS, så siden ruller fokus fri af en fast header, og sørg for, at bannere ikke dækker indholdet, eller at de kan lukkes.
2.4.12 Fokus ikke skjult (udvidet), niveau AAA
Som 2.4.11, men her må ingen del af elementet med fokus være skjult.
2.4.13 Fokusudseende, niveau AAA
Fokusmarkeringen skal være mindst lige så stor som en 2 CSS-pixels tyk kant rundt om elementet og have en kontrast på mindst 3:1 mellem tilstanden med og uden fokus. Det er et AAA-krav, men det er en god og konkret tommelfingerregel for, hvordan en tydelig fokusmarkering ser ud.
2.5.7 Trækbevægelser, niveau AA
Alt, der kan gøres ved at trække, skal også kunne gøres med et enkelt klik eller tryk, medmindre trækket er nødvendigt. Eksempler er en prisslider i et filter, et kort, man flytter ved at trække, eller en liste, man sorterer ved at trække elementerne rundt.
Sådan løser du det: Giv prisslideren felter, hvor man kan skrive beløbet, kortet knapper til at flytte og zoome, og listen knapper til at flytte et element op og ned.
2.5.8 Målstørrelse (minimum), niveau AA
Det, man kan klikke eller trykke på, skal være mindst 24 x 24 CSS-pixels. Er det mindre, skal der være så meget afstand, at en cirkel på 24 pixels i diameter, centreret på hvert element, ikke rammer andre klikbare elementer eller deres cirkler. Der er undtagelser, bl.a. for links i løbende tekst, for standardkontroller, hvis størrelse bestemmes af browseren og ikke er ændret (fx kalenderen i en datovælger), og når samme funktion findes i en anden kontrol på siden, der er stor nok.
Bemærk: Du ser ofte 44 x 44 pixels nævnt som kravet. Det er kravet i 2.5.5 Målstørrelse (udvidet), som er niveau AAA. På niveau AA er kravet 24 x 24 CSS-pixels.
3.2.6 Ensartet hjælp, niveau A
Tilbyder du hjælp på flere sider, fx telefonnummer, mail, chat eller en FAQ, skal den stå i samme rækkefølge i forhold til resten af indholdet på alle siderne. Den behøver ikke stå præcis samme sted visuelt. Kravet betyder ikke, at du skal tilbyde hjælp, kun at den skal være let at finde igen.
3.3.7 Overflødig indtastning, niveau A
Brugeren må ikke skulle indtaste de samme oplysninger to gange i samme proces. Oplysningerne skal enten udfyldes automatisk eller kunne vælges. Det klassiske eksempel er checkout, hvor leveringsadressen også skal kunne bruges som faktureringsadresse med et enkelt flueben. Der er undtagelser, fx når det er nødvendigt, af sikkerhedshensyn, eller når de tidligere oplysninger ikke længere er gyldige.
3.3.8 Tilgængelig autentificering (minimum), niveau AA
Login må ikke kræve en kognitiv test, fx at huske en adgangskode eller løse en opgave, medmindre der er et alternativ eller en hjælp. I praksis betyder det:
- Brugeren skal kunne indsætte adgangskoden og bruge en password manager. Bloker ikke kopier og indsæt.
- Engangskoder skal kunne indsættes og ikke kun skrives af.
- Login med et link på mail, en passkey eller en konto hos fx Google eller Microsoft er gode alternativer.
- En CAPTCHA, hvor man skal genkende objekter på billeder, er tilladt på niveau AA, men ikke på AAA.
3.3.9 Tilgængelig autentificering (udvidet), niveau AAA
Som 3.3.8, men uden undtagelserne for genkendelse af objekter og personligt indhold. Her er billed-CAPTCHA altså heller ikke tilladt.
Alle 55 krav på niveau A og AA
Her er alle krav på niveau A og AA i WCAG 2.2, delt op efter de fire principper. Navnene er fra Digitaliseringsstyrelsens autoriserede danske oversættelse af WCAG 2.1. Navnene på de nye krav fra 2.2 er vores egne og markeret med (ny i 2.2). Kolonnen Ansvar viser, hvem der typisk skal sørge for kravet: den, der designer, den, der udvikler, eller den, der skriver indholdet. Ved tvivl er det den engelske WCAG 2.2, der gælder.
1. Opfattelig (20 krav)
| Krav | Niveau | Hvad det betyder i praksis | Ansvar |
|---|---|---|---|
| 1.1.1 Ikke-tekstbaseret indhold | A | Billeder, ikoner og billedknapper har et tekstalternativ (alt-tekst). Rent dekorative billeder skjules for skærmlæsere. | Indhold, udvikling |
| 1.2.1 Rent lydindhold (audio only) og rent videoindhold (video only) (forudindspillet) | A | Optaget lyd uden billede har en tekstversion. Video uden lyd har en tekstversion eller et lydspor, der beskriver den. | Indhold |
| 1.2.2 Undertekster (forudindspillet) | A | Optagede videoer med lyd har undertekster. | Indhold |
| 1.2.3 Synstolkning eller mediealternativ (forudindspillet) | A | Det vigtige, der kun vises i billedet i en video, er beskrevet med synstolkning eller en tekstversion. | Indhold |
| 1.2.4 Undertekster (direkte) | AA | Livevideo med lyd har undertekster. | Indhold |
| 1.2.5 Synstolkning (forudindspillet) | AA | Optagede videoer har synstolkning af det vigtige, der kun ses i billedet. | Indhold |
| 1.3.1 Information og relationer | A | Den struktur, man kan se, findes også i koden: overskrifter er overskrifter, lister er lister, og felter er koblet til deres label. | Udvikling, indhold |
| 1.3.2 Meningsfuld rækkefølge | A | Rækkefølgen i koden giver mening, når siden læses op. | Udvikling |
| 1.3.3 Sensoriske egenskaber | A | Instruktioner afhænger ikke kun af form, placering eller lyd, fx “klik på den runde knap til højre”. | Indhold, design |
| 1.3.4 Retning | AA | Siden virker både på højkant og på tværs og er ikke låst til én retning. | Udvikling |
| 1.3.5 Identificering af inputformål | AA | Felter til personoplysninger som navn, mail og adresse har den rigtige autocomplete-værdi, så browseren kan udfylde dem. | Udvikling |
| 1.4.1 Anvendelse af farve | A | Farve er ikke den eneste måde at vise information på. En fejl i et felt vises også med tekst eller ikon, og links i brødtekst kan skelnes fra anden tekst, typisk med understregning. | Design |
| 1.4.2 Kontrol af lyd | A | Lyd, der starter automatisk og varer mere end 3 sekunder, kan sættes på pause, stoppes eller skrues ned uafhængigt af enhedens samlede lydstyrke. | Udvikling |
| 1.4.3 Kontrast (minimum) | AA | Tekst har en kontrast på mindst 4,5:1 mod baggrunden, stor tekst mindst 3:1. | Design |
| 1.4.4 Ændring af tekststørrelse | AA | Tekst kan forstørres til 200 %, uden at indhold eller funktioner går tabt. | Udvikling, design |
| 1.4.5 Billeder af tekst | AA | Tekst er rigtig tekst og ikke et billede af tekst. Logoer er undtaget. | Design, indhold |
| 1.4.10 Ombrydningsvisning | AA | Siden kan vises i en bredde på 320 CSS-pixels, svarende til 400 % zoom, uden at man skal scrolle vandret for at læse. | Udvikling |
| 1.4.11 Kontrast for ikke-tekstbaseret indhold | AA | Det, der skal til for at se felter, knapper og deres tilstand, fokusmarkering og nødvendige ikoner, har en kontrast på mindst 3:1. Fx en feltkant, hvis det er den eneste, der viser feltet. En knap med tekst behøver ikke en kant. | Design |
| 1.4.12 Tekstafstand | AA | Intet går tabt, hvis brugeren selv øger linjeafstand, afstand mellem afsnit, bogstaver og ord. | Udvikling |
| 1.4.13 Indhold ved svævepegning (hover) eller fokus | AA | Tooltips og menuer, der vises ved hover eller fokus, kan lukkes uden at flytte musen eller fokus, typisk med Esc, forsvinder ikke, når man flytter musen hen over dem, og bliver stående, til brugeren fjerner dem. | Udvikling |
2. Anvendelig (20 krav)
| Krav | Niveau | Hvad det betyder i praksis | Ansvar |
|---|---|---|---|
| 2.1.1 Tastatur | A | Alt kan betjenes med tastaturet: menu, filtre, kurv, formularer og pop-ups. | Udvikling |
| 2.1.2 Ingen tastaturfælde | A | Man kan altid komme videre med tastaturet og sidder ikke fast i fx en video eller et indlejret kort. | Udvikling |
| 2.1.4 Genvejstaster | A | Genveje på et enkelt tegn kan slås fra eller ændres, eller virker kun, når det element, de hører til, har fokus. Så aktiveres de ikke ved en fejl, fx med stemmestyring. | Udvikling |
| 2.2.1 Justerbar Tidsbegrænsning (Timing) | A | Tidsgrænser kan slås fra, justeres eller forlænges, fx en session, der udløber. | Udvikling |
| 2.2.2 Pause, stop, skjul | A | Indhold, der bevæger sig, blinker eller opdaterer automatisk, fx en karrusel, kan sættes på pause, stoppes eller skjules. | Udvikling, design |
| 2.3.1 Grænseværdi på tre glimt eller derunder | A | Intet blinker mere end 3 gange i sekundet, medmindre blinket er under grænseværdierne for generelle og røde glimt, fx fordi det er meget lille. | Design, indhold |
| 2.4.1 Spring over blokke | A | Man kan springe gentaget indhold over, typisk med et “Gå til indhold”-link øverst på siden. | Udvikling |
| 2.4.2 Sider har titler | A | Hver side har en titel, der beskriver emne eller formål. | Indhold, udvikling |
| 2.4.3 Fokusrækkefølge | A | Fokus flytter i en logisk rækkefølge, når man bruger Tab. | Udvikling |
| 2.4.4 Formål med links (i kontekst) | A | Det fremgår af linkteksten eller sammenhængen, hvor linket fører hen. Undgå “Læs mere” uden sammenhæng. | Indhold |
| 2.4.5 Flere måder | AA | Der er mere end én måde at finde en side på, fx menu og søgning. | Udvikling, design |
| 2.4.6 Overskrifter og etiketter | AA | Overskrifter og labels beskriver emnet eller formålet. | Indhold |
| 2.4.7 Synligt fokus | AA | Man kan altid se, hvilket element der har fokus, når man bruger tastaturet. Fjern aldrig fokusmarkeringen uden at erstatte den. | Design, udvikling |
| 2.4.11 Fokus ikke skjult (minimum) (ny i 2.2) | AA | Elementet med fokus er ikke helt skjult af fx en fast header, et cookiebanner eller en chat. | Udvikling, design |
| 2.5.1 Pegebevægelser (Pointer Gestures) | A | Funktioner, der kræver flere fingre eller en bestemt bevægelse, fx at knibe eller swipe, kan også bruges med et enkelt tryk. | Udvikling |
| 2.5.2 Pege-annullering | A | Handlingen udføres, når man slipper, ikke når man trykker ned. Så kan man fortryde ved at trække fingeren væk. | Udvikling |
| 2.5.3 Etiket i navn | A | Knappens navn i koden indeholder den tekst, man kan se på knappen. Det er vigtigt for stemmestyring. | Udvikling |
| 2.5.4 Betjening via bevægelse | A | Funktioner, der aktiveres ved at ryste eller vippe telefonen, kan også bruges med en knap, og bevægelsen kan slås fra. | Udvikling |
| 2.5.7 Trækbevægelser (ny i 2.2) | AA | Alt, der kan gøres ved at trække, kan også gøres med enkelte klik eller tryk. | Udvikling, design |
| 2.5.8 Målstørrelse (minimum) (ny i 2.2) | AA | Det, man kan klikke på, er mindst 24 x 24 CSS-pixels eller har nok afstand til andre klikbare elementer. | Design |
3. Forståelig (13 krav)
| Krav | Niveau | Hvad det betyder i praksis | Ansvar |
|---|---|---|---|
| 3.1.1 Sproget på siden | A | Sidens sprog er angivet i koden, fx lang="da", så skærmlæsere udtaler teksten rigtigt. | Udvikling |
| 3.1.2 Sprog, der anvendes til dele af indhold | AA | Afsnit på et andet sprog er markeret med deres sprog. | Udvikling, indhold |
| 3.2.1 I fokus | A | Der sker ikke uventede ændringer, fx en ny side eller et nyt vindue, bare fordi et element får fokus. | Udvikling |
| 3.2.2 Ved input | A | At udfylde et felt eller vælge en mulighed ændrer ikke siden uventet, medmindre brugeren er gjort opmærksom på det på forhånd. | Udvikling |
| 3.2.3 Konsekvent navigation | AA | Navigation, der går igen på flere sider, står i samme rækkefølge. | Design |
| 3.2.4 Konsekvent identifikation | AA | Ting med samme funktion har samme navn og ikon på tværs af sider. | Design, indhold |
| 3.2.6 Ensartet hjælp (ny i 2.2) | A | Hjælp som telefon, mail, chat eller FAQ står i samme rækkefølge i forhold til resten af indholdet på de sider, hvor den findes. | Design |
| 3.3.1 Identifikation af fejl | A | Fejl i formularer bliver vist med tekst, der fortæller, hvilket felt der er galt. | Udvikling, indhold |
| 3.3.2 Etiketter eller instruktioner | A | Felter har labels eller instruktioner, fx om feltet er påkrævet, eller hvilket format en dato skal have. | Design, indhold |
| 3.3.3 Fejlforslag | AA | Når en fejl bliver fundet, får brugeren et forslag til, hvordan den rettes, hvis det er muligt. | Indhold, udvikling |
| 3.3.4 Forhindring af fejl (juridisk, økonomisk, data) | AA | Ved køb, aftaler og sletning af data kan brugeren fortryde, rette eller bekræfte, før det er endeligt. | Udvikling |
| 3.3.7 Overflødig indtastning (ny i 2.2) | A | Oplysninger, brugeren allerede har givet i samme proces, bliver udfyldt automatisk eller kan vælges. | Udvikling |
| 3.3.8 Tilgængelig autentificering (minimum) (ny i 2.2) | AA | Login kræver ikke, at man husker eller skriver noget af uden hjælp. Indsæt og password managers skal virke. | Udvikling |
4. Robust (2 krav)
| Krav | Niveau | Hvad det betyder i praksis | Ansvar |
|---|---|---|---|
| 4.1.2 Navn, rolle, værdi | A | Knapper, felter, menuer og andre komponenter har navn, rolle og tilstand i koden, så hjælpemidler forstår dem. Brug rigtige HTML-elementer, fx <button> frem for <div>. | Udvikling |
| 4.1.3 Statusbeskeder | AA | Beskeder som “Lagt i kurven” eller “3 resultater” bliver læst op af skærmlæsere uden at flytte fokus. | Udvikling |
Skal du skrive alt-tekster til mange billeder, kan vores gratis Alt Text Optimizer hjælpe dig i gang.
Tallene du skal kende
Mange WCAG-krav handler om vurdering, men nogle har faste tal. Her er de vigtigste:
| Hvad | Krav | Niveau | Krav nr. |
|---|---|---|---|
| Kontrast, almindelig tekst | Mindst 4,5:1 | AA | 1.4.3 |
| Kontrast, stor tekst | Mindst 3:1 | AA | 1.4.3 |
| Kontrast, udvidet | Mindst 7:1, stor tekst 4,5:1 | AAA | 1.4.6 |
| Kontrast på grafik, der er nødvendig for at se felter, knapper, ikoner og fokus | Mindst 3:1 | AA | 1.4.11 |
| Klikflader | Mindst 24 x 24 CSS-pixels eller nok afstand | AA | 2.5.8 |
| Klikflader, udvidet | Mindst 44 x 44 CSS-pixels | AAA | 2.5.5 |
| Forstørrelse af tekst | 200 % uden tab af indhold | AA | 1.4.4 |
| Ombrydning | 320 CSS-pixels bredde uden vandret scroll | AA | 1.4.10 |
| Tekstafstand | Intet går tabt, når brugeren sætter linjeafstand til 1,5 gange skriftstørrelsen, afsnit til 2 gange, bogstaver til 0,12 gange og ord til 0,16 gange | AA | 1.4.12 |
| Blink | Højst 3 gange i sekundet, medmindre blinket er under grænseværdierne | A | 2.3.1 |
| Lyd, der starter automatisk | Kan sættes på pause, stoppes eller skrues ned, hvis den varer mere end 3 sekunder | A | 1.4.2 |
| Bevægeligt indhold | Kan sættes på pause, stoppes eller skjules, hvis det starter automatisk, varer mere end 5 sekunder og vises sammen med andet indhold | A | 2.2.2 |
Stor tekst er efter W3C mindst 18 punkt eller 14 punkt fed, svarende til cirka 24 pixels eller cirka 18,5 pixels fed. Logoer, inaktive knapper og ren dekoration er undtaget fra kontrastkravet. Kontrast kan du måle med en gratis kontrastberegner, fx WebAIM Contrast Checker, eller i udviklerværktøjerne i Chrome, hvor kontrastforholdet står, når du inspicerer en tekst.
Sådan tester du WCAG selv
W3C skriver selv, at værktøjer ikke kan afgøre, om en hjemmeside er tilgængelig. De kan kun hjælpe. Da GOV.UK i 2017 lavede en testside med 143 bevidste fejl, fandt ingen af de 10 testede værktøjer 29 % af fejlene. Testen er gammel og bygger på én side, men pointen holder: Automatisk test er et godt sted at starte, men du skal også teste i hånden.
Test de vigtigste sidetyper, fx forsiden, en underside, en formular og en eventuel kurv. Tallene i parentes er de krav, trinnet tjekker.
- Kør en automatisk test. Brug axe DevTools eller WAVE som udvidelse i browseren, eller Lighthouse, der er indbygget i Chrome. De finder typisk manglende alt-tekster, felter uden labels, lav kontrast og manglende sprog. (1.1.1, 1.3.1, 1.4.3, 3.1.1, 4.1.2)
- Brug kun tastaturet. Tab dig gennem hele siden. Kan du nå og bruge alt? Kan du se, hvor fokus er? Er rækkefølgen logisk? Bliver fokus dækket af noget? Kan du åbne og lukke menuer og pop-ups? (2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11)
- Zoom til 200 % og 400 %. Ved 200 % skal alt kunne læses og bruges. Ved 400 % på en skærm, der er 1280 pixels bred, svarende til 320 pixels, må du ikke skulle scrolle vandret for at læse. (1.4.4, 1.4.10)
- Tjek kontrasten. Mål tekst, knapper, feltkanter og fokusmarkering med en kontrastberegner. (1.4.3, 1.4.11)
- Tjek klikflader på mobil. Mål små ikoner, lukkeknapper og links i menuen med udviklerværktøjerne. Er de under 24 x 24 pixels, skal der være luft nok omkring dem. (2.5.8)
- Lyt med en skærmlæser. Brug VoiceOver på Mac og iPhone eller det gratis program NVDA på Windows. Giver billeder, knapper og links mening, når de bliver læst op? Bliver statusbeskeder og fejl læst op? (1.1.1, 2.4.4, 4.1.2, 4.1.3)
- Udfyld formularerne forkert. Lad påkrævede felter stå tomme, og skriv en forkert mail. Får du en tydelig fejlbesked i tekst med et forslag til, hvordan du retter den? (3.3.1, 3.3.2, 3.3.3)
- Gennemfør hele processen. Køb, book eller log ind fra start til slut med tastaturet. Skal du skrive noget to gange? Kan du indsætte din adgangskode? (3.3.7, 3.3.8)
- Tjek video og lyd. Har videoer undertekster, og kan lyd og bevægelse stoppes? (1.2.2, 1.4.2, 2.2.2)
- Skriv fejlene ned, og ret dem. Start med dem, der blokerer helt, fx en knap, der ikke kan bruges med tastatur, eller et felt uden label.
Digitaliseringsstyrelsen har en god vejledning i manuelle testmetoder. Har du en webshop, så se også vores artikel om tilgængelighedsloven, hvor vi gennemgår, hvordan du tester din webshop på 30 minutter, og hvad du selv skal tjekke i Shopify og WooCommerce.
Hvad siger loven om WCAG?
WCAG er ikke i sig selv lov. Men der er to danske love om digital tilgængelighed, og begge hænger sammen med standarden EN 301 549, der bygger på WCAG:
- Webtilgængelighedsloven gælder for offentlige myndigheder og offentligretlige organer. De bruger EN 301 549 V3.2.1, som henviser til WCAG 2.1 niveau AA, og de skal have en tilgængelighedserklæring. Loven gælder som udgangspunkt ikke for private virksomheder.
- Tilgængelighedsloven er den danske udgave af European Accessibility Act. Den gælder for udvalgte produkter og tjenester til forbrugere, fx webshops, og har haft virkning siden 28. juni 2025. Mikrovirksomheder er undtaget fra kravene til tjenester. Loven nævner ikke WCAG direkte.
Har du en webshop, der sælger til forbrugere, så læs vores artikel om tilgængelighedsloven. Den gennemgår, hvem der er omfattet, undtagelserne, oplysningspligten og tilsynet. Har du en almindelig hjemmeside, hvor forbrugere ikke kan indgå aftaler online, fx købe, bestille eller booke, er du som udgangspunkt ikke omfattet af tilgængelighedsloven. Det gælder typisk for mange håndværkere og rådgivere. WCAG er stadig god praksis: Flere kan bruge din side, og mange af kravene, fx tydelige knapper, gode formularer og læsbar tekst, gør siden bedre for alle.
Kan en widget gøre din hjemmeside WCAG-kompatibel?
Nej. Såkaldte overlays eller tilgængelighedswidgets lægger en knap på siden, hvor brugeren kan ændre fx skriftstørrelse og kontrast. Men de retter ikke fejlene i selve koden. Mangler en knap en label, eller kan menuen ikke bruges med tastatur, er det stadig sådan, med eller uden widget.
Den europæiske handicaporganisation EDF og den internationale forening for tilgængelighedsfagfolk IAAP skrev i 2023 i en fælles erklæring, at overlays ikke gør en hjemmeside tilgængelig eller i overensstemmelse med europæisk lovgivning. I USA endte den amerikanske forbrugermyndighed FTC i 2025 en sag mod virksomheden accessiBe med et forlig på 1 million dollars. FTC havde anklaget virksomheden for vildledende markedsføring af, at dens widget kunne gøre enhver hjemmeside WCAG-kompatibel.
WCAG 3.0: skal du vente?
Nej. WCAG 3.0 er en ny model for at måle tilgængelighed, men den er stadig et udkast. Det seneste udkast er fra september 2026, og W3C skriver, at WCAG 3 først forventes at blive en færdig standard om nogle år. Den erstatter heller ikke WCAG 2 med det samme. Ifølge W3C bliver WCAG 2 først udfaset flere år efter, at WCAG 3 er færdig.
W3C's eget råd er, at den bedste måde at forberede sig på WCAG 3 er at opfylde WCAG 2.2 i dag.
Kom i gang med WCAG
Du behøver ikke rette alt på én gang. Start med de krav, der går igen på mange sider: kontrast, tastaturbetjening, synligt fokus, alt-tekster og labels på felter. Brug testen ovenfor, skriv fejlene ned, og ret dem i temaet og skabelonerne, så rettelsen slår igennem på alle sider.
Tilgængelighed og brugervenlighed hænger tæt sammen. Læs også vores guide til en brugervenlig hjemmeside.
Skal du have en ny hjemmeside eller webshop, er det nemmere at bygge efter WCAG fra start end at rette bagefter. Vi bygger efter WCAG-retningslinjerne fra første skitse. Læs mere om, hvordan vi laver en ny hjemmeside eller en webshop, eller kontakt os, hvis du vil have hjælp til at gøre din side mere tilgængelig.
