Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
Lovkrav og jura 10 min. læsning Opdateret 9. oktober 2026

Webtilgængelighed i praksis: kontrast, tastatur og skærmlæsere i WordPress

Webtilgængelighed WordPress i praksis: kontrast 4,5:1, tastatur, skærmlæser og formularer. Med de 8 hyppigste fejl – og hvor i WordPress du retter dem.

Webtilgængelighed i praksis: kontrast, tastatur og skærmlæsere i WordPress

Kort svar: Webtilgængelighed i WordPress står på fire ben: kontrast (minimum 4,5:1 for brødtekst), tastatur (alt skal kunne nås og betjenes uden mus, med synligt fokus), skærmlæser (semantisk struktur: én H1, logiske overskrifter, alt-tekster og labels på formularfelter) og forståelighed (klare fejlbeskeder og læsbart sprog). Temaet og dine plugins afgør halvdelen, så vælg tilgængelighedstestede byggeklodser, og test selv med tastatur og en gratis skærmlæser. Overlay-widgets, der lover „tilgængelighed med ét script“, løser ikke opgaven.

Fagligt gennemgået: 2. oktober 2026

Webtilgængelighed i WordPress er et håndværk: det, du konkret gør for at gøre sitet opfatteligt, anvendeligt og forståeligt – med de værktøjer og vaner, der faktisk virker. Pligten, altså hvem loven gælder for, står i guiden til tilgængelighedsloven (EAA).

Målestokken er WCAG (Web Content Accessibility Guidelines), som er den internationale standard for webtilgængelighed. Niveau AA er det, både lovgivning og de fleste krav i praksis peger på.

De fire principper i WCAG

WCAG er bygget op om fire principper. De giver et godt tjekskema, når du gennemgår et WordPress-site:

PrincipBetyderTypiske tjek i WordPress
OpfatteligIndholdet kan opfattes – også uden syn eller hørelseAlt-tekster, kontrast, undertekster på video
AnvendeligAlt kan betjenes – også uden musTastaturnavigation, synligt fokus, store nok klikmål
ForståeligIndhold og betjening er til at forståSidesprog, klare labels, konkrete fejlbeskeder
RobustFungerer med hjælpemidler som skærmlæsereSemantisk HTML, rigtige knapper og links, gyldig markup

De otte hyppigste tilgængelighedsfejl i WordPress – og hvor du retter dem

De fleste WordPress-sites fejler på de samme få punkter. Brug tabellen som arbejdsliste: fejlen, stedet i WordPress, hvor den rettes, og den hurtigste test.

FejlHer retter du denSådan tester du
For lav kontrast på tekst og knapperTemaets globale farverKontrastchecker på tekstfarve mod baggrund
Billeder uden alt-tekstMediebiblioteket og billedblokkenAutomatisk scanning af siden
Formularfelter uden labelFormularpluginets feltindstillingerKlik på feltets navn – markøren skal hoppe ned i feltet
Fokusrammen er fjernetTemaets CSS (outline)Tryk Tab, og se, om du kan følge med
Overskrifter valgt efter størrelseOverskriftsniveauet i editorenDokumentoversigten i editoren
Menuen kan ikke åbnes med tastaturTemaets eller page builderens menuelementTab og Enter i mobilbredde
Links og ikonknapper uden sigende tekstLinkteksten – eller et tilgængeligt navn på ikonknappenSkærmlæserens liste over links
Video uden undertekster og karruseller, der kører selvVideotjenestens undertekster og sliderens indstillingerAfspil uden lyd, og led efter en pauseknap

De første fem kan en redaktør rette uden at røre kode. De sidste tre ligger i tema, page builder eller plugin – og er grunden til, at valget af byggeklodser fylder så meget.

Kontrast og tekst

WCAG’s minimum på niveau AA er 4,5:1 for almindelig tekst og 3:1 for stor tekst samt for grafiske elementer og UI-komponenter som feltkanter og ikoner. Mål det med en kontrastchecker i stedet for at vurdere med øjet, og ret farverne i temaets globale indstillinger, så hele sitet følger med.

Blok-editoren advarer selv, når du vælger en tekst- og baggrundsfarve med for lav kontrast. Tag advarslen alvorligt – den fanger mange fejl, før de bliver publiceret.

De klassiske syndere er lysegrå tekst på hvid, tynd tekst oven på billeder og „diskrete“ linkfarver, der ikke kan skelnes fra brødtekst. Links i brødtekst bør derfor også være understreget eller på anden måde tydelige uden farve alene.

Sørg for, at tekst kan forstørres til 200 %, og at indholdet kan vises i en smal kolonne (320 CSS-pixel bred) uden vandret scroll. Med moderne temaer er det mest et spørgsmål om relative enheder og et responsivt layout.

Kontrast i tal: fem grå nuancer på hvid baggrund

Forskellen på bestået og dumpet kan være én farvekode. Her er fem grå tekstfarver målt mod hvid baggrund:

TekstfarveKontrast mod hvidBrødtekst (kræver 4,5:1)Stor tekst (kræver 3:1)
#9999992,85:1DumperDumper
#7777774,48:1Dumper – lige akkuratBestår
#7676764,54:1BestårBestår
#5959597,0:1BestårBestår
#33333312,63:1BestårBestår

#767676 er den lyseste grå, der består som brødtekst på hvid. Er baggrunden lysegrå eller farvet, falder kontrasten – mål derfor altid den kombination, du faktisk bruger. Stor tekst betyder mindst 24 pixel, eller cirka 19 pixel i fed.

Tastaturet: den hårdeste test

Læg musen væk, og gå sitet igennem med Tab, Shift+Tab, Enter, mellemrum og piletaster:

  • Kan menuen – også mobilmenuen – åbnes og lukkes?
  • Kan du se, hvor fokus er? Fjern aldrig fokusrammen (outline) uden at erstatte den med en tydelig fokusmarkering.
  • Bliver fokus skjult bag en fast header eller et cookiebanner? Det er et selvstændigt krav i WCAG 2.2.
  • Kan du nå alle knapper, også dem, der kun er ikoner?
  • Kan hele købsrejsen gennemføres – produktvalg, kurv, checkout og betaling?

Mobilmenuer, sliders, modals og accordions fra page buildere er de typiske knaster. I Breakdance, Bricks Builder og lignende værktøjer skal interaktive elementer bygges med rigtige knapper og links, ikke klikbare div’er.

Tjek også, at temaet har et „spring til indhold“-link som det første fokuserbare element. Det sparer tastaturbrugere for at tabbe gennem hele menuen på hver side.

Skærmlæser og semantik

Semantisk struktur for tilgængelighed i WordPress: én H1, logiske overskriftsniveauer, alt-tekster, landmark-regioner og labels

Skærmlæseren læser strukturen, ikke designet:

  • Én H1 pr. side og overskrifter i logisk rækkefølge (H2 → H3 – aldrig spring for udseendets skyld).
  • Beskrivende alt-tekster på billeder, der bærer information, og tom alt-tekst på ren pynt.
  • Rigtige lister som lister og knapper som button.
  • Landmark-regioner (header, nav, main, footer), så brugeren kan hoppe direkte til indholdet.
  • Korrekt sidesprog: Vælg dansk under Indstillinger → Generelt, så skærmlæseren udtaler teksten rigtigt.

Links skal give mening løsrevet. „Læs vores fragtguide“ er bedre end „klik her“, fordi skærmlæserbrugere ofte navigerer via en liste over links.

Den disciplin har en bonus: Det er præcis samme struktur, som søgemaskiner og AI-crawlere har lettest ved at forstå. Tilgængelighed og SEO er to gevinster for ét arbejde.

Formularer og fejlbeskeder

Hvert felt skal have en synlig label. Placeholder-tekst alene forsvinder, når man begynder at skrive. Påkrævede felter skal være markeret, og fejl skal forklares konkret ved feltet („telefonnummeret skal være 8 cifre“ – ikke „ugyldigt input“ i toppen af siden).

I checkout gælder det dobbelt: En kunde, der ikke kan finde fejlen, forlader købet. Autocomplete-attributter på navne- og adressefelter hjælper både tilgængelighed og konvertering, og CAPTCHA-løsninger skal have et tilgængeligt alternativ.

Hold samtidig GDPR-disciplinen: Færre felter er både mere tilgængeligt og mere lovligt.

Bevægelse, video og klikmål

Tre områder bliver ofte glemt:

  • Bevægelse: Automatiske karruseller og animationer skal kunne sættes på pause. Respektér brugerens systemindstilling for reduceret bevægelse (prefers-reduced-motion) i temaets CSS.
  • Video og lyd: Video med tale skal have undertekster, og lyd må ikke starte automatisk.
  • Klikmål: WCAG 2.2 kræver som udgangspunkt, at klikmål er mindst 24 × 24 CSS-pixel eller har tilstrækkelig afstand til nabo-elementer. Små ikonknapper og tætte links i footeren er de typiske problemer.

Vælg tema og plugins med tilgængelighed for øje

Halvdelen af tilgængeligheden afgøres, før du skriver første linje indhold. På wordpress.org kan temaer bære tagget „accessibility-ready“, som betyder, at temaet er gennemgået efter WordPress’ egne tilgængelighedskrav. Det er ikke en garanti for hele sitet, men et godt udgangspunkt.

Stil samme krav til plugins, der leverer synlige elementer – formularer, sliders, menuer og cookiebannere. Spørg udvikleren, test med tastatur før du køber, og vælg hellere et enkelt element, der virker, end et avanceret, der kræver mus.

Hvem er omfattet af loven?

Tilgængelighedskravene til en række produkter og tjenester til forbrugere – herunder e-handel – gælder i Danmark fra 28. juni 2025. Sikkerhedsstyrelsen er den primære myndighed på området. Mikrovirksomheder med under 10 ansatte og en årlig omsætning eller balance under 2 mio. euro er undtaget fra kravene til tjenester.

Om din virksomhed er omfattet, og hvilke krav der gælder præcist, gennemgår guiden til tilgængelighedsloven. Er du i tvivl, så tjek Sikkerhedsstyrelsens vejledninger. Uanset loven er tilgængelighed god forretning: flere kan handle hos dig.

Værktøjer og testrutine

Automatiske scannere fanger kontrast, manglende alt-tekster og strukturfejl, men kun en del af problemerne. Kombinér dem med manuel test:

  1. Kør en automatisk scanning (fx Lighthouse i Chrome eller WAVE) på skabelonsiderne: forside, produktside, kurv, checkout og artikel.
  2. Tastaturtest: Gennemfør købsrejsen uden mus – 15 minutter er nok til at finde de blokerende fejl.
  3. Skærmlæsertest: Brug en gratis skærmlæser (NVDA på Windows, VoiceOver på Mac og iPhone) på de samme sider.
  4. Zoom- og mobiltest: Forstør til 200 %, og tjek, at intet overlapper eller forsvinder.
  5. Ret og dokumentér: Notér fejl og rettelser, så du kan vise, at du arbejder systematisk.

Undgå overlay-widgets som „løsning“. De retter ikke den underliggende kode og kritiseres bredt af både brugere og fagfolk. Læg i stedet tilgængelighed ind i arbejdsgangen: ved nye skabeloner, i tjeklisten over lovkrav og som krav til tema- og pluginvalg.

Indarbejd det i hverdagen – ikke som projekt

Tilgængelighed fejler oftest som engangsprojekt: en stor gennemgang, et fint dokument – og seks måneder senere har nye sider og billeder genindført fejlene. Gør i stedet kravene til redaktionelle vaner:

  • Alt-tekst skrives, når billedet uploades.
  • Overskrifter vælges efter struktur, ikke efter størrelse.
  • Linktekster siger, hvor de fører hen.
  • Nye farvekombinationer tjekkes for kontrast, før de kommer i designet.

Sæt så en fast kontrol i kalenderen, fx en gang i kvartalet eller i forbindelse med større ændringer: kør en automatisk scanning, og brug selv sitets vigtigste flow – køb, kontakt, tilmelding – alene med tastatur. Tilgængelighed vedligeholdt som vane koster minutter om ugen; genoprettet som projekt koster uger. Fundamentet er et stabilt og hurtigt site, fx på WordPress hosting hos Hostious.

Ret fejlene på en kopi først. Ændringer i tema, farver og plugins bør prøves, før kunderne ser dem. Med WordPress hosting hos Hostious får du staging fra planen WP StartUp til 89 kr./md. ekskl. moms, så du kan rette og teste med tastatur og skærmlæser på en kopi af sitet. Skal siden bygges fra bunden, så se vores WordPress hjemmeside til 5.499 kr. ekskl. moms – og tag tabellen her med som krav fra første dag.

Læs også

Ofte stillede spørgsmål om webtilgængelighed

Hvad er det vigtigste første skridt?

Tastaturtesten på købsrejsen: Kan et køb gennemføres uden mus, med synligt fokus hele vejen? Den afslører de blokerende problemer på 15 minutter.

Er en tilgængeligheds-widget (overlay) nok?

Nej – overlays retter ikke den underliggende kode og løser ikke kravene. Brug tiden på kontrast, semantik, tastatur og formularer i selve sitet.

Hvordan skriver jeg gode alt-tekster?

Beskriv billedets funktion i sammenhængen, fx „Blå herresneaker set fra siden“ på en produktside, og brug tom alt-tekst på ren dekoration. Skriv til et menneske, der ikke kan se billedet.

Gælder tilgængelighedsloven for min hjemmeside?

Kravene gælder fra 28. juni 2025 for en række tjenester til forbrugere, herunder e-handel. Mikrovirksomheder med under 10 ansatte og en omsætning eller balance under 2 mio. euro er undtaget for tjenester. Tjek din situation i guiden til tilgængelighedsloven og hos Sikkerhedsstyrelsen.

Hvilken WCAG-version skal jeg følge?

Arbejd efter WCAG 2.2 på niveau AA. Den indeholder alle krav fra 2.1 plus enkelte nye, fx at fokus ikke må skjules, og at klikmål skal være store nok. Opfylder du 2.2 AA, dækker du i praksis også 2.1 AA.

Påvirker webtilgængelighed placeringen i Google?

Google har ikke en særskilt karakter for tilgængelighed i rangeringen. Men meget af arbejdet er det samme: klare overskrifter, alt-tekster, sigende linktekster og en side, der virker på mobilen, hjælper både skærmlæsere og søgemaskiner med at forstå indholdet.

Kan en page builder levere et tilgængeligt WordPress-site?

Ja, men det kommer ikke af sig selv. Resultatet afhænger af, om menuer, faner, sliders og popups er bygget med rigtige knapper og links, og om du selv vælger overskriftsniveauer og kontraster med omhu. Test hvert interaktivt element med tastaturet, før du bruger det på hele sitet.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 2. september 2026Opdateret 9. oktober 2026Fagligt gennemgået 2. oktober 2026