WCAG — Web Content Accessibility Guidelines — er den internationale standard for, at webindhold kan bruges af mennesker med handicap. Den udgives af W3C, og stort set al lovgivning på området peger på WCAG i stedet for at skrive sine egne regler. Det gælder også i Danmark.
De aktuelle versioner er WCAG 2.1 (2018) og WCAG 2.2 (oktober 2023). WCAG 2.2 tilføjer ni success criteria og er bagudkompatibel: opfylder du 2.2, opfylder du også 2.1.
POUR-principperne
WCAG er bygget op om fire principper. Indhold skal være:
- Perceivable — information skal kunne opfattes. Tekstalternativer til billeder, undertekster til video, tilstrækkelig kontrast, indhold der ikke kun formidles med farve.
- Operable — brugerfladen skal kunne betjenes. Alt skal kunne nås med tastatur, der skal være tid nok til at læse og handle, ingen blink der kan udløse anfald, og tydelig fokusmarkering.
- Understandable — indhold og betjening skal give mening. Læsbart sprog, forudsigelig adfærd, brugbare fejlbeskeder.
- Robust — indhold skal virke med nuværende og fremtidige browsere og hjælpemidler. Valid markup, korrekte roller og navne.
Under de fire principper ligger guidelines, og under dem ligger success criteria — de konkrete, testbare krav, du rent faktisk lever op til.
Konformitetsniveauer: A, AA, AAA
| Niveau | Betydning | I praksis |
|---|---|---|
| A | Minimum | De værste barrierer er væk. Ikke nok til noget lovkrav. |
| AA | Standard | Det niveau al lovgivning kræver. Det realistiske mål. |
| AAA | Udvidet | Strengest. W3C skriver selv, at det ikke kan kræves for hele websites. |
Sigt efter AA. Det er det, loven beder om, og det kan lade sig gøre på tværs af et helt site. Vælg enkelte AAA-kriterier, hvor de reelt hjælper din målgruppe, men sæt ikke AAA som mål for hele sitet — W3C fraråder det direkte.
Nogle af de oftest fejlede AA-kriterier:
- 1.4.3 Contrast (Minimum) — 4,5:1 for normal tekst, 3:1 for stor tekst. Den klart mest udbredte fejl, og som regel en beslutning truffet i et designværktøj af en, der aldrig målte efter.
- 1.1.1 Non-text Content — alle billeder skal have et passende tekstalternativ. Dekorative billeder skal have et tomt
alt=""— ikke et manglende, og ikke en beskrivelse. - 2.4.7 Focus Visible — tastaturfokus skal være synligt. At fjerne fokusmarkering med
outline: noneuden at erstatte den er en direkte fejl. - 4.1.2 Name, Role, Value — alle kontroller skal eksponere navn, rolle og tilstand. Ikon-knapper uden tilgængeligt navn fejler her konstant.
- 2.1.1 Keyboard — al funktionalitet skal kunne betjenes med tastatur, uden fælder.
- 1.3.1 Info and Relationships — struktur, der vises visuelt, skal også findes i markup. Det er her overskriftsstruktur og rigtige formularlabels betyder noget.
ARIA
ARIA (Accessible Rich Internet Applications) er et sæt attributter — role, aria-label, aria-expanded, aria-live med flere — der beskriver formål og tilstand for elementer over for hjælpemidler, når HTML ikke selv kan.
Hovedreglen fra W3C's egne authoring practices er værd at huske udenad:
No ARIA is better than bad ARIA.
En almindelig <button> er tilgængelig gratis. En <div role="button"> kræver tabindex, key handlers til Enter og mellemrum, fokusstyling og korrekt tilstandshåndtering — og de fleste implementeringer rammer forkert på mindst ét af de punkter. Resultatet bliver mindre tilgængeligt end det simple element.
- Brug native HTML-elementer først. Grib kun til ARIA, når intet native element passer.
- Lav aldrig et elements implicitte rolle om uden at implementere hele den forventede adfærd.
- Hold
aria-*i sync med virkeligheden. Et forældetaria-expanded="false"på en åben menu er direkte vildledende. - Giv alle interaktive kontroller et tilgængeligt navn.
- Brug
aria-livesparsomt. Overforbrug gør siden ulidelig at lytte til.
Hvad automatiserede test kan og ikke kan finde
Det her er det vigtigste at forstå om tilgængelighedsværktøjer — også Sitechecks.
Automatiserede test finder pålideligt omkring 30-40% af WCAG-fejlene. Det er den gennemgående konklusion på området, og ethvert værktøj, der lover fuld automatisk compliance, fremstiller det forkert.
Automatisering er god til: farvekontrast, manglende alt, manglende formularlabels, tomme knapper og links, ugyldig ARIA, overskriftsrækkefølge, manglende sprogangivelse, dublerede id'er. Det er objektivt og maskinlæsbart — og også meget udbredt, så løbende scanning er indsatsen værd.
Automatisering kan ikke vurdere: om et alt-tekst er meningsfuldt og ikke bare til stede, om fokusrækkefølgen er logisk, om en fejlbesked rent faktisk hjælper, om en custom-widget opfører sig fornuftigt med en skærmlæser, om undertekster er korrekte, eller om siden giver mening linjeret.
En seriøs proces bruger begge dele:
- Automatiseret scanning, løbende, til at fange regressioner og de objektive fejl i stort antal.
- Manuel test — tastaturnavigation, en rigtig skærmlæser, zoom til 200%, og helst test med brugere med handicap.
Sitecheck kører axe-core og QualWeb, begge open source-implementeringer af WCAG success criteria, så resultater peger på navngivne kriterier i stedet for en score, nogen har fundet på. Værktøjet finder den automatiserbare del ærligt og foregiver ikke at dække resten.
Tilgængelighed og SEO overlapper
En stor del af tilgængelighedsarbejdet forbedrer SEO som sidegevinst, fordi begge dele hviler på maskinlæsbar semantik:
- Ordentlig overskriftsstruktur hjælper både skærmlæsernavigation og indholdsforståelse.
- Alt-tekst beskriver billeder for hjælpemidler og for billedsøgning.
- Beskrivende linktekst ("prisguide 2026" frem for "klik her") hjælper begge dele.
- Undertekster og transskriptioner gør videoindhold både tilgængeligt og indekserbart.
- Semantisk HTML giver crawlere og hjælpemidler det samme strukturelle kort.
Det er ikke samme disciplin, og tilgængelighed er indsatsen værd i sig selv — men overlappet er reelt og værd at bruge, når arbejdet skal prioriteres.
Lovgivningen i Danmark og EU
Dansk og europæisk lovgivning skriver ikke sine egne tekniske regler. Den peger på WCAG gennem den harmoniserede standard EN 301 549, som indeholder WCAG 2.1 niveau AA.
Offentlig sektor. Webtilgængelighedsloven (som implementerer EU-direktiv 2016/2102) har siden 2019 stillet krav til offentlige myndigheders websites og apps: WCAG 2.1 AA og en offentliggjort tilgængelighedserklæring på wcag.digst.dk. Digitaliseringsstyrelsen fører tilsyn og udtager hvert år et antal sites til kontrol — både en forenklet automatisk gennemgang og en dybere manuel vurdering.
Privat sektor. Det er her billedet har ændret sig. Tilgængelighedsdirektivet (European Accessibility Act, direktiv 2019/882) har fundet anvendelse siden 28. juni 2025 og udvider kravene til en lang række private produkter og tjenester — e-handel, bankydelser, transport, e-bøger, telekommunikation.
Det betyder i praksis, at en dansk webshop nu er omfattet af tilgængelighedskrav, som den ikke var før. Mikrovirksomheder — under 10 ansatte og under 2 mio. EUR i omsætning — er undtaget for tjenesteydelser, men undtagelsen er snævrere, end mange antager.
Sanktioner. Håndhævelsen sker gennem tilsyn frem for automatiske bøder. I praksis betyder det påbud om udbedring inden for en frist, og først derefter sanktionsmuligheder ved fortsat manglende efterlevelse. Den reelle risiko for de fleste virksomheder er derfor ikke en bøde ud af det blå, men et påbud med en kort frist — og et stykke arbejde, der er markant dyrere at lave under tidspres end planlagt.
Den korte version, hvis du driver et website i Danmark: WCAG 2.1 niveau AA, og det gælder allerede.