Universell utforming av IKT-løsninger

Universell utforming av IKT-løsninger – WCAG-krav og tilgjengelighetserklæring

Krav til universell utforming av IKT-løsninger følger av Diskrimineringsloven og tilhørende forskrift. Metoden er basert på de internasjonale retningslinjene WCAG – strukturert rundt fire kjerneprinsippene kjent som POUR.

⚖ Rettslig grunnlag: Diskriminerings- og tilgjengelighetsloven § 17 og Forskrift om universell utforming av IKT-løsninger pålegger virksomheter å sikre at IKT-løsninger rettet mot allmennheten er universelt utformet. Brudd kan medføre pålegg fra Likestillings- og diskrimineringsombudet.

De fire WCAG-prinsippene (POUR)

WCAG 2.1 (Web Content Accessibility Guidelines) er den internasjonale standarden for tilgjengelig webinnhold. Standarden er bygget rundt fire grunnprinsipper:

P – Mulig å oppfatte

Informasjon og brukergrensesnitt må presenteres på måter brukerne kan oppfatte – uansett sans eller hjelpemiddel.

O – Mulig å betjene

Brukergrensesnittkomponenter og navigasjon må fungere uavhengig av inndataenhet.

U – Forståelig

Informasjon og betjening av grensesnittet må være forståelig for alle brukere.

R – Robust

Innholdet må tolkes pålitelig av et bredt spekter av brukeragenter, inkludert skjermlesere.

1. Mulig å oppfatte (Perceivable)

Informasjonen og brukergrensesnittkomponenter må presenteres for brukerne på måter de kan oppfatte.

Formelt krav Konkret utfordring God løsning
Tekstalternativer for ikke-tekstlig innhold (1.1.1) Bilder, grafikk og knapper uten tekst Alt-tekster: Alle meningsbærende bilder og grafiske elementer må ha en beskrivende alt-tekst. Dekorative elementer skal ha tom alt-tekst (alt=»») slik at skjermlesere ignorerer dem.
Alternativer for tidsbaserte medier (1.2.1, 1.2.2, 1.2.5) Video og lyd uten teksting eller synstolking Teksting og transkripsjon: Tilby synkronisert teksting for forhåndsinnspilt video og transkripsjon for lydinnhold. Videoer med viktig visuell informasjon uten tale krever synstolking (AA).
Tilpasningsdyktig innhold (1.3.1–1.3.3) Manglende struktur og meningsbærende presentasjon Korrekt semantikk: Bruk korrekt HTML-struktur for overskrifter, lister, tabeller og skjemaer. Leserekkefølgen i koden må stemme med visuell rekkefølge. Ikke bruk farge alene for å formidle informasjon.
Kontrast og størrelse (1.4.3, 1.4.4, 1.4.11) Lav kontrast og uleselig tekst Kontrastforhold: All normal tekst må ha minimum 4,5:1 kontrastforhold mot bakgrunnen. Løsninger må tillate brukere å endre tekststørrelse opp til 200 % uten tap av innhold.

2. Mulig å betjene (Operable)

Brukergrensesnittkomponenter og navigasjon må være betjenbare.

Formelt krav Konkret utfordring God løsning
Tastaturbetjening (2.1.1) Elementer som kun kan betjenes med mus Full tastaturtilgjengelighet: All funksjonalitet må være tilgjengelig kun via tastatur (Tab, Enter, Space).
Tastaturfokus (2.4.7) Manglende visuell fokusindikator Tydelig fokusindikator: Det må alltid være en synlig indikator (ramme eller fargeendring) rundt elementet med tastaturfokus.
Tilstrekkelig tid (2.2.1) Tidsbegrensede funksjoner Justerbare tidsfrister: Unngå automatiske tidsbegrensninger. Gi brukeren mulighet til å forlenge, slå av eller justere fristen.
Navigasjon og orientering (2.4.1, 2.4.4, 2.4.6) Forvirrende navigasjon og uklare lenker Hopp til innhold: Inkluder en «Hopp til hovedinnhold»-lenke. Lenketekster må være beskrivende og forklare målet.

3. Forståelig (Understandable)

Informasjonen og betjeningen av brukergrensesnittet må være forståelig.

Formelt krav Konkret utfordring God løsning
Leselighet (3.1.1, 3.1.2) Manglende språkinformasjon i koden Angi språk: Definer hovedspråket i koden (lang=»nb»). For tekstpassasjer på annet språk, angi dette spesifikt.
Forutsigbarhet (3.2.1, 3.2.2) Uventede endringer ved fokus eller input Ingen plutselige endringer: Sørg for at det ikke skjer vesentlige endringer automatisk når et element får fokus. Bruk konsistent navigasjon på tvers av sider.
Hjelp til input (3.3.1, 3.3.3) Vanskelige skjemaer og manglende feilmeldinger Tydelige feilmeldinger: Identifiser inntastingsfeil tydelig i tekstformat. Foreslå korrektur der feilen er kjent.

4. Robust (Robust)

Innholdet må være robust nok til at det kan tolkes pålitelig av et bredt spekter av brukeragenter, inkludert kompenserende teknologi som skjermlesere.

Formelt krav Konkret utfordring God løsning
Kompatibilitet (4.1.1, 4.1.2) Feil i koden og ukjent innhold for hjelpemidler Korrekt og gyldig kode: Bruk ren, gyldig HTML og CSS. Bruk WAI-ARIA der standard HTML ikke strekker til, slik at hjelpemidler tolker komponenter riktig.

God praksis i UU-arbeidet

De beste løsningene handler ikke bare om teknisk implementering, men om prosessen:

  • Integrer UU tidlig: Inkluder universell utforming i designfasen – design-by-default.
  • Kompetanse: Sørg for at redaktører og innholdsprodusenter har tilstrekkelig kunnskap om kravene.
  • Testing: Kombiner automatiske verktøy (f.eks. WAVE, Axe) med manuell testing ved bruk av skjermleser.
  • Tilgjengelighetserklæring: Dokumenter samsvar og beskriv hvordan brukere kan melde avvik.
  • Kontinuerlig vedlikehold: Nye publiserte sider og oppdateringer av funksjonalitet må fortløpende testes mot kravene.

Tilgjengelighetserklæringen

Alle offentlige virksomheter er pålagt å utstede en tilgjengelighetserklæring. Tilsvarende gjelder for en rekke private virksomheter som leverer tjenester nødvendige for offentlig sektor eller tjener et allment formål.

Erklæringen tjener tre formål:

  • Lovpålagt plikt: Å sikre at personer med nedsatt funksjonsevne får lik tilgang til digitale tjenester.
  • Informasjonsverktøy: En redegjørelse for etterlevelse og handlingsplan for mangler som brukere kan lese.
  • Styringssystemet: For å sikre kontinuerlig og systematisk arbeid må erklæringen forankres som en del av virksomhetens internkontrollsystem.

Trenger du hjelp med universell utforming eller tilgjengelighetserklæring?

Vi hjelper virksomheter med å kartlegge status, lage handlingsplan og forankre UU-arbeidet i styringssystemet.

Ta kontakt her
Svein Roar Holt – Grunnlegger av Internkontroll AS og IS-modellen™

Svein Roar Holt

Grunnlegger av Internkontroll AS og arkitekt bak IS-modellen™ og AvvikStandard™.

Om Svein Roar → LinkedIn →

Internkontroll AS · © 2026 Svein Roar Holt · Sist revidert: 09.10.2024

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

Skroll til toppen