Kva vi snakkar om når vi snakkar om universell utforming i anskaffingar

Når offentlege verksemder kjøper eksterne tenester og nettløysingar, skal dette skje innanfor rammene av lov og forskrift om offentlege anskaffingar (LOA/FOA). Private verksemder står på si side friare når det kjem til korleis avtalen blir til. Når det kjem til universell utforming er likevel både private og offentlege verksemder omfatta av tekniske krav i WCAG 2.0 (private) og WCAG 2.1 (offentlege).

For å unngå nettløysingar som ikkje alle kan bruke, og som ikkje oppfyller krava i gjeldande regelverk, er det avgjerande at du er grundig i innkjøpsprosessen. Dette gjer seg gjeldande på same måte om du anskaffar hyllevare eller skreddarsaum, men måten du stiller krav på må gjerne tilpassast til om du spekkar for noko som allereie eksisterer eller om det er eit utviklingsprosjekt. Dei same prinsippa gjer seg også gjeldande for kravstilling til utvikling som skjer i eigenregi.

Du må ha kunnskap om behova og krava

Når eg held føredrag om krava til universell utforming av ikt brukar eg ofte eit sitat frå Christopher Patnoe, som er head of accessibility and disability inclusion i Google:

Eit innkjøpsprosjekt er gjerne sett saman av ulike fagekspertar. Det kan vere ein systemeigar som er oppteken av faglege krav og oppetid, ein innkjøpsekspert med fokus på dokumentasjon og det innkjøpsjuridiske, ein økonomiansvarleg som held i kostnadskontroll og innsparingar, ein personvernrådgjevar som brenn for sikker lagring og dataminimering, for å nemne nokon. I ei slik prosjektgruppe er det sjeldan nokon som har særleg ansvar eller kunnskap om universell utforming. Dette aukar risikoen for at universell utformin fell mellom stolar.

Før eg tok til å jobbe i Digdir var eg sjølv i ei rekkje år juridisk ansvarleg for ulike anskaffingar, og må berre innrømme at universell utforming av ikt ikkje var det eg hadde fremst i pannebrasken. Anskaffingar er komplekst, og det er eit hav av formelle rammer å halde styr på. Derfor er det avgjerande å ha eit rammeverk som «tvingar» alle prosjekt til å ta stilling til om ulike krav, slik som universell utforming, er aktuelle. Dette gjer ein for eksempel gjennom sjekklister og at det alltid er nokon som har særleg ansvar for dei ulike punkta på lista.

På denne måten får prosjektet ei påminning om at dette er vesentleg og kva dei må leggje vekt på. Hugs likevel at samsvar med krav alltid er eit samspel mellom fleire fag.

Tenk på behov framfor løysing

Som så ofte elles må ein starte med det første først: Kva behov skal anskaffinga løyse?

Det bør ikkje vere naudsynt å presisere at krava i ei anskaffing skal vere objektive, men det er ikkje til å kome unna at mange anskaffingar diverre er rigga. Éin ting er at det ikkje er lov for offentlege verksemder, men det er ofte heller ikkje ei løysing som er eigna for å møte verksemdas eigne behov. Når ein forelskar seg i éi løysing blir ein samstundes blind for andre. Dette øydelegg ikkje berre konkurransen, det hindrar også i ytste tilfelle at brukarane får den beste løysinga. Vidare kan slik rigging få følgjer for kontraktsoppfølginga i form av at ein i for lita grad avtalefestar det som objektivt sett er viktig i avtalen.

Spør deg sjølv om dette

I vurderinga av behovet er det nokre nøkkelspørsmål du må stille deg:

• Kva vil du oppnå med nettløysinga?
• Kven er brukarane og kva behov har dei?

Kravstillinga skal balansere kva du ynskjer å oppnå med kva som er mogleg å oppnå. Det er mykje ein gjerne ynskjer, men det hjelper ikkje viss ikkje marknaden kan tilby det. Derfor står marknadsdialog og -kartlegging sentralt.

Sjølv om det i utgangspunktet ikkje er noko i vegen for å gjennomføre marknadsdialog er det mange oppdragsgjevarar som kvir seg for dette i frykt for skuldar om rigging og at dialogen har gjort einskilde aktørar betre rusta for konkurranse. Det avgjerande i marknadsdialog er å vere ryddig og open om kva informasjon ein gir, ikkje røpe leverandøranes forretningsløyndomar og unngå at leverandørane får ein fordel. Sjå meir om rammene på DFØs temaside om marknadsdialog.

Kravspesifikasjon

Når ein har funne ut av behovet, må dette skrivast ned i kravspekken. Her er det vanleg å skilje mellom skal-krav og bør-krav.

I utgangspunktet kan ein ikkje kompromisse på minstekrav. Dei tekniske minstekrava som kjem av forskrift om universell utforming av ikt må derfor vere skal-krav. Krava må gjelde heile løysinga, inkl. funksjonar og innhald som er integrert (embedda) frå tredjepartar. Kravspekken bør også seie noko om kva tid krava skal vere oppfylte – dette er særleg aktuelt i vidareutvikling av eksisterande løysingar og innovative anskaffingar.

Innebygd funksjonalitet for å motverke at ein lagar nye uu-feller er derimot ikkje eit krav, sjølv om det kan ha mykje føre seg. Dette kan då vere eit bør-krav.

Merk at det kan vere lurt å gje føringar for kva ein legg i «vesentlige avvik frå anskaffelsesdokumentene», jf. FOA §§ 9-6 og 24-8, viss ein mistenkjer at det er skal-krav som vanskeleg let seg gjere å oppfylle.

Evaluering av tilbod

Evalueringa kan vere krevjande – særleg viss det er mange tilbod. Vidare veit vi at ein ikkje utan vidare kan leggje til grunn lovnadane leverandørane kjem med knytt til samsvar med tekniske minstekrav. Eit triks her kan vere å be leverandøren demonstrere korleis løysinga møter dei ulike tekniske krava.

Gjer ein jobben grundig her, kan dette spare deg for mykje arbeid seinare knytt til avtalebrot frå leverandøren.

Avtale

Det er i avtalen du låser dine og leverandørens rettar og plikter. Derfor skal kravspekken, leverandørens løysingsskildring og anna som forpliktar partane, inn som vedlegg til avtalen. I tillegg gir avtalen, typisk Statens standardavtalar, eit rammeverk for rettar, plikter, sanksjonar, konflikthandtering, heving osb. Merk likevel at det oftast er nødvendig å sjølv aktivt ta krava til universell utforming inn i kontrakten. Det er også føremålstenleg å ta inn ei ansvarsmatrise som tek føre seg kven har ansvar for kva gjennom avtaleperioden. Ein kan typisk sjå føre seg ulikt ansvar for det tekniske rammeverket (leverandøren), innhaldet (oppdragsgjevar) og tekniske oppdateringar (leverandøren).

Her bør ein også gje føringar for korleis ein skal gjennomføre akseptansetesting ved levering. Vidare kan ein tenkje seg føringar for å ta ein årleg digital helsesjekk på løysinga som dannar grunnlaget for feilretting og data til tilgjengelegheitserklæringa.