Sådan gør du din hjemmeside tilgængelig: en WCAG 2.2-startguide

For at gøre en hjemmeside tilgængelig bygger du den, så folk kan bruge den med et tastatur, en skærmlæser, zoom eller en kontakt-enhed såvel som med en mus: brug rigtige HTML-elementer til knapper, links, overskrifter og formularlabels, giv billeder meningsfuld alt-tekst, hold tekstkontrasten høj og gør fokus synligt. Standarden at sigte efter er WCAG 2.2 niveau AA. Automatiske tjek fanger en del af problemet; en ti-minutters test med tastatur og skærmlæser fanger meget af resten.

Hvad „tilgængelig“ betyder i praksis

Tilgængelighed handler om mennesker: en person, der er blind og bruger en skærmlæser, en person med rysten, der navigerer med tastatur, en person med nedsat syn, der zoomer til 200 %, en person, der læser i stærkt sollys, en person med et midlertidigt brækket håndled. God tilgængelighed gør typisk en side bedre for alle — tydeligere struktur, læsbar tekst, formularer der forklarer deres fejl.

Referencestandarden er W3C's Web Content Accessibility Guidelines (WCAG). Pr. september 2026 er den aktuelle version WCAG 2.2 (udgivet oktober 2023, opdateret december 2024); WCAG 3 er et tidligt udkast. WCAG er organiseret omkring fire principper — indhold skal være opfattelige, betjenelige, forståelige og robuste — og har tre konformitetsniveauer:

Love flere steder henviser til WCAG — for eksempel den europæiske tilgængelighedslov, som har gældt for mange digitale tjenester rettet mod forbrugere i EU siden juni 2025. Hvilke regler der gælder for dig, afhænger af, hvor du opererer, og hvad du sælger; spørg en rådgiver, hvis du er i tvivl. Denne guide dækker det praktiske arbejde.

Muligheder: sådan kommer du dertil

Til de fleste små sider er de to første nok: bed AI'en bygge tilgængeligt fra starten, og revider derefter før lancering.

De rettelser, der betyder mest

Brug de rigtige HTML-elementer

De fleste tilgængelighedsfordele kommer gratis med korrekt HTML. Et <button> kan fokuseres, virker med Enter og mellemrum og bliver annonceret som en knap. Et <div> med en klik-handler er ingen af delene. AI-genereret kode bruger nogle gange stylede divs til alt; bed om semantiske elementer:

• <button> til handlinger, <a href> til navigation
• Én <h1> pr. side, derefter <h2>, <h3> i rækkefølge — skærmlæserbrugere hopper mellem overskrifter
• Landmarks: <header>, <nav>, <main>, <footer>
• <label> forbundet til hvert formularfelt
• Sidens sprog i <html lang="da">

Brug ARIA-attributter kun, når intet nativt element passer — for eksempel et tilpasset fanesæt eller en combobox. Forkert ARIA er værre end ingen ARIA.

Tastaturadgang og synligt fokus

Alt, du kan gøre med en mus, skal kunne gøres med tastaturet alene (WCAG 2.1.1). Tryk Tab gennem siden: hvert link, hver knap og hvert felt skal kunne nås i logisk rækkefølge, og du skal altid kunne se, hvor fokus er (2.4.7 Focus Visible). WCAG 2.2 tilføjede, at det fokuserede element ikke må være helt skjult bag sticky headers eller cookiebannere (2.4.11, niveau AA).

Almindelige fejl: menuer der kun åbner ved hover, modaler der ikke fanger fokus eller ikke kan lukkes med Escape, og outline: none i CSS uden noget, der erstatter det.

Tekstalternativer

Hvert meningsfuldt billede skal have alt-tekst, der siger, hvad det viser i konteksten („Kok der anretter smagsmenuen“, ikke „billede1.jpg“). Dekorative billeder får en tom alt="", så skærmlæsere springer dem over. Ikonknapper uden tekst skal have et tilgængeligt navn („Luk“, „Søg“). Videoer skal have undertekster; lyd skal have et transskript.

Farve og kontrast

WCAG 2.2 AA kræver et kontrastforhold på mindst 4,5:1 for normal tekst og 3:1 for stor tekst (1.4.3), og 3:1 for grænsefladedele som inputkanter og meningsbærende ikoner (1.4.11). Lysgrå pladsholdertekst og bleg knapper er de typiske fejl. Brug også aldrig kun farve til at bære betydning — en rød kant på et ugyldigt felt skal også have en fejlbesked.

Zoom og reflow

Teksten skal forblive brugbar ved zoom til 200 % (1.4.4), og indholdet skal fungere ved en bredde på 320 CSS-pixels uden vandret scroll (1.4.10). Et ordentligt responsivt layout klarer det meste af dette.

Størrelser, formularer og fejl

• Målstørrelse: WCAG 2.2 AA kræver pointer-mål på mindst 24 × 24 CSS-pixels eller tilstrækkelig afstand omkring mindre mål (2.5.8). Større er venligere på telefoner.
• Formularer: synlige labels (ikke kun pladsholdere), klare instruktioner og fejlbeskeder, der siger, hvad der er galt, og hvordan det rettes, ved siden af feltet.
• Login: tving ikke folk til at løse et puslespil eller genskrive en kode uden et alternativ; tillad adgangskodeadministratorer og indsæt (3.3.8 Accessible Authentication).

Prompts der virker

Byg denne side, så den opfylder WCAG 2.2 niveau AA: semantiske HTML-landmarks, én h1 pr. side med overskrifter i rækkefølge, rigtige knap- og linkelementer, labels på alle formularfelter, synlige fokusstile, tekstkontrast på mindst 4,5:1, alt-tekst på meningsfulde billeder og alt="" på dekorative, og html lang sat.

Revider siderne /signup og /checkout for tilgængelighed. Tjek brug med kun tastatur, fokusrækkefølge, synligt fokus, labels, fejlbeskeder, kontrast og skærmlæsernavne for ikonknapper. List hvert problem med WCAG-kriteriet, og ret dem derefter uden at ændre det visuelle design mere end nødvendigt.

Den mobile menu kan ikke bruges med tastatur. Gør den til en knap med aria-expanded, flyt fokus ind i menuen, når den åbnes, luk den med Escape og flyt fokus tilbage til knappen.

Trin for trin

1. Kør et automatisk tjek. Lighthouses sektion om tilgængelighed i Chrome DevTools, eller axe-browserudvidelsen, på hver hovedside. Ret alt, de rapporterer.
2. Tag musen væk. Tab gennem hver side og gennemfør alle nøgleopgaver — tilmelding, søgning, køb. Bemærk alt, du ikke kan nå, ikke kan se fokus på, eller ikke kan komme ud af.
3. Zoom til 200 % og gør vinduet smalt til telefonbredde. Intet må være afskåret eller kræve vandret scroll.
4. Prøv en skærmlæser i ti minutter: VoiceOver på Mac og iPhone, TalkBack på Android eller NVDA på Windows (gratis). Lyt til overskrifter, links og formularfelter. „Knap“ uden navn, eller „link, klik her“, betyder arbejde, der skal gøres.
5. Tjek kontrasten for tekst, knapper og felter med et kontrasttjek.
6. Ret, og test igen de samme opgaver.
7. Publicer en tilgængelighedserklæring, der siger, hvilken standard du sigter efter, og hvordan man rapporterer problemer — og svar på disse rapporter.

Almindelige fejl

• At stole på et overlay-widget i stedet for at rette koden.
• At fjerne fokusrammer, fordi de ser rodede ud, uden en erstatning.
• Pladsholdertekst som eneste label. Den forsvinder, når nogen begynder at skrive, og er ofte lav kontrast.
• „Klik her“- og „Læs mere“-links. Ude af kontekst hører skærmlæserbrugere en liste af identiske links.
• Alt-tekst proppet med søgeord. Alt-tekst er til mennesker; beskriv billedet.
• At teste én gang. Hver ny funktion kan bryde tastaturadgangen. Tilføj et tastaturpas til din test før lancering.

Tjekliste for tilgængelighed

• Automatisk tjek (Lighthouse eller axe) rent på hovedsiderne
• Hver opgave kan gennemføres med kun tastatur
• Fokus altid synligt og aldrig skjult bag sticky-elementer
• Semantiske overskrifter, landmarks, knapper og links; lang sat
• Meningsfuld alt-tekst; dekorative billeder alt=""; undertekster på video
• Tekstkontrast ≥ 4,5:1 (stor tekst ≥ 3:1); grænsefladedele ≥ 3:1
• Fungerer ved 200 % zoom og 320 px bredde
• Hvert formularfelt har en synlig label og tydelige fejlbeskeder
• Tilgængelighedserklæring med en måde at rapportere problemer på

Til begreberne bag dette, læs hvad er webtilgængelighed. Tilgængeligt design og godt design overlapper meget; sådan designer du en flot app med AI dækker den visuelle side.

Tilgængelighed på Mythex

Mythex bygger efter den standard, du beder om, så skriv „WCAG 2.2 AA“ i din første prompt og i opfølgninger. Du kan bruge forhåndsvisningens telefonstørrelse til at tjekke små skærme (Preview og Code), men tests med tastatur, zoom og skærmlæser virker bedst på den udgivne URL eller en forhåndsvisning åbnet i sin egen fane. Bed agenten revidere en side, rette det den finder, og test derefter rettelserne selv — et automatisk gennemløb er en start, ikke en godkendelse.

Spørgsmål