Sjekkliste for universell utforming av nettsteder og nettbutikker

Se for deg en kunde som bruker skjermleser. Hun finner joggeskoene hun vil ha, velger størrelse og trykker på det hun tror er handlekurvknappen. Skjermleseren sier «knapp». Ingenting mer. Det er tre slike på siden, og ingen av dem har navn, så hun går, og du får aldri vite hvorfor.

De fleste tilgjengelighetsproblemer på nettsteder i små bedrifter ser slik ut: usynlige for eieren, en blindvei for kunden. Denne sjekklisten er for deg som driver et nettsted på Shopify, WooCommerce, Wix eller Squarespace uten egen utvikler.

Må nettstedet til en liten bedrift være universelt utformet?

I Norge, ja: forskrift om universell utforming av IKT-løsninger (åpnes i en ny fane) krever at også private virksomheters nettløsninger rettet mot allmennheten oppfyller WCAG 2.0 nivå A og AA (unntatt 1.2.3–1.2.5). Selger du til forbrukere i EU, gjelder trolig også EUs tilgjengelighetsdirektiv (åpnes i en ny fane), som har omfattet netthandelstjenester siden 28. juni 2025. Hovedunntaket der gjelder mikroforetak som yter tjenester: virksomheter med færre enn 10 ansatte og en årlig omsetning eller balansesum på høyst 2 millioner euro.

Netthandel betyr her salg på avstand, via et nettsted eller en app, «på forbrukerens individuelle anmodning med sikte på å inngå en forbrukeravtale» (artikkel 3 nr. 30). En nettbutikk eller en bookingmotor passer inn. Unntaket gjelder bare tjenester: selger du produkter som omfattes, for eksempel lesebrett, gjelder produktreglene fortsatt (artikkel 4 nr. 5). Å ligge utenfor EU hjelper heller ikke, for en norsk eller britisk nettbutikk som selger til kunder i Frankrike, omfattes for de kundene (artikkel 3 nr. 4). Guiden vår om EUs tilgjengelighetsdirektiv går gjennom nasjonale lover og bøter.

Storbritannias Equality Act 2010 (åpnes i en ny fane) krever rimelig tilrettelegging for personer med funksjonsnedsettelser, men fastsetter ingen teknisk standard for nettsteder. I USA sier justisdepartementets veiledning fra mars 2022 (åpnes i en ny fane) at virksomheter som er åpne for allmennheten, må gjøre det de tilbyr på nett tilgjengelig, og at standarder som WCAG «gir nyttig veiledning». Uansett hva loven sier: en kunde som ikke kommer gjennom kassen, handler ikke.

Hva er de vanligste tilgjengelighetsproblemene på nettsteder?

Seks feil dominerer. I WebAIM Million 2026 (åpnes i en ny fane), en automatisk skanning av forsidene til de én million største nettstedene i februar 2026, hadde 95,9 % av sidene påviste WCAG-feil, i snitt 56,1 feil per side. Tekst med lav kontrast var det vanligste problemet og ble funnet på 83,9 % av forsidene.

WCAG, retningslinjene for tilgjengelig webinnhold, er standarden bak disse kontrollene; de fleste lover viser til nivå AA, og guiden vår om WCAG 2.2 forklarer den nyeste versjonen. Flere av kontrollene nedenfor er ting ingen skanner kan vurdere.

Kan alle lese teksten din og forstå bildene dine?

Begynn her, for disse rettelsene er billige og stort sett noe du gjør selv i redigeringsverktøyet. Tekst trenger nok kontrast, bilder som formidler informasjon, trenger alternativ tekst, og ingenting skal formidles med farge alene. Omtrent 1 av 12 menn og 1 av 200 kvinner har nedsatt fargesyn, ifølge Colour Blind Awareness (åpnes i en ny fane).

• Kontrast. Vanlig tekst trenger et kontrastforhold på minst 4,5:1 (åpnes i en ny fane) mot bakgrunnen, stor tekst minst 3:1. Test fargene, også tekst oppå bannerbilder, i et gratis verktøy. Guiden vår om fargekontrast viser løsninger som bevarer merkevaren din.
• Alternativ tekst på produkter. Beskriv det kunden trenger å vite: «Marineblå ullgenser med ribbestrikket rullekrage, sett forfra» er bedre enn «produktbilde 1». Begynn med de ti bestselgerne.
• Dekorative bilder. En virvel i bakgrunnen bør ha tom alternativ tekst, slik at skjermlesere hopper over den. Noen plattformer fyller et tomt alt-felt med filnavnet, så sjekk hva din gjør.
• Bare farge. «Utsolgt» vist bare som en gråtonet fargeprøve, eller et obligatorisk felt markert bare med rødt, når ikke alle. Se på siden med gråtonefilteret på mobilen, og legg til et ord eller ikon der betydningen forsvinner.
• Zoom. Ved 200 % zoom i nettleseren skal teksten bli større uten å overlappe eller bli kuttet, og menyen skal fortsatt virke.
• Sidespråk. Alle gratis testverktøy varsler om manglende språkangivelse. Det er en innstilling i temaet eller en endring på én linje i malen.

Kan folk bruke nettstedet ditt med tastatur?

Mange surfer uten mus: skjermleserbrukere, folk med skjelving eller nedsatt bevegelighet i hendene, og alle med en styreplate som nettopp har sluttet å virke. Legg bort musen og trykk Tab. Du skal nå alle lenker, knapper og skjemafelt i en fornuftig rekkefølge, alltid se hvor du er, og aldri bli sittende fast.

• Synlig fokus. En ramme skal vise hvilket element som er aktivt, og en fast toppmeny eller chatteboble må ikke dekke den (2.4.11 Fokus ikke skjult i WCAG 2.2). Mange temaer fjerner rammen av estetiske grunner; en utvikler kan sette den tilbake.
• Ingen feller. Åpne menyen, størrelsesvelgeren, popup-vinduer og bildegalleriet med tastaturet, velg noe og prøv så å komme deg ut. Escape skal lukke popup-vinduer.
• Navn på ikoner. Hver ikonlenke og -knapp trenger et navn en skjermleser kan lese opp, for eksempel «Handlekurv, 2 varer». Bytt ut «Klikk her» med ord som sier hvor lenken går.
• Hopp-lenke og overskrifter. Det første trykket på Tab bør helst vise en «Hopp til innholdet»-lenke. I WebAIMs skjermleserundersøkelse fra 2024 (åpnes i en ny fane) sa 71,6 % av respondentene at de først navigerer på en lang side via overskriftene, så bruk ekte overskriftsnivåer, ikke fet skrift.
• Trykkflater. WCAG 2.2 krever mål på minst 24 × 24 CSS-piksler, eller nok avstand rundt dem (suksesskriterium 2.5.8 (åpnes i en ny fane)).

Kommer alle seg gjennom skjemaene, handlekurven og kassen?

I kassen koster tilgjengelighetsproblemer deg penger direkte, så test den fra start til slutt, også hva som skjer når noe går galt. Hvert felt trenger en synlig etikett, feilmeldinger må forklare problemet med ord, og innlogging skal ikke avhenge av hukommelsestester eller gåter. Sidene til betalingsleverandøren teller også.

• Etiketter, ikke plassholdere. Plassholdertekst forsvinner så snart noen skriver, og er ofte for blek til å leses. Hvert felt trenger en etikett som blir stående synlig.
• Feilmeldinger. Send inn skjemaet tomt. Hver feil skal være skrevet ut («Skriv inn et postnummer, for eksempel 0150»), stå ved siden av feltet sitt og bli lest opp, ikke bare gjøre en kant rød.
• Ikke spør to ganger. Tilby «Fakturaadressen er den samme» i stedet for å la folk skrive inn leveringsadressen på nytt. WCAG 2.2 gjorde dette til et krav på nivå A, 3.3.7 Overflødig inntasting.
• Innlogging. La folk lime inn passord og engangskoder og bruke passordbehandlere. Å blokkere innliming bryter WCAG 2.2s kriterium for tilgjengelig autentisering (åpnes i en ny fane) med mindre du tilbyr en annen vei inn.
• CAPTCHA. Skjermleserbrukere rangerte CAPTCHA som det mest problematiske på nettet i WebAIMs undersøkelse fra 2024. Trenger du beskyttelse mot roboter, bør du unngå visuelle gåter og alltid tilby et ikke-visuelt alternativ.
• Tidsfrister. Hvis en handlekurv eller en reservasjon utløper, bør du varsle folk og la dem forlenge fristen.

Hører deler av kassen til plattformen eller betalingsleverandøren, bør du likevel teste dem, melde fra om problemer og føre dem opp som kjente feil.

Hva med cookie-bannere, popup-vinduer og chatwidgeter?

For kundene dine er skript fra tredjeparter en del av nettstedet ditt. Et cookie-banner som ikke kan lukkes med tastatur, blokkerer hver side, og en popup for nyhetsbrev som tar fokus midt i kassen, kan stoppe et salg. Test alle skript du har lagt til, og spør leverandørene om tilgjengelighet før du installerer et nytt.

• Cookie-banner. Kan du nå «godta» og «avvis» med Tab, lese dem ved 200 % zoom og fortsette der du var etterpå?
• Popup-vinduer. Fokus skal flytte seg inn i popupen, bli der til den lukkes, og deretter gå tilbake. Escape skal lukke den.
• Chatwidgeter. Knappen trenger et navn, vinduet skal kunne åpnes og lukkes med tastaturet, og på mobil skal det ikke ligge oppå «Betal nå».
• Karuseller. Alt som beveger seg automatisk i mer enn fem sekunder, trenger en måte å pause, stoppe eller skjule det på (WCAG 2.2 (åpnes i en ny fane), suksesskriterium 2.2.2).
• Innebygd innhold. Anmeldelseswidgeter, kart og bookingverktøy ligger også på siden din. Ta opp feil med leverandøren.

Fungerer videoene, PDF-ene og menyene dine for alle?

Video trenger teksting, lyd trenger en transkripsjon, og viktig informasjon skal ikke bare finnes i en PDF eller et bilde. En restaurant der menyen er en skannet PDF, eller en butikk der størrelsesguiden er et bilde av en tabell, stenger ute skjermleserbrukere og alle som må zoome inn på mobilen.

• Teksting og transkripsjoner. Rett automatisk teksting før du publiserer. Podkaster trenger en tekstversjon.
• Bilder av tekst. Legg menyer, prislister, størrelsesguider og åpningstider på en vanlig nettside. Må du bruke PDF, bør du eksportere den med overskrifter og tagger fra tekstbehandleren i stedet for å skanne en utskrift.
• Eldre filer. EAA krever ikke at du retter kontorfiler eller forhåndsinnspilt lyd og video publisert før 28. juni 2025, eller arkiver du ikke lenger oppdaterer (artikkel 2 nr. 4). Nye filer omfattes.

Hva kan jeg rette selv, og når trenger jeg en utvikler eller en revisjon?

De fleste innholdsproblemer kan du rette selv i publiseringsløsningen: alternativ tekst, overskrifter, lenketekst, farger, teksting og mange etiketter på skjemafelt. Problemer i temaet, som manglende fokusstiler, tastaturfeller og egenutviklede nedtrekkslister, krever en utvikler. En revisjon gir mest mening når det grunnleggende er rettet, eller før et redesign lanseres.

Hvor passer en widget som vår inn? Et panel for besøkende, som SiteAccessible, lar folk øke kontrasten, forstørre teksten eller slå på en leselinjal. Det hjelper noen besøkende, men det gjør ikke at du kan krysse av noe på denne sjekklisten: en knapp uten navn er fortsatt uten navn, og en tastaturfelle er fortsatt en felle. Rett nettstedet først, og se på en widget som et tillegg.

Hvordan dokumenterer jeg det jeg har gjort?

Før en enkel logg over hva du har testet, når, hva du har rettet og hva som fortsatt er feil, og publiser et ærlig sammendrag i en tilgjengelighetserklæring. Gjelder EUs tilgjengelighetsdirektiv for deg, må du også publisere informasjon om hvordan tjenesten oppfyller tilgjengelighetskravene, som regel i vilkårene eller et tilsvarende dokument.

Den andre plikten kommer fra vedlegg V i direktivet; nasjonal lov bestemmer formatet. Guiden vår om å skrive en tilgjengelighetserklæring har en mal du kan tilpasse. Hold deretter rutinen i gang:

1. Kjør sjekklisten på de tre viktigste sidene, og ta skjermbilde av hver feil.
2. Rett innholdspunktene selv denne uken.
3. Gi en utvikler en oversikt over punktene i temaet og kassen, de verste først.
4. Test hver rettelse på nytt med tastatur i tillegg til testverktøy.
5. Publiser eller oppdater erklæringen din, med dato.
6. Gjenta hver gang du legger til en app, bytter tema eller lanserer en ny landingsside.