open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 4 Activity
ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/accessibility-requirements-wcag-norway.md
Kjell Tore Guttormsen 1c9af82daa refactor(ms-ai-architect): R13b — nøytraliser de mekaniske persona-forekomstene utenfor headinger, etter at ordrens egen korrigerte bøttegrense ble målt usann 
Ordren ba meg behandle sitt eget premiss som et premiss: «PM-ens 87/45 er korrigert
til 85/47 ved maaling ... Behandle ogsaa 85/47 som et premiss og re-maal det foer du
bygger.» Re-målt over de 389 ref-filene holder 85/47 heller ikke — og feilen ligger i
KLASSIFIKATOREN, ikke i tellingen. Summen 132 står; fordelingen er 62/70.

TRE FUNN, alle pinnet i test:

1. FJORTEN bold-etiketter er DIALOG-ATTRIBUSJONER, ikke etiketter. Dialog-bøtta
   matchet bare kursivformen `*Cosmo:*`. Fetformen står foran sitert tale —
   `**Naar kunden sier:** "..."` / `**Cosmo svarer:** "..."` — så å slette den
   etterlater replikken uten taler. Redaksjonelt, ikke mekanisk.
2. TI tabellceller er PROVENIENSPÅSTANDER i kildekvalitets-kolonnen. Celleposisjon
   deler de 26 tabellforekomstene i tre klasser, ikke én: 12 radetiketter (kolonne 0),
   4 kolonneoverskrifter, 10 proveniensverdier (`Moenstre er Cosmo-design`,
   `Raadgivende innhold basert paa Cosmo-persona`). Å skrive om en av dem er å avgi en
   ny påstand om hvor innholdet kommer fra, og den siste har ikke noe slettemål i det
   hele tatt. Seks av ordrens ni sammensetninger ligger helt inne i denne klassen —
   ordrens egen advarsel traff, målingen lokaliserte den.
3. Lekkasje ANDRE veien, +1 mekanisk: `- **For arkitekten (Cosmo):** ...` i
   reasoning-models-o1-o3-optimization.md:549 er nøyaktig målklassen, men et
   linjestart-forankret nett ser den ikke bak `- ` og bokførte den som prosa.

Operatøren ratifiserte 2026-09-15 alt. A: kjør de 62, hold dialog og proveniens for
R14. Begge tilbakeholdte klasser henger på #R14-persona-ramme som aldri er besvart;
de 62 gjør ikke det, fordi R13 ALT har kjørt `For Cosmo` -> `For arkitekten` over 401
headinger — dette gjør bare etiketter og tabellrader konsistente med en beslutning
som allerede er utført.

UTFØRT: 62 forekomster i 50 filer (ordren sa 47) — 46 etiketter i 16 ratifiserte
varianter, 16 celler i 4. Diffen er 62 fjernet = 62 lagt til, ren in-place-erstatning;
hver endret linje klassifisert, ANNET = 0. Ingen måltekst innfører et ord kilden ikke
hadde, utover R13s sanksjonerte `arkitekten` (samme invariant-test, gjenbrukt).

GATEN, DEKOMPONERT I TRE KLAUSULER, hver validert BEGGE veier før den ble konsumert:
  R1 REFERENT      mekaniske sites 62 -> 0, produkt 451 uendret.
                   Kjent-pos: `**For Cosmo:**` OG `| Cosmos raad |` (genitiven er den
                   et bold-only nett mister) feller begge. Kjent-neg:
                   `**Cosmos DB-anbefaling:**` — ser ut som persona, er produkt —
                   og `| Azure Cosmos DB |` passerer urørt.
  R2 REKKEVIDDE    0 umålte varianter, 0 utenfor rekkevidde. Kjent-pos: en ukjent
                   etikettform rapporteres som umålt OG transformen KASTER, den
                   hopper ikke stille over. Kjent-neg: dialog + proveniens bokføres
                   utenfor scope og er byte-identiske.
  R3 HVA SOM STÅR  16 redaksjonelle etiketter + 10 celler uendret, heading/TOC
                   fortsatt 0 (R13 ikke regradert), prosa 132 -> 70. Kjent-pos: et
                   fjernet tegn i `Cosmos DB` feller produkt-differansen. Kjent-neg:
                   alle kun-produkt-filer byte-identiske gjennom transformen.

Gaten ble kjørt FØR transformen og felte R1 (exit 1) — et nullresultat som aldri er
tvunget til det andre svaret er ingen måling. R13b har egen baseline-fil;
cosmo-gate-baseline.json er et referansepunkt-artefakt (personaHeadings 401) og er
IKKE re-emittert. Ny .gitignore-negasjon (6 entries), aldri `git add -f`.

Målt underveis: 0 av de 62 målinjene ligger i en kodeblokk, så fence-agnostisk
transform er trygg her — samme konklusjon R13 nådde for headinger. Nøyaktig 1 linje
bærer begge klasser; dens `Cosmo-persona` står igjen, som den skal.

Suite 1134/1134 (1120 + 14 nye), validate-plugin 250/0/0, transform idempotent,
R13-driveren fortsatt no-op. RX-OPS1 adversarial-scan kjørt MANUELT på de 56 stagede
filene (OK, exit 0) — `core.hooksPath` skygger repoets pre-commit, fiksen eies av
`.claude`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 21:09:00 +02:00

16 KiB
Raw Permalink Blame History

Tilgjengelighetskrav (WCAG) for AI i Norge

Last updated: 2026-06-19 Status: Gjeldende Category: Norwegian Public Sector AI Governance Type: reference Source: https://learn.microsoft.com/compliance/regulatory/offering-wcag-2-1

Innhold

Introduksjon

Universell utforming av IKT er lovpålagt i Norge for både offentlig og privat sektor. AI-løsninger som chatbots, virtuelle assistenter og generative AI-verktøy må følge samme krav som andre digitale tjenester. Dette dokumentet dekker hvordan WCAG-standardene (Web Content Accessibility Guidelines) gjelder for AI-systemer i norsk kontekst, og hvordan Microsoft AI-plattformer kan brukes for å oppfylle disse kravene.

Hvorfor dette er kritisk for offentlig sektor:

  • AI-systemer når stadig flere brukere (over 130 kommunale AI-prosjekter i 2026)
  • Diskriminering på grunnlag av funksjonsnedsettelse er forbudt i norsk lov
  • Offentlige tjenester må være tilgjengelige for alle innbyggere
  • EU AI Act (i kraft 2026) krever transparens og forklarbarhet

Lovgrunnlag

Norsk regulering

Likestillings- og diskrimineringsloven Forbyr diskriminering på grunnlag av nedsatt funksjonsevne. Dette gjelder også digitale tjenester.

Forskrift om universell utforming av IKT (2013, revidert 2021)

  • Gjelder nettsteder, apper og automater (inkludert AI-drevne løsninger)
  • Både offentlig og privat sektor omfattes
  • Offentlig sektor: 48 WCAG 2.1-krav (nivå AA)
  • Privat sektor: 35 WCAG 2.1-krav

Lov om offentlige anskaffelser Universell utforming skal være innarbeidet i kravspesifikasjoner ved anskaffelse av IKT-systemer.

Tilsynsmyndighet

UU-tilsynet (Tilsynet for universell utforming av IKT)

  • Administrativt underlagt Digitaliseringsdirektoratet (Digdir)
  • Fører tilsyn med etterlevelse av UU-forskriften
  • Kan gi pålegg og sanksjoner ved brudd

Europeisk standard

EN 301 549 (revideres 2026)

  • Europeisk standard for tilgjengelighetskrav til IKT
  • Inkluderer WCAG 2.1 som kjernekrav
  • Norsk oversettelse ventes i løpet av 2026
  • Referansedokument for offentlige anskaffelser

WCAG 2.1 (W3C)

WCAG er den internasjonale standarden som forskriften refererer til som juridiske krav.

Fire prinsipper (POUR):

  1. Perceivable (Oppfattbar) — Informasjon og grensesnittkomponenter må kunne oppfattes
  2. Operable (Manøvrerbar) — Brukergrensesnitt og navigasjon må kunne betjenes
  3. Understandable (Forståelig) — Informasjon og betjening må være forståelig
  4. Robust (Robust) — Innhold må tolkes pålitelig av varierte brukeragenter, inkludert hjelpemidler

Konformitetsnivåer:

  • A (minimum)
  • AA (påkrevd for offentlig sektor i Norge)
  • AAA (ønsket nivå, ikke påkrevd)

AI-spesifikke tilgjengelighetskrav

1. Chatbots og konversasjonsagenter

Krav:

  • Alternativ tekstbasert grensesnitt (hvis talebasert)
  • Tastaturnavigasjon uten mus
  • Skjermleser-kompatibilitet (ARIA-markering)
  • Mulighet for å pause, stoppe eller justere responstid
  • Klart skille mellom AI-generert og menneske-skrevet innhold (transparens)

WCAG-kriterier som gjelder:

  • 1.1.1 Ikke-tekstlig innhold (A)
  • 2.1.1 Tastatur (A)
  • 2.2.1 Justerbar hastighet (A)
  • 3.3.1 Feilidentifikasjon (A)
  • 4.1.2 Navn, rolle, verdi (A)

Eksempel fra norsk offentlig sektor: Kommune-Kari (chatbot brukt av over 100 norske kommuner) har stemmebaserte tillegg planlagt for å gjøre kommunale tjenester mer tilgjengelige for eldre og personer med funksjonsnedsettelser.

2. Talegjenkjenning og taleteknologi

Krav:

  • Tekstalternativer til talekommandoer
  • Flerspråklig støtte (norsk bokmål, nynorsk, samisk)
  • Mulighet for å justere talehastighet og volum
  • Feilhåndtering som forklarer hva som gikk galt

WCAG-kriterier:

  • 1.2.1 Bare lyd og bare video (forhåndsinnspilt) (A)
  • 1.2.2 Teksting (forhåndsinnspilt) (A)
  • 1.2.4 Teksting (direkte) (AA)
  • 1.4.2 Lydkontroll (A)

Microsoft-verktøy:

  • Azure AI Speech (norsk språkmodell)
  • Copilot Studio (støtter tale-til-tekst)

3. Automatisk generert innhold (LLM/GPT)

Krav:

  • Logisk struktur (overskrifter, lister, avsnitt)
  • Forklarbar og forståelig output
  • Mulighet for å regenerere svar
  • Transparens om at innholdet er AI-generert
  • Etterprøvbarhet (kildehenvisninger)

WCAG-kriterier:

  • 1.3.1 Informasjon og relasjoner (A)
  • 2.4.6 Overskrifter og ledetekster (AA)
  • 3.1.5 Lesenivå (AAA, anbefalt)
  • 3.3.2 Ledetekster eller instruksjoner (A)

Best practice:

  • Azure OpenAI Service med Content Safety filters
  • Prompt engineering for klart språk
  • Kildeattribusjon via retrieval-augmented generation (RAG)

4. Visuell AI (bildegjenkjenning, dokumentanalyse)

Krav:

  • Alternativ tekst for AI-genererte bilder
  • Tekstbeskrivelse av visuell analyse (f.eks. ansiktsgjenkjenning)
  • Mulighet for høyere kontrast
  • Ikke krev farge alene som informasjonsbærer

WCAG-kriterier:

  • 1.1.1 Ikke-tekstlig innhold (A)
  • 1.4.1 Bruk av farge (A)
  • 1.4.3 Kontrast (minimum) (AA)
  • 1.4.11 Kontrast for ikke-tekstlig innhold (AA)

Microsoft-verktøy:

  • Azure AI Vision (Image Analysis, OCR)
  • Azure AI Document Intelligence (Form Recognizer)

5. AI-assisterte beslutningssystemer

Krav (EU AI Act 2026):

  • Transparens om AI-bruk (bruker må vite at AI er involvert)
  • Forklarbarhet av automatiserte beslutninger
  • Menneske-i-løkken (human-in-the-loop) for høyrisikosystemer
  • Mulighet for manuell overstyring

WCAG-kriterier:

  • 3.3.3 Forslag til feilretting (AA)
  • 3.3.4 Feilforebygging (juridisk, økonomisk, data) (AA)
  • 3.3.6 Feilforebygging (alle) (AAA)

Eksempel: En AI som anbefaler en tiltakspakke i NAV må vise begrunnelse og la saksbehandler kunne overstyre.

Krav til tilgjengelighetserklæring

Hvem må publisere tilgjengelighetserklæring?

Offentlig sektor (fra 1. februar 2023):

  • Alle nettsteder og apper
  • Må opprettes via Digdirs sentrale løsning uustatus.no

Innhold i erklæringen:

  • Konformitetsstatus (fullt, delvis, ikke)
  • Liste over kjente tilgjengelighetsproblemer
  • Dato for siste vurdering
  • Kontaktinformasjon for tilbakemeldinger
  • Link til klageinstans (UU-tilsynet)

For AI-løsninger må erklæringen inkludere:

  • Hvilke AI-komponenter som brukes (chatbot, talegjenkjenning, osv.)
  • Kjente begrensninger (f.eks. "Talegjenkjenning fungerer best på norsk bokmål")
  • Alternativ kontaktmetode (telefon, skjema)

Eksempel fra forskriften: Hvis en kommune bruker en AI-chatbot for saksbehandling, må tilgjengelighetserklæringen forklare hvordan brukere med skjermleser kan bruke chatboten, eller tilby en e-postbasert alternativ kanal.

Microsoft-verktøy for universell utforming av AI

1. Copilot Studio (Verified MCP 2026-06-19)

Oppdatert Copilot Studio-oversikt:

  • Copilot Studio er et grafisk, low-code verktøy for å bygge agenter og agent flows
  • Agenter kan nå håndtere komplekse samtaler og autonomt bestemme beste handling basert på instruksjoner og kontekst
  • Flows finnes nå i to format: agent flows (eksisterende, Power Automate-lignende) og Workflows (nytt format med revidert visuell designer, public preview); begge kan utløses manuelt, av automatiserte hendelser/agenter eller tidsplan
  • Plattformen bruker Azure OpenAI GPT-modell for AI-kapabiliteter
  • Retirement: Etter utgangen av juni 2026 kan ikke lenger Copilot Studio for Teams-appen brukes til å lage klassiske chatbots — makers omdirigeres til Copilot Studio-webappen

Innebygde tilgjengelighetsfunksjoner:

  • Authoring canvas bygget etter Microsoft accessibility guidelines
  • Støtter standard navigasjonsmønstre (tastatur, skjermleser)
  • ARIA-semantikk for adaptiv card rendering
  • Flerspråklig støtte (inkludert norsk)

Responsible AI-prinsipper implementert:

  • Fairness: Unngå demografiske attributter i prompts
  • Reliability and safety: Aldri autoskriv til Dataverse (human-in-the-loop)
  • Privacy and security: Pass kun minimum nødvendige felt
  • Inclusiveness: Støtt skjermlesere og høykontrast-modus
  • Transparency: Marker AI-generert innhold tydelig
  • Accountability: Mennesket tar den endelige beslutningen

For norsk offentlig sektor:

  • Publiser bot i Teams (WCAG-kompatibel kanal)
  • Aktiver Power Automate-integrasjon for alternativ tekstbasert saksflyt
  • Bruk Dataverse for logging (transparens)

2. Azure AI Speech

Norsk språkstøtte:

  • Bokmål (nb-NO)
  • Nynorsk (nn-NO)
  • Custom Speech for dialektvarianter

Tilgjengelighetsfunksjoner:

  • Real-time transcription (1.2.4 AA)
  • Speaker diarization (skille mellom talere)
  • Profanity filter og content moderation
  • Batch-transkripsjon for etterbehandling

3. Azure AI Vision

Automatisk alternativ tekst:

  • Image Analysis API (beskrivende bildetekster)
  • OCR (optisk tegngjenkjenning for skannede dokumenter)
  • Face API (anonymisert attributtgjenkjenning)

Compliance:

  • Innebygd content moderation (fjerner støtende innhold)
  • PII detection (personvernsbeskyttelse)

4. Azure OpenAI Service

Content Safety:

  • Automatisk filtrering av hatefullt språk, vold, seksuelt innhold
  • Jailbreak detection (motvirk prompt injection)
  • Groundedness detection (faktagrunnlag)

Tilgjengelighet:

  • Output formatting for strukturert innhold (markdown, HTML)
  • Citation tracking (kildehenvisninger)
  • System message for klart språk (f.eks. "Skriv på B1-nivå")

5. Power Platform AI

AI Builder:

  • Form processing med OCR (dokumentautomatisering)
  • Sentiment analysis (tekstanalyse)
  • Object detection (bildegjenkjenning)

Tilgjengelighetsfunksjoner:

  • Power Apps støtter skjermlesere (Narrator, JAWS, NVDA)
  • Tastaturnavigasjon uten mus
  • Høykontrast-modus

Praktiske anbefalinger for arkitekten

Vurderingspunkter ved AI-arkitektur

  1. Hvilken brukergruppe treffer løsningen?

    • Eldre (talegjenkjenning viktigere enn tastatur?)
    • Synshemmede (skjermleser-kritisk)
    • Kognitive utfordringer (språknivå, feilhåndtering)
    • Døve/hørselshemmede (teksting, visuell tilbakemelding)

  2. Hvilken kanal skal brukes?

    • Web (følg WCAG 2.1 AA fullt ut)
    • Mobilapp (iOS VoiceOver, Android TalkBack)
    • Teams (innebygd tilgjengelighet)
    • Kiosk/automat (fysisk tilgjengelighet)

  3. Hvilke WCAG-kriterier er mest relevante?

    • Chatbot → 2.1.1 (tastatur), 4.1.2 (ARIA), 2.2.1 (pause)
    • Stemmeassistent → 1.2.2 (teksting), 1.4.2 (lydkontroll)
    • Dokumentanalyse → 1.1.1 (alt-tekst), 1.4.3 (kontrast)
    • Generativ AI → 3.1.5 (lesenivå), 1.3.1 (struktur)

  4. Hvordan teste tilgjengelighet?

    • Automatisert: Axe DevTools, WAVE, Lighthouse
    • Manuelt: Tastaturnavigasjon, skjermleser (NVDA, JAWS)
    • Brukertesting med personer med funksjonsnedsettelser (påkrevd)

  5. Hvordan dokumentere i tilgjengelighetserklæring?

    • Hvilke AI-funksjoner brukes?
    • Kjente begrensninger (f.eks. språkstøtte)
    • Alternativ kontaktmetode
    • Oppdateringsdato (minst årlig)

  6. Hvilke Microsoft-verktøy støtter UU best?

    • Copilot Studio (innebygd WCAG-støtte)
    • Azure AI Services (API-basert, lett å integrere med tilgjengelig frontend)
    • Power Platform (Power Apps har sterkt fokus på UU)

  7. Hvordan sikre compliance ved anskaffelse?

    • Krev WCAG 2.1 AA i kravspesifikasjon
    • Be om VPAT (Voluntary Product Accessibility Template)
    • Test før aksept (UAT med brukere med funksjonsnedsettelser)

  8. Hvordan håndtere EU AI Act (2026)?

    • Transparens: Marker AI-generert innhold
    • Forklarbarhet: Vis hvordan konklusjoner ble nådd
    • Human-in-the-loop: Aldri fullt automatiserte beslutninger i høyrisikodomener (helse, rettsvesen, NAV)

Spesifikke scenario-spørsmål

Scenario 1: Kommunal saksbehandling-chatbot

Spørsmål til kunde:

  • Skal boten kunne motta dokumenter? (WCAG 1.3.1 — strukturert PDF)
  • Må den støtte samisk? (Språklov § 3-1)
  • Hva er prosedyren hvis AI feiler? (2.2.1 — pause, 3.3.1 — feilhåndtering)
  • Er saksbehandling høyrisiko? (EU AI Act — krev human-in-the-loop)

Anbefaling:

  • Copilot Studio med Power Automate fallback
  • Azure AI Speech for norsk talegjenkjenning
  • Dataverse-logging for transparens
  • Publiser i Teams (WCAG-kompatibel kanal)

Scenario 2: Automatisk dokumentanalyse (fakturaskanning)

Spørsmål til kunde:

  • Må blinde saksbehandlere kunne bruke løsningen? (1.1.1 — alt-tekst for scan-preview)
  • Hva skjer ved feilgjenkjenning? (3.3.3 — forslag til rettelser)
  • Er det nødvendig med manuell godkjenning? (3.3.4 — feilforebygging)

Anbefaling:

  • Azure AI Document Intelligence (Form Recognizer)
  • Power Apps-frontend med skjermleser-støtte
  • Human-in-the-loop ved lav konfidensverdi (<85%)

Scenario 3: NAV-veilederassistent (generativ AI)

Spørsmål til kunde:

  • Hva er lesenivået til målgruppen? (3.1.5 — skriv på B1-nivå)
  • Må AI vise kildehenvisninger? (transparens + WCAG 2.4.4 — lenkehensikt)
  • Skal løsningen kunne gi råd om økonomi? (3.3.4 AA — feilforebygging påkrevd)

Anbefaling:

  • Azure OpenAI Service med RAG (retrieval-augmented generation)
  • System message: "Skriv på B1-nivå, vis alltid kildehenvisninger"
  • Content Safety filters (PII-beskyttelse)
  • Copilot Studio for orkestrerering

Kilder og verifisering

Norske myndigheter

Microsoft dokumentasjon

Internasjonale standarder

Norsk offentlig sektor

For arkitekten: Dette dokumentet skal brukes når kunde nevner "tilgjengelighet", "universell utforming", "WCAG", "funksjonshemmede brukere", eller når løsningen er for norsk offentlig sektor (der UU er lovpålagt). Kombiner med eu-ai-act.md og norwegian-public-sector-ai-governance.md for helhetlig vurdering.