Tilgængelighed var engang noget europæiske virksomheder kunne udskyde. Siden 28. juni 2025 har det for en bred vifte af forbrugerrettede digitale tjenester været et lovkrav — og WCAG er den målestok de fleste organisationer bruger til at opfylde det.
En kort bemærkning inden vi starter: denne artikel er et lærende overblik, ikke juridisk rådgivning. Om og hvordan direktivet gælder for netop din organisation, er et spørgsmål til en advokat. Hvad denne guide kan, er at forklare kravets form, den praktiske standard bag det og de konkrete fejl der fælder de fleste websites.
Hvad er det europæiske tilgængelighedsdirektiv?
Det europæiske tilgængelighedsdirektiv (European Accessibility Act, EAA) er et EU-direktiv der kræver, at mange forbrugerrettede produkter og digitale tjenester — herunder e-handel, bank, transportbooking og e-bøger — er tilgængelige for mennesker med handicap. Det har været gældende siden 28. juni 2025, og hvert medlemsland håndhæver det gennem national lovgivning.
Det væsentlige skifte er omfanget. Tidligere EU-regler om tilgængelighed fokuserede på den offentlige sektor; EAA udvider forpligtelsen til private virksomheder der betjener forbrugere. Hvis dit website lader forbrugere købe noget, booke noget eller administrere en konto, er der en god chance for at direktivet er relevant for dig — og det er netop dét spørgsmål du skal stille din juridiske rådgiver frem for at antage svaret på forhånd.
Kræver EAA compliance med WCAG?
Direktivet stiller funktionelle tilgængelighedskrav frem for at udpege en teknisk standard, men i praksis er Web Content Accessibility Guidelines (WCAG) den målestok der bruges i hele EU til at vurdere, om et website opfylder dem. At arbejde hen imod WCAG niveau AA er den bredt accepterede måde at adressere de webrelaterede krav på.
WCAG's styrke er at retningslinjerne omsætter en abstrakt forpligtelse — "opfattelig, anvendelig, forståelig, robust" — til testbare kriterier: har dette billede et tekstalternativ, kan denne formular udfyldes med tastaturet, har denne tekst tilstrækkelig kontrast mod sin baggrund. Den testbarhed er det der gør tilgængelighed til noget man kan måle og følge frem for at diskutere.
Hvad er de mest almindelige tilgængelighedsfejl?
Den samme håndfuld problemer går igen på de fleste websites: billeder uden alt-tekst, formularfelter uden labels, tekst med utilstrækkelig farvekontrast, sider der ikke angiver deres dokumentsprog, og overskriftshierarkier der springer niveauer over. Alle fem kan opdages med automatiseret test og er som regel billige at rette.
Bag hver af dem står en virkelig bruger:
- Manglende alt-tekst efterlader skærmlæserbrugere med "billede" — eller værre, filnavnet — dér hvor seende besøgende ser et produktfoto eller en graf.
- Formularfelter uden label gør en checkout- eller signup-formular til gættearbejde: skærmlæseren annoncerer "redigér tekst" uden nogen antydning af hvad der hører til i feltet.
- Dårlig kontrast rammer langt flere end nogen statistik over hjælpemidler antyder — alle med nedsat syn, aldrende øjne eller bare en telefon i solskin.
- Manglende dokumentsprog tvinger skærmlæsere til at gætte udtalen; engelsk tekst læst op med en stemme beregnet til et andet sprog kan være uforståelig.
- Overskriftsspring — en
h1efterfulgt af enh4— ødelægger den sideoversigt skærmlæserbrugere navigerer efter, ligesom en defekt indholdsfortegnelse ødelægger en bog.
Tilgængelighed overlapper med SEO og brugervenlighed
Arbejdet er sjældent spildt på tilgængelighedsdagsordenen alene. Alt-tekst beskriver billeder for søgemaskiner såvel som for skærmlæsere. Et rent overskriftshierarki er præcis det, søgemaskinernes crawlere bruger til at forstå en sides struktur. Dokumentsprog-attributten hjælper oversættelsesværktøjer og søgemaskiner med at klassificere dit indhold. Formularer med labels giver færre afbrudte køb for alle, og højere kontrast er ganske enkelt lettere at læse på enhver skærm.
Derfor hører tilgængeligheds-findings naturligt hjemme side om side med SEO- og performance-findings: de er alle facetter af det samme grundspørgsmål — virker denne side ordentligt for den, eller det, der prøver at læse den?
Hvordan auditerer jeg selv mit website for tilgængelighed?
Start med en automatiseret scanning med en engine som axe-core, der fanger problemer som manglende alt-tekst, formularfelter uden labels og kontrastfejl. Test derefter i hånden: navigér dine vigtigste sider udelukkende med tastaturet, og tjek at menuer, formularer og dialoger stadig kan bruges. Automatiserede værktøjer finder en væsentlig del af problemerne, men de manuelle tjek er nødvendige for resten.
En brugbar selv-audit-rutine ser sådan ud: kør den automatiserede scanning på hele sitet, ikke kun forsiden; ret de tilbagevendende problemer på template-niveau først, for én rettelse i en template reparerer alle sider der bruger den; gå derefter dine vigtigste brugerrejser igennem — søgning, produktside, checkout, kontakt — med tastaturet alene. Gør til sidst scanningen tilbagevendende. Tilgængeligheds-regressioner følger med hvert redesign og hver ny komponent, så en engangs-audit har kort holdbarhed.
Hvor SiteControl passer ind
SiteControl, website-kvalitetsproduktet i TrustCtrl, kører tilgængelighedstjek efter WCAG med axe-core ved hvert crawl — blandt andet alt-tekst, formular-labels, ARIA-brug, overskriftshierarki og dokumentsprog — så regressioner dukker op som findings i stedet for at hobe sig op i det stille. Fordi crawleren renderer siderne i headless Chromium, bliver single-page-applikationer tjekket sådan som brugerne faktisk oplever dem.
Tilgængeligheds-findings vises side om side med SiteControls tjek af teknisk SEO, Core Web Vitals og security headers, hver med en forklaring i almindeligt sprog, sandsynlige årsager og trin-for-trin-udbedring — så den der skal rette problemet, ikke behøver at være WCAG-specialist for at vide hvad der skal gøres.