Universell utforming av IKT-løsninger

1. Hva er universell utforming av IKT?

Universell utforming betyr at produkter, omgivelser, programmer og tjenester utformes slik at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpasning eller spesiell utforming. Begrepet er hentet fra FN-konvensjonen om rettighetene til mennesker med nedsatt funksjonsevne (CRPD), som Norge ratifiserte i 2013.

Når begrepet brukes om IKT-løsninger, handler det konkret om at nettsider, mobilapplikasjoner og selvbetjeningsautomater skal være tilgjengelige for personer med nedsatt syn, hørsel, motorikk eller kognisjon – uten at de må ha spesiell programvare eller hjelp av andre. Det er ikke det samme som «tilrettelegging for funksjonshemmede»; universell utforming er en hovedløsning som fungerer for alle, slik at særløsninger ikke er nødvendige.

Anslagsvis én av tre i Norge har behov for tilpasninger for å bruke digitale tjenester. Det inkluderer ikke bare personer med varige funksjonsnedsettelser, men også eldre, personer med midlertidige skader, og brukere i krevende omgivelser (sterkt sollys, dårlig nettverk, uvant språk). UU er derfor ikke en marginsak – det er kvalitet for hovedmålgruppen.

2. Rettslig grunnlag: §§ 17, 18 og forskriften

Det rettslige grunnlaget for universell utforming av IKT i Norge består av tre lag som virker sammen:

Likestillings- og diskrimineringsloven § 17

Setter den generelle plikten til universell utforming for offentlige og private virksomheter rettet mot allmennheten. § 17 er den prinsipielle bestemmelsen som dekker både fysisk utforming og IKT, og som forbyr diskriminering på grunnlag av funksjonsnedsettelse.

Likestillings- og diskrimineringsloven § 18

Spesialbestemmelse om universell utforming av IKT. § 18 hjemler forskriften og fastsetter at IKT-løsninger som retter seg mot allmennheten, skal være universelt utformet. Bestemmelsen omfatter både offentlig og privat sektor.

Forskrift om universell utforming av IKT-løsninger

Operasjonaliserer kravene fra § 18. Forskriften viser til konkrete tekniske standarder (WCAG i ulike versjoner) og spesifiserer hvilke suksesskriterier som er minstekrav. Den definerer også virkeområde og unntak. Forskriften har vært i kraft siden 1. juli 2014 og er senere revidert flere ganger.

3. Hvem omfattes? Virkeområde og unntak

Et av de vanligste spørsmålene fra ledere er: «Gjelder dette oss?». Svaret følger av forskriften og kan oppsummeres slik:

Hvem reglene gjelder for

• Alle offentlige virksomheter – stat, kommune, fylkeskommune og offentlige foretak.
• Private virksomheter, lag og organisasjoner som tilbyr IKT-løsninger rettet mot allmennheten – det vil si nettsteder, applikasjoner eller automater som er ment å informere eller tilby tjenester til innbyggere eller kunder i Norge.

Hvilke IKT-løsninger som omfattes

• Nettsteder og nettløsninger (inkludert mobilversjoner).
• Mobilapplikasjoner som henter eller leverer informasjon over internett.
• Selvbetjeningsautomater: minibanker, billettautomater, innsjekkingsautomater, betalingsterminaler.

Hvilke krav som gjelder hvor

Det er to viktige presiseringer som ofte misforstås:

• Intranett og ekstranett i offentlig sektor er omfattet etter Webdirektivet (WAD). Det samme gjelder ikke automatisk for privat sektor.
• Tilgjengelighetserklæring er per mai 2026 obligatorisk kun for offentlige virksomheter. Private virksomheter har ingen lovpålagt erklæringsplikt – men selve UU-kravene gjelder uansett.

Unntak

• Rene maskin-til-maskin-tjenester.
• Innhold publisert før 1. juli 2014 i visse kategorier (med unntak: NAV og andre tjenester rettet direkte mot innbyggere har siden 2021 plikt til å oppfylle krav også for eldre løsninger).
• Direkteoverføringer (live) av video og lyd er unntatt enkelte krav.
• Tredjepartsinnhold som virksomheten ikke har påvirkningsmulighet over – men oppfølgingsplikt overfor leverandør gjelder.
• Uforholdsmessig stor byrde kan begrunne unntak fra enkeltkrav, men dette må vurderes konkret og dokumenteres.

4. WCAG: Hvilken versjon gjelder for hvem?

WCAG (Web Content Accessibility Guidelines) er den internasjonale standarden som forskriften viser til. Det er imidlertid en kilde til mye forvirring at flere ulike versjoner av WCAG gjelder samtidig i Norge, avhengig av hvilken sektor du tilhører.

Sektor	Gjeldende standard	Hjemmel
Privat sektor (allmennheten)	WCAG 2.0 nivå A og AA, med unntak for synstolking	Forskrift om UU av IKT-løsninger
Offentlig sektor – nettsteder og apper	WCAG 2.1 nivå A og AA	Webdirektivet (WAD), i full kraft fra 1.2.2023
Offentlig sektor – intranett og ekstranett	WCAG 2.1 nivå A og AA	Webdirektivet (WAD)

Standarden EN 301 549 er den europeiske harmoniserte standarden som operasjonaliserer kravene i et IKT-perspektiv. En revidert versjon ventes endelig vedtatt i løpet av 2026.

5. A, AA og AAA – hvilke krav er lovpålagt?

WCAG har tre konformitetsnivåer. Det er kritisk å vite hvilket nivå som er lovkrav, og hvilket som er anbefaling:

• 🔴 Nivå A – minimumskrav. De mest grunnleggende kravene. Hvis disse ikke er oppfylt, vil mange brukere være helt utestengt fra å bruke løsningen. Lovpålagt i Norge.
• 🟡 Nivå AA – hovednivå (lovpålagt minstekrav). Det nivået forskriften krever oppfylt. Norge har lagt seg på AA fordi dette balanserer brukerbehov mot teknisk og økonomisk gjennomførbarhet, og samsvarer med EUs valg i Webdirektivet og EAA. Dette er nivået tilsynet kontrollerer mot.
• 🟢 Nivå AAA – anbefalt for kritiske tjenester. Strengeste nivå. Ikke lovkrav. Anbefales for tjenester rettet mot brukere med store funksjonsnedsettelser, eller der konsekvensene av utestenging er særlig alvorlige (helse, sosiale tjenester, demokratiske prosesser).

Når en tilsynssak åpnes, måles løsningen mot nivå AA – ikke AAA. Det betyr at virksomheter ikke skal bruke ressurser på AAA-tilpasninger før AA-nivået er solid på plass.

6. POUR – de fire prinsippene

WCAG er bygget rundt fire grunnprinsipper, kjent som POUR. Alle suksesskriteriene faller inn under ett av disse:

• P – Mulig å oppfatte: Informasjon må presenteres på måter brukeren kan oppfatte – uavhengig av sans.
• O – Mulig å betjene: Brukergrensesnitt og navigasjon må fungere uavhengig av inndataenhet.
• U – Forståelig: Informasjon og betjening må være forståelig for alle brukere.
• R – Robust: Innholdet må tolkes pålitelig av et bredt spekter av brukeragenter, inkludert skjermlesere.

7. P – Mulig å oppfatte

Formelt krav	Konkret utfordring	God løsning
Tekstalternativer (1.1.1)	Bilder, grafikk og knapper uten tekst	Alt-tekster: Alle meningsbærende bilder må ha beskrivende alt-tekst. Dekorative elementer skal ha tom alt-tekst (alt="") slik at skjermlesere ignorerer dem.
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.
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. 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. Tekststørrelse må kunne endres til 200 % uten tap av innhold.

8. O – Mulig å betjene

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: Synlig indikator (ramme eller fargeendring) rundt elementet med tastaturfokus.
Tilstrekkelig tid (2.2.1)	Tidsbegrensede funksjoner	Justerbare tidsfrister: 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.

9. U – 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.
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.

10. R – Robust

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.

11. Universell utforming som del av internkontrollen

Dette er det punktet som skiller virksomheter med papir-etterlevelse fra virksomheter med reell etterlevelse. UU-kravene gjelder uansett – men uten forankring i internkontrollsystemet vil etterlevelsen være tilfeldig og avhengig av enkeltpersoner.

Internkontrollforskriften § 5 stiller krav om at virksomheten skal ha systematikk, dokumentasjon og kontinuerlig forbedring i sitt arbeid med lover og forskrifter som regulerer helse, miljø, sikkerhet – og i utvidet forstand, andre lovpålagte styringskrav som UU. Konkret betyr dette:

Roller og ansvar

• Daglig leder har det overordnede ansvaret for at virksomheten oppfyller UU-kravene, på linje med andre lovpålagte styringskrav.
• Internkontrollansvarlig bør ha UU som del av sitt forvaltningsansvar – kartlegging, oppfølging og avviksbehandling.
• Webredaktør / produkteier har det operative ansvaret for at konkrete løsninger oppfyller WCAG-kravene.
• Innkjøper har ansvar for at krav til UU stilles i anbud og leverandøravtaler.

Periodisk kontroll og revisjon

UU er ikke et engangsarbeid. Forankringen i internkontrollen krever at det er definert hvor ofte løsningene testes, hvem som gjør det, og hvordan resultater dokumenteres. Anbefalt frekvens:

• Automatisk testing: ved hver publisering/utrulling.
• Manuell stikkprøvekontroll: kvartalsvis.
• Full revisjon med ekstern eller intern fagperson: årlig.

Avvikshåndtering

UU-avvik skal behandles i samme avvikssystem som andre internkontrollavvik. Det betyr at avvik registreres, klassifiseres etter alvorlighetsgrad, tildeles ansvarlig, gis frist for retting og lukkes formelt med dokumentasjon. Når UU-arbeidet kobles til virksomhetens øvrige avvikssystem, blir tilsynsdokumentasjon en biprodukt – ikke en ekstra arbeidsoppgave.

Kobling til styringssystemet

UU bør være beskrevet som et eget område i virksomhetens styrende dokumenter, på linje med personvern, informasjonssikkerhet og HMS. En typisk struktur:

• Policy/instruks for universell utforming.
• Rutine for testing og dokumentasjon.
• Sjekkliste/kontrolldokument før publisering.
• Rutine for avviksbehandling.
• Plan for kompetansebygging hos redaktører og utviklere.

12. Tilgjengelighetserklæring i praksis

For offentlige virksomheter er erklæringen obligatorisk og skal lages via den nasjonale løsningen på uustatus.no. Erklæringen tjener tre formål:

1. Lovpålagt plikt og dokumentasjon

Sikrer at personer med nedsatt funksjonsevne får informasjon om hvilke deler av løsningen som er tilgjengelig, hvilke som har mangler, og hva virksomheten gjør med det.

2. Styringsverktøy og forbedringslogg

Når erklæringen tas på alvor som styringsverktøy, fungerer den som en kontinuerlig forbedringslogg: avvik som identifiseres føres inn med tidsplan for retting, og oppdateres ved gjennomgang.

3. Dokumentasjon ved tilsyn

Erklæringen er tilsynets førstesjekk. En grundig, ærlig erklæring viser modenhet og samarbeidsvilje. En mangelfull eller usann erklæring gir motsatt signal.

Hva som må inngå i erklæringen

• Hvor full samsvar foreligger, delvis samsvar, eller manglende samsvar.
• Konkret beskrivelse av kjente brudd, med henvisning til suksesskriterium.
• Begrunnelse for unntak (uforholdsmessig byrde) der det påberopes.
• Tilbakemeldingsfunksjon: brukere må kunne melde feil og få svar.
• Dato for siste vurdering og hvem som har utført den.

Typiske feil i tilgjengelighetserklæringer

• «Alt er i samsvar» uten dokumentert testing.
• Manglende rutine for å behandle innkomne tilbakemeldinger.
• Erklæring som ikke oppdateres ved endringer.
• Vage formuleringer uten konkret kobling til suksesskriterier.

13. Testing og dokumentasjon – revisjonsvennlig

For at virksomheten skal kunne vise at den har «testet» – ikke bare påstå det – må følgende dokumenteres:

Hva som må dokumenteres	Eksempel
Hvilke verktøy er brukt	WAVE, Axe DevTools, Lighthouse, Siteimprove, manuell skjermlesertest med NVDA eller VoiceOver
Hvilke sider/funksjoner ble testet	Forside, kontaktskjema, søkefunksjon, betalingsflyt, innloggingsside
Mot hvilken standard	WCAG 2.0 AA / WCAG 2.1 AA
Dato og ansvarlig	Tester (navn, rolle), dato, hvilken versjon av løsningen
Funn og tiltak	Liste over avvik, kategorisering, frister, status (åpen/lukket)

Engangstesting vs. kontinuerlig kontroll

En vanlig misforståelse er at «vi har testet siden, så vi er ferdige». UU-testing må kobles til endring:

• Ved publisering eller endring: Automatisk test som del av publiseringsrutinen, supplert med manuell stikkprøve.
• Periodisk full gjennomgang: Minst én gang per år for nettsteder, oftere for kritiske tjenester.
• Brukertesting: Tester med personer som faktisk bruker hjelpemidler. Dette fanger problemer som verktøytester ikke avdekker.

14. Typiske avvik i UU-tilsyn

Erfaring fra Tilsynet for universell utforming av IKT viser at de samme avvikene går igjen:

• Manglende eller mangelfull tilgjengelighetserklæring – særlig hos offentlige virksomheter som har erklæring, men ikke vedlikeholder den.
• Dårlig kontrast i designmaler – spesielt knapper med hvit tekst på lys bakgrunnsfarge, og lenker uten understrek.
• Skjema uten korrekt feilhåndtering – feilmeldinger som kun vises som rød tekst (farge alene), eller som ikke leses opp av skjermlesere.
• Manglende tastaturnavigasjon – modaler, dropdowns og navigasjonsmenyer som krever mus.
• PDF-er uten struktur – skannede dokumenter eller PDF-er uten taggede overskrifter, alternativ tekst eller leserekkefølge.
• Manglende språkangivelse i kode – sider uten lang-attributt eller med feil språk.
• Videoer uten teksting – særlig forhåndsinnspilte videoer i informasjons- eller markedsføringssammenheng.
• Tredjepartsløsninger uten oppfølging – chatbots, betalingsmoduler eller widgets som virksomheten ikke har testet eller stilt krav til.

Tilsyn og sanksjoner – hva risikerer dere?

Dette er spørsmålet ledere oftest stiller – og som sjelden besvares konkret nok. Tilsynet for universell utforming av IKT er ikke et hypotetisk risikomoment; det er et aktivt tilsynsorgan som åpner saker mot både offentlige og private virksomheter hvert år. Slik fungerer det i praksis:

Hvordan starter en tilsynssak?

Inngang	Praktisk forklaring
Klage fra bruker	Vanligste inngang. En person med funksjonsnedsettelse opplever at en løsning ikke fungerer, og melder det til tilsynet. Klagen utløser undersøkelse.
Egeninitiert tilsyn	Tilsynet velger ut sektorer eller virksomheter for systematisk gjennomgang. Eksempler tidligere år: kommuner, banker, offentlige tjenester, e-handel.
Mediedekning	Saker som får oppmerksomhet kan utløse tilsynsmyndighetens interesse, særlig hvis flere brukere bekrefter problemer.
Tematiske kontroller	Tilsynet kjører tematiske gjennomganger – f.eks. tilgjengelighetserklæringer hos kommuner, eller skjemafunksjonalitet i offentlige tjenester.

Saksgangen i et typisk tilsyn

1. Varsel om tilsyn. Tilsynet sender brev som forklarer omfanget. Virksomheten får kort frist for å forberede seg.
2. Innhenting av dokumentasjon. Tilsynet ber om: tilgjengelighetserklæring, testdokumentasjon, ansvarsbeskrivelse, avvikshåndtering, eventuelle DPIA-er.
3. Teknisk gjennomgang. Tilsynet kjører automatisk og manuell test mot WCAG-kravene. Dette er den faktiske «målingen».
4. Foreløpig rapport med funn. Virksomheten får anledning til å kommentere – og ofte til å rette enkle feil før vedtak.
5. Endelig vedtak. Pålegg om retting, eventuelt med tvangsmulkt dersom frister ikke holdes.
6. Klagebehandling. Vedtak kan klages inn for Klagenemnda for likestilling og diskriminering / Diskrimineringsnemnda (avhengig av sakstype).

Konsekvensskala – hva risikerer dere?

Nivå	Konkret konsekvens	Når brukes det?
1. Veiledning	Tilsynet gir råd om hvordan løsningen kan tilpasses kravene. Ingen formell sanksjon.	Førstegangsproblem av begrenset omfang, der virksomheten viser samarbeidsvilje.
2. Pålegg om retting	Formelt vedtak med konkret frist. Krever dokumentert retting innen frist.	Reell mangel på etterlevelse, men virksomheten anses i stand til å rette.
3. Tvangsmulkt	Løpende dagbøter inntil retting er gjennomført. Beløpet fastsettes individuelt.	Når pålegg ikke etterleves innen frist. Også som forhåndsvarsel ved alvorlige saker.
4. Diskrimineringssak	Erstatningsansvar overfor enkeltperson som er diskriminert. Følger av likestillings- og diskrimineringsloven.	Når manglende UU har gitt konkret diskriminering av identifiserbar person.
5. Omdømmekonsekvens	Offentliggjøring av sak – på tilsynets nettside og ofte i media. Påvirker tillit hos kunder og samarbeidspartnere.	Følger ofte med pålegg, særlig i alvorlige saker eller saker som har stor offentlig interesse.

Hva tilsynet ser etter

Erfarne tilsynsfolk fokuserer på systematikk – ikke perfekt etterlevelse. Det betyr:

• Har virksomheten en tilgjengelighetserklæring? (Hvis offentlig sektor: må)
• Er erklæringen ærlig og oppdatert?
• Finnes dokumentert testpraksis – ikke bare påstand om at det testes?
• Er det rutiner for å fange opp og rette avvik?
• Er ansvaret klart definert – på navn?
• Er det rapportering oppover i organisasjonen?

En virksomhet med dokumentert systematikk og noen tekniske mangler får mildere tilsynsrespons enn en virksomhet med få tekniske mangler men ingen styringsmessig forankring. Dette er den viktigste enkeltinnsikten ledere bør ta med seg.

15. EU Accessibility Act (EAA) – status og hva det betyr

EAA (European Accessibility Act, direktiv 2019/882) er primært et indre marked-direktiv. Formålet er å harmonisere tilgjengelighetskravene for utvalgte produkter og tjenester i hele EU/EØS, slik at brukere med funksjonsnedsettelse får lik tilgang og virksomheter får ett sett krav å forholde seg til.

Hvilke produkter og tjenester EAA omfatter

• Datamaskinvare og operativsystemer for forbrukere (PC-er, nettbrett, smarttelefoner).
• Selvbetjeningsterminaler: minibanker, billettmaskiner, betalingsterminaler, innsjekkingsautomater.
• Forbrukerterminalutstyr knyttet til telefoni og audiovisuelle tjenester.
• E-handel og nettbutikker.
• Banktjenester for forbrukere.
• E-bøker og dedikert programvare.
• Elektroniske kommunikasjonstjenester.
• Visse transporttjenester (passasjertransport via fly, tog, buss, båt).

Unntak

• Mikrobedrifter (under 10 ansatte og under 2 millioner euro i omsetning) er unntatt fra kravene til tjenester.
• Uforholdsmessig stor byrde kan begrunne unntak fra enkeltkrav.

Hva norske virksomheter bør gjøre nå

• Selger dere til EU? Da må dere etterleve EAA nå, uavhengig av norsk ikrafttredelse.
• Vurder modenhetsnivå. EAA bygger på samme tekniske krav som dagens norske regelverk, men er strengere på dokumentasjon og samsvarserklæring.
• Følg EN 301 549. Den europeiske harmoniserte standarden gir presumsjon om samsvar med EAA. Ny versjon ventes endelig vedtatt i 2026.

16. Modenhetsnivåer i UU-arbeidet

Hvor moden er din virksomhet på UU? Bruk denne trappen til å vurdere – og til å sette mål for hva neste nivå krever:

1. Reaktiv etterlevelse. UU håndteres når noen klager, eller når tilsynet melder seg. Ingen systematikk, ingen rutine, ingen dokumentasjon. De fleste virksomheter starter her.
2. Strukturert oppfølging. Det finnes en rutine for testing, en ansvarlig person, og en form for dokumentasjon. UU er definert som oppgave, men ikke fullt integrert i arbeidsprosesser.
3. Integrert i design og utvikling. UU er en del av kravspesifikasjon, designprosess og publiseringsrutine. Utviklere har kompetanse, redaktører har sjekklister, og automatisk testing er en del av byggepipelinen.
4. Del av kvalitets- og styringssystemet. UU-arbeidet er forankret i internkontrollsystemet med policy, rutiner, avviksbehandling, periodisk revisjon og rapportering til ledelsen. Tilsynsdokumentasjon er et biprodukt av det daglige arbeidet, ikke en ekstra oppgave.

Forskjellen mellom nivå 3 og 4 er styringssystemet. Det er på dette nivået UU slutter å være «en jobb for IT» og blir «en del av virksomhetsstyringen» – med rapportering oppover, prioritering på linje med andre lovpålagte krav, og budsjett som reflekterer reell ressursinnsats.

Avsluttende vurdering

Universell utforming av IKT er et felt der det rettslige bildet er fragmentert – ulike standarder for offentlig og privat sektor, ulike WCAG-versjoner, og et EU-direktiv (EAA) som er i kraft i EU men ennå ikke i Norge. Dette gjør det krevende for ledere å vite akkurat hva som gjelder, og enda vanskeligere å vite hva som kreves for å være på trygg grunn.

Likevel er kjernen enkel: WCAG 2.0/2.1 AA er minstekravet. Forankring i internkontrollsystemet er nøkkelen til varig etterlevelse. Tilgjengelighetserklæring er obligatorisk for offentlige virksomheter, frivillig god praksis for private. EAA gjelder allerede for de som har kunder i EU.

De virksomhetene som lykkes best, er ikke de som starter med å lese WCAG fra ende til annen – men de som først får på plass en styringsmessig forankring: hvem har ansvaret, hvor ofte testes løsningene, hvordan dokumenteres det, og hvor havner avvikene? Når dette rammeverket er på plass, blir det tekniske arbeidet håndterbart og varig.

Forbehold: Denne artikkelen gir en generell fremstilling av regelverket per mai 2026. Konkret rådgivning forutsetter individuell vurdering. Ved tvil – kontakt Tilsynet for universell utforming av IKT eller juridisk rådgiver.