Webtilgængelighed

Webtilgængelighed handler om at sikre, at alle mennesker kan bruge din hjemmeside, uanset om de har et synshandicap, hørenedsættelse, motoriske begrænsninger eller kognitive udfordringer. Det er ikke blot god praksis, det er i stigende grad et lovkrav, der gælder for mange danske virksomheder og offentlige institutioner. Forstår du kravene og implementerer dem korrekt, undgår du juridiske problemer og når ud til en bredere målgruppe.

Hvad er webtilgængelighed?

Webtilgængelighed, ofte refereret til via standarden WCAG (Web Content Accessibility Guidelines), definerer et sæt tekniske og designmæssige krav til, hvordan webindhold skal præsenteres. Målet er, at hjemmesider kan bruges af alle, herunder personer der anvender skærmlæsere, tastaturnavigation eller andre hjælpemidler.

WCAG er udviklet af W3C (World Wide Web Consortium) og udgør det internationale referencepunkt for tilgængelighed. Den seneste version, WCAG 2.2, indeholder kriterier fordelt på tre overensstemmelseniveauer: A, AA og AAA, hvor AA er det niveau, som lovgivning typisk kræver.

Hvem er lovgivningen rettet mod?

I Danmark er webtilgængelighed reguleret via EU’s webdirektiv (direktiv 2016/2102), som er implementeret i dansk ret. Loven gælder primært for offentlige myndigheder, men private virksomheder er i stigende grad underlagt krav via EU’s tilgængelighedslov (European Accessibility Act), som trødte fuldt i kraft i juni 2025.

Tilgængelighedsloven fra 2025 berører produkter og tjenester, der sælges eller leveres i EU, herunder e-handelsplatforme, banktjenester og digitale kommunikationsværktøjer. Driver du en webshop, bør du allerede nu gennemgå din platform for tilgængelighed.

Hvem er undtaget?

Mikrovirksomheder med færre end 10 ansatte og en årsomsætning under 2 millioner euro er som udgangspunkt undtaget fra European Accessibility Act. Det fritager dem dog ikke fra god praksis, og mange kunder forventer i dag tilgængeligt indhold uanset virksomhedens størrelse.

De fire principper i WCAG

WCAG er bygget op om fire overordnede principper, der tilsammen danner akronymet POUR. Alle kriterier i standarden falder ind under ét af disse fire principper.

Princip	Betydning	Eksempel
Perceivable (Opfattelig)	Indhold skal kunne opfattes af sanserne	Alternativ tekst på billeder, undertekster på video
Operable (Betjenelig)	Brugergrænseflade skal kunne betjenes	Tastaturnavigation, ingen tidsbegrænsede handlinger
Understandable (Forståelig)	Indhold og betjening skal være forståelig	Klart sprog, forudsigelig navigation, fejlmeddelelser
Robust	Indhold skal fortolkes af hjælpemidler	Korrekt HTML-markup, ARIA-attributter

De vigtigste tekniske krav i WCAG 2.2 AA

Alternativ tekst (alt-tekst)

Alle informationsbærende billeder skal have en beskrivende alt-tekst, som skærmlæsere kan oplæse. Dekorative billeder bør have en tom alt-attribut (alt=""), så hjælpemidler springer dem over. Det er et af de hyppigst oversete krav, selv på professionelle hjemmesider.

Farvekontrast

WCAG 2.2 AA kræver en kontrastforhold på mindst 4,5:1 for normal tekst og 3:1 for stor tekst (18pt og derover). Mange hjemmesider fejler på dette punkt, fordi designere vælger lyse gråtoner eller pastelfarver, der ser æstetiske ud, men er svære at læse for personer med nedsat syn.

Du kan kontrollere kontrasten med gratis værktøjer som WebAIM Contrast Checker eller Colour Contrast Analyser. Disse er uundværlige, når du arbejder med hjemmesidedesign.

Tastaturnavigation

Alle funktioner på hjemmesiden skal kunne betjenes udelukkende med tastaturet, uden brug af mus. Det inkluderer menuer, formularer, modaler og knapper. Mange brugere med motoriske handicap er afhængige af tastaturet eller alternative inputenheder.

Fokusindikatoren, den visuelle markering der viser, hvilken element der er aktivt, må ikke fjernes med CSS. Det er en udbredt fejl, der opstår, når designere skriver outline: none i stylesheets for at undgå den blå kant rundt om klikbare elementer.

Overskriftshierarki

Brug overskrifter i logisk rækkefølge: H1, H2, H3 og så videre. Spring ikke niveauer over. Skærmlæsere bruger overskrifter til at give brugere et overblik over sidens struktur og til at hoppe direkte til relevante afsnit. Forkert hierarki forvirrer og gør indholdet utilgængeligt.

Formularetiketter

Alle formularfelter skal have en tilknyttet label-tag, der beskriver feltets formål. Brug aldrig kun placeholder-tekst som erstatning for en label, da placeholder forsvinder, når brugeren begynder at skrive, og ikke altid oplæses korrekt af hjælpemidler.

Linkbeskrivelser

Links skal give mening uden den omgivende kontekst. Undgå generiske linktekster som “klik her” eller “læs mere”. Skriv i stedet beskrivende tekster som “læs vores guide til GDPR”, så skærmlæserbrugere forstår, hvad linket fører til, når de gennemgår en liste af links på siden.

Undertekster og transskriptioner

Videoindhold skal have undertekster for brugere med hørenedsættelse. Lydindhold bør have en teksttransskription. Automatisk genererede undertekster fra platforme som YouTube er ikke altid tilstrækkelige og bør gennemgås og rettes manuelt.

WCAG-niveauer: A, AA og AAA

Niveau	Krav	Lovkrav?
A	Grundlæggende tilgængelighed, minimumskrav	Ja, som minimum
AA	Standard niveau, dækker de fleste brugerbehov	Ja, kræves i de fleste lovgivninger
AAA	Højeste niveau, ikke altid praktisk muligt	Nej, men anbefales hvor muligt

Tilgængelighed og SEO: To sider af samme sag

Mange af de tekniske krav i WCAG overlapper direkte med god søgemaskineoptimering. Alt-tekster hjælper Google med at forstå billeder. Korrekt overskriftshierarki gør indholdet lettere at indeksere. Beskrivende linktekster forbedrer intern linkstruktur. En tilgængelig hjemmeside er som regel også en SEO-venlig hjemmeside.

Derudover er sidens indlæsningshastighed relevant for tilgængelighed. En langsom side er en barriere for brugere med ældre enheder eller dårlig internetforbindelse. Arbejder du med hastighedsoptimering, styrker du samtidig tilgængeligheden.

Tilgængelighed på populære platforme

WordPress

WordPress har et stort udvalg af tilgængeligheds-plugins, herunder WP Accessibility og Accessibility Checker. Mange temaer er dog ikke tilgængeligheds-testede som standard, og det er dit ansvar at vælge et tema, der overholder WCAG. Gutenberg-editoren understøtter ARIA-attributter og semantisk markup, hvis du bruger det korrekt.

Wix

Wix har forbedret sin tilgængelighed markant de seneste år og tilbyder et tilgængeligheds-panel, der guider dig igennem de vigtigste indstillinger. Platformen er dog stadig begrænset i forhold til fuld kontrol over HTML og ARIA-attributter sammenlignet med mere tekniske løsninger.

Shopify

Shopify har et stigende fokus på tilgængelighed og mange af de populære temaer er delvist WCAG-kompatible. Du bør stadig gennemgå dit tema manuelt, da tilpasninger og apps kan introducere tilgængeligheds-fejl. Bruger du Shopify, anbefales det at køre en automatisk tilgængeligheds-scanning efter større opdateringer.

Squarespace

Squarespace tilbyder begrænsede muligheder for manuel tilpasning af tilgængelighed. Platformen håndterer en del grundlæggende krav automatisk, men du har ikke fuld kontrol over markup og ARIA-roller, hvilket kan gøre det vanskeligt at opnå fuld WCAG AA-overensstemmelse.

Tilgængelighed og mobilvenlig design

En mobilvenlig hjemmeside er ikke automatisk tilgængelig, men de to begreber hænger tæt sammen. Responsivt design sikrer, at indhold vises korrekt på alle skærmstørrelser, men tilgængelighed kræver yderligere opmærksomhed på touch-mål størrelse, zoom-muligheder og skærmlæser-kompatibilitet på mobile enheder.

WCAG 2.2 introducerede nye kriterier specifikt rettet mod touch-interfaces, herunder krav om at klikbare elementer er mindst 24×24 CSS-pixels store, og at der er tilstrækkelig afstand mellem interaktive elementer.

Tilgængelighed for specifikke brugergrupper

Synshandicap

Brugere med synshandicap anvender skærmlæsere som NVDA, JAWS eller VoiceOver. De er afhængige af korrekt semantisk HTML, meningsfulde alt-tekster, logisk fokusrækkefølge og ARIA-landmarks, der definerer sidens regioner som header, main, nav og footer.

Motoriske begrænsninger

Brugere med motoriske begrænsninger kan anvende tastatur, øjenstyring, stemmestyring eller switch-enheder. Alle interaktive elementer skal være tilgængelige via disse inputmetoder, og der må ikke være tidsbegrænsede handlinger, der ikke kan forlænges eller deaktiveres.

Kognitive udfordringer

Klart og enkelt sprog, forudsigelig navigation og tydelige fejlmeddelelser er afgørende for brugere med kognitive udfordringer som dysleksi, ADHD eller demens. Undgå lange, komplekse sætninger og brug visuelle hjælpemidler som ikoner og strukturerede lister til at understøtte teksten.

Hørenedsættelse

Brugere med hørenedsættelse er afhængige af undertekster, transskriptioner og visuelle alternativer til lydbaserede advarsler og notifikationer. Brug aldrig lyd alene som den eneste måde at kommunikere vigtig information på.

Sådan tester du din hjemmeside for tilgængelighed

Automatiserede værktøjer

Automatiserede scanningsværktøjer kan identificere op til 30-40 procent af tilgængeligheds-fejl. De er et godt udgangspunkt, men kan ikke erstatte manuel testning. De mest anvendte gratis værktøjer inkluderer:

• WAVE (wave.webaim.org) – visuel tilgængeligheds-evaluering direkte i browseren
• axe DevTools – browser-udvidelse til Chrome og Firefox
• Lighthouse – indbygget i Chrome DevTools, giver en tilgængeligheds-score
• Siteimprove Accessibility – mere avanceret scanning med prioriteret fejlliste

Manuel testning

Manuel testning er uundværlig og bør inkludere tastaturnavigation gennem hele siden, test med en skærmlæser (NVDA er gratis til Windows, VoiceOver er indbygget i macOS og iOS), og kontrol af farvekontrast på alle tekstfarver og baggrunde.

Brugertest med personer med handicap

Den mest effektive testmetode er at involvere faktiske brugere med handicap. Organisationer som Danske Handicaporganisationer kan hjælpe med at finde testpersoner. Brugertest afslører problemer, som hverken automatiserede værktøjer eller eksperter opdager.

Tilgængeligheds-erklæring

Offentlige myndigheder er lovpligtigt krævet at publicere en tilgængeligheds-erklæring på deres hjemmeside. Erklæringen skal beskrive, i hvilken grad hjemmesiden overholder WCAG, hvilke dele der ikke er tilgængelige og hvorfor, samt en kontaktmulighed for brugere der oplever barrierer.

Private virksomheder, der er underlagt European Accessibility Act, vil fra 2026 ligeledes have krav om dokumentation for tilgængelighed. Det er god praksis at udarbejde en erklæring allerede nu, da det signalerer ansvarlighed og giver et klart overblik over, hvad der mangler at blive løst.

Hyppige fejl og hvordan du undgår dem

Fejl	Konsekvens	Løsning
Manglende alt-tekst på billeder	Skærmlæsere kan ikke beskrive billedet	Tilføj beskrivende alt-tekst til alle informationsbærende billeder
For lav farvekontrast	Tekst er svær at læse for svagsynede	Brug kontrasttjekker og sikr minimum 4,5:1 ratio
Fjernet fokusindikator	Tastaturbrugere ved ikke, hvor de er på siden	Behold eller redesign fokusindikatoren, fjern den aldrig
Formularer uden labels	Skærmlæsere kan ikke identificere felternes formål	Tilknyt label-tags til alle formularfelter
Video uden undertekster	Utilgængeligt for hørehæmmede	Tilføj korrekte undertekster og transskriptioner
Ikke-semantisk HTML	Hjælpemidler kan ikke fortolke sidens struktur	Brug korrekte HTML-elementer: button, nav, main, header

ARIA-attributter: Hvornår og hvordan

ARIA (Accessible Rich Internet Applications) er et sæt HTML-attributter, der tilføjer semantisk information til elementer, som ikke har det i forvejen. ARIA bruges til at beskrive roller, tilstande og egenskaber for dynamisk indhold og komplekse UI-komponenter som dropdowns, tabs og modaler.

Den vigtigste regel ved brug af ARIA er: brug altid native HTML-elementer, når de findes. Brug <button> frem for <div role="button">. ARIA er en løsning, når native HTML ikke slår til, ikke en erstatning for korrekt HTML.

De mest brugte ARIA-attributter

• aria-label – giver et element et tilgængeligt navn, når synlig tekst ikke er tilstrækkelig
• aria-describedby – peger på et element, der indeholder en beskrivelse
• aria-expanded – angiver om et element som en dropdown er åbent eller lukket
• aria-hidden – skjuler dekorative elementer for skærmlæsere
• aria-live – annoncerer dynamiske indholdsopdateringer for skærmlæsere
• role – definerer elementets semantiske rolle, fx role=”dialog” eller role=”navigation”

Tilgængelighed som en del af udviklingsprocessen

Den mest effektive tilgang til webtilgængelighed er at integrere det fra starten af et projekt, ikke som en eftertanke. Tilgængelighed er langt billigere og nemmere at implementere under design og udvikling end at rette op på efterfølgende.

Definér tilgængeligheds-krav i din designbrief, vælg komponenter og temaer der er dokumenteret tilgængelige, og inkluder tilgængeligheds-testning som en del af din kvalitetssikring. Arbejder du med hjemmeside sikkerhed og krav generelt, bør tilgængelighed stå på listen over faste tjekpunkter ved lancering og ved større opdateringer.

Juridiske konsekvenser ved manglende tilgængelighed

I USA har der i årevis været retssager om manglende webtilgængelighed under Americans with Disabilities Act (ADA). I Europa er retshåndhævelsen historisk set mindre aggressiv, men European Accessibility Act ændrer dette billede markant fra 2026.

Virksomheder der ikke overholder kravene risikerer klager til nationale tilsynsmyndigheder, bøder og krav om at bringe hjemmesiden i overensstemmelse inden for en given frist. I Danmark er det Digitaliseringsstyrelsen, der fører tilsyn med offentlige myndigheders overholdelse af webtilgængeligheds-reglerne.