Web & compliance
Hvis I søger efter webtilgængelighed, EAA-krav til et website eller "tilgængelighedslov Danmark", står I typisk i ét af tre rum: I har en webshop og har hørt, at reglerne gælder fra sommeren 2025. I har fået en mail fra en leverandør, der sælger et overlay. Eller en kunde har spurgt, om jeres site kan bruges med tastatur og skærmlæser — og I kan ikke svare ærligt.
Vi møder teams der enten overreagerer ("vi skal WCAG-certificere hele internettet") eller underreagerer ("det er kun for det offentlige"). Begge tager fejl. Den europæiske tilgængelighedslov — EAA — rammer bestemte produkter og tjenester, der sælges til forbrugere. Den rammer ikke automatisk jeres interne portal eller jeres B2B-brochure. Den rammer heller ikke "et lille script i hjørnet". Den rammer den måde, et menneske faktisk køber, betaler og finder hjælp på.
TL;DR
De vigtigste pointer
- EAA er et krav til bestemte forbrugerrettede tjenester — ikke et stempel på alle websites i Danmark.
- En webshop, et checkout og betaling/login er det, loven typisk peger på. En ren B2B-brochure er et andet spørgsmål.
- WCAG er metoden. Et overlay-widget er ikke en genvej — det er ofte det, der får jer til at tro, I er færdige.
- Tastatur, kontrast, labels, fokus og ærlige fejlbeskeder slår en lang PDF med et AA-badge.
- Mikrovirksomheder som loven definerer dem, er typisk undtaget for tjenester. Det er et juridisk kald — ikke noget et bureau skal gætte.
- Start med de flows, et menneske ikke kan gennemføre. Ikke med at male hvert ikon om.
Hvorfor det her overhovedet er vigtigt
Tilgængelighed blev i årevis behandlet som pænhed: noget det offentlige skulle, og noget private "gjorde, hvis der var tid". EAA ændrer den ramme for en konkret slags privat tjeneste — især e-handel, visse finansielle og transportnære ydelser, e-bøger og elektronisk kommunikation. I Danmark er det implementeret som lov om tilgængelighedskrav for produkter og tjenester. Anvendelsen startede i juni 2025. Det er ikke et rygte. Det er en dato, mange shops allerede er forbi.
Det betyder ikke, at hvert marketing-site pludselig er ulovligt. Det betyder, at I skal kunne svare på to spørgsmål, før I køber et værktøj eller lover en kunde noget: er vores tjeneste overhovedet i scope — og hvis ja, kan et menneske med tastatur, skærmlæser eller nedsat syn gennemføre det, I sælger?
Det andet spørgsmål er det, de fleste hopper over. De køber et overlay, sætter et badge i footeren og kalder det compliance. Overlayet ændrer ikke, at jeres checkout-knap ikke kan nås uden mus, at fejl i formularen kun er røde rammer, eller at jeres video-reklame er den eneste forklaring på fragt. Loven spørger, om tjenesten kan bruges. Den spørger ikke, om I har købt et lag ovenpå.
Det her er ikke juridisk rådgivning. Det er den ingeniørsamtale, I skal have, før juristen kan sige noget nyttigt. Uden at kende jeres flows bliver "vi er EAA-klar" en sætning, I ikke kan forsvare — hverken over for Sikkerhedsstyrelsen eller over for den kunde, der ikke kan betale.
Hvad EAA faktisk dækker — og hvad det ikke dækker
EAA handler om produkter og tjenester i bestemte kategorier, når de rettes mod forbrugere. E-handel er den, vi oftest bliver spurgt om: et site eller en app, hvor en forbruger kan indgå en aftale — browse, kurv, checkout, betaling, konto, levering, retur. Det er ikke kun "webshoppen". Det er også de trin, I har outsourcet: betaling, MitID-agtig identifikation, fragtvælger. Hvis de trin er en del af tjenesten, er de en del af problemet.
Andre kategorier er typisk bank og visse finansielle selvbetjeninger, elektronisk kommunikation, e-bøger, visse transport- og billetløsninger, og en række fysiske produkter med digital flade. Hvis I sælger tøj online til forbrugere og ikke er en mikrovirksomhed som loven definerer den, er I i den samtale. Hvis I driver en intern timesags-portal til jeres egne medarbejdere, er I sandsynligvis i en anden.
B2B er det sted, folk slår sig. En ren erhvervstjeneste, der ikke sælges til forbrugere, er som udgangspunkt ikke det, EAA blev skrevet til. En shop der sælger til både privat og erhverv, eller et checkout der er det samme for begge, er et andet billede. "Vi er B2B" er ikke et stempel, I kan sætte på et site, hvor privatpersoner stadig kan oprette en ordre. Scope er et juridisk kald ud fra hvad I faktisk tilbyder — ikke ud fra hvordan I brander jer.
Mikrovirksomheder — loven bruger antal årsværk og en omsætnings- eller balancegrænse — er typisk undtaget for tjenestekravene. Produktregler kan se anderledes ud. Vi gentager det, fordi leverandører elsker at sige "alle skal overholde EAA". Det er forkert. Det er også forkert at antage, at I er undtaget, fordi I føler jer små. Tæl det, loven tæller. Spørg en jurist, hvis I er i tvivl. Et bureau skal ikke gætte jer ind eller ud af scope.
WCAG er en metode — ikke et certifikat I kan hænge i receptionen
Når folk siger "vi skal være AA", mener de typisk Web Content Accessibility Guidelines på niveau AA. Den harmoniserede standard, der peger på, hvordan digitale grænseflader skal kunne opfattes, betjenes, forstås og være robuste, bygger på den tænkning. POUR: perceivable, operable, understandable, robust. Det er et nyttigt sprog. Det er ikke et diplom, I får efter at have kørt en automatisk scanner.
En scanner er et fint første pass. Den finder manglende alt-tekst, tynd kontrast, tomme links og inputs uden label. Den finder ikke, at jeres dato-vælger fanger fokus, at jeres "næste trin" er en div med et click-handler, eller at fejlbeskeden kun er en rød ramme. Den finder heller ikke, at jeres indhold er skrevet i et sprog, ingen kan parse — inklusive dem uden handicap. Automatik er et net. Det er ikke fiskeriet.
Det offentlige Danmark har i årevis levet under webtilgængelighedsdirektivet. Det er en anden slags pligt, med erklæringer og tilsyn, der ikke er det samme som EAA. At kopiere en offentlig erklæring ind i footeren på en privat webshop er ikke compliance. At låne deres tjekliste — tastatur, kontrast, captions, labels — er derimod et ærligt sted at starte, uanset om I er i scope.
Vi anbefaler at behandle WCAG som acceptkriterier på de flows, der betyder noget: forside til produkt, kurv, checkout, konto, søgning, kontakt. Et site kan score pænt i en scanner og stadig være ubrugeligt i checkout. Omvendt: et site med ærlige labels, synlig fokus, fornuftig heading-rækkefølge og tastaturbare dialoger er allerede langt — også før nogen har sagt "AA".
Overlay og badge vs. det et menneske faktisk kan gennemføre
Det teams typisk køber
Det der ser ud som compliance på et slides.
- Et overlay der lover AA uden at røre jeres komponenter
- En footer-erklæring kopieret fra et offentligt site
- En scanner-rapport med grønne tal og ingen checkout-test
- En følelse af at emnet er "taget af bordet"
Det der faktisk afgør sagen
Det en bruger og et tilsyn kan eftervise.
- Tastatur hele vejen gennem køb, login og betaling
- Labels, fejl og status der også findes som tekst
- Kontrast og zoom der ikke ødelægger layoutet
- Ægte skærmlæser-test på de to-tre flows, I lever af
Sådan vurderer I jeres site, før I lover noget
En eftermiddag. Uden den her rækkefølge køber I det forkerte — enten et overlay eller en bunke kosmetik.
- 01
Afgør om I er i scope — ærligt
Sælger I til forbrugere i en kategori, loven nævner? Er checkout, konto eller betaling en del af tjenesten? Er I en mikrovirksomhed som loven definerer den? Skriv svaret ned. Hvis I er i tvivl, er næste skridt en jurist — ikke et plugin.
- 02
List de flows, et menneske skal kunne gennemføre
Find produkt, læg i kurv, betal, opret konto, nulstil kodeord, kontakt support, læs vilkår. Det er jeres rigtige backlog. En forside med pæn kontrast og en brudt checkout er ikke et tilgængeligt site.
- 03
Gennemfør dem med tastatur alene
Tab, Enter, Escape. Kan I se fokus? Kan I lukke modaler? Fanges I i en datepicker? Hvis I selv taber tråden, har en skærmlæser-bruger allerede tabt den. Det her finder mere end de fleste scannere.
- 04
Kør en scanner — og behandl den som et net
Ret de åbenlyse: manglende labels, tom alt, kontrast under det, WCAG kalder AA, links der siger "læs mere" syv gange. Stop, når I begynder at jage falske positiver i stedet for at teste checkout igen.
- 05
Test med en skærmlæser på ét flow
VoiceOver eller NVDA på køb eller login. I behøver ikke blive eksperter. I skal høre, om knapper har navne, om fejl bliver læst op, og om rækkefølgen giver mening. Det I ikke kan forklare, kan I ikke påstå er tilgængeligt.
“EAA spørger, om et menneske kan bruge tjenesten. Den spørger ikke, om I har købt et lag der lover, at de kan.”
Hvad vi typisk retter først — og hvad vi bevidst lader vente
Først: tastatur og fokus. Knapper der er divs, menuer der kun åbner på hover, dialoger uden fokusfælde og uden Escape, skip-links der ikke findes. Uden det er resten kosmetik. På et Next.js-site sidder det ofte i jeres egne komponenter — ikke i CMS'et. På WordPress sidder det ofte i temaet og i de pagebuildere, der spytter <div> ud, hvor der skulle have været en knap.
Derefter: formularer. Label der er synlig og knyttet, fejl der er tekst og knyttet til feltet, autocomplete der er ærlig, og et checkout hvor hvert trin har en heading. Betaling og identifikation, I har embedded, skal kunne bruges med tastatur og have et navn. "Det er leverandørens iframe" er et ærligt problem. Det er ikke en fritagelse. I skal kunne skifte leverandør eller kræve en tilgængelig embedding.
Så: indhold og media. Alt-tekst på meningsfulde billeder, tom alt på dekoration, undertekster på den video der forklarer produktet, og heading-rækkefølge der spejler siden — ikke et hop fra h1 til h4 fordi designet var pænere. Det er også SEO. En side, en skærmlæser kan parse, er en side en crawler kan parse. Core Web Vitals og tilgængelighed er ikke det samme, men layout-shift der stjæler klikket på "køb" er begge dele.
Det vi lader vente: at male hvert ikon, at skrive erklæringer, før flows virker, og at "gøre hele arkivet AA" mens checkouten stadig er en musefælde. Prioriter det, et menneske skal kunne i dag. Arkivet og den gamle kampagne-landing kan I tage, når købet virker. Et bureau der starter med en 80-siders rapport og ingen ændring i kurven, har solgt jer teater.
Hvad I typisk bør gøre i den situation, I står i
Venstre er det, I typisk siger. Højre er det næste skridt, vi typisk anbefaler.
Situation
I ved ikke, om EAA overhovedet rammer jer
Næste skridt
Skriv ned hvad I sælger, til hvem, og om checkout er en del af tjenesten — så en jurist
Situation
I har købt et overlay og kalder jer færdige
Næste skridt
Slå det fra og tab gennem checkout. Det I ikke kan, er det I skal rette
Situation
Scanneren er grøn, men I har aldrig prøvet uden mus
Næste skridt
Tastatur-test de to-tre pengestrømme. Scanner-tal er ikke acceptkriterier
Situation
I er en ren B2B-brochure uden forbrugerkøb
Næste skridt
I er sandsynligvis uden for EAA — ret alligevel tastatur og labels, fordi det er godt håndværk
Situation
Betaling eller login sidder i en iframe, I ikke kan style
Næste skridt
Kræv en tilgængelig embedding, eller skift leverandør. Det er jeres tjeneste
Tjekliste før I siger "vi er EAA-klar"
Hvis I mangler flere af punkterne, er løftet for tidligt — uanset hvilket badge I har i footeren.
- I kan forklare, om jeres tjeneste er i scope, og I har ikke gættet jer til undtagelsen
- Køb, login og kontakt kan gennemføres med tastatur, med synlig fokus
- Alle felter har labels, og fejl er tekst — ikke kun farve
- Meningsfulde billeder har alt, videoer I sælger med har undertekster
- I har testet ét rigtigt flow med en skærmlæser — ikke kun en scanner
- Betaling, identifikation og andre embeds er med i testen, ikke undskyldt
Spørgsmål vi får igen og igen
Gælder EAA for alle danske hjemmesider?
Nej. Den gælder bestemte produkter og tjenester, typisk når de sælges til forbrugere — e-handel er det hyppigste eksempel. En intern portal eller en ren B2B-brochure er et andet spørgsmål. Mikrovirksomheder som loven definerer dem, er typisk undtaget for tjenester. Hvis I er i tvivl, er det et juridisk kald ud fra hvad I faktisk tilbyder, ikke ud fra om I har et website.
Er det nok at sætte et tilgængeligheds-plugin på WordPress?
Næsten aldrig, hvis plugin'et er et overlay. Det rører ikke jeres tema, jeres pagebuilder eller jeres checkout. Et plugin kan hjælpe med enkelte ting — better captions, bedre media. Det kan ikke gøre en musefælde til en tastbar tjeneste. Ret komponenterne. På WordPress betyder det tema og de blokke, I faktisk bruger. På Next.js betyder det jeres egne primitives.
Hvad med B2B-webshops og kundeportaler?
En portal til eksisterende erhvervskunder er sjældent det, EAA blev skrevet til. En shop der også sælger til forbrugere, eller et checkout der er det samme for begge, kan være det. Skil de to. Selv uden for EAA er en portal, der ikke kan bruges med tastatur, et dårligt produkt — især hvis jeres kunder har indkøbere, der ikke sidder med mus hele dagen. Loven er gulvet, ikke loftet.
Skal vi have en tilgængelighedserklæring?
Offentlige sites har i årevis skullet erklære. For private EAA-tjenester handler det om, at tjenesten lever op til kravene, og at I kan forklare hvordan — inklusiv de oplysninger om et produkts tilgængelighed, I skal sende videre, hvis producenten har givet dem. En erklæring uden fungerende checkout er et dokument. Få flows til at virke, skriv så ærligt hvad der stadig er brudt, og hvornår I retter det.
Hvor starter vi, hvis budgettet er småt?
Tastatur gennem køb og kontakt. Labels og fejl som tekst. Kontrast på tekst og knapper. Det er håndværk, ikke et program. En scanner-eftermiddag plus en ærlig test af checkout slår en stor rapport, I ikke handler på. Hvis I bygger nyt, så gør knap, felt og dialog rigtigt i designsystemet første gang — det er billigere end at eftermontere tilgængelighed på et tema, der aldrig var tænkt til det.
Hvis I skal kunne svare på, om sitet kan bruges
Lad os teste de flows, I lever af — med tastatur.
En kort gennemgang af checkout, login og kontakt er ofte nok til at skille et rigtigt EAA-problem fra et overlay, I ikke har brug for.
