Universell utforming i utviklingsprosessen

Introduksjon

Omfanget av ulike utviklingsløp vil variere mye avhengig av hva som skal utvikles, type prosjekt og arbeidsmetoder. Nedenfor har vi satt opp noen viktige punkter som handler om universell utforming i utviklingsløpet.

Start med brukerne

For å få til noe som er brukervennlig må du lage løsninger som svarer på bestemte mål og brukernes behov.

Hvilke målgrupper er det du henvender deg til? La brukerne selv fortelle hva som er viktig for dem. Tenk også på at de som skal bruke det du lager, vil ha ulike funksjonsnedsettelser, midlertidige eller varige. Husk også at mange typer funksjonsnedsettelser er usynlige, for eksempel fargeblindhet eller konsentrasjonsvansker.

Mer om ulike brukerforutsetninger i Hvem er brukerne?.

Rammer for prosjektet

Prosjektet må avklare rammene for arbeidet med universell utforming. Spørsmål som prosjektgruppen må finne svar på er for eksempel:

• Hvilke ambisjoner har vi? Tilgjengelighet for noen eller brukervennlighet for alle?
• Hva kan prosjektleder, formgiver og utvikler om universell utforming?
• Behøver prosjektet kompetanse utenfra?
• Er det mulig å publisere universelt utformet innhold i publiseringsløsningen?
• Er det andre systemer eller tredjepartsløsninger som skal brukes? Kan dere påvirke utformingen av disse systemene?

Rutiner og planlegging

Universell utforming handler om kvalitet. Kvalitetsarbeid handler i stor grad om kunnskap og godt definerte rutiner som blir fulgt opp. Sørg også for å planlegge nok tid for tester og utbedringer allerede fra begynnelsen i prosjektet.

Roller og ansvar

Det er viktig å bestemme hvem som har ansvar for å

• definere krav til universell utforming
• kontrollere at kravene oppfylles

Tenk gjennom hvordan deres utviklingsprosess ser ut og når universell utforming skal inn. Hovedsaken er at det finnes en plan med tydelige oppgaver for hver fase og hver rolle. En bra tommelfingerregel er at universell utforming minimum er med i

• forstudie
• kravspesifikasjon
• innhold og informasjonsstruktur
• konseptutvikling og prototyping
• formgiving
• frontend
• backend
• akseptansetest

Samarbeid

Det er avgjørende for en effektiv prosess og et godt resultat at de ulike fagpersonene jobber sammen. Lag en rutine for hvordan arbeidet skal foregå. Da vet alle hvem de skal henvende seg til og hvordan hver fase fungerer.

For eksempel bør alle roller samarbeide slik at samspillet mellom konsept, design og utvikling fungerer som planlagt.

• Interaksjonsdesignere må blant annet forholde seg til krav relatert til motorikk og klikkeflater 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.
• Grafiske designere må blant annet ta hensyn til krav til kontrast og bruk av farger. De må også ha dialog med interaksjonsdesignerne, blant annet for å sikre at den planlagte funksjonaliteten er tydelig. Videre kan det være relevant å diskutere med front-endutviklere for å oppnå mest mulig effektiv CSS-kode.
• Redaktøren må sikre at løsningen gjør det mulig å legge ut de ønskede formene for innhold på en universelt utformet måte. Dette kan kreve dialog med utviklerne for å tilpasse eller forbedre publiseringsløsningen. Videre må de som kun skriver, vite hvordan de lager tilgjengelige tekster og dokumenter.

Testing

Når kravene skal følges opp, kan dere vurdere om dere skal teste i hver sprint, eller om det holder å kontrollere med lengre mellomrom. Avhengig av prosesstilnærming og fase vil det være ulike saker som er relevante å teste på ulike tidspunkt. Noen jobber med konsept og design i parallell, mens andre separerer dette som to påfølgende faser. Noen starter med informasjonsstrukturen før konsept og design, andre venter med dette til senere. Noen designer direkte i front-end, andre lager bilder eller grafikk først, for så å konvertere til CSS-kode.

Noen eksempler på hva som kan testes når:

• Navigasjonskonsept kan testes allerede i konseptfasen.
• Fargevalg og typografi kan testes i designfasen.
• Tastaturnavigering kan testes i prototyp- eller betaversjon.
• Semantisk kode kan testes når man har lagt inn innhold i det endelige rammeverket.
• Tekst kan testes fortløpende, og alt innhold bør testes når det er lagt inn i det endelige rammeverket.

Det vil være lønnsomt å teste hver sak så tidlig som mulig. For eksempel bør man verifisere grunnleggende konsept og design for skjema før man begynner med utstrakt produksjon av ulike skjema.

Husk å sett av plass i budsjett og kalender, både til å utføre testing og utbedre funnene. Sørg også for tydelig definering av ansvar og rutiner for testgjennomføring, dokumentasjon, utbedring og oppfølging.

En del testing kan du gjøre selv og krever ikke annet enn nettleseren og det utstyret du bruker til vanlig.

Involver gjerne brukerne underveis i prosessen. Det finnes for eksempel verktøy for testing av informasjonsstruktur helt fristilt fra konsept og design, du kan gjøre enkle tester på stillbilder uten interaksjonsmuligheter, og mer komplekse tester når du har et fungerende grensesnitt. Dette er særlig viktig dersom du har valgt nye tilnærminger til kjente funksjoner eller benytter funksjonalitet som er lite kjent.

Husk også å brukerteste med funksjonshemmede.

Kravspesifikasjon og regelverk

Kravene i forskriften bygger på WCAG-standarden. Denne standarden utgjør minimumskrav, som innebærer at det ikke er tilstrekkelig bare å følge forskriften hvis målet er en god og brukervennlig løsning.

WCAG-standarden er ikke tilstrekkelig spesifikk til å fungere som kravunderlag rett ut av boksen, men må tilpasses og spesifiseres ut fra blant annet valgt teknologi og ønsket funksjonalitet. Det er viktig at alle involverte forstår hva kravene går ut på og hvordan de skal møtes.

Lag tydelige og konkrete krav både for eksterne leverandører av konsept, design og kode, samt for interne roller som redaktører og bestillere. I anbudsprosessen har du store muligheter til å stille krav til universell utforming. Hvis du gjør det, blir det enklere for tilbydere å gi presise tilbud, og det blir enklere for deg å følge opp kravene underveis i prosessen. Er målet brukervennlighet for alle, eller kun teknisk tilgjengelighet for hjelpemidler? Dette vil ha stor betydning for hvordan du formulerer teksten i kravspesifikasjonen.

Kontroller jevnlig

Et nettsted blir aldri ferdig. På samme måte vil universell utforming være en del av videreutviklingen som en måte å tenke på og en metode å jobbe etter. Rutinene og prosessene som du bygger opp undervegs, bør være en naturlig del av den videre forvaltningen, med løpende kontroller og tester.

Det er viktig å bygge den interne kompetansen i organisasjonen, slik at nivået på universell utforming vedlikeholdes, og gjerne forbedres.

Ved å spre kunnskap og ansvar gjør du organisasjonen mindre avhengig av konsulenter, og sikrer arbeidet med universell utforming for fremtiden.