Guider
Universell utforming i IKT-anskaffelser: fra krav til akseptanse
Slik stiller du målbare krav til universell utforming i en IKT-anskaffelse – med dokumentasjon, testmiljø, akseptansekriterier og kontraktsoppfølging.
Av Eivind Pihl Martinsen, Synli.aiSist oppdatert 1. september 2026
Det dyreste tidspunktet å oppdage utilgjengelig IKT på er etter at løsningen er valgt, konfigurert og tatt i bruk. En formulering om at leveransen «skal være i samsvar med WCAG» hjelper lite dersom konkurransegrunnlaget ikke angir hvilke deler av løsningen som omfattes, hvilken standard og versjon som gjelder, hvilken dokumentasjon som kreves, hvordan leveransen skal testes, eller hvilke følger manglende oppfyllelse får.
Fem trinn må henge sammen
- RegelgrunnlagAvklar lov, forskrift, sektor, løsningstype, brukere og eventuelle unntak
- KravspesifikasjonNavngi standard, versjon, funksjoner, brukeroppgaver og dokumentasjon
- TilbudsevalueringEtterprøv påstander, avvik, kompetanse og tilgang til tilbudt løsning
- AkseptansetestTest representativ konfigurasjon, innhold, roller, integrasjoner og hjelpemidler
- KontraktsoppfølgingKrev regresjon, oppdatert dokumentasjon, utbedring og varsling ved endringer
DFØs mal gjør tre viktige ting: den krever at løsningen oppfyller gjeldende krav ved levering, at oppdateringer også skal være universelt utformet, og at leverandøren skal tilby dokumentasjon som alltid er tilgjengelig for kunden. Det er et godt minimum, men hver anskaffelse trenger i tillegg et konkret omfang og en testbar akseptanse.
Kravmatrise du kan tilpasse
| Tema | Eksempel på krav | Dokumentasjon i tilbudet | Akseptanse og oppfølging |
|---|---|---|---|
| Regelverk og standard | Løsningen skal oppfylle avtalte krav i relevant forskrift og avtalt standard for løsningstypen, med angitt versjon og relevante WCAG-kriterier. | Kravmatrise med status per punkt, standardversjon, metode, dato og ansvarlig vurderer. | Oppdragsgiveren tester et avtalt utvalg og avviser udokumenterte generelle påstander. |
| Omfang | Kravene gjelder alle tilbudte moduler, maler, komponenter, roller, integrasjoner og representative brukeroppgaver. | Liste over inkludert og utelatt funksjonalitet, konfigurasjon, versjon og begrunnede avgrensninger. | Akseptansetesten bruker den tilbudte konfigurasjonen, ikke bare en forenklet demonstrasjonsside. |
| Innlogging | Viktige brukerforløp som krever vanlig innlogging, SSO eller MFA skal kunne brukes og testes med avtalt testrolle. | Beskrivelse av roller, innloggingsløsninger som støttes, tidsavbrudd og tilgjengelig autentisering. | Oppdragsgiveren får testkontoer og ufarlige testdata, og fremkaller feil- og utløpstilstander. |
| Hjelpemidler | Leverandøren skal oppgi og støtte avtalte kombinasjoner av hjelpemiddel, nettleser og operativsystem. | Navn og versjoner, testresultater, kjente begrensninger og plan for kompatibilitetsendringer. | Representative oppgaver verifiseres med avtalte kombinasjoner før godkjenning. |
| Testmiljø | Oppdragsgiveren skal ha tilgang til et representativt miljø med relevante roller, moduler og testdata. | Tilgangsplan, miljøforskjeller, dataoppsett og kontaktpunkt for teknisk bistand. | Miljøet skal være tilgjengelig i tilbudsevaluering, akseptanse og avtalt kontraktsoppfølging. |
| Kjente avvik | Alle kjente avvik skal oppgis med berørt funksjon, konsekvens for brukerne, WCAG-kobling og rettingsplan. | Prioritert avviksliste med versjon, omfang, midlertidig tiltak, ansvar og dato. | Oppdragsgiveren angir hvilke avvik som blokkerer levering, og følger opp avtalte frister. |
| Oppdateringer | Nye versjoner og vesentlige endringer skal fortsatt oppfylle avtalte tilgjengelighetskrav. | Regresjonsstrategi, endringslogg og oppdatert kravmatrise ved relevante oppdateringer. | Oppdragsgiveren kan kontrollere endringene. Nye avvik skal utbedres innen avtalte frister, og avtalte reaksjoner kan brukes ved mislighold. |
| Kompetanse | Leverandøren skal ha tilgjengelig kompetanse til å designe, utvikle, teste og rette løsningen. | Roller, erfaring, metode, opplæring og hvordan kompetansen brukes i leveransen. | Navngitte roller deltar i oppstart, avviksvurdering og relevante endringer. |
Be om bevis, ikke bare et ja
SSBs publiserte leverandørkrav viser hva konkret dokumentasjon kan innebære: EN 301 549, WCAG 2.1 A og AA, W3C-sjekkliste eller en oppdatert ACR basert på VPAT, navngitte kombinasjoner av hjelpemiddel, nettleser og operativsystem, tilgang til testmiljø med testdata, prioritert avviksplan og dokumentert kompetanse.
- Krev dato, produktversjon, konfigurasjon og presist testomfang for hvert dokument.
- Be om metoden og utvalget bak statusen, ikke bare en prosent eller et samsvarsmerke.
- Skill leverandørens egenvurdering fra uavhengig test og oppdragsgiverens akseptansetest.
- Krev konkrete forklaringer på delvis støtte, krav som ikke er relevante, og kjente brudd.
- Sørg for at dokumentasjonen kan oppdateres og alltid er tilgjengelig gjennom kontraktsperioden.
Gjør akseptansetesten etterprøvbar
En akseptansetest bør bruke et forhåndsdefinert, representativt utvalg av sider, komponenter, roller og oppgaver. Testmiljø, testdata, nettlesere, hjelpemidler og ansvar for godkjenning bør være beskrevet i konkurransegrunnlaget. Da vet leverandørene hva som skal dokumenteres, og oppdragsgiveren kan gjenta testen etter retting eller oppdatering.
- Kartlegg brukergrupper, kritiske oppgaver, innholdstyper, roller, enheter og integrasjoner.
- Koble hvert krav til dokumentasjon og en konkret test eller kontrollhandling.
- Definer hvilke avvik som blokkerer aksept, hvilke som kan få frist, og hvem som kan godkjenne unntak.
- Kjør automatisk og manuell testing på samme avtalte versjon og konfigurasjon.
- Registrer funn med dokumentasjon, konsekvens, ansvar og resultat fra ny test – uten å bruke verktøyets poengsum som eneste grunnlag for kontraktsmessig godkjenning.
- Gjenta relevante tester ved oppgraderinger og vesentlige endringer gjennom avtaleperioden.
Et eksempel fra Doffin
En kunngjort konkurranse i 2026 med anslått verdi på 2,2 millioner kroner ba om automatisert WCAG-overvåking av både åpne og innloggede sider, støtte for 48 erklæringskriterier og funksjoner for innhold, SEO, AEO og KI-synlighet. Resultatkunngjøringen oppgir to mottatte tilbud.
Hva Synli kan bidra med i anskaffelsen
En leverandør kan bruke Synli til å finne og strukturere WCAG-knyttede funn før tilbud og levering. En oppdragsgiver kan bruke samme type skanning til å kontrollere et representativt testmiljø og følge regresjoner. Rapporten gir sporbar dokumentasjon og utbedringsforslag for det verktøyet faktisk har undersøkt.
Kontrollspørsmål før konkurransen publiseres
- Har vi brukt dagens lov- og forskriftshenvisninger, og avklart særregler for løsningen?
- Er standard, versjon, løsningstype, moduler, roller og brukeroppgaver entydige?
- Vet leverandøren nøyaktig hvilken dokumentasjon som skal følge tilbudet?
- Får vi tilgang til representativ løsning, innlogging, testdata og relevante hjelpemidler?
- Er kjente avvik, prioritering, rettingsplan og ansvar en del av tilbudet?
- Er akseptansekriterier, krav til ny test etter retting, frister, kontrollrett og reaksjoner skrevet inn i kontrakten?
- Gjelder kravene også oppdateringer og vesentlige endringer gjennom hele avtaleperioden?
Spørsmål og svar
Må offentlige oppdragsgivere stille krav til universell utforming?
Anskaffelsesloven § 5 n slår fast at oppdragsgiver skal stille krav til universell utforming. Plikten er videre spesifisert i anskaffelsesforskriften § 15-2 og forsyningsforskriften § 11-2. Virkeområde, anskaffelsestype og eventuelle særregler må vurderes konkret.
Hvilken standard bør en IKT-anskaffelse vise til?
DFØs gjeldende IKT-mal viser til forskriften og EN 301 549 v3.2.1 (2021-03) for nettløsninger, med WCAG 2.1 som eksempel på krav som skal dokumenteres. Kravgrunnlaget må tilpasses løsningstype, sektor og den versjonen som faktisk gjelder ved leveransen.
Er en ACR basert på VPAT nok som dokumentasjon?
Nei, ikke alene. En oppdatert Accessibility Conformance Report (ACR), for eksempel utarbeidet med en VPAT-mal, kan være nyttig leverandørdokumentasjon. Oppdragsgiveren bør også kreve testomfang, metode, versjon, kjente avvik, støttede hjelpemidler og tilgang til et representativt testmiljø. Påstander bør kunne etterprøves i den tilbudte konfigurasjonen.
Kan en automatisk WCAG-skanning avgjøre om leveransen skal godkjennes?
Ikke alene. Automatisk testing kan dokumentere resultatene fra repeterbare kontroller som verktøyet støtter, og bidra i regresjonstesting. Akseptansetesten må også omfatte manuell testing, representative brukeroppgaver, bruk av hjelpemidler, avtalte avvik og forhold skanneren ikke kunne nå eller vurdere.
Hvordan sikrer kontrakten at oppdateringer forblir tilgjengelige?
Kravene bør gjelde hele kontraktsperioden, ikke bare leveringsdagen. Avtal dokumentasjon ved vesentlige endringer, regresjonstesting, tilgang til testmiljø, frister for avvik, ansvar, rapportering, kontrollrett og egnede reaksjoner ved mislighold.