Universell utforming av nettsider – fra WCAG-krav til fungerende brukerreiser

Universell utforming handler om hvorvidt mennesker faktisk kan finne informasjon, forstå den og fullføre det de kom for å gjøre. En forside kan se ryddig ut og få høy score i et testverktøy, men likevel stenge ute brukere når menyen åpnes, et skjema feiler eller teksten forstørres.

Godt arbeid begynner derfor ikke med én skanning. Det begynner med tre spørsmål:

1. Hvilke krav gjelder for virksomheten og løsningen?
2. Hvilke sider, komponenter og brukeroppgaver inngår?
3. Hvordan skal resultatene testes, dokumenteres, rettes og holdes ved like?

Denne guiden ble kontrollert mot Uu-tilsynets informasjon 22. august 2026. Regelverk og standarder kan endres, så bruk alltid tilsynets oppdaterte sider når dere avgjør egne plikter.

Hvilke norske krav gjelder?

Norske regler skiller mellom privat og offentlig sektor. Det er misvisende å skrive at «norsk lov krever WCAG 2.1 AA» uten å angi sektor og hvilke kriterier som faktisk er tatt inn.

Uu-tilsynet oppgir per august 2026:

Den filtrerbare oversikten over WCAG-krav i norsk regelverk viser hvilke kriterier som gjelder for nettside, app, dokument og sektor. Bruk den som kravliste fremfor en tilfeldig WCAG-sjekkliste fra nettet.

Offentlige nettsteder og apper skal i tillegg publisere en tilgjengelighetserklæring gjennom den sentrale løsningen. Uu-tilsynet beskriver arbeidet med tilgjengelighetserklæringen , inkludert krav om jevnlig oppdatering.

Er virksomheten og nettsiden omfattet?

Uu-tilsynet oppgir at både private og offentlige virksomheter, lag og organisasjoner kan være omfattet. Vurderingen gjelder ikke bare organisasjonsform eller om kunden er privatperson.

Tilsynets veiledning peker på tre sentrale forhold: Løsningen er rettet mot brukere i Norge, er en viktig kanal for informasjon eller tjenester, og er knyttet til virksomhetens alminnelige funksjon. Også B2B-nettsteder og løsninger bak innlogging kan være omfattet. Se den oppdaterte forklaringen av virkeområde, hovedløsning og tredjepartsløsninger .

Ikke konkluder ut fra at nettstedet er lite, at virksomheten bare selger til bedrifter, eller at en ekstern plattform leverer teknologien. Virksomheten som bruker løsningen mot sine brukere, beholder ansvaret etter regelverket; avtalen avgjør hvordan leverandøren skal bidra og hvem som betaler for retting.

Det finnes unntak og mulighet for dispensasjon, men terskler og dokumentasjon må vurderes konkret. Ikke bruk en generell artikkel som juridisk konklusjon for egen løsning.

WCAG 2.2 er nyttig, men ikke norsk minstekrav nå

WCAG 2.2 er W3Cs nyeste ferdige anbefaling og tilfører blant annet kriterier om skjult fokus, draoperasjoner, målområder, konsekvent hjelp, gjentatt inntasting og tilgjengelig autentisering. Den kan være et fornuftig mål for nyutvikling og anskaffelser.

Uu-tilsynet sier samtidig at WCAG 2.2 ikke er del av norsk regelverk nå . Skill derfor mellom:

• kriterier som gjelder etter norsk regelverk
• strengere krav i kontrakt eller sektor
• frivillige mål for WCAG 2.2
• øvrige brukervennlighets- og kvalitetsmål

Denne sporbarheten gjør det mulig å vite hvorfor et krav er med og hvem som kan godkjenne et avvik.

EAA er ikke innført i norsk rett ennå

EUs tilgjengelighetsdirektiv, EAA, gjelder i EU fra 28. juni 2025 for utvalgte produkter og tjenester, blant annet e-handel rettet mot forbrukere. Uu-tilsynet opplyser at direktivet per august 2026 fortsatt ikke er tatt inn i EØS-avtalen eller norsk rett.

Norske virksomheter som tilbyr varer eller tjenester i EU-land, kan likevel måtte følge kravene i landet de opererer i. Les Uu-tilsynets oppdaterte EAA-status og få juridisk vurdering for aktuelle markeder. Ikke bruk «EAA-kompatibel» som en løs markedsføringsetikett uten å definere tjeneste, land, kravgrunnlag og dokumentasjon.

Avgrens testen før dere starter

Et nettsted kan ha tusenvis av URL-er, men et mindre antall maler, komponenter og arbeidsflyter. Lag en oversikt over:

• forside, seksjonssider, artikler og landingssider
• søk, filtrering, meny og navigasjon
• skjema, innlogging, bestilling og betaling
• dialoger, faner, trekkspill og statusmeldinger
• tabeller, grafer, kart, video og lyd
• PDF-er og andre dokumenter
• sider fra tredjepart som inngår i brukerreisen
• mobilvisning, språkvarianter og tilstander med feil

Ta med både vanlig innhold og vanskelige eksempler: lang overskrift, tomt søkeresultat, manglende bilde, ugyldig skjemaverdi, utsolgt produkt og utløpt sesjon. Mange barrierer finnes bare i en bestemt tilstand.

Test oppgaver, ikke bare enkeltsider

Velg de viktigste oppgavene brukerne skal kunne fullføre. For en bedriftsside kan det være:

1. Forstå hva virksomheten tilbyr.
2. Finne pris, adresse eller åpningstid.
3. Navigere til riktig tjeneste.
4. Ringe, sende e-post eller fylle ut skjema.
5. Forstå feilmelding og rette innsendingen.

For en nettbutikk kommer søk, produktvalg, handlekurv, betaling, kvittering og retur i tillegg. Følg hele reisen. En tilgjengelig produktside hjelper lite hvis betalingsdialogen ikke kan brukes med tastatur.

Bruk automatiske verktøy som feilfinnere

Automatiske tester kan finne bestemte maskinlesbare avvik raskt, for eksempel noen kontrastfeil, manglende navn og ugyldige relasjoner. De kan også kjøres ved hver kodeendring for å hindre tilbakefall.

De kan ikke avgjøre om:

• alternativ tekst formidler riktig mening
• en overskrift beskriver innholdet godt
• fokusrekkefølgen er logisk i oppgaven
• en feilmelding er forståelig og nyttig
• teksting er korrekt og synkronisert
• et grensesnitt er praktisk å bruke med hjelpemidler

Dropp derfor prosentpåstander om hvor mye et verktøy «dekker». Dekning avhenger av kriterium, innhold, teknologi, regler og hva dere teller som feil.

Uu-tilsynet publiserer egne testindikatorer, sjekklister og verktøy . Bruk tilsynets indikatorer når målet er å teste på samme måte som ved norsk tilsyn.

Manuell test som bør gjøres hver gang

Tastatur

Legg bort musen. Bruk Tab, Shift+Tab, Enter, Mellomrom og piltaster etter komponentens forventede mønster. Kontroller at:

• alle handlinger kan nås og brukes
• fokus er synlig og ikke skjult bak fast innhold
• rekkefølgen følger oppgaven
• menyer og dialoger kan åpnes og lukkes
• fokus ikke blir fanget eller forsvinner
• handlingen ikke utløses uventet ved fokus

Forstørring og dynamisk tilpasning

Test større tekst og høy forstørring i smal visning. Innhold og funksjoner skal ikke forsvinne, overlappe eller kreve unødvendig rulling i begge retninger. Kontroller særlig menyer, tabeller, dialoger, cookiepaneler og feilmeldinger.

Ikke likestill «responsivt design» med godkjent test. En side kan bytte kolonner pent på mobil og likevel klippe tekst når brukeren endrer skriftstørrelse eller tekstavstand.

Skjermleser og tilgjengelighetstre

Test representative brukerreiser med relevante nettleser- og skjermleserkombinasjoner. Kontroller:

• sidetittel, språk og overskriftsstruktur
• landemerker og mulighet til å hoppe til hovedinnhold
• navn, rolle, verdi og tilstand for kontroller
• meningsfulle lenketekster
• etiketter, instruksjoner og feilkobling i skjema
• statusmeldinger etter dynamiske endringer
• tabelloverskrifter og leseorden

Å høre at en skjermleser «leser alt» er ikke nok. Informasjonen må komme i forståelig rekkefølge, og kontrollene må kunne betjenes.

Berøring og peker

Test mobil i stående og liggende retning der relevant. Handlinger som krever draing eller presis pekerbevegelse, bør ha et tilgjengelig alternativ. Kontroller at målområder ikke ligger så tett at feiltrykk blir sannsynlige.

Farge, kontrast og ikke-visuelle signaler

Mål kontrast for tekst, kontroller og synlige tilstander. Kontroller samtidig at informasjon ikke gis med bare farge, plassering, form eller lyd. En rød kant rundt et felt må for eksempel ledsages av en tydelig tekstlig feilforklaring.

Innhold, bilder, lyd og video

Alternativ tekst skal formidle bildets funksjon i konteksten, ikke bare beskrive alle synlige detaljer. Dekorative bilder bør ignoreres av hjelpemidler. Diagrammer trenger et reelt tekstlig alternativ for data eller konklusjon.

Test teksting, lydalternativ og eventuell synstolking mot kriteriene som gjelder for sektor, medietype og publiseringsdato. Automatisk generert teksting må kontrolleres av et menneske.

Skjemaer krever test av feiltilstanden

Et skjema er ikke ferdig testet når gyldige data kan sendes. Prøv:

• å sende tomt
• ugyldig e-post, dato og format
• svært lang verdi
• feil i ett og flere felt
• utløpt sesjon eller serversvar med feil
• tastaturnavigasjon til og fra feilmeldingen
• ny innsending etter retting

Brukeren må forstå hva som gikk galt, hvor feilen er og hvordan den kan rettes. Ikke slett andre gyldige verdier når ett felt feiler. Status etter innsending må kunne oppfattes uten at brukeren tilfeldigvis finner meldingen.

Et tilgjengelig navn er ikke det samme som synlig tekst

Skjermlesere og talestyring bruker informasjonen som eksponeres programmatisk. En knapp med synlig tekst «Søk» bør ikke få et utilgjengelig navn som bare sier «Send» eller et ikonnavn. Synlig etikett og tilgjengelig navn må henge sammen.

Start med riktig, semantisk HTML. Legg ikke på roller og egenskaper for å reparere et element som kunne vært en vanlig lenke, knapp, overskrift eller etikett. Komplekse egendefinerte komponenter krever langt mer tastatur- og hjelpemiddeltesting enn standardelementer.

Brukertest og WCAG-test svarer på ulike spørsmål

En kriteriebasert test spør om løsningen oppfyller definerte krav. En brukertest undersøker om mennesker klarer reelle oppgaver og hvor de møter friksjon. Dere trenger ofte begge.

Involver personer med ulike funksjonsnedsettelser i representative oppgaver, og betal dem for kompetansen og tiden. Én deltaker representerer ikke alle brukere, og en vellykket brukertest beviser ikke full WCAG-samsvar. Funnene kan likevel avdekke alvorlige barrierer som en teknisk sjekkliste ikke prioriterer riktig.

Dokumenter hvert avvik slik at det kan rettes

En nyttig avvikslogg bør inneholde:

Skjermbilder kan hjelpe, men de erstatter ikke trinn og tekst. Et problem med fokusrekkefølge eller skjermleserstatus er ofte usynlig på et bilde.

Prioriter blokkering før kosmetikk

Prioriter først barrierer som hindrer kritiske oppgaver, særlig når mange sider deler samme komponent:

1. Brukeren kan ikke navigere, forstå eller fullføre oppgaven.
2. Brukeren kan fullføre bare med betydelig ekstraarbeid eller en omvei.
3. Feilen rammer en gjenbrukt komponent på mange sider.
4. Feilen finnes i sjeldnere innhold eller har mindre konsekvens.

En retting i meny, skjema eller designsystem kan fjerne mange avvik samtidig. Men retest alle tilstander; en endring som løser tastaturbruk, kan introdusere et nytt problem for forstørring eller berøring.

Still målbare krav til leverandøren

«Nettsiden skal være universelt utformet» gir for lite styring. En avtale bør angi:

• kravgrunnlag, versjon, nivå og konkrete kriterier
• hvilke sider, dokumenter, integrasjoner og tredjepartsflater som inngår
• støttede nettlesere og hjelpemiddelkombinasjoner
• testmetode, utvalg og akseptansekriterier
• format og eierskap til dokumentasjon
• hvem som retter feil, responstid og kostnadsansvar
• håndtering av nye komponenter og innhold etter lansering
• retest, reklamasjon og konsekvens ved manglende samsvar

Tredjepartsverktøy må inn i omfanget når de er del av brukerreisen. En leverandørlogo eller en påstand om at et tema er «WCAG-klart», er ikke bevis på at deres innhold, konfigurasjon og samlede løsning oppfyller kravene.

Tilgjengelighet må inn i publiseringsrutinen

Samsvar kan forsvinne når en redaktør publiserer et dårlig dokument, en utvikler endrer en dialog eller markedsføring legger inn et nytt skjema. Fordel derfor ansvaret:

Kjør automatiske kontroller i utviklingsløpet, manuelle komponenttester ved endring og periodiske gjennomganger av representative brukerreiser. Offentlige virksomheter må også holde tilgjengelighetserklæringen oppdatert.

Universell utforming og SEO er ikke det samme

Tydelige overskrifter, gode lenketekster, forståelig innhold og semantisk HTML kan hjelpe både brukere og søkemotorer. Men Core Web Vitals, indeksering eller en SEO-score sier ikke om løsningen oppfyller tilgjengelighetskrav. Omvendt garanterer ikke WCAG-samsvar høy synlighet i søk.

Arbeid med universell utforming fordi brukerne skal kunne bruke tjenesten og fordi kravene skal etterleves. Behandle eventuell SEO-effekt som en mulig bieffekt, ikke som dokumentasjon.

Hva leverer Vymo?

Vymos standardtilbud er én enkel bedriftsside med hosting i tolv måneder. Det er ikke en sertifisert eller dokumentert WCAG-samsvarstjeneste, og en bestilling gjennom standardskjemaet inkluderer ikke full kriterietest, brukertest eller tilgjengelighetserklæring.

Bedriften må kontrollere at innsendt tekst, bilder, dokumenter og kontaktopplysninger er egnede. Har virksomheten et bestemt lov-, kontrakts- eller sektorbehov, må kravgrunnlag, testutvalg, dokumentasjon, retting og ansvar avtales før leveransen.

Beskriv tilgjengelighetskravene før bestilling , eller se nøyaktig hva standardsiden inkluderer .