Hvordan forholde seg til uu i politiet?

Forskrift for universell utforming av IKT er et minimumskrav, som sikrer et basisnivå av tilgjengelighet. Det er lett å nedprioritere dette arbeidet og begrunne det med at det krever ekstra kostnader og resurser som man ikke har mulighet til avsette. Det at team ikke følger kravene, men heller finner opp noe eget bidrar til bortkastet tid og tyder på manglende kompetanse i teamet. Å sikre de lovpålagte kravene krever at hele teamet har kunnskap om hva disse kravene er og hva det krever av dem å levere på dem. Når denne kompetansen er på plass vil ikke temaet lenger bruke ekstra tid, det inngår i vanlig produktutvikling og er en hjelp til å sikre god brukervennlighet. Det er også et krav om at eksterne løsninger skal levere og kontinuerlig holde tilgjengelighetserklæringen sin oppdatert. Minimumskravet er at erklæringen skal oppdateres en gang i året.  

Selv om alle teknisk sett kan bruke noe, er det ikke alltid brukeropplevelsen er god. Skal vi få til virkelig inkluderende tjenester, må vi derfor tenke på mer enn bare WCAG og forskriften. Vi må brukerteste, ha bred brukerinnsikt og aktivt jobbe med språk og brukeropplevelse. Vi må sikre at også innbyggere som ikke kan eller ønsker å benytte seg av digitale løsninger får hjelp til de tjenestene de har krav på. Vi må se på hele brukerreiser på tvers av det fysiske og digitale. Det bør sjekke hvordan opplevelsen er for brukere med sammensatte behov, slik at vi unngår kryssdiskriminering.  

Interne systemer er per i dag ikke omfattet av Forskriften for universell utforming av IKT. Her gjelder det istedenfor rett til individuell tilrettelegging. I realiteten ser vi at individuelle tilpasninger er vanskelig å oppnå, og ofte blir nedprioritert med argumenter som går på kostnader og merarbeid. Hvis vi ikke tenker på uu og teknisk tilgjengelighet når vi lager interne systemer, risikerer vi derfor at kollegaer som bruker hjelpemidler eller har situasjonsbetingede/midlertidige funksjonsnedsettelser ikke lenger kan utføre jobben sin optimalt. Det blir også vanskelig for politiet å være en inkluderende arbeidsplass. Nye løsninger må derfor fungere sammen med hjelpeteknologi og være i tråd med forskriften så langt det er mulig - og eldre løsninger skal oppgraderes så fort som mulig. 

Det vil etter hvert bli pålagt også med universell utforming på interne løsninger og da er det bedre og mer økonomisk å være i forkant. Det koster mer å oppgradere en eksisterende løsning enn å gjøre dette fra starten av. En godt universell utformet løsning vil kunne gi alle en mer brukervennlig og effektiv hverdag.  

Internsystemer brukes ikke bare av ansatte i politiet på kontor men i tillegg ute i patrulje. Her gjelder igjen viktigheten av å følge prinsipper for uu, slik at løsningene imøtekommer behov som er situasjonsbetingede. Eksempelvis kan det være behov i patruljebil for lavere kontrast når løsningen brukes i skumring eller mørk modus, for å ivareta HMS. Politiet jobber under svært ulike og til tider krevende forhold, der noen brukere møter dårlig vær, som regn og snø eller sterkt sollys. Andre faktorer som spiller inn på teknologien vi utvikler er temperaturen og fart.

Krav for interne løsninger

Krav for universell utforming av interne løsninger som ikke er omfattet av loven, gjelder for alle løsninger som enda ikke er lansert. For alle andre løsninger skal man innen utgangen av 2025, oppfylle de krav som til enhver tid er gjeldende.  

Løsninger utviklet eller levert av politiet skal i utgangspunktet etterstrebe å oppfylle de samme krav som publikumsløsninger. Politiets designsystem inneholder en anbefaling for universell utforming i interne løsninger. Interne løsninger bør følge disse kravene og føringene, hvor noen av kravene i listen kan vurderes opp mot begrensninger i målgruppen. Det betyr at man kan gjennomføre en konsekvensvurdering, hvis brukergruppen er tydelig avgrenset ved at produktet kun brukes av en spesifikk målgruppe med formelle krav i stillingen, eller i brukskontekst med spesielle behov 

Et virkemiddel som kan benyttes i alle team er å stille spørsmål om hvem som blir ekskludert til enhver tid i utviklingsprosessen, for å skape bevisstgjøring og potensielt avdekke brukergrupper som ekskluderes underveis i stedet for å oppdage dette langt ut i en prosess. På den måten kan utviklingsteam jobbe mer bevisst med uu og sikre at brukerne blir ivaretatt i høyere grad. I et team vil de ulike rollene ha ulikt ansvar knyttet til universell utforming, les punktlisten under for mer informasjon om hvordan universell utforming treffer de ulike fagområdene i Politiets IT-enhet. Universell utforming er ikke et valgfag. Alle fagdomener berøres på ulik måte av uu og har til felles at de må overholde minste-kravene for WCAG 2.1. Fagdomenene i PIT er ingen unntak og må forholde seg til lovverket på lik linje med andre aktører. 

Designsystemet bidrar positivt

Et annet virkemiddel for å ivareta universell utforming i større grad er at team benytter seg av designsystemet i politiet. Designsystemet Sheriff er under stadig endring og dets oppgave er å ivareta uu i komponenter. Her vil teamene få mye gratis i forhold til å imøtekomme uu-krav og spare ressurser på manuelt arbeid i utviklingen av nye komponenter. Det er fortsatt manuelt arbeid som kreves i team i forhold til å etterleve alle uu-krav, brukerteste mangfoldige brukergrupper og ha et bevisst forhold til uu i utviklingsprosessene. 

Eksempel på økt fokus på uu i et team

Et eksempel fra et team i PIT som har jobbet med universell utforming er Team Anmeldelse. Alle i teamet tok kurset til DFØ om universell utforming for å øke kompetansen på området. I etterkant avdekket teamet flere feil som de nå har rettet opp i og jobber kontinuerlig med fokus på universell utforming av løsningen, uten å bruke mengder med ressurser på det grunnet økt kunnskap. 

Kostnader knyttet til universell utforming er i stor grad knyttet til manglende kompetanse i utviklingsteam og prioriteringer fra en organisasjon. Erfaringer fra blant annet NRK og NAV tilsier at teamene som har tilstrekkelig kompetanse minsker ekstrakostnader med universell utforming i utviklingen fordi det inkluderes som en naturlig del av prosessen.

For utvikling er det viktig både med teknisk forståelse av kravene, men også forståelse for de kvalitative delene. Erfaring viser at man kan implementere teknisk uten feil, men allikevel ikke oppfylle kravene fordi opplevelsen for noen brukergrupper blir ulogisk og gir dårlig brukeropplevelse. For design er det viktig å være oppmerksom på både tekniske krav, og jobbe fra starten av med gode brukeropplevelser. For produktledelse må det være på plass en grunnleggende kunnskap, slik at verdien blir prioritert inn allerede fra start.  

Ved feilretting i retroperspektiv, kan man raskt ende opp med å måtte gjøre om på kode eller design, som vil være unngått om man jobber tverrfaglig med universell utforming fra starten av. Universell utvikling gjør løsninger bedre for alle å bruke, og øker kvaliteten både på kode og design. I PIT mangler vi kompetanse. Bare en liten del av teamene har medlemmer som har erfaring med WCAG 2.1 og WAD-direktivet.  

I kompetanseprofilen til produkteier, også kalt produktleder, står det beskrevet som en av oppgavene å sørge for etterlevelse når det kommer til lover, regler og pålegg. Det betyr at produkteier skal sørge for å følge opp hvordan teamet imøtekommer krav til universell utforming, da dette er knyttet til lovverket. Ta eierskap til kravene og vær med teamet på å avdekke eventuelle problemer, foreslå løsninger og få oversikt over tilstanden til ditt produkt. Start først med å samsvare til de laveste kravene, før man går løs på de høyere standardene. 

Å jobbe med kravene skal utføres på lik linje med andre arbeidsoppgaver. Tidligere har dette hatt en tendens til å komme sist i rekken selvom det er like viktig som resten av brukeropplevelsen. Kompetansedagene kan være et fint tidspunkt å jobbe med universell utforming og tilgjengelighet, hvis man kjenner at tiden ikke strekker til i hverdagen. Her kan man eksempelvis bruke tid som team på å sette seg inn i uu-krav og gå gjennom tjenesten teamet leverer for å se hvordan man egentlig svarer på kravene. Når teamet har skaffet oversikt vil det være lettere å lage spesifikke oppgaver for å rette opp i evenetuelle feil og mangler.  

Det finnes også kurs-videoer om universell utforming hos uutilsynet og andre nettbaserte kurs for ulike roller i et team, les Ressurser og nyttige lenker. Vær med på å ta kurs om universell utforming sammen med resten av teamet.  

Som utvikler er man nødt til å bygge løsningen slik at den samsvarer til lovens krav. Det er mange enkle grep du kan gjøre for å få bedre kontroll på universell utforming i applikasjonene du har ansvar for. Her kommer noen forslag som skal hjelpe deg i gang, i tilfeldig rekkefølge: 

• Forstå WCAG sin intensjon, prinsipper, suksesskriterier, teknikker for å oppfylle kriteriene og teste dem.
• Gjennom å lese WCAG-standarden, les gjerne seksjonen om WCAG for utviklere.
• Gjennom å teste applikasjonen mot standarden, uutilsynet har en god guide for dette.
• Gjennom å ta DFØ sitt kurs i Universell utforming.
• Sjekke applikasjonen din selv etter enkle feil med verktøy som Lighthouse, axe-core eller annet.
• Sette opp verktøy for å avdekke feil i koden.
• Statisk analyse av HTML og se at det samsvarer med HTML 5 standarden.
• Statisk analyse av koden som danner HTML til sluttbruker.
• Sette opp automatiske tester som sjekker at kravene til UU er oppfylt innenfor teamets kontekst.
• Skrive komponenter som samsvarer til krav og gjenbruke det i løsningen. 

Vi må også samarbeide godt med design rundt løsningen, slik at vi kan sikre at løsningen ikke bare ser bra ut og er enkel å bruke, men også at den lar seg implementere, samtidig som vi overholder alle tilgjengelighetskrav. 

Det er mange tilgjengelighetskrav som er et “ja”/ “nei” spørsmål. Med god bruk av verktøy for å kvalitetssikre løsningen, vil vi kunne raskt og effektivt bidra inn i arbeidet med å få kontroll på tilgjengelighet i våre løsninger. Det er også en gevinst når hele teamet har tillit til verktøyene vi bruker tidlig i utviklingsprosessen, da man slipper å måtte bruke tid på å gjenoppta arbeid allerede testede krav og kan fokusere på de kravene som er litt mer opp til tolkning. Når det gjelder kravene som er opp til tolkning, bør utviklere være med i dette arbeidet også, for å få en bedre forståelse av hva som skal implementeres og hvordan vi skal kvalitetssikre dette. 

Som nevnt over, er det mange grunner til at utviklere er nødt til å delta og bidra inn i kvalitetssikringen i forholdt til universell utforming. Andre motivasjoner bak å jobbe med universell utforming som utvikler: 

• Kortere utviklingstid.
• Feilmeldinger kan komme mens man utvikler, så man slipper å fikse ting i etterkant.
• Slipper overrekkelsen av sluttresultatet til noen andre for å motta en dårlig rapport.
• Det går raskere å bruke mulighetene i semantisk korrekt html enn å finne på noe eget, som f. Eks dialog-elementet burde brukes i stedet for å lage en egen modal.
• Yrkesstolthet og håndverk, vi vil ikke lage noe som er dårlig.
• Det står i loven, og siden vi er de som skriver disse applikasjonene, så gjør vi ikke jobben vår hvis vi ikke gjør det skikkelig og passer på at det gjøres skikkelig.  

Design sin oppgave i et team er å sikre brukerorientert utvikling og ivareta brukeropplevelsen. Underveis i dette arbeidet er det viktig å forstå hvordan man kan ivareta universell utforming. Det finnes mange resurser på nett for å ivareta dette, både veiledere og konkrete verktøy. Her er en liste over noen av dem: 

• Veileder fra Tilsynet for universell utforming  
• WebAIM kontrastsjekker
• Designing for Accessibility

En designer har ansvar for å fasilitere brukertester og lage gode spørsmål brukerne kan svare på. Teamene sammen utfører brukertester for å få felles forståelse av hvem brukerne er, og hva de har behov for. Brukertesing av mangfoldige brukergrupper er essensielt i arbeidet med universell utforming, både når det gjelder innbyggertjenester, men også interne systemer. Politiet kan til tider operere under krevende forhold og kan ha behov for tilpasninger. Designere må blant annet forholde seg til krav relatert til motorikk og klikkflater når de utformer navigasjonskonsept, skjema og arbeidsflyt. I tillegg er det viktig at de diskuterer med utviklerne hva som er teknisk mulig å få til.