Tjekliste for webtilgængelighed til små virksomheder og webshops

Forestil dig en kunde, der bruger skærmlæser. Kunden finder de løbesko, der skal være, vælger størrelse og trykker på det, kunden tror er knappen til kurven. Skærmlæseren siger »knap«. Intet andet. Der er tre af dem på siden, og ingen af dem har et navn, så kunden forsvinder, og du finder aldrig ud af hvorfor.

De fleste tilgængelighedsproblemer på små virksomheders hjemmesider ser sådan ud: usynlige for ejeren, en blindgyde for kunden. Denne tjekliste er til dig, der driver en hjemmeside på Shopify, WooCommerce, Wix eller Squarespace uden en udvikler i huset.

Skal min lille virksomheds hjemmeside være tilgængelig?

Sælger du til forbrugere i EU, er svaret sandsynligvis ja. European Accessibility Act (åbner i en ny fane) har omfattet e-handelstjenester siden 28. juni 2025. Den vigtigste undtagelse gælder mikrovirksomheder, der leverer tjenester: virksomheder med under 10 ansatte og en årlig omsætning eller balance på højst 2 mio. euro. I Danmark står undtagelsen i tilgængelighedslovens § 6, stk. 3.

E-handel betyder her salg på afstand via en hjemmeside eller app »efter individuel anmodning fra en forbruger med henblik på at indgå en forbrugeraftale« (artikel 3, nr. 30). En webshop eller et bookingsystem passer ind. Undtagelsen gælder kun tjenester: sælger du omfattede produkter som e-bogslæsere, gælder kravene til produkter stadig (artikel 4, stk. 5). Det hjælper heller ikke at ligge uden for EU, for en britisk webshop, der sælger til kunder i Frankrig, er omfattet, hvad angår de kunder (artikel 3, nr. 4). Vores guide til European Accessibility Act gennemgår nationale love og bøder.

Storbritanniens Equality Act 2010 (åbner i en ny fane) kræver rimelige tilpasninger for personer med handicap, men fastsætter ingen teknisk standard for hjemmesider. I USA siger justitsministeriets vejledning fra marts 2022 (åbner i en ny fane), at virksomheder, der er åbne for offentligheden, skal gøre det, de tilbyder online, tilgængeligt, og at standarder som WCAG »giver nyttig vejledning«. Uanset hvad loven siger, køber en kunde ikke, hvis vedkommende ikke kan gennemføre din checkout.

Hvad er de mest almindelige tilgængelighedsproblemer på hjemmesider?

Seks fejl dominerer. I WebAIM Million 2026 (åbner i en ny fane), en automatisk scanning af forsiderne på de en million største hjemmesider i februar 2026, havde 95,9 % af siderne påviste WCAG-fejl, i gennemsnit 56,1 fejl pr. side. Tekst med lav kontrast var det mest almindelige problem og fandtes på 83,9 % af forsiderne.

WCAG, retningslinjerne for tilgængeligt webindhold, er standarden bag disse tjek; de fleste love henviser til niveau AA, og vores guide til WCAG 2.2 forklarer den nyeste version. Flere af tjekkene nedenfor kan ingen scanner vurdere.

Kan alle læse din tekst og forstå dine billeder?

Start her, for rettelserne er billige og for det meste nogle, du selv kan lave i redigeringsværktøjet. Tekst skal have nok kontrast, billeder, der bærer information, skal have alternativ tekst, og intet må afhænge af farve alene. Omkring 1 ud af 12 mænd og 1 ud af 200 kvinder har nedsat farvesyn ifølge Colour Blind Awareness (åbner i en ny fane).

• Kontrast. Almindelig tekst skal have et kontrastforhold på mindst 4,5:1 (åbner i en ny fane) mod baggrunden, stor tekst mindst 3:1. Test dine farver i et gratis værktøj, også tekst oven på bannerfotos. Vores guide til farvekontrast viser løsninger, der bevarer dit brand.
• Alternativ tekst til produktbilleder. Beskriv det, en kunde har brug for at vide: »Marineblå uldsweater med ribstrikket rullekrave, set forfra« er bedre end »produktbillede 1«. Start med dine ti bedst sælgende produkter.
• Dekorative billeder. En dekorativ krusedulle i baggrunden skal have tom alternativ tekst, så skærmlæsere springer den over. Nogle platforme udfylder et tomt alt-felt med filnavnet, så tjek din.
• Kun farve. »Udsolgt«, der kun vises som en nedtonet farveprøve, eller et obligatorisk felt, der kun er markeret med rødt, når ikke ud til alle. Se siden med telefonens gråtonefilter, og tilføj et ord eller et ikon overalt, hvor betydningen forsvinder.
• Zoom. Ved 200 % zoom i browseren skal teksten blive større uden at overlappe eller blive skåret af, og menuen skal stadig virke.
• Sidesprog. Alle gratis værktøjer markerer en manglende sprogangivelse. Det er en indstilling i temaet eller en ændring på én linje i skabelonen.

Kan folk bruge din hjemmeside med tastatur?

Mange surfer uden mus: skærmlæserbrugere, personer med rystelser eller begrænset håndbevægelighed og alle, hvis touchpad lige er gået i stykker. Læg musen væk, og tryk på Tab. Du skal kunne nå alle links, knapper og formularfelter i en fornuftig rækkefølge, altid kunne se, hvor du er, og aldrig sidde fast.

• Synligt fokus. En ramme skal vise, hvilket element der er aktivt, og en fastgjort topmenu eller chatboble må ikke dække den (kriterie 2.4.11 Focus Not Obscured i WCAG 2.2). Mange temaer fjerner rammen af æstetiske grunde; en udvikler kan sætte den ind igen.
• Ingen fælder. Åbn menuen, størrelsesvælgeren, pop op-vinduerne og billedgalleriet med tastaturet, vælg noget, og prøv så at komme ud igen. Escape skal lukke pop op-vinduer.
• Navne på ikoner. Alle ikonlinks og ikonknapper skal have et navn, som en skærmlæser kan læse op, f.eks. »Kurv, 2 varer«. Erstat »Klik her« med ord, der siger, hvor linket fører hen.
• Spring over-link og overskrifter. Første tryk på Tab bør helst vise et link som »Gå til indhold«. I WebAIMs skærmlæserundersøgelse fra 2024 (åbner i en ny fane) svarede 71,6 %, at de først navigerer på en lang side via overskrifterne, så brug rigtige overskriftsniveauer og ikke fed skrift.
• Trykflader. WCAG 2.2 kræver flader på mindst 24 × 24 CSS-pixels eller tilstrækkelig afstand omkring dem (succeskriterie 2.5.8 (åbner i en ny fane)).

Kan alle komme igennem dine formularer, din kurv og din checkout?

Det er i checkout, at tilgængelighedsproblemer koster dig penge direkte, så test den fra start til slut, også hvad der sker, når noget går galt. Alle felter skal have en synlig etiket, fejlmeddelelser skal forklare problemet med ord, og login må ikke afhænge af hukommelsestest eller gåder. Din betalingsudbyders sider tæller også.

• Etiketter, ikke pladsholdere. Pladsholdertekst forsvinder, så snart man begynder at skrive, og er ofte for bleg til at kunne læses. Hvert felt skal have en etiket, der forbliver synlig.
• Fejlmeddelelser. Send formularen tom. Hver fejl skal være skrevet ud (»Angiv et postnummer, f.eks. 2100«), stå ved sit felt og blive læst op, ikke bare gøre en ramme rød.
• Spørg ikke to gange. Tilbyd »Faktureringsadressen er den samme som leveringsadressen« i stedet for at lade folk skrive deres leveringsadresse igen. WCAG 2.2 gjorde det til et krav på niveau A, 3.3.7 Redundant Entry.
• Login. Lad folk indsætte adgangskoder og engangskoder og bruge adgangskodeadministratorer. At blokere indsættelse dumper efter kriteriet Accessible Authentication (åbner i en ny fane) i WCAG 2.2, medmindre du tilbyder en anden måde at logge ind på.
• CAPTCHA. Skærmlæserbrugere vurderede CAPTCHA som det mest problematiske på nettet i WebAIMs undersøgelse fra 2024. Har du brug for beskyttelse mod bots, så undgå visuelle opgaver, og tilbyd altid et ikke-visuelt alternativ.
• Tidsfrister. Hvis en kurv eller en reservation udløber, så advar i god tid, og lad folk forlænge den.

Hvis dele af checkout hører til din platform eller betalingsudbyder, så test dem alligevel, rapportér problemerne, og angiv dem som kendte fejl.

Hvad med cookiebannere, pop op-vinduer og chatwidgets?

For dine kunder er scripts fra tredjeparter en del af din hjemmeside. Et cookiebanner, der ikke kan lukkes med tastaturet, blokerer hver eneste side, og en pop op til nyhedsbrevet, der tager fokus midt i checkout, kan stoppe et salg. Test alle scripts, du har tilføjet, og spørg leverandørerne om tilgængelighed, før du installerer et nyt.

• Cookiebanner. Kan du nå knapperne til at acceptere og afvise med Tab, læse dem ved 200 % zoom og fortsætte, hvor du var, bagefter?
• Pop op-vinduer. Fokus skal flytte ind i vinduet, blive der, indtil det lukkes, og så vende tilbage. Escape skal lukke det.
• Chatwidgets. Knappen skal have et navn, vinduet skal kunne åbnes og lukkes med tastaturet, og på en telefon må det ikke ligge oven på »Betal nu«.
• Karruseller. Alt, der bevæger sig automatisk i mere end fem sekunder, skal kunne sættes på pause, stoppes eller skjules (WCAG 2.2 (åbner i en ny fane), succeskriterie 2.2.2 Pause, stop, skjul).
• Indlejret indhold. Anmeldelseswidgets, kort og bookingværktøjer står også på din side. Tag fejlene op med leverandøren.

Virker dine videoer, pdf'er og menukort for alle?

Video skal have undertekster, lyd skal have en transskription, og vigtige oplysninger må ikke kun findes i en pdf eller et billede. En restaurant, hvis menukort er en scannet pdf, eller en butik, hvis størrelsesguide er et foto af en tabel, lukker skærmlæserbrugere ude og alle, der skal zoome ind på en telefon.

• Undertekster og transskriptioner. Ret automatiske undertekster, før du offentliggør. Podcasts skal have en tekstversion.
• Billeder af tekst. Læg menukort, prislister, størrelsesguider og åbningstider på en almindelig webside. Skal du bruge en pdf, så eksportér den med overskrifter og tags fra dit tekstbehandlingsprogram i stedet for at scanne en udskrift.
• Ældre filer. European Accessibility Act kræver ikke, at du retter kontordokumenter eller forudindspillet lyd og video, der er offentliggjort før 28. juni 2025, eller arkiver, du ikke længere opdaterer (artikel 2, stk. 4). Nye filer er omfattet.

Hvad kan jeg selv rette, og hvornår har jeg brug for en udvikler eller en audit?

De fleste problemer med indholdet kan du selv rette i dit CMS: alternativ tekst, overskrifter, linktekster, farver, undertekster og mange formularetiketter. Problemer i temaet, som manglende fokusmarkering, tastaturfælder og specialbyggede rullemenuer, kræver en udvikler. En audit giver mest mening, når det grundlæggende er rettet, eller før et redesign går live.

Hvor passer en widget som vores ind? Et panel til besøgende som SiteAccessible lader folk øge kontrasten, forstørre teksten eller slå en læselinje til. Det hjælper nogle besøgende, men det krydser ikke noget af på denne liste: en knap uden navn forbliver uden navn, og en tastaturfælde forbliver en fælde. Ret hjemmesiden først, og betragt en widget som et ekstra lag.

Hvordan dokumenterer jeg, hvad jeg har gjort?

Før en enkel log over, hvad du har testet, hvornår, hvad du har rettet, og hvad der stadig ikke virker, og offentliggør derefter et ærligt resumé i en tilgængelighedserklæring. Gælder European Accessibility Act for dig, skal du også offentliggøre oplysninger om, hvordan din tjeneste opfylder tilgængelighedskravene, som regel i dine handelsbetingelser eller et tilsvarende dokument.

Den anden pligt kommer fra direktivets bilag V; formen fastlægges af den nationale lov. Vores guide til at skrive en tilgængelighedserklæring indeholder en skabelon, du kan tilpasse. Hold derefter rutinen i gang:

1. Gå tjeklisten igennem på dine tre vigtigste sider, og tag et skærmbillede af hver fejl.
2. Ret indholdspunkterne selv i denne uge.
3. Giv en udvikler en beskrivelse af punkterne i temaet og checkout, de værste først.
4. Test hver rettelse igen med tastaturet og ikke kun med et værktøj.
5. Offentliggør eller opdatér din erklæring med dato.
6. Gentag, når du tilføjer en app, skifter tema eller lancerer en ny landingsside.