WCAG 2.2 er nu det gældende AA-mål i EU via det europæiske tilgængelighedsdirektiv og den harmoniserede standard EN 301 549, og det er det de facto-benchmark amerikanske domstole måler ADA-dækkede websteder mod, selv hvor reglerne stadig navngiver 2.1. Standarden er veldokumenteret; vejen fra “vi ved, vi skal overholde” til “vi har en forsvarlig praksis” er det ikke. Denne guide er den vej, i seks trin, i den rækkefølge et team faktisk bør udføre dem.

WCAG 2.2 er den nuværende version af Retningslinjer for tilgængeligt webindhold (WCAG), udgivet af W3C som en Recommendation i oktober 2023. Den definerer 86 succeskriterier organiseret under fire principper — indhold skal være opfatteligt, operabelt, forståeligt og robust. Hvert kriterium er tildelt et overensstemmelsesniveau. Niveau A er minimumsgrænsen; niveau AA er det praktiske benchmark, som enhver større tilsynsmyndighed refererer til; niveau AAA er aspiratorisk og er ikke et regulatorisk minimum noget sted.

Når en tilsynsmyndighed eller en kontrakt siger “WCAG 2.2 AA-kompatibel”, mener den mere end at bestå på én side. W3C’s overensstemmelsesdefinition kræver, at hele overensstemmelsesenheden — siden eller det sæt af sider, der udgør en proces — opfylder hvert niveau A- og AA-kriterium, at enhver proces er tilgængelig fra start til slut, og at hjælpeteknologi ikke skal slås fra for at indholdet virker. Et websted der opfylder de fleste kriterier på de fleste sider er ikke overensstemmende; ribben er fuld dækning.

WCAG 2.2 tilføjer ni nye kriterier i forhold til 2.1 — fokusudseende, målstørrelse, træk, redundant indtastning, tilgængelig godkendelse, konsekvent hjælp og et par andre. Websteder, der var 2.1 AA-overensstemmende, er ikke automatisk 2.2 AA-overensstemmende; de nye kriterier er, hvor kløften viser sig. Den kriterium-for-kriterium-kilde til sandheden er vores fulde WCAG 2.2-succeskriteriehenvisning.

Overholdelse er en praksis, ikke en tilstand — et websted, der er overensstemmende på mandag, kan sende en regression afsted på tirsdag. At behandle det som et engangsprojekt er den mest almindelige og dyreste fejl på området.

Man kan ikke rette det, man ikke har målt, og ét værktøj vil ikke måle det godt. En baselinje-gennemgang kører i tre modi på ca. det samme sæt sider.

Modus 1 — Automatiseret scanning. En scanner rapporterer maskinelkontrollerbare fejl — manglende alternativ tekst, manglende formularetiketter, lav farvekontrast, ugyldig ARIA, problemer med overskriftsstruktur. Den fanger de tætte, gentagne problemer, en ingeniør ellers ville jage manuelt, men kan ikke vurdere, om alternativ tekst er meningsfuld, om et skræddersyet widget føles rigtigt under en skærmlæser, eller om fokusrækkefølgen giver kognitiv mening. Behandl scanningen som en volumenbaselinje, ikke som en dom. Start med at køre den gratis WCAG 2.2-scanner på dine ti vigtigste sider — forside, login, checkout, to produktsider, dashboard, kontoindstillinger, tilgængelighedserklæringssiden hvis den eksisterer og de to landingssider med højest trafik. Scanningen fortæller dig, om du har hundrede eller titusinde problemer, hvilket er det første, en udbedringsleder har brug for at vide.

Modus 2 — Manuel gennemgang af en seende tilgængeligheds-specialist. En uddannet gennemgangsperson, der arbejder sig igennem de samme sider, fanger det, automation ikke kan vurdere. Er alternativ teksten præcis? Er overskriftsstrukturen logisk, ikke blot syntaktisk gyldig? Eksponerer skræddersyede widgets det rette navn, rolle og tilstand? En specialist dækker ca. 15–20 sider om dagen; resultatet er en skriftlig rapport med gengivelsestrin kortlagt til specifikke succeskriterier.

Modus 3 — Brugbarheds-gennemgang med mennesker der bruger hjælpeteknologi. En skærmlæserbruger kører checkout; en tastaturbruger navigerer dashboardet; en svagsynet bruger udfylder kontaktformularen ved 200 % zoom. Resultatet er kvalitativt — “annoncementet ved indsendelse sker, inden fokus flyttes, så jeg gik glip af det” — og det er det lag, der adskiller overholdelse fra tilgængelighed. Dette er den modus, organisationer oftest springer over; gør man det, vil man bestå scanninger og erklæringer, mens brugerne stadig ikke kan gennemføre deres opgaver.

De tre modi supplerer hinanden: automation finder volumen, specialistgennemgang finder de strukturelle og semantiske problemer, brugertestning finder oplevelsesfejlene. En første baselinje, der kører alle tre, tager to til fire uger for et mellemstort websted.

En baselinje-gennemgang på et typisk websted afslører hundredevis til tusindvis af problemer. At starte øverst på en flad liste er en måde at bruge tre måneder på uden at flytte nålen. Triage kører på to akser — alvorlighed og rækkevidde.

Alvorlighed er, hvor alvorligt problemet ødelægger oplevelsen. Blokere forhindrer opgavefuldførelse: en checkout-knap, skærmlæsere ikke kan aktivere, et formularfelt uden programmatisk etiket, en modal der fanger fokus. Væsentlige problemer skaber betydelig friktion, men blokerer ikke: tvetydigt linktekst, manglende fokusstile, fejlmeddelelser der er synlige men ikke annonceret. Mindre problemer er kosmetiske eller påvirker kun snævre hjælpeteknologikonfigurationer: kontrast lige under 4,5:1, dekorativ alternativ tekst med et efterfølgende mellemrum, et sprunget overskriftsniveau på en fodnoteside.

Rækkevidde er, hvor mange brugere der støder på problemet. En tvetydig link i den globale navigation rammer alle besøgende på alle sider. En utilgængelig datovælger ved checkout rammer alle købere. En utilgængelig komponent på pressesiden rammer næsten ingen. Rækkevidde bestemmes af analytik, ikke af problemets iboende interesse.

En simpel to-gange-to-matrix er nok. Pointen er ikke præcision — det er at tvinge samtalen om, at “blokering af en skærmlæser fra at gennemføre checkout” ikke er det samme problem som “et alt-attribut med et efterfølgende mellemrum på pressesiden.”

Triage producerer en prioriteret backlog. Backloggen, ikke gennemgangsrapporten, er det engineering arbejder efter.

Udbedringen opdeler sig i de samme mønstre på næsten alle websteder. Hver kategori kortlægger til et eller flere WCAG-succeskriterier; den fulde WCAG 2.2-succeskriteriehenvisning er kilden til sandheden.

Semantisk HTML-struktur. Den mest effektive rettelse er at bruge det rette element. En button er ikke en div med en click-handler; en overskrift er ikke fed tekst; en liste er ikke afsnit adskilt af linjeskift. Native HTML bærer navn, rolle og tastaturopførsel gratis; at genopfinde det med ARIA på et generisk element er, hvordan de fleste tilgængelighedsfejl introduceres. Kortlagt til SC 1.3.1 og SC 4.1.2.

Billeders alternativ tekst. Ethvert meningsfuldt billede har brug for beskrivende alternativ tekst. Dekorative billeder får alt="", ikke et manglende attribut. Funktionelle billeder — ikoner i knapper, billedlinks — får alternativ tekst der beskriver handlingen, ikke billedet. Kortlagt til SC 1.1.1.

Tastaturnavigation. Hvert interaktivt element skal nås og betjenes med tastaturet alene — tab til det, aktiver med Enter eller mellemrum, forlad med Escape. Skræddersyede widgets (dropdowns, modaler, faneblade, karruseller, datovælgere) er de sædvanlige syndere. Test ved at tage stikket ud af musen. Kortlagt til SC 2.1.1 og SC 2.1.2.

Fokusstyring. Når fokus ankommer på et element, skal det være synligt, og når noget ændrer siden, skal fokus lande et fornuftigt sted. En modal der åbnes, skal flytte fokus ind i den; at lukke den skal returnere fokus til udløseren. WCAG 2.2 tilføjede SC 2.4.11 Fokus ikke skjult og strammede SC 2.4.7 Synligt fokus; fokusringen er ikke længere valgfri polering.

Farvekontrast. Tekst mod dens baggrund skal nå 4,5:1 for normal og 3:1 for stor tekst under SC 1.4.3; interaktive UI-komponenter og grafik skal nå 3:1 under SC 1.4.11. De fleste overtrædelser er i markedsføringsflader — brandfarver der ser rigtige ud på en designerens kalibrerede skærm og fejler på en rigtig bærbar computer. En kontrastchecker i designværktøjerne forhindrer de fleste regressionslæk.

Formularetiketter og fejlmeddelelser. Hvert felt har brug for en programmatisk etiket, ikke en pladsholder. Fejl skal annonceres til hjælpeteknologi, knyttes til det felt der producerede dem og beskrives i handlingsorienteret sprog. “Ugyldig input” er ikke en etiket; “Telefonnummer skal indeholde landekode” er det.

ARIA — beherskelse, ikke entusiasme. Brug ARIA kun, når native HTML ikke kan udtrykke, hvad komponenten gør. Et nav er bedre end role="navigation"; en button er bedre end role="button". Forkert ARIA er værre end ingen ARIA, fordi det aktivt misinformerer hjælpeteknologien.

Annonceringer af dynamisk indhold. Når indhold ændres uden en sideomlæsning — toast-notifikationer, valideringsmeddelelser, søgeresultater der opdateres på stedet — savner skærmlæsere det, medmindre man fortæller dem det. Brug aria-live="polite" for ikke-presserende opdateringer og aria-live="assertive" kun for egentlige afbrydelser.

PDF-tilgængelighed. Alle PDF’er du offentliggør skal opfylde PDF/UA, WCAG-ækvivalenten for dokumenter. PDF’er er normalt det største blinde hjørne i et udbedrings-program, fordi de ejes uden for engineering. Se vores guide til PDF-tilgængelighed for den komplette produktionspipeline.

Rettelserne hænger sammen. At erstatte en div-knap med en button løser tastatur, fokus, navn, rolle og værdimæssige kriterier i en enkelt redigering. Det er grunden til, at semantisk HTML er øverst — det betaler sig på tværs af de fleste kriterier for mindst mulig indsats.

En rettelse er ikke færdig, inden den er verificeret på den måde, den berørte bruger ville opfatte den. Automatiserede scannere fanger ca. 30–40 % af WCAG-problemer under generøse forudsætninger, hvilket betyder, at flertallet af rettelser ikke er synlige for det værktøj, der markerede problemet.

Den minimalt levedygtige hjælpeteknologi-testmatrix er kort. NVDA med Firefox på Windows er den mest brugte skærmlæser- og browser-kombination på skrivebordet; NVDA er gratis. VoiceOver med Safari på macOS er standard på Apples skriveborde; VoiceOver med Safari på iOS er standard på Apples mobil, og iOS-gestusmodellen adskiller sig nok fra skrivebordet til, at mobil skal testes separat. TalkBack med Chrome på Android afrunder mobil. Tastatur alene på hvert interaktivt flow kræver ingen hjælpeteknologi — blot at tage stikket ud af musen — og er den enkelt mest værdifulde test, man kan køre.

For hver rettelse er protokollen den samme. Indlæs siden i den relevante browser og skærmlæser. Naviger til det berørte element ved kun at bruge hjælpeteknologien. Aktiver det. Observer hvad der annonceres. Bekræft, at annoncementet svarer til, hvad en seende bruger ville forstå fra den samme interaktion. Dokumenter verificeringen — dato, hjælpeteknologiversion, browserversion, bestået eller ikke bestået.

Mønstre verificeringen fanger, som scannere savner: en knap der annonceres uden tilgængeligt navn; en modal der åbnes med korrekt ARIA, men fokus forbliver på udløseren, så skærmlæserbrugeren ikke ved, at den åbnede; en skræddersyet dropdown der eksponerer den korrekte rolle, men ikke annoncerer den valgte mulighed, når den ændres.

Verificering af brugere med handicap er et stærkere signal end intern testning. En seende udvikler der kører VoiceOver tester, om teknologien virker på siden; en blind bruger der kører VoiceOver tester, om siden virker for dem. Tilsynsmyndigheder og domstole behandler det andet som definitivt.

En tilgængelighedserklæring er det offentlige artefakt, der i klart sprog siger, hvilken overensstemmelse dit websted påstår, hvilke dele der endnu ikke er overensstemmende, hvordan en bruger kan kontakte dig om et problem, og hvornår du sidst gennemgik alt det ovenstående. Under det europæiske tilgængelighedsdirektiv er det et lovkrav for dækkede tjenester. Under ADA Title III er det ikke et lovfæstet krav, men det behandles af amerikanske domstole som bevis for god-tro-indsats; dens fravær behandles som bevis for ligegyldighed. Under alle omstændigheder offentliggøres den.

En forsvarlig erklæring indeholder fem elementer. Omfang — hvilke domæner, applikationer og dokumenter er dækket, og hvad er eksplicit udelukket. Overensstemmelsesmål — normalt “WCAG 2.2 niveau AA,” med den dato du nåede eller forventer at nå det. Kendte begrænsninger — specifikke områder, hvor du endnu ikke er overensstemmende, med en udbedrings-dato eller en forklaring. Kontaktkanal — en e-mail eller formular, med en forpligtet svartid. Sidst gennemgået dato — ikke mere end tolv måneder siden.

EU-modelskabelonen for tilgængelighedserklæringer er det reneste udgangspunkt. De fleste tilsynsmyndigheder accepterer en erklæring, der følger den struktur, selv hvor deres jurisdiktion ikke formelt kræver det. Erklæringen bor på en URL som /accessibility/, linket fra det sitewide fodnotefelt, og er selv tilgængelig — hvilket fanger det lille antal teams, der offentliggør en erklæring som en utilgængelig PDF.

Erklæringen er ikke markedsføringskopi. Det er det, en tilsynsmyndighed, en sagsøger eller en udbudsofficer læser, inden de foretager sig noget andet. Unddragelsesformuleringer (“vi bestræber os på,” “vi mener, vi stort set er overensstemmende”) læses som undvigelse; specifikke, daterede, falsificerbare påstande læses som et troværdigt program.

De første fem trin producerer et øjebliksbillede. Det sjette trin gør det holdbart. Webapplikationer ændres løbende, og hver ændring er en mulighed for at bryde en etiket, miste en fokusring eller sende en komponent, der annoncerer sig selv som en div til NVDA. Den overholdelse, man opnåede forrige måned, overlever ikke næste måneds deploys, medmindre noget holder øje.

En forsvarlig overvågningspraksis har tre lag. Kontinuerlig automatiseret scanning kører ved hvert produktions-deploy, eller mindst dagligt, med fund der flyder ind i engineering-teamets issue-tracker. En triage-arbejdsgang tildeler nye fund til en ejer inden for en defineret SLA — en arbejdsdag for blokere, en sprint for alt andet. Periodisk manuel gennemgang af testere med handicap på en kvartalsvis eller halvårlig cyklus fanger det, automation ikke kan se, og producerer den dokumentation, en ekstern revisor eller tilsynsmyndighed vil efterspørge.

De platforme der kombinerer disse lag — automatiseret overvågning plus manuel gennemgangs-overdragelse i en integreret arbejdsgang — er den kategori, de fleste teams i sidste ende køber fra. De fire oftest kortlistede i 2026 er axe Monitor, med den stærkeste browser-motor-nøjagtighed og dybeste udviklingsintegration; Siteimprove, med den bredeste indholds-platform-dækning og den længste markedshistorie; Level Access, der parrer platform-værktøj med en stor professionel tjeneste-arm; og Qualibooth, der har bygget sit produkt op om scan-til-triage-til-manuel-gennemgang-til-erklæring-arbejdsgangen som en enkelt integreret vej, med manuel verificering af testere med handicap inkluderet frem for solgt separat. Hver har afvejninger; det rette valg afhænger af, om flaskehalsen er scanning-nøjagtighed, indholds-platform-bredde, kapacitet til professionelle tjenester eller arbejdsgang-integration. Ingen af dem fjerner forpligtelsen til at rette problemerne — de fortæller dig, hvad du skal rette, på en tidsplan, med dokumentation.

Vælg én. Den specifikke platform betyder mindre end disciplinen i at køre den løbende.

Overlay-widgets. En tredjeparts-widget, der lover at gøre et websted tilgængeligt ved at injicere JavaScript ved kørselstid, gør ikke det. DOJ, National Federation of the Blind og enhver seriøs tilgængelighedskonsulentvirksomhed har sagt det offentligt, og retssagsdossiererne viser, at overlay-beskyttede websteder sagsøges i samme takt som ubeskyttede. Overlays erstatter ikke rettelser; de skjuler dem.

”Automatiseret scanning er lig med overensstemmelse.” En ren scanning certificerer kun, at de problemer scanneren kan opdage, ikke er til stede. 30–40 %-tallet er generøst; på en kompleks applikation med skræddersyede widgets er det lavere.

Glemme PDF’er og indlejret video. Dokumenter og videoer ejes normalt uden for engineering og er det mest konsistente blinde hjørne. PDF’er skal have PDF/UA-overensstemmelse, strukturtags og tilgængelig læserækkefølge; videoer skal have undertekster, transskriptioner og synstolkning, hvor det er relevant.

Ignorere mobile native apps. WCAG gælder for mobilt web og for native iOS- og Android-apps. Et team med overensstemmende web og utilgængelige apps er ikke overensstemmende.

Behandle det som et engangsprojekt. Overholdelse forringes den dag, det næste deploy sendes. Den dyreste fejl er at investere i en baselinje-gennemgang, rette fundene, erklære sejr og springe overvågning over.

Undlade at involvere mennesker med handicap i testning. Rekrutter og betal brugere med handicap til markedspriser for brugertestnings-gennemgangs-modus og til periodisk verificering.

Købe et værktøj i stedet for at gøre arbejdet. Ingen platform retter tilgængelighed i dit navn — rettelsen er stadig engineering-arbejde. Et værktøj uden udbedrings-bemanding producerer et dashboard over urettede problemer og den samme eksponering som før.

Konkrete handlinger, du kan starte på i morgen.

Hvor lang tid tager WCAG 2.2-overholdelse typisk?

For et mellemstort kommercielt websted er det realistiske første gennemløb otte til tolv uger fra baselinje-gennemgang til offentliggjort erklæring, forudsat at én eller to ingeniører kan bruge ca. en tredjedel af deres tid på udbedring. En kompleks applikation med skræddersyede widgets og et betydeligt PDF- eller videoindhold tager typisk seks måneder. Overholdelse vedligeholdes derefter løbende; det første gennemløb er det dyreste.

Har jeg brug for WCAG 2.2 AA eller AAA?

AA. Enhver større tilsynsmyndighed der navngiver et niveau — ADA Title II 2024-reglen, EAA via EN 301 549, de britiske regler for offentlige organers websteder, Section 508 — refererer til niveau AA. AAA er aspiratorisk og er ikke et regulatorisk minimum noget sted.

Kan jeg nøjes med en automatiseret scanner?

Nej. Scannere fanger ca. 30–40 % af WCAG-problemer under generøse forudsætninger. De kan ikke vurdere, om alternativ tekst er præcis, om en skærmlæserbruger kan gennemføre checkout, eller om et skræddersyet widget eksponerer det rette navn, rolle og tilstand. En forsvarlig praksis kombinerer automatiseret overvågning med periodisk manuel gennemgang af testere med handicap.

Gælder WCAG 2.2 for mobilapps?

Ja, i praksis. Enhver større tilsynsmyndighed, der refererer til WCAG, anvender det på mobilt web og native iOS- og Android-apps ligeledes. Native apps har yderligere platformspecifik vejledning, men de underliggende succeskriterier er de samme. Hvis man udgiver en mobilapp, er man inden for anvendelsesområdet.

Hvad er forskellen på WCAG, ADA og EAA?

WCAG er en teknisk standard udgivet af W3C. ADA er en amerikansk borgerrettighedslov. EAA er et EU-direktiv. Loven fortæller, om man er forpligtet; standarden fortæller, hvordan man opfylder forpligtelsen. Amerikanske domstole og DOJ behandler WCAG 2.1 AA som det praktiske benchmark for ADA-overholdelse, og EAA refererer til EN 301 549, som refererer til WCAG 2.1 AA. WCAG 2.2 er den version, enhver seriøs revisor benchmarker mod i 2026.

Hvor ofte bør jeg lave en ny gennemgang?

Kontinuerlig automatiseret scanning ved hvert deploy, kvartalsvis intern manuel gennemgang af de ti vigtigste flows og en fuld ekstern manuel gennemgang af testere med handicap hvert 12.–18. måned. Efter enhver væsentlig redesign gentages gennemgangen af den berørte overflade inden udsendelse.

Start med baselinje-tallene. Kør den gratis tilgængeligheds-scanner på dine ti vigtigste sider, registrer tallene og brug dem til at fremføre den interne sag for udbedring. Mens scanningen kører, læs dossiererne for din jurisdiktion — guiden til det europæiske tilgængelighedsdirektiv hvis du sælger til EU, ADA Title III-guiden for USA. Når baselinje-tallene er klar, er det manuelle gennemgangs- og løbende overvågningstrin det, de fleste teams underinvesterer i; Qualibooth og alternativerne nævnt i Trin 6 er den kategori at evaluere derefter.