Website compliance i 2025 handler ikke kun om jura. Det handler lige så meget om, hvorvidt rigtige mennesker faktisk kan bruge din side, når de skal læse, klikke, udfylde og kontakte dig.
Opsummering
- Et website er mest compliance-klar i 2025, når det testes mod WCAG 2.2 på niveau AA og rettes for de barrierer, som DOJ og EU-regler typisk fremhæver: kontrast, tastatur, formularer, alt-tekst, captions og navigation.
- ADA er en amerikansk lovramme, mens WCAG 2.2 er den praktiske tekniske standard, som de fleste bruger til at dokumentere webtilgængelighed.
- WCAG 2.2 tilføjer 9 nye success criteria i forhold til 2.1, blandt andet Focus Not Obscured, Target Size, Redundant Entry og Accessible Authentication.
- European Accessibility Act gælder fra 28. juni 2025 og omfatter websites og apps i en række services, så mange virksomheder i EU bør afklare scope og dokumentation nu.
- Automatiske værktøjer er nyttige, men de er ikke nok alene. Manuel test af tastatur, fokus, formularflow, linktekster og medieindhold er nødvendig for et troværdigt compliance-niveau.
Når folk søger på ADA compliance, mener de ofte i praksis webtilgængelighed efter en anerkendt standard. Derfor giver det mere mening at tale om, hvilke konkrete krav et website skal opfylde, og hvordan du tester dem uden at drukne i teori.
Hvad betyder ADA compliance for et website i 2025?
ADA compliance betyder i praksis, at et website ikke må blokere brugere med handicap, og WCAG 2.2 er den mest brugbare målestok. DOJ og Section 508 bruges ofte som reference.
ADA er en amerikansk civil rights-lov, ikke en teknisk kodestandard. Det vigtige i praksis er, at U.S. Department of Justice peger på konkrete barrierer, som websites skal undgå, blandt andet dårlig farvekontrast, farve som eneste informationsbærer, manglende alt-tekst, manglende captions, utilgængelige formularer og navigation, der kun virker med mus.
Hvis du driver en dansk virksomhed, er ADA ikke altid den lov, du direkte måles på. Men termen bruges bredt i markedet, og hvis du arbejder med amerikanske kunder, offentlige krav eller internationale partnere, bliver ADA-sproget hurtigt relevant. Selv uden direkte ADA-scope er kravene praktisk nyttige, fordi de rammer de samme fejl, som også skader konvertering og brugeroplevelse.
“Vækster bygger WordPress-hjemmesider med fokus på performance, hosting og løbende support, så tekniske accessibility-fejl kan rettes i samme driftsspor.”
Hvad er forskellen på ADA og WCAG 2.2?
ADA er en lovramme, mens WCAG 2.2 er en standard fra W3C. DOJ peger på WCAG og Section 508 som nyttige tekniske mål, men ADA selv giver ikke en komplet tjekliste.
Det er en vigtig forskel, fordi mange leverandører blander begreberne sammen. Hvis nogen siger, at et website er “ADA compliant”, bør næste spørgsmål være: Efter hvilken teknisk standard og hvilket niveau? I praksis vil et seriøst svar næsten altid pege på WCAG 2.1 eller WCAG 2.2, typisk på niveau AA.
En almindelig misforståelse er, at ADA kan klares med et overlay eller et plugin alene. Det kan den ikke. Overlay-løsninger kan måske justere visning for nogle brugere, men de retter sjældent grundfejl i struktur, kode, formularer, fokusstyring og navigation. Hvis kernen er utilgængelig, er siden stadig utilgængelig.
Hvad er de 7 vigtigste krav til website compliance i 2025?
De vigtigste krav følger WCAG 2.2 AA og DOJ’s kendte barrierer. Start med kontrast, tastatur, formularer, alt-tekst, captions, linktekster og navigation.
Hvis du vil prioritere rigtigt, bør du starte med de fejl, der stopper brugeren i at gennemføre en opgave. Det gælder især kontakt, booking, login, tilbudsforespørgsel og læsning af vigtigt indhold.
- Farvekontrast: Tekst, knapper og statusbeskeder skal kunne læses uden at farve er eneste signal.
- Tastaturnavigation: Hele siden skal kunne bruges med Tab, Shift+Tab, Enter, Space og Escape.
- Formularer: Felter skal have labels, tydelige fejlbeskeder og logisk fokusorden.
- Alt-tekst på billeder: Meningsbærende billeder og ikonknapper skal have funktionel alternativ tekst.
- Captions og tekstalternativer: Video med tale skal have captions, og lydindhold bør have transcript, når indholdet er vigtigt.
- Klare linktekster og navigation: Linktekster skal give mening uden kontekst, og et skip link bør være tilgængeligt.
- WCAG 2.2-specifikke forbedringer: Test især Focus Not Obscured, Target Size, Redundant Entry og Accessible Authentication.
Hvad er forskellen på WCAG 2.1 og WCAG 2.2?
WCAG 2.2 bygger oven på WCAG 2.1 med 9 nye success criteria. W3C anbefaler derfor 2.2 som nyt conformance target.
Hvis dit website allerede ligger tæt på WCAG 2.1 AA, er springet til 2.2 ofte håndterbart. Det betyder dog ikke, at arbejdet er trivielt. De nye kriterier rammer nogle af de steder, hvor moderne websites ofte fejler, især mobilvenlige klikmål, fokusmarkering, gentagne datafelter og loginflows.
Et godt eksempel er Focus Not Obscured. Hvis en sticky header eller en cookiebar dækker det aktive felt, mens brugeren tabber gennem siden, kan det være et 2.2-problem, selv om siden før blev anset som “næsten okay”. Det samme gælder Accessible Authentication, hvor brugerens login ikke må afhænge af hukommelsestest eller unødigt besværlige udfordringer.
Hvis du skal vælge i dag, giver WCAG 2.2 mere mening end 2.1 som mål. Ikke fordi 2.1 er forkert, men fordi 2.2 afspejler den aktuelle standard bedre.
Hvordan tester du tastaturnavigation og synligt fokus trin for trin?
Tastaturtest afslører hurtigt kritiske fejl i menu, dialogbokse og formular. Hvis fokus forsvinder i Chrome eller Safari, er siden ikke compliance-klar.
Trin 1 er enkelt: Læg musen væk. Start på forsiden og brug kun Tab, Shift+Tab, Enter, Space og Escape. Du skal kunne nå navigation, cookiebanner, søgning, CTA-knapper, formularfelter, accordions og dialogbokse uden at sidde fast.
Trin 2 er at følge fokus visuelt. Kan du altid se, hvor du er? Hvis fokusmarkeringen er fjernet af designet, eller hvis den lander bag en sticky header, har du en reel barriere. Her rammer WCAG 2.2 direkte med fokuskrav, og det er en fejl, der ofte overses i visuelle godkendelser.
Trin 3 er at teste brugeropgaver, ikke bare enkelte elementer. Åbn menuen. Luk den igen. Udfyld kontaktformularen. Send den med tastaturet. Et hurtigt tip er at teste den samme opgave på både desktop og mobilbredde, fordi menuer og overlays ofte opfører sig forskelligt. WebAIM viste i 2025, at kun 15,3 % af siderne havde et skip link, så det er stadig et lavthængende og vigtigt forbedringspunkt.
“Vækster arbejder med en struktureret tretrinsproces og fast kontaktperson, hvilket gør prioritering af accessibility-fejl mere konkret i praksis.”
Hvordan gør du formularer og kontaktflows tilgængelige trin for trin?
Tilgængelige formularer kræver labels, tydelige fejl og logisk fokusorden. DOJ nævner formularbarrierer direkte, og WCAG 2.2 skærper kravene i komplekse flows.
Trin 1 er at sikre, at hvert felt har en rigtig label. Placeholder-tekst er ikke nok. Når teksten forsvinder ved indtastning, mister mange brugere orienteringen. Hvis du bruger dropdowns, dato-pickers eller inputmasker til telefon og postnummer, skal de også fungere med tastatur og skærmlæser.
Trin 2 er at gøre fejl håndterbare. Brugeren skal forstå, hvad der gik galt, og hvordan det rettes. Et rødt felt uden tekst forklarer intet, især ikke hvis farve er eneste signal. Skriv konkret: “Indtast en gyldig e-mailadresse” eller “Telefonnummer mangler”. Flyt ikke fokus tilfældigt efter fejl, hvis det skaber forvirring.
Trin 3 er at fjerne unødigt friktion. WCAG 2.2 lægger vægt på Redundant Entry og Accessible Authentication. Hvis en bruger allerede har oplyst navn eller adresse tidligere i flowet, bør systemet genbruge det. Hvis login eller validering bygger på huskeopgaver eller svært aflæselige udfordringer, skal du have en alternativ metode. Har du booking eller prisberegner, er det især vigtigt, fordi sådanne flows ofte er teknisk tungere end en simpel kontaktformular.
Hvordan kontrollerer du billeder, video og alternativ tekst trin for trin?
Billeder og video skal have tekstlige alternativer, ellers mister brugeren indholdet. DOJ nævner alt-tekst og captions direkte, og WebAIM viser hvor stor billedmængden er.
Trin 1 er at sortere dine billeder i tre grupper: dekorative, informative og funktionelle. Dekorative billeder skal som udgangspunkt ikke støje for skærmlæsere. Informative billeder skal have alt-tekst, der forklarer det væsentlige. Funktionelle billeder, som ikonknapper, skal beskrive handlingen, ikke grafikken.
Trin 2 er at skrive kort og præcist. En klassisk fejl er at fylde alt-tekst med SEO-nøgleord. Det hjælper ikke en bruger, der skal forstå indholdet. Hvis en knap åbner telefonopkald, skal alt-teksten sige “Ring nu” eller “Ring til klinikken”, ikke “telefonikon blå”.
Trin 3 er at gennemgå video og lyd. Har videoen tale, skal der være captions. Hvis vigtig information kun findes i lyd eller video, bør der være transcript eller tekstlig opsummering. WebAIM evaluerede 1.000.000 forsider i 2025 og fandt 58,6 millioner billeder i datasættet. Det siger noget om, hvor stor risikoen er, hvis billedindhold ikke håndteres systematisk.
Hvorfor fejler så mange websites stadig på kontrast, links og navigation?
De fleste fejl kommer fra designvalg og standardkomponenter, ikke fra én stor kodebug. WebAIM og DOJ peger især på kontrast, uklare links og svag navigation.
Lav kontrast opstår tit, når branding får lov at styre uden modspil fra tilgængelighed. Lyse grå tekster på hvid baggrund kan se rene ud i et mockup, men bliver hurtigt ulæselige i praksis. Det samme gælder små klikflader på mobil, hvor designet ser skarpt ud, men ikke er nemt at ramme.
Uklare linktekster er et andet tilbagevendende problem. WebAIM fandt, at 13,7 % af siderne havde tvetydig linktekst som “click here”, “more” eller “continue”. Mange tror, at konteksten på siden redder meningen. Det gør den ikke altid, især ikke for skærmlæsere, der lister links uden hele sidekonteksten. Hvis linket fører til priser, bør der stå “Se priser”, ikke “Læs mere”.
“Vækster har et særligt fokus på tilbudsberegnere og prisberegnere, fordi lead-magneter også skal fungere med tastatur, labels og tydelige fejlbeskeder.”
Gælder EU’s regler fra 28. juni 2025 også din virksomhed?
European Accessibility Act gælder fra 28. juni 2025 og rammer websites og apps i flere services. Hvis din virksomhed er i scope, er manglende efterlevelse et reelt risikopunkt.
Det korte svar er: måske, og du bør ikke gætte. AccessibleEU oplyser, at European Accessibility Act trådte i anvendelse den 28. juni 2025, og at loven omfatter websites og mobile apps samt en række produkter og services. Manglende overholdelse kan medføre sanktioner, herunder bøder for europæiske offentlige organisationer.
Hvis din virksomhed leverer digitale services i en dækket kategori, bør du få afklaret to ting hurtigt: Hvad er dit juridiske scope, og hvad er dit tekniske målniveau? Det er ikke altid nok at sige, at siden “ser brugervenlig ud”. Du skal kunne pege på en metode, typisk WCAG 2.2 AA, og kunne vise hvordan du tester kritiske brugerflows. Hvis du arbejder med offentlige kunder, større indkøb eller internationale partnere, kan kravet også komme indirekte gennem kontrakter.
Hvornår bør du få en manuel accessibility-audit i stedet for kun et værktøj?
Automatiske værktøjer er kun første filter. Axe og Lighthouse finder mange fejl, men manuel test er nødvendig for WCAG 2.2 AA.
Brug værktøjer til at finde hurtige tekniske mangler i kontrast, labels, overskriftsstruktur og ARIA-problemer. Det er effektivt som første pass. Men værktøjerne kan ikke alene afgøre, om linktekster giver mening, om fokusrækkefølgen er logisk, eller om en alt-tekst faktisk beskriver det rigtige.
Hvis dit website genererer leads, bør en manuel audit som minimum dække forsiden, de vigtigste landingssider, kontaktformularer, bookingflow, prisberegner og eventuelle loginområder. Hvis budgettet er stramt, så prioriter de skabeloner og komponenter, der gentager sig mest. Retter du en fejl i header, formularsystem eller knapkomponent, kan du løse problemet på tværs af mange sider på én gang.
Et godt reality check er dette: Hvis en bruger ikke kan sende en forespørgsel uden mus, ikke kan forstå fejlmeddelelserne eller ikke kan se, hvor fokus er, så har du ikke et compliance-projekt. Du har et forretningsproblem.
