Hvordan gjøre nettsiden din tilgjengelig: en startguide for WCAG 2.2

For å gjøre en nettside tilgjengelig, bygg den slik at folk kan bruke den med tastatur, skjermleser, zoom eller en bryterenhet i tillegg til mus: bruk ekte HTML-elementer for knapper, lenker, overskrifter og skjemaetiketter, gi bilder meningsfulle alt-tekster, hold tekstkontrasten høy og gjør fokus synlig. Standarden å sikte mot er WCAG 2.2 nivå AA. Automatiske sjekkere fanger en del av problemet; en ti minutters test med tastatur og skjermleser fanger mye av resten.

Hva «tilgjengelig» betyr i praksis

Tilgjengelighet handler om mennesker: noen som er blind og bruker skjermleser, noen med rystelser som navigerer med tastatur, noen med nedsatt syn som zoomer til 200 %, noen som leser i sterkt sollys, noen med et midlertidig brukket håndledd. God tilgjengelighet gjør som regel en side bedre for alle: tydeligere struktur, lesbar tekst og skjemaer som forklarer feilene sine.

Referansestandarden er W3Cs Web Content Accessibility Guidelines (WCAG). Fra september 2026 er gjeldende versjon WCAG 2.2 (publisert oktober 2023, oppdatert desember 2024); WCAG 3 er et tidlig utkast. WCAG er organisert rundt fire prinsipper (innhold må være oppfattbart, betjenbart, forståelig og robust) og har tre konformitetsnivåer:

Lover på flere steder viser til WCAG, for eksempel den europeiske tilgjengelighetsloven (European Accessibility Act), som har gjeldt for mange digitale tjenester rettet mot forbrukere i EU siden juni 2025. Hvilke regler som gjelder for deg, avhenger av hvor du opererer og hva du selger; rådfør deg med en rådgiver hvis du er usikker. Denne guiden dekker det praktiske arbeidet.

Alternativer: slik kommer du dit

For de fleste små nettsider er de to første nok: be AI-en bygge tilgjengelig fra starten, og revider før lansering.

De tiltakene som betyr mest

Bruk de riktige HTML-elementene

Mye tilgjengelighet kommer gratis med riktig HTML. Et <button> kan fokuseres, fungerer med Enter og mellomrom, og leses opp som en knapp. Et <div> med en klikkbehandler er ingen av delene. AI-generert kode bruker noen ganger stilte div-er til alt; be om semantiske elementer:

• <button> for handlinger, <a href> for navigasjon
• Én <h1> per side, deretter <h2> og <h3> i rekkefølge; brukere av skjermleser hopper mellom overskrifter
• Landemerker: <header>, <nav>, <main>, <footer>
• <label> koblet til hvert skjemafelt
• Sidens språk i <html lang="nb">

Bruk ARIA-attributter bare når ingen naturlig element passer, for eksempel for et egendefinert fanesett eller en combobox. Feil ARIA er verre enn ingen.

Tastaturtilgang og synlig fokus

Alt du kan gjøre med en mus, må fungere med tastaturet alene (WCAG 2.1.1). Trykk Tab gjennom siden: hver lenke, knapp og felt skal kunne nås i logisk rekkefølge, og du skal alltid se hvor fokus er (2.4.7 Focus Visible). WCAG 2.2 la til at det fokuserte elementet ikke må være helt skjult bak klebrige topptekster eller informasjonskapselbannere (2.4.11, nivå AA).

Vanlige feil: menyer som bare åpnes ved musepeker, modaler som ikke fanger fokus eller ikke kan lukkes med Escape, og outline: none i CSS uten noe som erstatter det.

Tekstalternativer

Hvert meningsfullt bilde trenger alt-tekst som sier hva det viser i sammenhengen («Kokk som anretter smaksmenyen», ikke «bilde1.jpg»). Dekorative bilder får tom alt="", slik at skjermlesere hopper over dem. Knapper med bare ikon trenger et tilgjengelig navn («Lukk», «Søk»). Videoer trenger undertekster; lyd trenger en transkripsjon.

Farge og kontrast

WCAG 2.2 AA krever et kontrastforhold på minst 4,5:1 for vanlig tekst og 3:1 for stor tekst (1.4.3), og 3:1 for grensesnittdeler som inntastingsrammer og meningsbærende ikoner (1.4.11). Lysgrå plassholdertekst og svake knapper er de vanlige feilene. Bruk heller aldri bare farge for å formidle mening: en rød ramme rundt et ugyldig felt trenger også en feilmelding.

Zoom og tilpasning

Tekst må fortsatt være brukbar ved zoom til 200 % (1.4.4), og innhold må fungere ved 320 CSS-piksler bredde uten sideveis rulling (1.4.10). En god responsiv layout håndterer det meste av dette.

Mål, skjemaer og feil

• Målstørrelse: WCAG 2.2 AA krever pekermål på minst 24 x 24 CSS-piksler, eller nok avstand rundt mindre (2.5.8). Større er vennligere på telefoner.
• Skjemaer: synlige etiketter (ikke bare plassholdertekst), tydelige instruksjoner, og feilmeldinger som sier hva som er galt og hvordan det rettes, ved siden av feltet.
• Innlogging: ikke la folk løse en gåte eller tegne av en kode uten et alternativ; tillat passordbehandlere og liming (3.3.8 Accessible Authentication).

Ledetekster som fungerer

Bygg denne nettsiden for å oppfylle WCAG 2.2 nivå AA: semantiske HTML-landemerker, én h1 per side med overskrifter i rekkefølge, ekte knapp- og lenkeelementer, etiketter på hvert skjemafelt, synlige fokusstiler, tekstkontrast på minst 4,5:1, alt-tekst på meningsfulle bilder og alt="" på dekorative, og html lang satt.

Revider /signup- og /checkout-sidene for tilgjengelighet. Sjekk bruk kun med tastatur, fokusrekkefølge, synlig fokus, etiketter, feilmeldinger, kontrast og skjermleser-navn for ikonknapper. List opp hvert problem med WCAG-kriteriet, og rett dem deretter uten å endre det visuelle designet mer enn nødvendig.

Den mobile menyen kan ikke brukes med tastatur. Gjør den til en knapp med aria-expanded, flytt fokus inn i menyen når den åpnes, lukk den med Escape og send fokus tilbake til knappen.

Steg for steg

1. Kjør en automatisk sjekk. Lighthouses tilgjengelighetsdel i Chrome DevTools, eller axe-utvidelsen for nettleseren, på hver hovedside. Rett alt den rapporterer.
2. Ta musen bort. Tab gjennom hver side og fullfør alle sentrale oppgaver: registrering, søk, betaling. Noter alt du ikke kan nå, ikke kan se fokus på, eller ikke kan komme ut av.
3. Zoom til 200 % og gjør vinduet smalt til telefonbredde. Ingenting skal være kuttet av eller kreve sideveis rulling.
4. Prøv en skjermleser i ti minutter: VoiceOver på Mac og iPhone, TalkBack på Android, eller NVDA på Windows (gratis). Lytt til overskrifter, lenker og skjemafelt. «Knapp» uten navn, eller «lenke, klikk her», betyr arbeid som må gjøres.
5. Sjekk kontrast for tekst, knapper og felt med et kontrastsjekkverktøy.
6. Rett, og test på nytt de samme oppgavene.
7. Publiser en tilgjengelighetserklæring som sier hvilken standard du sikter mot og hvordan problemer kan rapporteres, og svar på rapportene.

Vanlige feil

• Å stole på en overlay-widget i stedet for å fikse koden.
• Å fjerne fokusrammer fordi de ser rotete ut, uten erstatning.
• Plassholdertekst som eneste etikett. Den forsvinner når noen begynner å skrive, og er ofte lav kontrast.
• «Klikk her» og «Les mer»-lenker. Utenfor sammenheng hører skjermleserbrukere en liste med identiske lenker.
• Alt-tekst fylt med nøkkelord. Alt-tekst er for mennesker; beskriv bildet.
• Å teste én gang. Hver ny funksjon kan ødelegge tastaturtilgang. Legg til en tastaturgjennomgang i din testing før lansering.

Sjekkliste for tilgjengelighet

• Automatisk sjekk (Lighthouse eller axe) uten feil på hovedsidene
• Hver oppgave kan fullføres med tastatur alene
• Fokus alltid synlig og aldri skjult bak klebrige elementer
• Semantiske overskrifter, landemerker, knapper og lenker; lang satt
• Meningsfull alt-tekst; dekorative bilder alt=""; undertekster på video
• Tekstkontrast ≥ 4,5:1 (stor tekst ≥ 3:1); grensesnittdeler ≥ 3:1
• Fungerer ved 200 % zoom og 320 px bredde
• Hvert skjemafelt har synlig etikett og tydelige feilmeldinger
• Tilgjengelighetserklæring med en måte å rapportere problemer på

For begrepene bak dette, les hva er webtilgjengelighet. Tilgjengelig design og god design overlapper mye; hvordan designe en flott app med AI dekker den visuelle siden.

Tilgjengelighet på Mythex

Mythex bygger etter standarden du ber om, så ta med «WCAG 2.2 AA» i første ledetekst og i oppfølgingene. Du kan bruke Previews telefonramme for å sjekke små skjermer (Preview and Code), men tester med tastatur, zoom og skjermleser fungerer best på den publiserte URL-en eller en forhåndsvisning åpnet i egen fane. Be agenten revidere en side, rette det den finner, og test rettingene selv: en automatisk gjennomgang er en start, ikke en godkjenning.

Spørsmål