# Digital tilgjengelighet - handlingsplan for AI

**Last updated:** 2026-04
**Status:** Gjeldende
**Category:** Norwegian Public Sector AI Governance

---

## Introduksjon

Digital tilgjengelighet er ikke bare et lovkrav – det er en grunnleggende forutsetning for inkluderende AI-løsninger i offentlig sektor. Med over 1 milliard mennesker med funksjonsnedsettelser globalt, og en betydelig andel av den norske befolkningen som opplever digitale barrierer, må AI-systemer designes med tilgjengelighet som et kjernekrav fra dag én.

For norsk offentlig sektor innebærer dette å navigere et komplekst regelverk som omfatter nasjonale forskrifter, EU-direktiver (WAD, kommende EAA), WCAG-standarder, og ikke minst FNs konvensjon om rettigheter for personer med nedsatt funksjonsevne (CRPD).

**Kontekst for AI-løsninger:**
- AI-chatbots og konversasjonsgrensesnitt må være tilgjengelige for skjermlesere
- Automatiserte beslutningssystemer må gi forståelige forklaringer
- Multimodale AI-grensesnitt (tekst, tale, bilde) må støtte ulike interaksjonsformer
- Generativ AI må ikke reprodusere eller forsterke diskriminerende mønstre

---

## Nasjonal strategi for digital inkludering

### Handlingsplan for auka inkludering i eit digitalt samfunn (2023-2026)

Regjeringens handlingsplan består av **32 tiltak** for å motvirke digital ekskludering og legge til rette for at alle kan delta i samfunnet.

**Hovedmål:**
- Sikre at alle innbyggere kan ta del i den digitale transformasjonen
- Samarbeid mellom offentlig sektor, frivillig sektor og næringsliv
- Koordinert innsats for å bygge ned digitale barrierer

**Digdirs rolle:**
Digitaliseringsdirektoratet har hovedansvaret for å koordinere regjeringens politikk på området og følge opp status på tiltakene i handlingsplanen.

**Relevans for AI-arkitekter:**
- AI-løsninger må vurderes for digital inkludering i tidlig fase
- Eldre og personer med lav digital kompetanse er særlig sårbare grupper
- Halvparten av eldre i Norge trenger hjelp til å betale en regning digitalt – AI-grensesnitt må være intuitive nok til å senke terskelen

**Kilde:** [Regjeringen.no - Handlingsplan for auka inkludering](https://www.regjeringen.no/no/dokumenter/handlingsplan-for-auka-inkludering-i-eit-digitalt-samfunn/id2984233/)

---

## Gjeldende regelverk for universell utforming av IKT

### Forskrift om universell utforming av IKT-løsninger (oppdatert 1. februar 2023)

Norge har implementert EUs webdirektiv (WAD) i norsk rett, med krav som trådte i kraft **1. februar 2023**.

**Offentlig sektor må oppfylle:**
- **48 suksesskriterier** fra WCAG 2.1 (nivå A og AA)
- Krav til tilgjengelighetserklæring på UUstatus.no
- Synstolking av førehandsinnspelte tidsbaserte medium (fra 1. februar 2024)
- Universell utforming av intranett og ekstranett (nye eller vesentlig oppgradert etter 1. februar 2023)

**Privat sektor må oppfylle:**
- **35 suksesskriterier** fra WCAG 2.1
- Gjelder for virksomheter med mer enn 10 ansatte eller omsetting over 1 million NOK

**Viktig for AI-chatbots:**
- Konversasjonsgrensesnitt må følge WCAG 2.1-krav for tastaturnavigasjon, skjermleserstøtte, fokusindikatorer, og kontrast
- Responsformater må være tilgjengelige (ikke bare visuell output)
- Feilmeldinger og veiledning må være forståelige for brukere med kognitive funksjonsnedsettelser

**Kilder:**
- [UU-tilsynet: EUs webdirektiv (WAD)](https://www.uutilsynet.no/webdirektivet-wad/eus-webdirektiv-wad/265)
- [UU-tilsynet: Offentlig sektor](https://www.uutilsynet.no/regelverk/offentlig-sektor/1584)

---

## EUs tilgjengelighetsdirektiv (EAA) – kommende krav

### Status i Norge (per februar 2026)

EUs tilgjengelighetsdirektiv (European Accessibility Act - EAA) trådte i kraft i EU **28. juni 2025**, men er **ikke ennå implementert i Norge**.

**Hva forsinker implementeringen?**
- EAA er ikke inkorporert i EØS-avtalen ennå
- Uavklart om EAA er et minimumsdirektiv eller totalharmoniserende
- Norge har allerede strengere regler på enkelte områder (f.eks. salgsautomater)
- Balansegang mellom EAA og forpliktelser under FNs CRPD

**Ansvarlig departement:**
Kulturdepartementet (KUD) er ansvarlig for implementering av EAA i Norge.

**Hva dekker EAA?**
- Produkter: datamaskiner, smarttelefoner, billettautomater, betalingsterminaler, e-bøker
- Tjenester: e-handel, banktjenester, transport, telefoni, audiovisuelle medietjenester

**Implikasjoner for AI:**
Når EAA implementeres i Norge, vil AI-drevne selvbetjeningstjenester (chatbots, automatiserte kundesentre, digitale assistenter) måtte oppfylle tilgjengelighetskrav som en del av tjenestekategoriene.

**Kilder:**
- [UU-tilsynet: EUs tilgjengelighetsdirektiv (EAA)](https://www.uutilsynet.no/tilgjengelighetsdirektivet-eaa/eus-tilgjengelegheitsdirektiv-eaa/268)
- [AccessibleEU: EAA comes into effect in June 2025](https://accessible-eu-centre.ec.europa.eu/content-corner/news/eaa-comes-effect-june-2025-are-you-ready-2025-01-31_en)

---

## UU-tilsynets rolle og fremtidig AI-tilsyn

### Tilsynet for universell utforming av IKT

UU-tilsynet er den norske etaten som fører tilsyn med at IKT-løsninger er universelt utformet.

**Tilsynsmetoder:**
- **Forenklet kontroll:** Årlig kontroll av ca. 250 virksomheter i offentlig sektor
- Klagebehandling
- Veiledning og informasjon

**AI-spesifikke utfordringer:**
Per februar 2026 finnes det ikke offentlig tilgjengelig informasjon om at UU-tilsynet har gjennomført spesifikk tilsyn av AI-chatbots eller kunstig intelligens-systemer. Men gitt at:
- AI-chatbots er IKT-løsninger underlagt forskriften
- EUs AI-forordning (AI Act) krever at brukere informeres når de samhandler med AI

... er det sannsynlig at UU-tilsynet vil utvikle spesifikke retningslinjer for AI-tilgjengelighet i nærmeste fremtid.

**Krav fra EU AI Act (gjeldende fra august 2024):**
Brukere som snakker eller skriver med en chatbot skal gjøres oppmerksom på at det er et AI-system de samhandler med. Mennesker skal være klar over at de samhandler med en maskin slik at de kan ta informerte beslutninger.

**Kilder:**
- [UU-tilsynet](https://www.uutilsynet.no/)
- [AI Act enters into force](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en)

---

## AI og digital inkludering – særlige hensyn

### Tilgjengelighetsdimensjoner for AI-systemer

AI-løsninger introduserer nye tilgjengelighetsutfordringer som går utover tradisjonelle WCAG-krav:

| Dimensjon | Utfordring | Løsning |
|-----------|------------|---------|
| **Grensesnitt** | Konversasjonsbaserte UI krever nye interaksjonsmønstre | Støtte for tastatur, tale, braille-display, alternative inputmetoder |
| **Forklarbarhet** | AI-beslutninger kan være uforståelige | Eksplicitte forklaringer på begrenset norsk, visuell støtte |
| **Bias og diskriminering** | Treningsdata kan inneholde skjevheter | Systematisk testing mot utsatte grupper, norsk kontekst |
| **Kognitive krav** | Komplekse prompts, uventet oppførsel | Strukturerte dialoger, feiltoleranse, forutsigbarhet |
| **Multimodalitet** | Ikke alle kan bruke alle modaliteter | Tilby tekst, tale, og bilde som likeverdige alternativ |
| **Autonomi** | Brukeren kan miste kontroll over interaksjonen | Tydelige avbrytelsesmekanismer, menneskelig eskalering |

### Microsoft AI og tilgjengelighet

**Microsoft Learn — Use AI tools to create an inclusive learning environment *(Verified MCP 2026-04)*:**
Modul tilgjengelig for K-12 lærere, bedriftsbrukere og utdanningsinstitusjonell ledelse. Læringsmål:
- Gjenkjenne AI-rollen i å støtte samarbeidslæring
- Vurdere tekst-til-tale-teknologi og hvem som har nytte av den
- Forstå hvordan AI i Microsoft Teams forbedrer tilgjengelighet for brukere med hørselshemming eller ADHD
Modulen dekker adaptiv læring, AI-drevet tilbakemelding og personalisert innholdslevering.

**Microsoft har inkludert tilgjengelighet som en del av sin Responsible AI Standard:**

**Seks prinsipper:**
1. **Fairness (rettferdighet):** AI skal ikke diskriminere
2. **Reliability and Safety (pålitelighet og sikkerhet):** AI skal fungere konsekvent
3. **Privacy and Security (personvern og sikkerhet):** Datasikkerhet
4. **Inclusiveness (inkludering):** AI skal være tilgjengelig for alle
5. **Transparency (gjennomsiktighet):** Forståelige beslutninger
6. **Accountability (ansvarlighet):** Tydelig ansvar for AI-systemets oppførsel

**Inclusiveness-prinsippet:**
Microsoft krever at AI-systemer følger eksisterende accessibility-programmer og AI-spesifikk veiledning for tilgjengelighet.

**Microsoft-verktøy for tilgjengelig AI:**
- **Azure AI Speech:** Tekst-til-tale og tale-til-tekst for universelt design
- **Azure AI Translator:** Flerspråklig støtte (viktig for minoritetsspråk)
- **Immersive Reader:** Forenklet lesing for personer med dysleksi/kognitive funksjonsnedsettelser
- **Azure AI Vision:** Bildegjenkjenning for å beskrive visuelt innhold for synshemmede
- **Copilot Studio:** Bygge chatbots med innebygde tilgjengelighetsfunksjoner

**Kilder:**
- [Microsoft AI: Responsible AI Principles and Approach](https://www.microsoft.com/en-us/ai/principles-and-approach)
- [Microsoft Learn: Create accessible AI experiences](https://learn.microsoft.com/en-us/training/modules/create-accessible-solutions-using-ai-innovations/)

---

## Handlingsplan for AI-prosjekter

### Fase 1: Kravspesifikasjon (Inception)

**Sjekkliste:**
- [ ] Identifiser brukergrupper med funksjonsnedsettelser (synshemming, hørselshemming, motoriske, kognitive)
- [ ] Involver representanter fra brukergrupper tidlig i prosessen
- [ ] Kartlegg eksisterende tilgjengelighetsprofiler i virksomheten
- [ ] Definer målbare tilgjengelighetskriterier (ikke bare "WCAG-compliant")
- [ ] Vurder om AI-løsningen kan erstatte eksisterende tilgjengelige løsninger negativt

**Eksempel på kravformulering:**
> "AI-chatboten skal være fullt navigerbar med tastatur, gi meningsfulle ARIA-labels for skjermlesere, og tilby tekstalternativ for alle AI-genererte bilder og diagrammer. Responsen skal være forståelig for brukere med lesenivå tilsvarende 8. klasse."

---

### Fase 2: Design og arkitektur

**Designprinsipper:**
1. **Likeverdige opplevelser:** AI skal gi samme verdi uavhengig av funksjonsnivå
2. **Fleksibilitet i bruk:** Støtt ulike interaksjonsmetoder (tastatur, tale, mus, touch)
3. **Enkel og intuitiv bruk:** Reducer kognitive krav
4. **Oppfattbar informasjon:** Informasjon må kommuniseres effektivt til alle sanser
5. **Toleranse for feil:** AI skal håndtere uventede inputs uten å "krasje"
6. **Lav fysisk anstrengelse:** Minimer repeterende handlinger
7. **Størrelse og plass for tilgang:** Grensesnitt må fungere på ulike skjermstørrelser

**Microsoft-verktøy for design:**
- **Inclusive Design Toolkit:** [inclusive.microsoft.design](https://inclusive.microsoft.design/)
- **Accessibility Insights:** Automatisk testing av web, Windows, Android
- **Azure AI Foundry:** Bygg AI-løsninger med innebygde accessibility-tester

**Arkitekturmønstre:**
- Multimodal input/output (tekst, tale, bilde)
- Graciøs degradering (fallback til enklere grensesnitt ved feil)
- Eksplisitt AI-disclosure (brukeren vet at de snakker med AI)
- Menneskelig eskalering (mulighet til å overføre til menneskelig agent)

---

### Fase 3: Utvikling og testing

**Utviklingspraksis:**
- Bruk ARIA-standarder for rike webapplikasjoner (f.eks. ARIA live regions for AI-respons)
- Test med skjermlesere (NVDA, JAWS, Narrator, VoiceOver)
- Bruk kontrastverktøy (minimum 4.5:1 for normal tekst, 3:1 for store tekster)
- Implementer tastaturnavigasjon (Tab, Enter, Escape, piltaster)
- Valider HTML (ugyldig markup kan ødelegge skjermleserstøtte)

**Automatisert testing:**
- **Accessibility Insights for Web:** Browser-plugin for WCAG-testing
- **axe DevTools:** Automatisk tilgjengelighetstesting i utviklerverktøy
- **Pa11y CI:** Integrer tilgjengelighetstester i CI/CD-pipeline

**Manuell testing:**
- Test med ekte brukere med funksjonsnedsettelser
- Bruk selv skjermleser i én dag
- Naviger chatboten uten mus
- Test med 200% zoom
- Test med high contrast mode

**AI-spesifikke tester:**
- Bias-testing: Gir AI-en ulike svar basert på navn, dialekt, eller kulturell kontekst?
- Responskompleksitet: Er svarene forståelige for brukere med kognitive funksjonsnedsettelser?
- Multimodal konsistens: Er tekst-, tale-, og bildeoutput konsistente?

---

### Fase 4: Dokumentasjon og erklæring

**Tilgjengelighetserklæring (obligatorisk fra 1. februar 2023):**
Alle offentlige nettsteder skal ha en tilgjengelighetserklæring publisert på [UUstatus.no](https://uustatus.no/).

**Innhold i erklæringen:**
- Hvilke WCAG-krav som er oppfylt
- Kjente tilgjengelighetsproblemer
- Alternativer for brukere som ikke kan bruke løsningen
- Kontaktinformasjon for tilgjengelighetsspørsmål
- Klageadgang (til UU-tilsynet)

**AI-spesifikke tillegg:**
- Beskriv hvordan AI-systemet fungerer (gjennomsiktighet)
- Forklar hvilke data AI-en bruker til beslutninger
- Informer om begrensninger i AI-ens evne til å håndtere edge cases
- Gi informasjon om hvordan brukere kan eskalere til menneskelig agent

**Eksempel:**
> "Denne chatboten bruker Azure OpenAI til å svare på spørsmål om NAV-ytelser. Den er trent på offentlig tilgjengelig informasjon og vil ikke alltid ha oppdatert informasjon om endringer i regelverket. Hvis du ikke får svar på spørsmålet ditt, kan du ringe NAV på 55 55 33 33."

---

### Fase 5: Drift og forbedring

**Kontinuerlig monitorering:**
- Logg tilgjengelighetsrelaterte feil (f.eks. brukere som forlater chatbot etter få interaksjoner)
- Analyser bruksmønstre for hjelpemiddelteknologi (hvor mange bruker skjermleser?)
- Samle inn tilbakemeldinger fra brukere med funksjonsnedsettelser

**Oppgraderinger:**
- Følg med på oppdateringer til WCAG (WCAG 2.2 og 3.0 er under utvikling)
- Overvåk nye retningslinjer fra UU-tilsynet
- Oppdater AI-modeller basert på tilgjengelighetstesting

**Organisatorisk læring:**
- Gjennomfør årlige tilgjengelighetsvurderinger
- Tren utviklere i tilgjengelighetsprinsipper
- Bygg nettverk med brukerorganisasjoner (f.eks. Norges Blindeforbund, Norsk Forbund for Utviklingshemmede)

---

## Microsoft-verktøy for tilgjengelig AI

### Azure AI Services med tilgjengelighetsfokus

| Tjeneste | Tilgjengelighetsfunksjon | Bruksområde |
|----------|---------------------------|-------------|
| **Azure AI Speech** | Tekst-til-tale, tale-til-tekst, talegjenkjenning | Gi AI-chatbot stemmegrensesnitt for synshemmede og motorisk funksjonshemmede |
| **Azure AI Translator** | 100+ språk, inkl. nynorsk og bokmål | Tilgjengelighet for minoritetsspråk og flerspråklige brukere |
| **Azure AI Vision** | Bildeanalyse, OCR, ansiktsgjenkjenning | Generer tekstbeskrivelser av bilder for skjermlesere |
| **Immersive Reader** | Forenklet lesing, opplesing, oversettelse | Støtte for dysleksi og lærevansker |
| **Azure AI Document Intelligence** | Strukturert tekstekstraksjon fra PDF/bilder | Gjør utilgjengelige dokumenter maskinlesbare |
| **Azure OpenAI + GPT-4o** | Multimodal forståelse, lang kontekst | Generer forklaringer på flere nivåer (ekspert vs. nybegynner) |

### Copilot Studio og tilgjengelighet

**Innebygde funksjoner:**
- **Adaptive Cards:** Responsivt design som fungerer på tvers av enheter og skjermlesere
- **SSML-støtte:** Speech Synthesis Markup Language for naturlig talesyntese
- **Sentiment analysis:** Tilpasse tone basert på brukertilstand
- **Handoff til agent:** Automatisk eskalering når AI ikke klarer å hjelpe

**Best practices for Copilot Studio:**
- Bruk Adaptive Cards i stedet for ren tekst (bedre strukturering for skjermlesere)
- Implementer ARIA live regions for dynamisk oppdatert innhold
- Gi brukeren kontroll over interaksjonshastighet (pause, gjenspill)
- Test med Microsoft Accessibility Insights

---

## For arkitekten (Cosmo)

### Når tilgjengelighet er kritisk i AI-arkitektur

**Obligatoriske vurderinger:**
1. **Målgruppe:** Er løsningen rettet mot borgere (høy risiko for ekskludering)?
2. **Kritikalitet:** Er tjenesten nødvendig for å delta i samfunnet (f.eks. helsehjelp, trygderettigheter)?
3. **Alternativ:** Finnes det et likeverdig ikke-digitalt alternativ?
4. **Compliance:** Hvilke regelverk gjelder (WAD, kommende EAA, WCAG 2.1)?

**Arkitekturvedtak:**
- Velg plattformer med innebygd tilgjengelighetsstøtte (Copilot Studio > hjemmesnekret chatbot)
- Prioriter multimodal design fra starten (ikke som en "phase 2"-funksjon)
- Dokumenter tilgjengelighetsbeslutninger i ADR (Architecture Decision Record)

**Eksempel på ADR:**
> **ADR-023: Bruk av Azure AI Speech for stemmegrensesnitt**
>
> **Kontekst:** NAV-chatboten skal være tilgjengelig for synshemmede brukere.
>
> **Beslutning:** Vi implementerer Azure AI Speech for tekst-til-tale og tale-til-tekst.
>
> **Konsekvenser:**
> - Positivt: WCAG 2.1-kompatibelt, støtte for norsk språk, lavere terskel for synshemmede
> - Negativt: Økte kostnader (ca. 10 000 NOK/mnd for forventet trafikk), avhengighet av Azure-tjeneste
> - Risiko: Tale-til-tekst har 90% nøyaktighet – må ha fallback til tekstinput

**Arkitekturmønster:**
```
Bruker → [Multimodal Frontend (Adaptive Cards)]
            ↓
        [API Gateway med accessibility headers]
            ↓
        [Azure OpenAI (GPT-4o)]
            ↓
        [Response Formatter]
            ↙        ↘
    [Tekst]    [Tale (Azure Speech)]
```

**Kvalitetskrav:**
- WCAG 2.1 nivå AA (48 suksesskriterier for offentlig sektor)
- Responsetid < 3 sekunder (viktig for skjermleserbrukere)
- Fallback ved feil (graciøs degradering)

**Kostnadsimplikasjon:**
Tilgjengelighet er ikke "gratis" – det krever:
- **Tid:** +20-30% ekstra utviklingstid for testing og tilrettelegging
- **Kompetanse:** Opplæring i WCAG, skjermlesertesting, inkluderende design
- **Verktøy:** Accessibility Insights, axe DevTools, manuell testing
- **Azure-tjenester:** Speech, Translator, Immersive Reader (se Cost-estimering)

**Verdi:**
- **Juridisk:** Unngå tilsyn/sanksjoner fra UU-tilsynet
- **Etisk:** Inkluderende tjenester som når hele befolkningen
- **Økonomisk:** Bredere brukerbase, redusert behov for manuell støtte

### Spørsmål å stille kunden

1. **Har dere kartlagt brukernes tilgjengelighetsbehov?**
2. **Har dere tilgjengelighetserklæring for eksisterende IKT-løsninger?**
3. **Har dere kompetanse på WCAG-testing internt, eller trenger dere ekstern støtte?**
4. **Planlegger dere å involvere brukere med funksjonsnedsettelser i testing?**
5. **Har dere budsjett for tilgjengelighetstiltak (Azure Speech, Translator, testing)?**
6. **Hva er konsekvensen hvis en bruker ikke kan bruke AI-løsningen? (Kritikalitet)**
7. **Finnes det alternativer (telefon, fysisk møte) for brukere som ikke kan bruke AI?**

### Røde flagg

⚠️ **Advarselstegn på dårlig tilgjengelighet:**
- "Vi fikser tilgjengelighet i fase 2" (det skjer aldri)
- "Vi har ikke budsjett for skjermlesertesting" (obligatorisk krav)
- "AI-en er for kompleks til å gjøre tilgjengelig" (designfeil)
- "Vi tester kun på Chrome med mus" (ekskluderende)
- "Kun 2% av brukerne har funksjonsnedsettelser" (underdrevet + ulovlig)

---

## Kilder og verifisering

### Norske myndigheter

1. [Regjeringen.no – Handlingsplan for auka inkludering i eit digitalt samfunn](https://www.regjeringen.no/no/dokumenter/handlingsplan-for-auka-inkludering-i-eit-digitalt-samfunn/id2984233/)
2. [Digdir – Strategi og handlingsplan](https://www.digdir.no/digital-inkludering/strategi-og-handlingsplan/5761)
3. [UU-tilsynet – EUs webdirektiv (WAD)](https://www.uutilsynet.no/webdirektivet-wad/eus-webdirektiv-wad/265)
4. [UU-tilsynet – EUs tilgjengelighetsdirektiv (EAA)](https://www.uutilsynet.no/tilgjengelighetsdirektivet-eaa/eus-tilgjengelegheitsdirektiv-eaa/268)
5. [UU-tilsynet – Offentlig sektor](https://www.uutilsynet.no/regelverk/offentlig-sektor/1584)
6. [UU-tilsynet – WCAG-standarden](https://www.uutilsynet.no/wcag-standarden/wcag-standarden/86)

### Internasjonale standarder

7. [W3C – WCAG 2.1 Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/)
8. [European Commission – AI Act enters into force](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en)
9. [AccessibleEU – EAA comes into effect in June 2025](https://accessible-eu-centre.ec.europa.eu/content-corner/news/eaa-comes-effect-june-2025-are-you-ready-2025-01-31_en)

### Microsoft ressurser

10. [Microsoft AI – Responsible AI Principles and Approach](https://www.microsoft.com/en-us/ai/principles-and-approach)
11. [Microsoft AI – Responsible AI](https://www.microsoft.com/en-us/ai/responsible-ai)
12. [Microsoft Accessibility](https://www.microsoft.com/en-us/accessibility)
13. [Microsoft Learn – Create accessible AI experiences](https://learn.microsoft.com/en-us/training/modules/create-accessible-solutions-using-ai-innovations/)
14. [Microsoft Learn – Explore AI for all](https://learn.microsoft.com/en-us/training/modules/explore-ai-for-all/)
15. [Microsoft Learn – Use AI tools to create an inclusive learning environment](https://learn.microsoft.com/en-us/training/modules/use-ai-tools-to-create-inclusive-learning-environment/) *(Verified MCP 2026-04)*
16. [Microsoft Learn – Web Content Accessibility Guidelines](https://learn.microsoft.com/en-us/compliance/regulatory/offering-wcag-2-1)
17. [Microsoft Learn – U.S. Section 508](https://learn.microsoft.com/en-us/compliance/regulatory/offering-section-508-vpats)
18. [Microsoft Inclusive Design](https://inclusive.microsoft.design/)

### Forskningsressurser

19. [OsloMet – Halvparten av eldre i Norge trenger hjelp for å betale en regning](https://www.oslomet.no/forskning/forskningsnyheter/eldre-hjelp-betale-regning)

---

**Dokumentet oppdateres jevnlig. Siste kontroll av kilder: 9. april 2026.**