Webtilgængelighed: hvad kræver loven af din hjemmeside og webapp?

Kravene til webtilgængelighed afhænger af hvem du sælger til, og hvor stor din virksomhed er. Siden 28. juni 2025 skal webshops, netbanker og andre digitale tjenester, hvor forbrugere indgår aftaler online, leve op til tilgængelighedsloven, mens offentlige myndigheder har haft deres egen lov siden 2018. Er du mikrovirksomhed, eller sælger du kun til andre virksomheder, er du som udgangspunkt ikke omfattet.

Jeg er udvikler og ikke jurist. Gennemgangen bygger på lovteksten og skal hjælpe dig med at stille de rigtige spørgsmål, men få din konkrete situation vurderet af en rådgiver, hvis der er meget på spil.

Den korte version: er du omfattet?

Min tommelfingerregel: kan en privatperson købe, booke eller indgå en aftale direkte på din side eller i din app, og er virksomheden større end en mikrovirksomhed, så gå ud fra at du er omfattet. Tilgængelighed hører hjemme i planlægningen og designet, ikke i en oprydning efter lanceringen. Du kan se hvor det passer ind i min gennemgang af et udviklingsprojekt fra idé til drift.

Hvad tilgængelighedsloven kræver

Loven hedder officielt lov om tilgængelighedskrav for produkter og tjenester (lov nr. 801 af 7. juni 2022). Den er Danmarks udgave af EU's tilgængelighedsdirektiv, som på engelsk kaldes European Accessibility Act. Loven trådte i kraft i 2022, men kravene gælder for produkter og tjenester der bringes i omsætning eller leveres fra 28. juni 2025.

Hvilke tjenester er omfattet

Loven dækker både produkter, fx computere og betalingsterminaler, og tjenester. For hjemmesider og webapps er det tjenesterne der tæller. Følgende er omfattet, når de leveres til forbrugere (§ 1, stk. 2):

• E-handelstjenester
• Forbrugerorienterede banktjenester, fx lån, betalinger og investering
• E-bøger og den software der bruges til at læse dem
• Websteder, apps og elektroniske billetter til persontransport med fly, bus, tog og skib
• Elektroniske kommunikationstjenester og adgang til audiovisuelle medier som tv

E-handel er den bredeste kategori. Loven definerer det som tjenester via websteder og apps, der leveres "efter individuel anmodning fra en forbruger med henblik på at indgå en forbrugeraftale". Det dækker klassiske webshops, men efter min læsning også fx bookingsystemer hvor kunden bestiller og betaler en ydelse online.

Hvad tjenesten skal leve op til

Bilag 1 til loven beskriver kravene. Kernen er at websteder og apps skal være "opfattelige, anvendelige, forståelige og robuste". Det er de fire principper WCAG bygger på, og derfor bliver WCAG brugt som målestok. For e-handel kommer to særlige krav oveni:

• Du skal give oplysninger om tilgængeligheden af de varer du sælger, når producenten leverer dem.
• Login, identifikation, sikkerhed og betaling skal være tilgængelige. Efter min læsning gælder det også en betalingsløsning du har integreret fra en tredjepart, når den er en del af dit købsforløb.

Derudover skal du oplyse hvordan tjenesten lever op til kravene (§ 35 og bilag 4). Oplysningerne skal stå i dine almindelige betingelser eller et tilsvarende dokument, og de skal selv være tilgængelige. Den nemmeste løsning er en tilgængelighedserklæring, som du linker til fra sidefoden og handelsbetingelserne. Du skal også have procedurer der sikrer at tjenesten bliver ved med at leve op til kravene, når den ændres (§ 36).

Hvem fører tilsyn

Loven giver Sikkerhedsstyrelsen tilsynet med e-handel, banktjenester og e-bøger, mens andre styrelser tager sig af kommunikation og transport (§ 45). Sikkerhedsstyrelsen er siden januar 2026 en del af Erhvervsstyrelsen, men opgaverne er de samme. Myndigheden kan kræve oplysninger og dokumentation, og overtrædelser kan straffes med bøde, også for selskaber (§ 57).

Undtagelser og særlige tilfælde

Mikrovirksomheder

Mikrovirksomheder der leverer tjenester, er helt undtaget fra kravene (§ 6, stk. 3). En mikrovirksomhed har under 10 ansatte og enten en årlig omsætning eller en samlet balance på højst 2 mio. euro. Vokser du over grænsen, gælder kravene. Så selvom du er undtaget i dag, er det klogt at bygge en ny løsning tilgængelig.

Løsninger til virksomheder og offentlige kunder

Loven handler om tjenester til forbrugere. En B2B-platform, en kundeportal for erhvervskunder eller et internt system er derfor ikke omfattet. Det kan alligevel blive et krav, hvis dine kunder stiller det i kontrakten.

Det gælder især offentlige kunder. Statslige, regionale og kommunale myndigheder er omfattet af lov nr. 692 af 8. juni 2018 om tilgængelighed af offentlige organers websteder og mobilapplikationer. De skal gøre deres websteder og apps tilgængelige og offentliggøre en tilgængelighedserklæring. Leverer du software til en kommune, er kravet deres, men opgaven bliver din.

Ældre indhold og tredjepartsindhold

Loven undtager blandt andet dokumenter og forudindspillet video og lyd der er offentliggjort før 28. juni 2025, arkiver der ikke er opdateret siden, og tredjepartsindhold som du hverken har finansieret, udviklet eller har kontrol over (§ 2). Et betalingsmodul eller en bookingwidget du selv har valgt og bygget ind, falder efter min vurdering ikke ind under den undtagelse.

Uforholdsmæssig byrde

Du kan undlade krav, hvis de vil ændre tjenesten grundlæggende eller være en uforholdsmæssig stor byrde (§ 8). Men vurderingen skal laves efter kriterierne i lovens bilag 5, dokumenteres, gemmes i mindst fem år og fornyes mindst hvert femte år, og myndigheden skal have besked (§§ 9-12). Bruger du andre midler end dine egne til at forbedre tilgængeligheden, fx et tilskud, kan du slet ikke påberåbe dig byrden (§ 8, stk. 2). Det er ikke en genvej.

WCAG: den standard du i praksis skal bygge efter

WCAG (Web Content Accessibility Guidelines) er W3C's retningslinjer for tilgængeligt webindhold. De består af konkrete succeskriterier på tre niveauer: A, AA og AAA. Niveau AA er det typiske mål i lovgivning og kontrakter, mens AAA er for strengt til at være et realistisk krav til en hel løsning.

Tilgængelighedsloven nævner ikke WCAG direkte. Den siger i stedet at tjenester der følger harmoniserede europæiske standarder, formodes at opfylde kravene (§ 14). Den europæiske standard for digital tilgængelighed hedder EN 301 549. Offentlige websteder bliver allerede målt efter den, og ifølge W3C's oversigt over EU-reglerne indeholder version 3.2.1 af standarden WCAG 2.1 niveau AA ordret for webindhold.

Den nyeste version er WCAG 2.2, som tilføjer seks kriterier på niveau A og AA:

• Klikflader skal have en vis minimumsstørrelse.
• Det element der har fokus, må ikke gemme sig bag fx en fast menu eller et cookiebanner.
• Login må ikke afhænge af at brugeren husker eller løser noget, fx ved at blokere for at indsætte en adgangskode.
• Træk og slip skal have et alternativ.
• Hjælp og kontaktmuligheder skal stå samme sted, når de går igen på flere sider.
• Brugeren skal ikke indtaste de samme oplysninger to gange i samme forløb.

WCAG 2.2 bygger oven på 2.1, så jeg anbefaler at bygge nye løsninger efter WCAG 2.2 AA. Så er du dækket i dag og bedre forberedt, når standarderne bliver opdateret.

De fleste hjemmesider har langt igen. WebAIM's årlige analyse af en million forsider fandt automatisk registrerbare WCAG-fejl på 95,9 % af dem i 2026. Seks fejltyper går igen år efter år: for lav kontrast, billeder uden alternativ tekst, formularfelter uden label, tomme links, tomme knapper og manglende angivelse af sprog. Alle seks er billige at undgå, når man bygger fra bunden.

Sådan gør du din hjemmeside eller webapp tilgængelig i seks trin

1. Afklar om du er omfattet. Brug tabellen øverst, og skriv begrundelsen ned. Er du undtaget, har du svaret klar, når en kunde eller samarbejdspartner spørger.
2. Udpeg de vigtigste brugerrejser. Find de forløb hvor en barriere koster mest: søgning, kurv, oprettelse af konto, login, betaling og kontakt. Start dér i stedet for at teste hver eneste side.
3. Kør en automatisk test. Gratis værktøjer som Lighthouse (indbygget i Chrome), axe og WAVE finder de mest almindelige fejl på få minutter. De finder kun en del af problemerne. De kan se at et billede mangler en alternativ tekst, men ikke om teksten beskriver billedet.
4. Test med tastatur og skærmlæser. Læg musen væk, og gennemfør et køb kun med Tab, Enter og piletasterne. Kan du hele tiden se hvor du er? Kan du lukke cookiebanneret og vælge levering? Prøv derefter med VoiceOver på Mac og iPhone eller den gratis NVDA på Windows. Det er her de alvorlige fejl viser sig.
5. Ret fejlene i den rigtige rækkefølge. Først det der blokerer et køb eller et login, så det der gør det besværligt, og til sidst det kosmetiske. Ret fejlen i den fælles komponent, fx knappen eller formularfeltet, så rettelsen slår igennem overalt.
6. Skriv tilgængelighedserklæringen, og gør det til en vane. Beskriv tjenesten, hvordan den bruges, hvilken standard du følger, og hvilke mangler du kender til. Skriv kravet ind i kravspecifikationen til nye projekter, så nye funktioner bliver testet før hver udgivelse og ikke kun én gang.

Hvad der driver prisen på tilgængelighed

Jeg kan ikke give dig en pris uden at se løsningen, og jeg vil ikke opfinde gennemsnitstal. Men hvad der driver prisen, er ret forudsigeligt:

• Om det bygges ind fra start. På en ny løsning handler det mest om at gøre tingene rigtigt første gang: korrekt HTML, labels, kontrast og synligt fokus. Det koster langt mindre end at rette det bagefter.
• Hvordan koden er bygget. Har løsningen et fælles sæt komponenter, rettes en knap ét sted. Er den bygget side for side, skal den samme fejl rettes mange steder. Det er et af tegnene på en sund kodebase.
• Tredjepartsværktøjer. Cookiebanner, chat, betaling og booking er ofte de sværeste dele, fordi du ikke selv styrer koden. Nogle gange er løsningen at skifte leverandør.
• Indholdet. Alternative tekster, overskrifter og linktekster skrives af dem der redigerer siden. Det kræver en kort instruktion og et CMS der beder om dem.
• Designet. Er farverne valgt uden tanke på kontrast, kan rettelsen ramme brandets farver. Så er det en designbeslutning og ikke kun en kodeopgave.

Tilgængelighed minder på den måde om sikkerhed: begge dele er billige at tænke ind fra start og dyre at eftermontere. Jeg har en tilsvarende gennemgang af de sårbarheder alle webapps skal beskyttes mod.

Hvornår du ikke har brug for en udvikler

En stor del af arbejdet kan du klare selv:

• Har du en webshop på en standardplatform, er det temaet og de installerede apps der afgør det meste. Vælg et tema hvor udvikleren dokumenterer tilgængelighed, og ret indholdet selv.
• Er du mikrovirksomhed med en enkel hjemmeside, kommer du langt med tjeklisten nedenfor og en automatisk test.
• Er dit spørgsmål om du er omfattet, eller hvordan en undtagelse skal dokumenteres, er det en jurist og ikke en udvikler du har brug for.

Du har brug for en udvikler, når fejlene sidder i koden: egne komponenter, et specialudviklet betalingsforløb, en webapp med dynamiske formularer eller et bookingsystem bygget til dig. Og skal du alligevel have lavet en ny løsning, er det det rigtige tidspunkt at få tilgængelighed med.

Næste skridt

Brug tjeklisten som et første tjek af din egen løsning. Den erstatter ikke en grundig test, men den fanger de fejl der oftest står i vejen for brugerne.

Skal du lancere en ny side, så tag punkterne med i tjeklisten før din nye hjemmeside går live. Vil du have bygget en hjemmeside eller webshop der er tilgængelig fra første dag, kan du se hvordan jeg arbejder, på siden om udvikling af hjemmesider.

Ofte stillede spørgsmål

Hvem har ansvaret: min virksomhed eller udvikleren?+

Det har din virksomhed. Loven lægger ansvaret på tjenesteyderen, altså den der tilbyder tjenesten til forbrugerne, også når en udvikler eller et bureau har bygget den. Skriv derfor i aftalen med udvikleren hvilken standard løsningen skal leve op til, fx WCAG 2.2 niveau AA, og hvordan det bliver testet. Så har du noget konkret at holde leverandøren op på, hvis kravet ikke er opfyldt.

Gælder kravene også for apps?+

Ja, hvis appen bruges til en omfattet tjeneste. Loven nævner udtrykkeligt tjenester til mobile enheder, herunder apps, så en app hvor forbrugere handler eller booker, er omfattet på samme måde som hjemmesiden. Principperne er de samme, men testen er anderledes: brug VoiceOver på iPhone og TalkBack på Android, og tjek at teksten kan forstørres via telefonens indstillinger uden at layoutet går i stykker.

Skal gamle PDF'er og videoer gøres tilgængelige?+

Ikke dem der er offentliggjort før 28. juni 2025. Loven undtager dokumenter og forudindspillet video og lyd fra før den dato, og det samme gælder arkiver der ikke er opdateret siden. Nye PDF'er og videoer, der er en del af en omfattet tjeneste, skal derimod være tilgængelige. Det betyder typisk undertekster på videoer og PDF'er med rigtig tekst og overskrifter i stedet for indscannede billeder.

Hjælper et tilgængelighedsplugin eller overlay?+

Sjældent nok til at opfylde kravene. Et overlay er et script der lægger en værktøjslinje oven på siden, men det retter ikke fejlene i selve koden, fx en knap uden navn eller et formularfelt uden label. Brugere af skærmlæsere har desuden typisk deres egne indstillinger og hjælpemidler, så værktøjslinjen tilføjer ikke meget. Jeg anbefaler at bruge pengene på at rette fejlene i koden.