Slik jobber vi med universell utforming hos NAV

Har du noen gang jobbet i et prosjekt hvor en ikke har brydd seg noe særlig om universell utforming før i sluttfasen, og kjent på smerten det medfører? Eller har du kanskje vært den som har blitt kalt inn i innspurten av et prosjekt for å sjekke om en er “innafor kravene”, som det heter, for så å peke på eventuelle feil og mangler? Jeg mener, klok av skade, at den måten å jobbe på er grunnleggende feil og at det er både kjedelig og lite motiverende for alle involverte.

Du har sikkert hørt noen snakke om at det er lurt å tenke på universell utforming fra starten av et prosjekt, men hvordan gjør en det i praksis? I denne bloggposten vil jeg se litt på hvordan vi jobber med universell utforming på tvers av flere team hos NAV, og hvordan vi har forbedret oss på det fra prosjekt til prosjekt.

Hos NAV er vi flere team som jobber med flere forskjellige, men likevel nokså like, prosjekter. I det siste har det for eksempel vært jobbet med digitalisering av forskjellige søknader, som foreldrepengesøknad og søknad om bilstønad. I 2014 lanserte vi også nye nav.no. Sjekk gjerne ut tekniske detaljer om tilgjengelighet på nav.no.

'Stønad til kjøp av motorkjøretøy, skjermbilde'
Skjermbilde fra den digitaliserte søknadsdialogen for “Stønad til kjøp av motorkjøretøy”, som ble lansert i 2015.

Problemer vi har opplevd

Til tross for at vi har prøvd å ta hensyn til universell utforming gjennom hele prosessen, har vi likevel slitt med en del feil som ikke har blitt avdekket før helt på tampen i akseptansetest. Mange av feilene har vært de samme fra prosjekt til prosjekt. For å finne frem til noen grep vi kunne ta for å forbedre oss, ble feilene analysert og kategorisert. Vi fant følgende årsaker til at de oppstod:

  • For liten forståelse for, og manglende fokus på universell utforming under både design og utvikling
  • Like komponenter har blitt laget på ulike måter i forskjellige prosjekter, noe som har gjort dem lite konsistente. Derfor har det også vært vanskelig å oppdage feil
  • Liten kjennskap til IKT-hjelpemidler, og manglende tilgang til skjermleseren JAWS
  • For liten grad av profesjonell testing underveis i prosjektet. Alt fanges ikke opp i brukertest
  • En del feil relatert til universell utforming har blitt fikset av eksperter, uten at andre har lært av det

Feil løsning på feil problem

Når feil dukker opp i tolvte time har en som regel veldig dårlig tid. Noen av de som har vært med i prosjektet har kanskje allerede startet på et nytt prosjekt. En kortsiktig løsning har da noen ganger vært at feilene har blitt satt til eksperter, for å få de unna, uten at andre nødvendigvis har lært av det. I neste prosjekt har de samme feilene dukket opp igjen, og en har fått en ny runde feilhåndtering og støy på grunn av de samme tingene. Dette får ikke akkurat universell utforming til å “fly” i prosjektet. Det oppleves mer som at en går inn i en slags flatspinn, som er vrien å rette opp om en er for mye bakpå.

Det kan oppleves som frustrerende å måtte plukke fra hverandre det en har laget for å gjøre tilpasninger i etterkant, og i noen tilfeller kan slik feilfiksing og “ettermontering” av universell utforming innebære relativt heftig refaktorering. Jeg tror det er mye av årsaken til at noen kanskje ser på universell utforming som et slags hårete beist en helst ikke vil ha noe med å gjøre. Feil innstilling og liten forståelse for det hele er sånn sett en uheldig kombinasjon.

Så hva ble løsninga?

Grep vi har tatt

Vi har jobbet aktivt med å øke kompetansen og å få på plass en mer riktig, fremoverlent holdning til universell utforming på tvers av teamene. For å kunne jobbe effektivt og samtidig lage universelt utformede løsninger, må en forstå hvorfor universell utforming er viktig. En må vite noe om hvem brukerne er og hvilke behov for tilrettelegging de har. En må vite noe om hvilke IKT-hjelpemidler som finnes og hvordan de fungerer, og samtidig også vite noe om hvordan en kan teste løsningene sine selv.

Universell utforming av IKT koker egentlig bare ned til godt håndverk. Det er kunsten å gjøre den digitale brukeropplevelsen best mulig for flest mulig.

Apropos digitalt; det digitale har potensial til å bryte ned barrierer mange ellers møter i det fysiske rom. Akkurat det har en enorm samfunnsverdi, og må selvfølgelig utnyttes! Og hvem vil ikke ha flere, mer fornøyde og selvhjulpne brukere?

Tilgang til relevante hjelpemidler

Mange feil har vært relatert til skjermleseren JAWS. JAWS er den mest brukte skjermleseren (på desktop) blant blinde og svaksynte, men den har en lite utviklervennlig og dyr lisens. Brukskvalitetsteamet hos NAV IKT, som har som rolle å være “vaktbikkje” for etterleving av NAVs krav til universell utforming, tester løsningene våre i blant annet JAWS. Vi har likevel opplevd det som lite effektivt å ikke kunne verifisere de enkle tingene selv. Derfor fikk enkelte utviklere i forskjellige team utdelt JAWS-lisenser, hvorpå antall feil sank betraktelig. Det ble enklere å skjønne hva som forårsaket problemer, og hvordan det kunne løses.

Det skal nevnes at JAWS ikke er den eneste skjermleseren vi tester med, og at en ofte kommer langt med å bare teste i andre skjermlesere i stedet. De har alle sine sine særegenheter, og det gjelder i høyeste grad også JAWS. En må uansett fortsatt ha ekspertbrukere, som kjenner de forskjellige skjermleserene godt, til å gjøre mer omfattende testing.

I prosjekter hvor en ikke har noen som kan gjøre grundig testing med skjermleser og andre hjelpemidler, eller om en på andre måter trenger hjelp til å komme ordentlig igang med universell utforming, så kan for eksempel Norges Blindeforbund være et bra sted å starte. BEKK har ved flere anledninger samarbeidet med blindeforbundet, noe som har skapt både engasjement og entusiasme.

Parkinson-simulator

Et annet eksempel på hvordan vekke engasjement rundt universell utforming, er å lage en “Parkinson-simulator”! Det har en av de mer oppfinnsomme i brukskvalitetsteamet til NAV gjort. Simulatoren er laget ved hjelp av en 3D-printer, en elektrisk motor og et fiskelodd. Motoren driver fiskeloddet rundt i en boks, og skaper dermed et dreiemoment. Når en fester denne boksen på håndleddet, og slår den på, så har en ikke sjans til å holde hånda i ro. Det blir litt som om en hadde Parkinson. Å føle det på kroppen selv, gjør at en i større grad skjønner hensikten med noen av de grepene som tas. Hvordan tror du treffsikkerheten på veldig små trykkflater blir, med musepeker og touch, om du er ordentlig ustø på hånda?

Designmanual og tverrfaglig samarbeid

For å sørge for et mer helhetlig visuelt inntrykk på tvers av løsninger, og for å unngå at flere team lager relativt like komponenter på forskjellige måter, er det laget en designmanual. Manualen viser både design og HTML, og er sånn sett også et slags kodebibliotek. Tilhørende CSS og Javascript ligger i et eget prosjekt (repository) som andre prosjekter har en avhengighet til. Herfra plukker en det en det en trenger, og bygger det deretter sammen med lokale stiler og script, per applikasjon.

Nye tjenester som har kommet på lufta i høst er laget på denne måten, og det har fungert veldig bra. Kvaliteten på det vi lager har økt, og antall registrerte feil relatert til frontend og universell utforming har sunket som en stein. Alt som ligger i designmanualen er grundig gjennomgått og testet, og danner en standard for konsistent design og funksjonalitet på tvers av sider og løsninger.

Et annet viktig poeng her er at en tenker universell utforming fra start til slutt. Når designeren er klar over retningslinjene som gjelder for universell utforming fra første stund, slipper en å måtte foreta endringer, som kanskje går på akkord med det visuelle uttrykket en i utgangspunktet har prøvd å skape, langt uti prosessen. Det samme gjelder for UX-eren og mer funksjonelle konsepter.

For å sørge for at alle er “ombord” så tidlig som mulig når noe nytt skal lages, har vi hatt stor nytte av mer eller mindre faste tverrfaglige diskusjonsmøter hvor design, UX og frontend er representert.

Prototyping, testing og feilhåndtering

Det kan være verdifult å prototype noe før full implementering. Det gjelder også for testing av komplekse konsepter i en skjermleser. Et eksempel er validering av et skjema, hvor det er viktig at brukeren får med seg alle feilmeldinger. Måten vi prøvde å løse validering av enkelte skjema på, var blant annet ved at hver feilmelding ble vist innenfor hver sin live region, like ved tilhørende input-felt. Når tekst spretter frem i en live region skal skjermleseren fange det opp, og lese det for brukeren. Problemet er at det ikke fungerer om en oppdaterer flere slike regioner samtidig; for eksempel i det øyeblikk brukeren prøver å poste skjemaet. Meldingene køes ikke opp, og skjermleseren annonserer kun den siste.

Dette er ikke en problemstilling en møter hver dag, og problemet ble ikke oppdaget før applikasjonen var nærmest ferdig implementert. Hadde vi visst om begrensningene på forhånd, så hadde vi løst det på en bedre og mer elegant måte med en gang. Enkel HTML-prototyping kan være veien å gå for å få til nettopp det.

Et annet grep som har hatt verdi, er mer og hyppigere testing. En er tidligere på ballen for å teste de forskjellige brukerhistoriene — også med tanke på universell utforming. Under utvikling og QA har vi i tillegg blitt bedre på å verifisere viktig funksjonalitet selv. Det kan for eksempel være å sjekke at en kan navigere med tasaturet og at bra nok fokusmarkering er på plass.

Feil tildeles i mindre grad enn før til “dedikerte bugfiksere”, også kjent som eksperter, uten at teamene selv blir gjort oppmerksom på hva som har feilet, og hvorfor. Større grad av ansvarsfordeling hva angår universell utforming, er viktig.

Hvor står vi i dag?

Teamene har blitt mer proaktive når det kommer til universell utforming. En evner å se mye av det det som kan skape problemer tidligere enn før, og en får ikke like mange feil og utfordringer i sluttfasen av prosjektene. Det skulle jo forsåvidt bare mangle ettersom en får mer kompetanse og erfaring på området, men det er også takket være god innsats fra både brukskvalitetsteamet og testlederene våre. Disse har vært veldig gode pådrivere for å få satt universell utforming ordentlig på agendaen.

Når det er sagt er det fortsatt en vei å gå for å øke forståelsen for universell utforming ytterligere blant alle involverte. Jeg tror det å faktisk se menneskene, og hva de sliter med når de prøver å bruke det vi lager, er noe som hjelper. Da snakker jeg ikke bare om mennesker med varig funksjonsnedsettelse, men også alle andre som i forskjellige situasjoner nyter godt av at vi gjør det enkelt for de.

Hva er dine erfaringer rundt praktisk jobbing med universell utforming i prosjekt? Har du andre kriterier for hva som må til for å lykkes med det?

Forsidebilde: Double vision av Georgie Pauwels / CC BY 2.0.

Like what you read? Give Anders Skifte a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.