Hopp til hovedinnhold

Webtilgjengelighet: hvorfor det er viktig og hvordan du forbedrer nettstedet

Forfatter: Milos ZekovicLesetid: 10 minKategori: Nettsidekvalitet

Hva WCAG og universell utforming betyr for nettstedet ditt, hvilke krav norske virksomheter bør kjenne til, og hvordan du prioriterer praktiske forbedringer uten skremsler eller falske løfter om automatisk samsvar.

Webtilgjengelighet: hvorfor det er viktig og hvordan du forbedrer nettstedet

Når mennesker ikke kan bruke nettstedet, forsvinner de stille

De fleste virksomheter får ikke en detaljert klage hver gang noen møter en digital barriere. En besøkende som ikke får åpnet menyen med tastatur, forstått en feilmelding eller lest tekst med svak kontrast, går ofte bare videre.

Dermed kan tilgjengelighetsproblemer vise seg som:

  • avbrutte skjemaer
  • færre bookinger eller kjøp
  • flere spørsmål til kundeservice
  • brukere som ikke finner viktig informasjon
  • ansatte som må tilby manuelle omveier
  • lavere tillit til virksomheten

Webtilgjengelighet handler derfor ikke bare om et ideal eller en sjekkliste. Det handler om hvorvidt mennesker faktisk kan oppfatte innholdet, navigere, forstå grensesnittet og fullføre oppgaven de kom for å gjøre.

Min praktiske vurdering er enkel: Tilgjengelighet er brukervennlighet tatt på alvor. Mange av forbedringene som hjelper personer med funksjonsnedsettelser, gjør samtidig nettstedet bedre for eldre brukere, mobilbrukere, mennesker med midlertidige skader og alle som befinner seg i en krevende situasjon.

WCAG er det praktiske referansepunktet

Web Content Accessibility Guidelines (WCAG) utvikles av W3C gjennom Web Accessibility Initiative. Retningslinjene beskriver hvordan webinnhold kan gjøres mer tilgjengelig for mennesker med blant annet syns-, hørsels-, motoriske og kognitive funksjonsnedsettelser.

WCAG bygger på fire prinsipper. Innhold og funksjonalitet skal være:

  • mulig å oppfatte
  • mulig å betjene
  • forståelig
  • robust

I praksis omfatter dette blant annet:

  • tekstalternativer for informative bilder
  • tastaturtilgang til menyer, knapper og skjemaer
  • tilstrekkelig fargekontrast
  • synlige fokusmarkeringer
  • korrekt bruk av overskrifter og semantisk HTML
  • etiketter og feilmeldinger som forklarer hva brukeren skal gjøre
  • innhold som fortsatt fungerer ved zoom og større tekst
  • støtte for hjelpemidler som skjermlesere

WCAG har tre nivåer: A, AA og AAA. A dekker de mest grunnleggende barrierene, mens AA legger til flere krav som er viktige for praktisk bruk. AAA er det høyeste nivået, men er ikke et realistisk eller nødvendig mål for alle typer innhold.

For de fleste profesjonelle nettsteder er nivå AA et fornuftig kvalitetsmål, samtidig som det konkrete juridiske kravet må vurderes ut fra land, sektor og type tjeneste.

WCAG 2.2 er nyeste standard, men regelverket kan vise til eldre versjoner

WCAG 2.2 er den nyeste ferdige W3C-anbefalingen. Den bygger videre på WCAG 2.1 og legger blant annet større vekt på synlig tastaturfokus, størrelsen på klikkbare mål og tilgjengelig autentisering.

W3C anbefaler å bruke den nyeste versjonen. Innhold som oppfyller WCAG 2.2, oppfyller også WCAG 2.1 og 2.0, med de presiseringene som følger av standarden.

Det betyr likevel ikke at alle lover automatisk krever hele WCAG 2.2. Regelverk og tekniske standarder kan fortsatt vise til utvalgte krav fra WCAG 2.0 eller 2.1.

Det er nyttig å skille mellom:

  1. Det loven krever i din situasjon
  2. Det som er et fornuftig kvalitetsmål for nye løsninger
  3. Det som bør prioriteres fordi det blokkerer reelle brukere

En tilgjengelighetsgjennomgang bør avklare alle tre, ikke bare produsere en generell poengsum.

Hva gjelder for nettsteder i Norge?

I Norge omfattes nettløsninger av regelverket for universell utforming av IKT. Ifølge Tilsynet for universell utforming av ikt gjelder regelverket både offentlige og private virksomheter, i tillegg til lag og organisasjoner som oppfyller vilkårene i regelverket.

De konkrete minstekravene varierer mellom sektorene:

  • Private virksomheter skal følge et utvalg på 35 WCAG-krav.
  • Offentlig sektor skal følge 48 krav, i tillegg til enkelte andre plikter som tilgjengelighetserklæring.

Det er derfor upresist å si at alle norske nettsteder må dokumentere fullt samsvar med hele WCAG 2.2 AA. Det er like upresist å anta at tilgjengelighet bare gjelder offentlig sektor.

Hvilke plikter som gjelder, avhenger blant annet av virksomheten, løsningen og hvem nettstedet retter seg mot. Ved spørsmål om juridisk samsvar bør virksomheten kontrollere informasjonen hos tilsynet eller få en vurdering som tar utgangspunkt i den konkrete tjenesten. En teknisk revisjon kan finne barrierer, men erstatter ikke juridisk rådgivning.

Hva med EUs tilgjengelighetsdirektiver?

EUs webdirektiv gjelder nettsteder og mobilapper i offentlig sektor og er gjennomført i norsk regelverk med utvidede krav for offentlig sektor.

I EU gjelder dessuten European Accessibility Act for bestemte produkter og forbrukertjenester fra 28. juni 2025. Dette omfatter blant annet netthandel, forbrukerbanktjenester, e-bøker, elektronisk kommunikasjon og deler av persontransport.

Det betyr ikke at hvert enkelt nettsted automatisk omfattes på samme måte. Omfang, unntak og nasjonal gjennomføring må vurderes konkret. For norske virksomheter som selger tjenester til kunder i EU, kan det likevel være relevant å undersøke hvilke krav som gjelder i markedene de opererer i.

Poenget er ikke å skremme noen til å kjøpe en revisjon. Poenget er at tilgjengelighetsstandarder allerede inngår i regelverk, innkjøp og kvalitetskrav. Det er som regel billigere å bygge gode mønstre fra starten enn å reparere et helt designsystem senere.

Forretningsverdien er praktisk

Tilgjengelighetsarbeid gir ikke automatisk en bestemt prosentvis økning i konvertering. Verdien ligger i at unødvendige barrierer fjernes fra oppgaver nettstedet allerede skal støtte.

Skjemaer og bestilling

Et skjema uten tydelige etiketter, forståelige feilmeldinger eller logisk fokusrekkefølge er et konverteringsproblem før det blir en juridisk diskusjon.

Et tilgjengelig skjema bør blant annet:

  • ha en synlig og programmatisk koblet etikett for hvert felt
  • forklare forventet format
  • identifisere feil tydelig
  • flytte eller lede fokus på en forutsigbar måte
  • gi bekreftelse når innsendingen er fullført
  • kunne brukes uten mus

Dette hjelper skjermleserbrukere, men også alle som fyller ut skjemaet på telefon eller gjør en enkel feil.

Mobilbruk

Mange tilgjengelighetstiltak forbedrer mobilopplevelsen direkte:

  • større trykkflater
  • bedre kontrast i sollys
  • tydeligere fokus og aktive tilstander
  • innhold som tåler zoom
  • færre presisjonskrav
  • mer forståelige feilmeldinger

En bruker trenger ikke å ha en permanent funksjonsnedsettelse for å ha nytte av dette. Personen kan holde telefonen med én hånd, sitte på toget eller ha midlertidig nedsatt syn eller bevegelighet.

Struktur og søk

Semantiske overskrifter, beskrivende lenker, tekstalternativer og ryddig innhold hjelper søkemotorer med å forstå siden. Det er ingen garanti for bedre rangering, men det er et bedre teknisk og redaksjonelt fundament.

Tilgjengelighet og SEO overlapper på enkelte områder, men de er ikke det samme. En side kan være godt optimalisert for søk og fortsatt være vanskelig å bruke med tastatur eller skjermleser.

Vedlikehold og kvalitet

Tilgjengelige komponenter er ofte enklere å:

  • teste systematisk
  • dokumentere
  • gjenbruke
  • overlevere
  • kontrollere etter senere endringer

Når knapper, modaler, skjemaer og navigasjon har tydelige standarder, reduseres behovet for å løse de samme feilene på nytt i hver kampanje.

Vanlige problemer jeg ser i praksis

Tilgjengelighetsfeil er ikke alltid kompliserte. Mange kommer fra design- og utviklingsvalg som så uskyldige ut hver for seg:

  • lys grå tekst som fungerte i designfilen, men ikke på en vanlig skjerm
  • ikonknapper uten tilgjengelig navn
  • egendefinerte rullegardinmenyer som ikke kan brukes med tastatur
  • karuseller som flytter seg automatisk uten god kontroll
  • overskrifter valgt etter utseende i stedet for struktur
  • lenker som bare heter «Les mer»
  • feilmeldinger som kun markeres med rød farge
  • bilder med filnavnet som alternativ tekst
  • videoer uten teksting
  • PDF-er som eneste kilde til viktig informasjon
  • cookie- og chatløsninger som fanger fokus
  • animasjoner uten støtte for redusert bevegelse

Et automatisert verktøy kan finne noen av disse feilene. Andre krever manuell testing og forståelse av hva brukeren prøver å gjøre.

Slik ville jeg prioritert et typisk bedriftsnettsted

Du trenger ikke rette alt samtidig. Start med brukerreisene der en barriere får størst konsekvens.

1. Test hovedoppgavene med tastatur

Gå gjennom:

  • navigasjon
  • hovedtjenester
  • kontaktskjema
  • booking eller kjøp
  • innlogging
  • eventuelle modaler og cookie-innstillinger

Bruk bare Tab, Shift+Tab, Enter, mellomrom og piltaster. Kontroller at du kan nå og betjene alt, at fokus er synlig, og at rekkefølgen gir mening.

2. Rett skjemaene først

Skjemaer er ofte den siste barrieren før en henvendelse eller bestilling. Kontroller etiketter, instruksjoner, feilmeldinger, fokusrekkefølge og bekreftelse etter innsending.

Ikke bruk placeholder-tekst som eneste etikett. Den forsvinner når brukeren begynner å skrive, og kan være vanskelig å tolke.

3. Kontroller kontrast med faktisk innhold

Test mer enn toppseksjonen:

  • vanlig brødtekst
  • små hjelpetekster
  • lenker
  • knapper
  • feilmeldinger
  • tekst over bilder
  • navigasjon og bunntekst
  • tilstander som hover, fokus og deaktivert

Kontrastproblemer oppstår ofte når designsystemets farger brukes i en kombinasjon ingen testet.

4. Gå gjennom struktur og semantikk

Hver side bør ha en forståelig dokumentstruktur:

  • en tydelig hovedoverskrift
  • logisk rekkefølge på underoverskrifter
  • ekte lister for listeinnhold
  • knapper for handlinger og lenker for navigasjon
  • landemerker som header, nav, main og footer
  • beskrivende sidetitler og lenketekster

Semantisk HTML gir både nettlesere og hjelpemidler mer informasjon uten at det visuelle uttrykket må endres.

5. Revider bilder, ikoner og grafikk

Informative bilder trenger et tekstalternativ som formidler funksjonen eller meningen. Dekorative bilder bør ikke skape unødvendig støy for skjermleseren.

Alternativ tekst skal ikke beskrive alt som er synlig. Den skal gi den informasjonen brukeren ellers ville gått glipp av.

6. Test zoom og tekstforstørrelse

Zoom siden til minst 200 prosent og kontroller at:

  • innholdet fortsatt kan leses
  • kontroller ikke overlapper
  • viktig tekst ikke blir skjult
  • horisontal rulling ikke oppstår unødvendig
  • skjemaer fortsatt kan fylles ut
  • faste bannere ikke dekker store deler av skjermen

7. Kontroller video, lyd og bevegelse

Når tale eller lyd formidler viktig informasjon, bør brukeren få teksting eller et relevant tekstalternativ.

Bevegelse bør kunne pauses eller reduseres der den kan skape problemer. Respekter brukerens innstilling for redusert bevegelse når animasjonen ikke er nødvendig for funksjonen.

8. Test med en skjermleser

En grunnleggende gjennomgang med VoiceOver, NVDA eller et tilsvarende verktøy kan avdekke problemer automatiserte tester ikke fanger:

  • meningsløs opplesningsrekkefølge
  • knapper uten navn
  • uklare feltetiketter
  • statusmeldinger som aldri leses opp
  • dynamisk innhold som ikke annonseres
  • unødvendig støy fra dekorative elementer

For mer omfattende løsninger er testing med faktiske brukere med funksjonsnedsettelser enda mer verdifullt.

Automatiske verktøy er nyttige, men utilstrekkelige

Verktøy som axe, Lighthouse og ulike nettleserutvidelser er gode til å finne bestemte tekniske feil raskt. De kan blant annet oppdage enkelte kontrastproblemer, manglende navn og ugyldig struktur.

De kan ikke alene avgjøre:

  • om alternativ tekst faktisk er nyttig
  • om overskriftsstrukturen gir mening
  • om fokusrekkefølgen er logisk
  • om feilmeldingen hjelper brukeren videre
  • om en arbeidsflyt er forståelig
  • om tastaturbruk føles forutsigbar
  • om innholdet er skrevet på et forståelig språk

En grønn automatisk score er derfor ikke det samme som samsvar eller god brukeropplevelse. Den er ett datapunkt i en bredere gjennomgang.

Avveininger det er verdt å være ærlig om

Full gjennomgang eller trinnvis forbedring

Et enkelt markedsføringsnettsted og en kompleks bookingplattform har ulik risiko. Hvis alt ikke kan rettes samtidig, prioriter funksjonene som leverer tjenester, håndterer kjøp eller skaper henvendelser.

Trinnvis arbeid bør likevel ha en plan. Ellers blir «vi tar det senere» ett av tegnene på at nettstedet trenger en oppgradering.

Visuell profil eller lesbarhet

Et merkeuttrykk kan fortsatt være særpreget uten tynn grå tekst, lav kontrast og konstant bevegelse. Tilgjengelighet fjerner ikke kreativitet, men tvinger frem tydeligere beslutninger om hva som faktisk er viktig.

Egen kode eller tredjepartsløsninger

Du kan bygge et solid nettsted og fortsatt få problemer gjennom:

  • chat
  • cookie-banner
  • bookingverktøy
  • betalingsløsning
  • kart
  • videospiller
  • innebygd skjema

Disse delene bør inkluderes i testen. Brukeren bryr seg ikke om hvilken leverandør som eier feilen.

Teknisk samsvar eller reell brukbarhet

En løsning kan bestå mange formelle tester og fortsatt være unødvendig komplisert. WCAG er et nødvendig referansepunkt, men god tilgjengelighet krever også tydelig innhold, forutsigbar navigasjon og reell brukertesting.

Hva god fremgang faktisk betyr

Meningsfull forbedring krever ikke at hele nettstedet blir perfekt på én gang.

God fremgang kan bety at:

  • kontakt- og bestillingsskjemaer fungerer med tastatur og skjermleser
  • hovednavigasjonen har synlig fokus og logisk rekkefølge
  • primære handlingsknapper er tydelige og lesbare
  • nøkkelsidene har en forståelig overskriftsstruktur
  • videoer med viktig tale har teksting
  • teamet vet hvordan det publiserer mer tilgjengelig innhold
  • nye komponenter testes før de tas i bruk flere steder

Det reduserer faktiske barrierer nå og gjør senere forbedringer billigere.

Tilgjengelighet bør ikke være et engangsprosjekt like før lansering. Den bør inn i design, utvikling, innholdsarbeid og kvalitetskontroll, slik at nye feil ikke bygges inn igjen.

Vil du vite hvor nettstedet ditt står i dag?

Kontakt meg for en fokusert tilgjengelighetsgjennomgang. Du får en prioritert oversikt over reelle barrierer, hvilke brukerreiser som bør rettes først, og hva som kan planlegges som neste steg.

Nyhetsbrev med ideer som betyr noe

Meld deg på nyhetsbrevet mitt. I nyhetsbrevet deler jeg nye innsikter, konkrete tips og av og til casestudier, alt som kan hjelpe bedriften din å vokse.

Ingen spam, én gang i uken eller bare når det faktisk er noe å si, og noe du vil lese.