ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/digital-accessibility-action-plan.md
Kjell Tore Guttormsen 565043dbde docs(architect): weekly KB update — 66 files refreshed (2026-04)
Updated 66 stale knowledge base reference files (10 critical, 56 high)
across all 5 skills using Microsoft Learn MCP research.

Key factual updates:
- Groundedness Detection API: `correction` → `mitigating` param,
  `correctedText` → `correctionText` (breaking change)
- Copilot Studio: GPT-4.1 mini now default (was GPT-4o mini);
  Claude Sonnet 4.5 + Opus 4.5 added (experimental, 200K ctx)
- Agentic Retrieval: still public preview; 50M free tokens/month
- Azure security baselines: "Cognitive Services" → "Foundry Tools"
- Databricks: Delta Live Tables → Lakeflow Spark Declarative Pipelines
- MLflow 3 GenAI: new Feedback/Expectation data model
- Token tracking doc: "Azure OpenAI in Foundry Models through a gateway"
- Agent Registry: Risks column (M365 E7), Graph API (preview)
- Copilot DLP: new Entra AI Admin + Purview Data Security AI Admin roles
- ISO/IEC 42001: scope expanded to M365 Copilot, Foundry, Security Copilot
- Zero Trust: CAE now via Conditional Access, Strict Location Enforcement
- Purview: new Fabric Copilots/agents governance section
- AG-UI HITL: ApprovalRequiredAIFunction (C#), @tool approval_mode (Python)

All files: Last updated → 2026-04, *(Verified MCP 2026-04)* markers added.
Build registry: 1341 URLs from 387 files (+2 new URLs).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-09 22:41:26 +02:00

21 KiB
Raw Blame History

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


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:


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-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:


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:


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
  • 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.

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
  2. Digdir – Strategi og handlingsplan
  3. UU-tilsynet – EUs webdirektiv (WAD)
  4. UU-tilsynet – EUs tilgjengelighetsdirektiv (EAA)
  5. UU-tilsynet – Offentlig sektor
  6. UU-tilsynet – WCAG-standarden

Internasjonale standarder

  1. W3C – WCAG 2.1 Guidelines
  2. European Commission – AI Act enters into force
  3. AccessibleEU – EAA comes into effect in June 2025

Microsoft ressurser

  1. Microsoft AI – Responsible AI Principles and Approach
  2. Microsoft AI – Responsible AI
  3. Microsoft Accessibility
  4. Microsoft Learn – Create accessible AI experiences
  5. Microsoft Learn – Explore AI for all
  6. Microsoft Learn – Use AI tools to create an inclusive learning environment (Verified MCP 2026-04)
  7. Microsoft Learn – Web Content Accessibility Guidelines
  8. Microsoft Learn – U.S. Section 508
  9. Microsoft Inclusive Design

Forskningsressurser

  1. OsloMet – Halvparten av eldre i Norge trenger hjelp for å betale en regning

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