Universell utforming som prosess, virkemiddel og mål i utvikling av ny programvare

I Norges Handicapforbunds (NHFs) prosjekt "Universelt utformet CRM" var målet å utvikle et kundeoppfølgingssystem som kan brukes av alle. Microsoft Dynamic CRM ble brukt som rammeverk, og nettopp dette var et viktig poeng i prosjektet: Sjekke om et slikt rammeverk inkluderte nødvendig funksjonalitet for å implementere et universelt utformet system.

Jeg ble engasjert for å teste tilgjengelighet og fungere som en ekspert på datatekniske hjelpemidler og web-grensesnitt. I dette notatet oppsummerer jeg noen av erfaringene fra prosjektet gjennom å sette opp viktige fokusområder for universell utforming i utvikling av ny programvare. Siden det har vært et mål for NHF å gi generelle råd mht. universell utforming (UU) og utviklingsprosjekter, har jeg også tatt med noen erfaringer fra annet arbeid og ulike referanser for de som ønsker å lese mer. I all hovedsak er referansene tilgjengelige kostnadsfritt på internett.

I dette notatet har jeg ikke fokusert på nytteverdien av universell utforming. Leser du dette vet du antakelig at det å ta høyde for ulike forutsetninger og behov er viktig. Du vet kanskje at dette kan gi bedre lønnsomhet. Du vet sannsynligvis at det å ta hensyn til funksjonshemmede gjerne fører til bedre systemer for alle. Dette er helt vanlige påstander [5], og kanskje stemmer det til og med!

Veilederen er skrevet med håp om at språket er relativt uakademisk og enkelt. Blant annet benyttes jeg-form. Dette betyr imidlertid ikke på noen måte at erfaringene og kunnskapen som ble generert i NHF-prosjektet kun er mine! Columbus IT og Microsoft har gjort en god jobb. Likevel er det først og fremst Norges Handikapforbund som skal ha æren for å ha gått så seriøst inn i et så komplekst prosjekt!

Tusen hjertelig takk for at jeg fikk være med, og for all den erfaringen jeg har fått i dette prosjektet! En stor takk går også til Norges forskningsråd og IT funk som har støttet prosjektet!

Ta gjerne kontakt med meg, dersom du har spørsmål eller andre tilbakemeldinger.

Morten Tollefsen
Januar, 2011

1. Innledning

Norges Handikapforbund (NHF) er en interesseorganisasjon med ca 20000 medlemmer, ca. 2000 tillitsvalgte og 80 ansatte. Organisasjonen består av 9 regionslag og 200 lokallag, samt 12 landsforeninger med ca 100 lokale landsforeningslag.

NHF vedtok å anskaffe et CRM-system [11] for håndtering av kunderelasjoner. CRM skal bidra til en helhetlig, planmessig og strukturert tilnærming til håndteringen av organisasjonens relasjoner. En relasjon defineres som en person eller bedrift/institusjon som av ulike årsaker har eller har hatt kontakt med NHF. Verktøyet skal være universelt utformet slik at det kan brukes av alle uavhengig av eventuell funksjonsnedsettelse. Med alle menes det i denne sammenheng "de det er naturlig å se for seg som målgruppe av et CRM-verktøy" [10]. Det organisatoriske målet med innføringen av et slikt verktøy var å få økt effekt av påvirkningsarbeidet og økte inntekter.

Da det var vedtatt å anskaffe ny programvare ble ulike CRM-systemer og leverandører kartlagt. Konklusjonen var at ingen IKT-baserte CRM verktøy var universelt utformet. NHF har ansatte med ulike funksjonsnedsettelser. Disse ansatte har hatt problemer med andre IKT-verktøy, og nye løsninger skal kunne brukes av alle. Dette er et ufravikelig krav for NHF, og vil etter hvert også kreves som følge av Antidiskrimineringsloven [12]. Loven er initiert av NHF, og det er viktig for organisasjonen å stå i bresjen også mht. utforming av teknologi.

Valg av produkt eller rammeverk er vesentlig for muligheten til å utvikle løsninger som kan brukes av alle. I mange tilfeller vil også valg av leverandør være viktig. I praksis er det foreløpig få programvareleverandører som har dybdekompetanse mht. konsekvensene av ulike funksjonshemninger. NHF skjønte raskt dette og tok initiativet til å gjennomføre et FoU-prosjekt knyttet til nytt CRM-system. Flere utfordringer var klare helt fra starten, f. eks:

Universell utforming (UU) innebærer mer enn tilgjengelighet
Datatekniske hjelpemidler presenterer innhold på forskjellig måte.
Det kan være begrensninger i rammeverk og/eller utviklingsverktøy som hindrer valgfrihet mht. implementasjon.
Brukertesting er komplisert, fordi det er vanskelig å definere kompetansekrav.
...

Målet i FoU-prosjektet ble definert som følger: "Utrede og dokumentere hva som skal til for å få et standard CRM-rammeverk tilgjengelig og implementere dette i NHFs løsning". Hvorvidt hovedmålet er nådd problematiseres ikke her. Hensikten med dette notatet er å formidle erfaringene NHF har gjort i forbindelse med planlegging, implementasjon og tidlig drift av det nye systemet. Dette er ikke CRM-spesifikke erfaringer, men bør kunne benyttes i alle liknende anskaffelser. Følgende milepæler/prosjektaktiviteter ble satt opp:

Definere funksjonalitet basert på kravspesifikasjon
Identifisere utfordringer knyttet til tilgjengelighet
Teste standardløsning mht. UU.
Brukersentrert design i implementasjon av NHFs løsning
Brukertester
Korrigering
Dokumentere erfaringer.

1.1 Om dette notatet

I kapittel 2 avgrenses universell utforming slik begrepet er brukt i NHF-prosjektet. Kapittelet kan også brukes som en første introduksjon for de som ikke kjenner begrepet fra før.

Kapittel 3 tar for seg den tidlige fasen i et utviklingsprosjekt. Det fokuseres på problemstillinger knyttet til UU. Med andre ord behandles i liten grad utviklingsmetodikk etc.

Implementasjon og brukertesting tas opp i kapittel 4.

Opplæring og dokumentasjon er en del av suksesskriteriene for et vellykket IKT-system. Dette behandles i kapittel 5.

Driftfasen av et IKT-system innebærer brukerstøtte, feilretting, videreutvikling, opplæring av nyansatte osv. Noen problemstillinger tas opp i kapittel 6. NHF-prosjektet avsluttes imidlertid før det finnes mye erfaring med drift, og kapitlet er derfor hovedsaklig en oppsummering av erfaringer fra annet arbeid.

Notatet oppsummeres med en sjekkliste i kapittel 7, referanser i kapittel 8 og vedlegg.

2. UUUU: Universell Utforming Uten Unntak

Tittelen på dette notatet er "Universell utforming som prosess, virkemiddel og mål i utvikling av ny programvare". Kokt ned til beinet er det akkurat dette det handler om. UU må bli en del av tankegangen vår, en del av verktøykassa, ikke et separat og tidsbegrenset satsningsområde.

2.1 Hva er universell utforming?

Når jeg første gang hørte "barrier-free/accessible/universal design", er jeg usikker på, men det var sannsynligvis tidlig på 1990-tallet. Ordene skal beskrive noe i retning av "mest mulig for flest mulig", såpass skjønner jeg, men ellers er innholdet i dette begrepet relativt vagt. Er det f.eks. mulig å si at en eneste nettside eller et eneste PC-program er universelt utformet? Selvsagt er svaret nei! Likevel er begrepet viktig. Kanskje enda viktigere for å beskrive prosesser enn som betegnelse på ferdige produkter og tjenester. Det som helt sikkert er et viktig mål er universell utvikling, dvs. at all utvikling skal ta høyde for at mennesker har ulike forutsetninger og behov.

Den tradisjonelle definisjonen av UU er: "Universell utforming er utforming av produkter og omgivelser på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming." Dette er en oversettelse fra The Center for Universal Design (http://www.design.ncsu.edu/cud/about_ud/about_ud.htm): "Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design." (Ron Mace).

Arbeidet som er gjort ved The Center for Universal Design ved North Carolina State University [13] regnes som utgangspunktet for begrepet "universell utforming". En tverrfaglig gruppe har satt opp 7 hovedprinsipper (jfr. [14] for definisjoner og retningslinjer):

Like muligheter for bruk
Fleksibel i bruk
Enkel og intuitiv i bruk
Forståelig informasjon
Toleranse for feil
Lav fysisk anstrengelse
Størrelse og plass for tilgang og bruk

Produktutvikling tar utgangspunkt i en målgruppe. For meg er det naturlig at en definisjon av universell utforming gjør det samme. Alle produkter skal ikke nødvendigvis være like hensiktsmessige for alle mennesker, men universell utforming skal brukes som prinsipp for å oppnå tilgjengelighet for hele målgruppen.

Jeg har derfor foreslått følgende tolkning av UU for utvikling av ny programvare: Universell utforming innen IKT betyr at produkter og tjenester skal utvikles på en slik måte at alle mennesker det er naturlig å tenke seg som målgruppe skal kunne bruke teknologien på en hensiktsmessig måte. [10].

2.2 Fysisk tilgjengelighet

I et utviklingsprosjekt avvikles det gjerne møter, kurs og konferanser. Fysisk tilgjengelighet er nødvendig for at alle skal kunne delta på en hensiktsmessig måte. Lokaler skal være egnet for rullestol, det må finnes teleslynge, førerhund må kunne tas med, det skal tas høyde for allergikere mm. Deltasenteret har utgitt veilederen "Tilgjengelige møter, kurs og konferanser" [9], og denne inneholder en sjekkliste som er et godt hjelpemiddel for å planlegge den fysiske tilgjengeligheten. Veilederen inneholder også enkle råd om utdeling av materiell og hvordan presentasjoner bør gjennomføres.

2.3 Prosjekt-team, kompetanse og kommunikasjon

Det å sette sammen gode prosjekt-team er ikke trivielt:

Fagkompetanse, f.eks. innen prosjektledelse og systemutvikling.
Forankring i kundens ledelse.
Sluttbrukere
Programmerere, designere og andre "utviklere".

Dette er selvsagt ikke en lærebok om hvordan man setter sammen prosjekt-team. Men også UU må tas med som en av forutsetningene. Kompetanse som lett undervurderes er kunnskap om datatekniske hjelpemidler, spesiell tilgjengelighetsfunksjonalitet i operativsystem og/eller utviklingsmiljø, problemer knyttet til tilgjengelighet i eksisterende IKT-systemer mm.

Det er vanlig at brukere med nedsatt funksjonsevne og eksperter på IT og universell utforming kommer for seint med i utviklingsprosjekter. Selv i leveranser der universell utforming er en del av kravspesifikasjonen, har jeg sett en rekke eksempler på at UU helt utelates eller at det skal gjøres en mer eller mindre tilfeldig test kort tid før lansering. I slike prosjekter blir handlingsrommet lite for å gjøre endringer før systemet settes i drift! Mot slutten av et utviklingsprosjekt er gjerne "potten" tom, og vanligvis er også tidspresset stort rett før lansering.

Fordelene med å få brukere tidlig på banen er blant annet at:

Kjente feil kan unngås.
Viktige utfordringer kan identifiseres tidlig.
Utviklere kan få kjennskap til hvordan hjelpemiddelteknologi fungerer i praksis (før de lager brukergrensesnitt, definerer prosesser osv).

I tillegg til de fordelene som oppnås mht. brukervennlighet og funksjonalitet argumenteres det mye for økonomiske gevinster [5]. Det er garantert billigere å ha med UU-ekspertise fra starten enn å drive brannslokking i etterkant. Også UU vil imidlertid koste noe, og disse kostnadene bør naturligvis inn i prosjektet helt fra planleggingsfasen.

2.3.1 Rekruttering av eksperter og brukere

Hvem som er eksperter på universell utforming kan diskuteres. Da Antidiskrimineringsloven kom på banen, dukket det samtidig opp både enkeltpersoner og miljøer med "lang fartstid" innen dette feltet. Det finnes selvsagt dyktige personer både i Norge og andre steder i verden, men det er svært ofte et problem at kunden selv ikke vet hva som kan forventes og hvilke krav som må settes. Et eksempel på dette er bruk av skjermlesere for blinde. Kan en som kun har erfaring med visuelle brukergrensesnitt, være ekspert på bruk av blindeskrift, syntetisk tale og navigering vha. tastatur og skjermleserfunksjonalitet? Kan man skjønne navigeringsstrategier og riktige arbeidsteknikker for blinde uten selv å ha jobbet som blind i lang tid? Det å ta høyde for blinde er det mest komplekse i forb. med utvikling av universelle løsninger. Grunnen er enkelt nok at det visuelle grensesnittet har hovedfokus i de fleste utviklingsprosjekter. Også utforming der det skal tas høyde for kognitive funksjonsnedsettelser er veldig utfordrende, men faller litt utenfor hovedmålgruppen for dette notatet. Skal du ha med eksperter på tilgjengelighet/UU i prosjekt-teamet, bør du sjekke både kompetanse og referanser. Det å ha prøvd skjermleser noen timer kvalifiserer neppe til å forstå hva som skal til for å gjøre komplekse systemer brukbare for blinde og sterkt svaksynte.

Jeg tror det å rekruttere gode UU-eksperter i mange tilfeller er ganske vanskelig. I tillegg bør brukere av det systemet som skal utvikles være med. Brukere som kjenner oppgaver som skal løses: interne prosesser og arbeidsflyt i organisasjonen, utfordringer med eksisterende løsninger osv. Eksperter kan ikke erstatte "ekte" brukere, men man kan heller ikke forvente seg at brukere skal kunne vite hvordan ulike utfordringer skal løses rent teknisk. I mange tilfeller vil brukere, f.eks. av web-baserte grensesnitt måtte ha en grunnkompetanse. Dette gjelder rent generelt, men er helt essensielt i forbindelse med komplekse datatekniske hjelpemidler. Hvilken kompetanse som er nødvendig i et gitt prosjekt vil variere. Et forsøk på definisjon av nødvendig brukerkompetanse innen web for synshemmede er utviklet i forskningsprosjektet "Universal User Competence" [16].

Et argument jeg svært ofte hører i forhold til utvelgelse av funksjonshemmede, er at det er viktig å unngå ekspert-brukerne. I noen tilfeller kan dette helt sikkert være riktig! På den annen side vet ofte dyktige brukere av skjermlesere og andre datatekniske hjelpemidler hvilke teknikker som er minst mentalt krevende, mest effektive og hvilke løsninger som fungerer best med hjelpemidlene. Det kan i like stor grad hjelpe mindre kompetente brukere at ekspertene finner gode løsninger, og at disse løsningene læres bort. Hvem vil du lære å kjøre bil av? En erfaren kjørelærer eller en åtteåring som er god på "Need for speed"? Et nokså retorisk spørsmål, men ikke helt ulikt de problemstillingene jeg ofte konfronteres med i utviklingsprosjekter! Jeg har sett mange eksempler på at dårlige løsninger har blitt laget pga. dårlige råd fra brukere. Dette gjelder først og fremst web-sider, men også flere frittstående applikasjoner (til og med datatekniske hjelpemidler for funksjonshemmede).

2.3.2 Brukere må gis nødvendig informasjon og kompetanse

Skal brukere ha sjanse til å bidra på en fornuftig måte, må de få tilstrekkelig opplæring! Dette inkluderer blant annet:

Opplæring i hva det nye systemet skal brukes til og forutsetninger/begrensninger for implementasjonen.
Tilgjengelig og brukervennlig informasjon.
Tilgjengelige møter....

Dette er et punkt det syndes forferdelig mye mot! Min erfaring som deltaker i utviklingsprosjekter, inkl. NHFs CRM-prosjekt er at det ikke tas tilstrekkelig hensyn til synshemmede. Noen eksempler:

Det vises skjermbilder på møter som hverken forklares eller kan gjøres tilgjengelige på brukerens maskin
Presentasjonsprogrammer benyttes for å vise systemoversikt, prosesser osv.
Dokumentasjon leveres ut i formater som ikke kan leses av alle (f. eks scannet PDF).
Opplæring og dokumentasjon forutsetter at det brukes mus (selv om det finnes alternative fremgangsmåter)..
...

Er ikke prosessen universelt utformet, er neppe sluttproduktet optimalt heller. Tilrettelegges ikke prosessen for alle, vil noen lett miste muligheten til å bidra: brukeren blir gissel. Du har kanskje en funksjonshemmet eller flere som er med på papiret, men hva hjelper det dersom de ikke bidrar til et bedre produkt? I beste fall får de som lager systemet pengene sine, men kunden får neppe et optimalt system.

Faktisk begynner dette i noen tilfeller alt med "innsalg". Selgere av ulike produkter kommer med PowerPoint-presentasjoner og evt. noen papirbrosjyrer. Skal man kreve universelt utformede produkter, bør man kreve UU presentasjoner også! I de siste årene har jeg sett flere eksempler på leverandører som tar sjansen på å si at de kan levere universelt utformede systemer. Når det kommer til stykke, viser det seg imidlertid at leverandørene ikke aner hva dette innebærer. De vet heller ikke om rammeverkene (f. eks Microsoft Dynamic CRM) er eller kan tilpasses til brukere med alternative brukergrensesnitt.

2.3.3 Opplæring av utviklere

When designers and developers see people with disabilities use products like theirs, most are highly motivated by a new understanding of accessibility. Rather than seeing accessibility as only a checklist item, the real-life experience shows the human side of accessibility. Designers and developers get a different level of understanding of the opportunity for their work to impact lives. [5]

Det at utviklere skjønner hvordan datatekniske hjelpemidler fungerer er helt essensielt for å få god fremdrift og suksess i utviklingsprosjekter. I tillegg blir ofte utviklere motiverte av å se hvordan funksjonshemmede benytter teknologi [5].

Moderne brukergrensesnitt er vanligvis svært visuelle. Dette er spesielt tilfelle for datamaskiner. Hjelpemidler som gjør synshemmede i stand til å benytte standard operativsystemer vil skille seg nokså mye fra det visuelle grensesnittet. I web-grensesnitt vil f. eks en skjermleser presentere siden på en måte utviklerne må skjønne for å kunne lage gode løsninger. Den ikke-visuelle omformingen skjer fordi en blind kun leser noen få punkttegn av gangen og/eller hører et og et ord lest opp med syntetisk tale. Her er det imidlertid viktig å påpeke at selv det å kun bruke tastatur i mange tilfeller medfører at det bør tas spesielle grep i forhold til utvikling av brukergrensesnittet. En spesiell variant av tastaturbruk er brytersystemer. Skal funksjonalitet kunne styres effektivt med brytere må det f. eks gjerne legges inn "lokale hopp" for å unngå alt for mange brytertrykk eller for lang ventetid. Det finnes selvsagt også en rekke andre hjelpemidler som fungerer best, dersom det tas høyde for dette i utviklingsløpet.

Metoden for å lære opp utviklere kan variere fra det å sitte sammen med funksjonshemmede brukere i noen timer til å ta sertifiserende kurs [8]. Kurset "Universell utforming og hjelpemiddelteknologi" [8] er resultatet av et prosjekt støttet av IT Funk, og deltakerne har formidlet at utbyttet av kurset har vært veldig stort. Dette kommer sannsynligvis av at det legges mye vekt på praktisk demonstrasjon og bruk av hjelpemidler.

3. Spesifikasjon

3.1 Ideutvikling

Behovet for ny programvare kan oppstå av ulike grunner:

Gammel programvare fungerer dårlig eller det er behov for mer effektive løsninger.
Nye oppgaver skal løses.
Regelendringer krever nye systemer.
Integrasjon mot andre systemer fungerer ikke eller det kan være ønskelig å utvikle denne typen funksjonalitet.
...

Mennesker har ulike forutsetninger og behov. I en ideutvekslingsfase er det derfor naturlig å trekke inn alle involverte brukere. Min erfaring er at det er to hovedgrunner til å legge spesiell vekt på ideer/synspunkter fra mennesker med nedsatt funksjonsevne:

Mennesker må i mange tilfeller kompensere for manglende funksjonsevne ved å bruke kreativitet. Strategier funksjonshemmede har etablert kan være verdifulle i forbindelse med nyutvikling.

Funksjonshemmede kan ha behov det ikke er så lett å identifisere for andre. Dette kan likevel være behov som gir merverdi for alle uten at prosjektet behøver å bli mer kostbart.

Strategier/kreativitet: Støtte for hensiktsmessig tastaturbruk som et alternativ til mus mangler i mange brukergrensesnitt. De som primært bruker tastatur (sterkt synshemmede, mennesker med musesyke osv) vet mye om standard hurtigtaster, hvilke løsninger som fungerer bra/dårlig og kan til og med ha ideer om innovative fremgangsmåter. Strategiene for å bruke et web-basert grensesnitt med tastatur kan f. eks være ganske annerledes enn hvis musa er den primære input-enheten. Gode tastaturløsninger kan i tillegg til å hjelpe noen brukere gjøre at alle kan redusere sjansen for musesyke og med trening sannsynligvis jobbe raskere enn når de bare bruker mus.

Andre behov: Et eksempel på at funksjonshemmede kan ha andre behov enn "gjennomsnittsbrukeren" er scanning av innkommet post. Uten optisk tegngjenkjenning kan ikke blinde lese posten. Automatisert tegngjenkjenning er imidlertid enkelt å få på plass, og i tillegg til at blinde kan lese dokumentene gir det stor merverdi for alle, siden tegngjenkjenningen medfører at dokumentene blir søkbare.

Ved å inkludere prinsippene om universell utforming i planleggingsfasen kan oppdragsgiver spare betydelige midler i forhold til å måtte bygge om eller tilpasse produktet i ettertid for at flere brukergrupper skal kunne nyttegjøre seg produktet [17]. Bruk av tverrfaglige anskaffelsesteam (TAT) kan være en egnet måte å definere behov [17].

3.2 Standarder

Det finnes ikke standarder som garanterer universell utforming. Heldigvis må man likevel ikke finne opp alle hjul på nytt. Legg derfor ned innsats i å kartlegge eksisterende retningslinjer og standarder.

De mest etablerte retningslinjene som finnes for tilgjengelighet er laget for web. W3C har en egen gruppe som jobber med tilgjengelighet. I et komplekst system som f. eks et web-basert CRM system kan følgende sett med W3c-retningslinjer være aktuelle:

Authoring Tool Accessibility Guidelines (ATAG) [1]
User Agent Accessibility Guidelines (UAAG) [2]
Web Content Accessibility Guidelines (WCAG) [3]
Accessible Rich Internet Applications (WAI-ARIA) [4]

Tilgjengelighet er mindre omfattende enn UU. Universelt utformede produkter er tilgjengelige, men tilgjengelige produkter trenger ikke å være enkle i bruk, lette å forstå osv. I [19] står det blant annet følgende om UU, web og standarder: "Standardiseringsrådet har foreslått at WCAG 2.0 på nivå AA skal være obligatorisk standard for offentlige virksomheters nettsider, og at nivå AAA skal være anbefalt. Videre er det foreslått at ATAG 1.0 på alle nivåer skal være obligatorisk for publiseringsverktøy. Dette forslaget vil bli sendt ut på høring før det tas inn i Referansekatalogen og i forskrift om IT-standarder i offentlig sektor. Dersom man er i ferd med å utvikle et nytt nettsted , anbefales det sterkt at man stiller krav om full støtte for WCAG 2.0 AAA og ATAG 1.0 AAA. Dersom WCAG 2.0 blir etablert som forvaltningsstandard, vil WCAG 1.0 endre status fra anbefalt til under utfasing." Dersom målet er UU, må man absolutt ikke tro at standarder er et tilstrekkelig virkemiddel, men som nevnt over er standarder et nyttig hjelpemiddel. I [19] anbefales det også at testing av mennesker med nedsatt funksjonsevne inngår som en del av kravspesifikasjonen.

Tilgjengelighet og universell utforming blir i økende grad fokusert i internasjonalt standardiseringsarbeid. Standardiseringsorganet ISO/IEC har laget Veileder 71, som er oversatt til norsk. Denne er også adoptert av de europeiske standardiseringsorganene CEN og CENELEC. Veilederen gir anvisninger til standardiseringsgruppene om hvordan man kan inkludere universell utforming i arbeid i utviklingen av standarder. I 2008 satte EU i gang et initiativ for å trappe opp standardiseringsarbeidsgruppenes bruk av veilederen og det er satt opp en egen CEN arbeidsgruppe med dette formålet. Veilederen identifiserer områder som det skal tas hensyn til ved utforming av produkter, tjenester, bygg/miljø, arbeidsplasser etc. slik at ikke standardene begrenser utformingen. Den gir veiledning om hvordan man kan ta hensyn til behovene til eldre og funksjonshemmede tidlig i en designfase slik at utformingen blir universell, det vil si tilgjengelig og brukervennlig for alle. En del relevante standarder innen IKT vises i Vedlegg 1.

3.3 Konkurransegrunnlag/kravspesifikasjon

[17] legger spesiell vekt på følgende punkter i forhold til å ivareta UU i utformingen av et konkurransegrunnlag:

Spesifikasjon
Kvalifikasjonskrav
Tildelingskriterier
Kontraktsvilkår

Det er viktig å være tydelig i konkurransegrunnlaget/kravspesifikasjonen mht. hva som legges i UU. Jeg har sett mange eksempler på at konkurransegrunnlag og/eller kravspesifikasjoner kun sier at: "Løsningen skal være universelt utformet". Dette er både utilstrekkelig, dumt og defensivt! Utilstrekkelig fordi det er umulig å etterprøve om løsningen er universelt utformet uten mer spesifikke krav. Dumt fordi sluttresultatet etter all sannsynlighet blir mindre universelt utformet enn dersom kravene var tydelig kommunisert. Defensivt fordi det med all tydelighet viser at oppdragsgiver heller ikke vet hva som ligger i begrepet universell utforming.

Det finnes flere ressurser på nett som kan benyttes for å få gode råd i forbindelse med utformingen av konkurransegrunnlag/kravspesifikasjoner, f. eks [17, 18 og 19].

3.4 Valg av teknologi og leverandør

Mange utviklingsprosjekter baseres på anbudskonkurranser. Det kan være ulike leverandører som benytter ulik eller identisk teknologi. I mange tilfeller, f. eks i NHF-prosjektet lages løsninger vha. ferdige rammeverk (Microsoft Dynamics CRM, Microsoft Sharepoint, EPiServer etc). Både teknologi og leverandørens kompetanse er viktige forutsetninger for å nå målet om systemer som kan brukes av alle aktuelle sluttbrukere. Dette må det tas høyde for i valg av teknologi og leverandør.

Selgere og utviklere lever på hver sin planet. Mens selgere har en tendens til å bagatellisere hva det innebærer å vektlegge universell utforming, har ikke utviklere forutsetninger for å lykkes. Selgere er gjerne fornøyd dersom ordet "tilgjengelighet" er nevnt i forhold til produktet de jobber med, men en krevende kunde vil ofte ha langt høyere ambisjoner knyttet til UU enn at et datasystem oppfyller enkelte tilgjengelighetskriterier. Et enkelt eksempel er at "systemet skal kunne brukes med tastatur". Da holder det rett og slett ikke at noe som kan gjøres med et museklikk krever 20 tastetrykk (absolutt vanlig i web-baserte grensesnitt, og da kan det til og med kreve 200 tastetrykk å trykke Tab til riktig lenke eller kontroll får fokus). Se eksempelvis [20] for hvordan noen enkle museklikk kan erstattes med tastatur i Microsoft Dynamic CRM.

Antidiskrimineringsloven har medført økt behov for kompetanse knyttet til UU. Plutselig har svært mange leverandører dybdekompetanse om både tilgjengelighet og UU. Dessverre stopper det ofte med reklamen for seniorkonsulenten. Min erfaring er at kompetansen begrenses til at konsulenten har hørt om eller kanskje til og med lest WCAG. I kreativ programutvikling er det naturligvis ikke slik at UU kan garanteres med noen få og enkle retningslinjer. UU krever også både kompetanse og kreativitet! Be derfor leverandørene om å dokumentere hva de kan om UU og hvordan de ser for seg å sikre at UU blir en integrert del av prosjektet.

Lages datasystemer fra grunnen, har man normalt stor fleksibilitet. Dette gir et potensial for "optimale" løsninger. Ulempene er imidlertid betydelige: kostnader og tid er antakelig de to viktigste. Benyttes Microsoft Dynamic CRM eller andre rammeverk, er fleksibiliteten mindre, og ofte vil det være praktiske eller tekniske begrensninger knyttet til hva det er mulig å endre. Krev dokumentasjon på tilgjengelighet og hvilke praktiske og tekniske begrensninger som eksisterer i forhold til å endre på standardløsninger.

4. Implementering

4.1 Utviklingsmetoder

Etter all sannsynlighet finnes det ikke utviklingsmetoder som sikrer UU. Benyttes tradisjonelle metoder som "vannfall", kan kravspesifikasjoner etc. inneholde detaljerte spesifikasjoner også for UU. Min erfaring er imidlertid at slike detaljspesifikasjoner aldri lar seg gjennomføre i praksis for komplekse utviklingsprosjekter. Moderne metoder som Scrum [21] er muligens bedre egnet, men UU må da være en integrert del av både sprinter, team og mål. Med andre ord en integrert del av hele prosessen.

En av aktivitetene I Nettborger-prosjektet [22] er å se på metodeutvikling der UU er en integrert del. Den foreløpige konklusjonen i prosjektet er at mange metoder kan benyttes, men at det må gjøres grep for å sikre UU.

4.2 Brukersentrert design

"Brukersentrert design" er Et virkemiddel for å oppnå UU. Det som skiller brukersentrert design fra vanlige produktutviklingsprosesser, er at det foreligger en spesielt sterk motivasjon for å fokusere på og ta hensyn til brukere under produktutviklingen. Hvis en skal oppnå brukersentrering, må brukernes vurderinger og erfaringer ikke bare være med i designarbeidet, men være bestemmende og avgjørende faktorer i designprosessen. Det vil si at vi må lage en produktutviklingsprosess som tillater brukersentrerte beslutninger som kriterier for overgang til neste fase. En prosess hvor det gis anledning til å hente inn eller utvikle kunnskap om brukere og brukssituasjoner før beslutninger tas [23].

Begrepet bruker anvendes først og fremst om sluttbrukeren som er den eller de personer som er knyttet til produktet i en brukssituasjon. Sluttbrukernes kapasiteter, ønsker og behov står derfor sentralt i designprosessen. Brukerne er mennesker med ulike måter å fungere på, som utvikler seg gjennom hele livsløpet med vekslende behov. For de involverte i en produktutviklingsprosess er det derfor viktig å tilegne seg kunnskap om menneskelig funksjonsevne, utvikling, forutsetninger og behov både fysisk, psykisk og sosialt. Samtidig påvirkes vi av de produkter, systemer og miljøer vi allerede omgir oss med. [23]

”Brukervennlighet i produktdesign” [23] er en fin introduksjon til hva brukersentrert design handler om, og dette behandles ikke videre her. Brukere av et datasystem, også funksjonshemmede, er helt essensielle for å oppnå suksess. Det er imidlertid relativt utfordrende å ta høyde for alle mulige forutsetninger og behov. Er målet at et produkt skal kunne brukes av alle i en definert målgruppe, er det ikke sikkert prosjektet har brukere som representerer alle behov. En kunde er kanskje interessert i å ansette funksjonshemmede, men har ikke nødvendigvis ansatte med alle typer funksjonshemninger. Det bør derfor vurderes å engasjere eksperter på UU i alle utviklingsprosjekter.

4.3 Testmiljø

En praktisk utfordring i mange utviklingsprosjekter er å sette opp egnede testmiljøer. Dette er spesielt tilfelle, dersom det skal testes med avanserte hjelpemidler. Brukere kan ikke nødvendigvis benytte eget utstyr til testing, og ofte kan hjelpemidler både være kostbare og kompetansekrevende å sette opp. Det kan også være rent tekniske utfordringer knyttet til brukertesting, f. eks teknologi for virtualisering og/eller tynne klienter [7]. Egnede testmiljøer bør planlegges tidlig i prosjektet for å unngå praktiske problemer når det er klart for brukertesting.

4.4 Brukertesting og ekspertvurdering

Det er viktig å velge riktige brukere til testing (jfr. 2.3.1) og gi disse brukerne nødvendig opplæring (jfr. 2.3.2). Ofte kan det imidlertid være hensiktsmessig å la UU-eksperter, spesielt med dybdekompetanse og praktisk erfaring med datatekniske hjelpemidler gjøre ekspertvurderinger før brukerne slippes til. Eksperter vil kunne identifisere mange typiske problemer og skissere mulige løsninger. For brukere vil testingen lett kunne bli en negativ opplevelse, dersom unødvendige feil gjør at systemet blir vanskelig eller umulig å bruke. Ekspertvurderinger er i praksis langt billigere enn brukertesting. Lag derfor det som skal testes best mulig og benytt brukere for å få et enda bedre resultat!

Etter en eksperttesting i NHF-prosjektet ble det avdekket ulike utfordringer med Microsoft Dynamic CRM 4.0 (jfr. Vedlegg 2). Testingen var spesielt knyttet opp mot skjermleseren Jaws versjon 10 (dvs. her ble det testet spesifikt, ikke bredt for å avdekke alle mulige utfordringer). Uten å gjøre spesielle grep ville det helt opplagt hatt lite for seg å la en "vanlig" Jaws bruker teste. Utfordringene ble diskutert med Microsoft. Noe av det som ble funnet var alt kjente problemer, andre ting var nytt for Microsoft. I CRM 2011 er flere av problemene løst, og i prosjektet følte vi at det var stor velvilje mht. å ta tilgjengelighetsproblemer på alvor. En annen fordel ved å gjøre eksperttestingen med Jaws var at brukere kunne få presentert workarounds for å minimere problemene i forbindelse med testing. Målet skal være at også funksjonshemmede skal gis muligheten for å teste funksjonalitet, om systemet fungerer etter intensjonen, om riktige data registreres, om Metadata er hensiktsmessig definert osv. osv. Målet er ikke at funksjonshemmede kun skal teste tilgjengelighet!

5. Opplæring og dokumentasjon

Det finnes ulike strategier for opplæring i bruk av IKT-systemer og svært ofte kombineres disse (listen er ikke nødvendigvis komplett):

Kurs

Superbrukere og erfaringsutveksling

Interaktiv opplæring og online hjelp

Opplæringsmateriell

I universelt utformet programvare må også opplæringen ta høyde for at mennesker har ulike forutsetninger og behov. Dette er ikke nødvendigvis enkelt. Hovedutfordringen er mennesker som bruker standard programvare, men med helt alternative brukergrensesnitt. Det å bruke et web-basert system med en skjermleser (punktskrift/tale) er f. eks helt annerledes enn å bruke skjerm og mus. Hvis en blind er med på et kurs, må det tas høyde for nettopp denne forskjellen, og det samme er tilfelle i presentasjoner, læremateriell osv.

5.1 Kurs

Kurs bør i størst mulig grad ta høyde for ulike forutsetninger og behov. Dette kan f. eks bety at kursdeltakerne skal kunne bruke enten mus eller tastatur. Dette høres muligens enkelt ut? I praksis er det imidlertid ikke vanlig at kursholderen bruker tastatur for å utføre "alle" oppgaver. Det er flere grunner til dette:

Muspekeren vises i skjermbildet, og det er lett å demonstrere flytting av pekeren for å endre fokus. Tastetrykk vises ikke.
Normalt er majoriteten av kursdeltakerne mer vant til å bruke mus enn tastatur (bortsett fra innskriving av tekst). Hovedregelen er nok at dette også gjelder kursholder.
Det er for tidkrevende å vise alt med tastatur.
Det er for tidkrevende å vise flere teknikker.
Det blir forvirrende for kursdeltakerne at all funksjonalitet demonstreres på ulike måter.

Er systemet godt nok laget, hvis det blir for tungvint å vise tastaturteknikker? For deltakere kan det lett bli forvirrende med for mange "veier til målet". Dette blir veldig tydelig, dersom det også skal tas høyde for skjermlesere og andre datatekniske hjelpemidler. Det er nok heller ikke vanlig at kursholdere har nødvendig kompetanse til å undervise brukere med helt spesielle behov. På den annen side vil eksperter på hjelpemidler ikke nødvendigvis være eksperter på det systemet som er utviklet. Skal opplæring bli vellykket for alle, kreves det derfor god planlegging.

5.2 Interaktiv opplæring og online hjelp

Så og si alt læremateriell er i dag tilgjengelig "online". Elektronisk informasjon er godt egnet til å ta høyde for alternative presentasjoner (f. eks vist på skjerm, lest opp med syntetisk tale, skrevet ut i punktskrift osv). Det er egentlig ikke så vanskelig å sørge for at selve informasjonen kan brukes av alle. WCAG gir langt på vei tilstrekkelige retningslinjer, men noe testing av eksperter kan muligens vurderes (f. eks knyttet til søk og navigering). To av hovedutfordringene knyttet til god dokumentasjon er:

Skrive forståelig.
Ta høyde for alternative brukergrensesnitt.

5.2.1 Skrive forståelig

Det å skrive forståelig er ikke trivielt. Alt for ofte lages dokumentasjonen av teknikere som benytter begreper sluttbrukerne ikke kjenner. Det å "treffe med" nivået på forklaringer er vanskelig. Er forklaringene for knappe, hjelpes ikke brukerne. Er forklaringene alt for lange og omstendelige, orker ingen å lese dokumentasjonen. Dokumentasjonen må testes av brukere, spesielt av mennesker som ikke har deltatt i utviklingsprosjektet.

5.2.2 Ta høyde for alternative brukergrensesnitt

Web-baserte brukergrensesnitt og skjermlesere representerer en spesiell utfordring i forhold til dokumentasjon. Informasjonen omformateres og presenteres i en kolonne for at det skal bli enklere med syntetisk tale og punktskrift. Forklaringer av typen "Klikk på knappen øverst til venstre", "... vises med et rødt ikon", "pek med musen for å få opp en forklaring" etc. blir helt meningsløse for en blind.

Spesiell tilgjengelighetsfunksjonalitet må forklares. Eksempler:

Tekst og kontroller som ikke vises på skjermen, men som er lagt inn for å gjøre det enklere for skjermlesere.
Flash som kan vise alternative kontroller og informasjon til skjermlesere.
Hurtigtaster

5.3 Superbrukere og erfaringsutveksling

Det er vanlig at noen brukere gis ekstra ansvar for systemet. Disse brukerne skal være ressurser for andre og kan i tillegg ha spesielle rettigheter. Mange funksjonshemmede (særlig sterkt synshemmede) må dessverre fungere som sin "egen IT-sjef og superbruker". Dette er for så vidt forståelig siden de bruker spesielle hjelpemidler, men dette er naturligvis ikke ønskelig! Minst en superbruker bør gis opplæring og ha et spesielt ansvar i forhold til den eller de brukerne som benytter spesielle hjelpemidler. Superbrukeren kan ikke forventes å ha dybdekompetanse om hjelpemidlene, men han/hun skal skjønne hovedfunksjonalitet og hvordan hjelpemidlene brukes.

5.4 Annet opplæringsmateriell

I tillegg til online dokumentasjon kan annet opplæringsmateriell utvikles, f. eks:

Introduksjonsartikler på web eller ukeavis.
Komme i gang hefte.
Papirbaserte eller elektroniske referansekort.
...

For denne typen opplæringsmateriell gjelder naturligvis de samme retningslinjene som nevnt i avsnitt 5.2.

5.5 Teknisk dokumentasjon

Erfaringsmessig dokumenteres ikke spesiell tilgjengelighetsfunksjonalitet godt nok. Dette er uheldig av mange grunner:

Funksjonalitet kan bli borte eller ødelagt i forbindelse med oppgraderinger eller innføring av ny funksjonalitet.
Superbrukere og IKT-personell som ikke var med på utviklingsprosjektet vet ikke om tilgjengelighetsfunksjonaliteten i systemet.
Kunnskap om de løsningene som er utviklet videreføres ikke i forbindelse med videreutvikling eller nye prosjekter.
...

Sørg for teknisk dokumentasjon av tilgjengelighetsfunksjonalitet. Dette må skrives slik at utviklere som ikke var med på prosjektet også har nytte av dokumentasjonen.

6. Drift

Datasystemer utvikles for å settes i drift. Driftfasen har ikke vært en direkte del av NHF-prosjektet, men noen generelle tips tas med under. UU skal også settes i drift:

Opplæring av nyansatte (jfr. 5.1, 5.2 og 5.4)
Brukerstøtte (jfr. kapitlene 1 til 5)
Videreutvikling (jfr. 5.5)

6.1 Oppsett av spesielt klientutstyr

Klientutstyr for funksjonshemmede har ofte oppsett som skiller seg fra organisasjonens standard:

Datatekniske hjelpemidler (talegjenkjenning, skjermleser/forstørrer, øyestyring, bryterløsninger, ...).
Spesiell oppsett av programvare (høy kontrast, minimering av synlige objekter i brukergrensesnittet, ...)
Økte rettigheter (f. eks for å kunne surfe eller for å få hjelpemidler til å fungere)
...

Etabler gode rutiner slik at disse spesialmaskinene ikke mister brukerspesifikke oppsett og at også dette klientutstyre huskes i forbindelse med oppgraderinger.

7. Huskeliste for universell utforming i utviklingsprosjekter

7.1 Universell utforming

Universell utforming må integreres som prosess og virkemiddel. Dette innebærer fokus på fysisk tilgjengelighet til møteplasser (inne og ute), dokumenter, kommunikasjon osv. Det å kreve eller teste at et sluttprodukt er universelt utformet er vanskelig.
Utvikling skal ta høyde for at mennesker har ulike forutsetninger og behov. Dette gjelder i alle prosjektfaser fra ide til drift.

7.2 Prosjekt-team, kompetanse og kommunikasjon

UU må tas med som en av forutsetningene når det settes sammen prosjekt-team.
Eksperter og brukere med nedsatt funksjonsevne må delta fra starten av i prosjektet.
Sjekk kompetanse og referanser for UU-eksperter.
Sørg for en seriøs utvelgelse av brukerrepresentanter og at disse har nødvendig IKT-kompetanse.
Vurder nøye om prosjektet er tjent med ekspertbrukere eller om mangelfull IKT-kompetanse ikke spiller noen rolle.
Sørg for at all informasjon og kommunikasjon er universelt utformet, dvs. hele prosessen! Dette gjelder alle presentasjoner, møter, Brainstorminger, forslag til funksjonalitet, hva som skal lagres, Metadata, ...
Alle må gis god innføring i hovedfunksjonaliteten til det som skal utformes, f.eks. hva er et CRM-system, hvordan integreres CRM mot andre systemer (f.eks. økonomi, intranett etc) og andre forutsetninger som er viktige for å kunne delta/dele kompetanse på en god måte i prosjektet.
Lær utviklerne grunnleggende hjelpemiddelfunksjonalitet.

7.3 Spesifikasjon

Dra nytte av kreativiteten og strategiene til mennesker med nedsatt funksjonsevne i ideutviklingsfasen.
Identifiser behovene til funksjonshemmede tidligst mulig. Disse behovene kan føre til merverdi for alle.
Kartlegg aktuelle retningslinjer og standarder som kan brukes for å oppnå tilgjengelighet og UU.
Vær tydelig i konkurransegrunnlaget/kravspesifikasjonen mht. hva som menes med UU.
UU skal være en integrert del av konkurransegrunnlaget/kravspesifikasjonen, dvs. UU skal ikke trekkes ut som et separat avsnitt, kapittel e. l.
Be leverandørene om å dokumentere hva de kan om UU.
Krev dokumentasjon på tilgjengelighet og hvilke praktiske og tekniske begrensninger som eksisterer i forhold til å endre på standardløsninger.

7.4 Implementering

Eksisterende utviklingsmetoder sikrer ikke UU, men ulike metoder kan antageligvis fungere gitt at UU blir en integrert del av hele utviklingsløpet.
Sørg for å benytte teknikker som involverer brukere (brukersentrert design).
Ha med eksperter på ulike forutsetninger og behov for å sikre kunnskap som ikke nødvendigvis gjenfinnes blant de brukerne som er direkte engasjert i prosjektet.
Egnede testmiljøer bør planlegges tidlig i prosjektet for å unngå praktiske problemer når det er klart for brukertesting.
La UU-eksperter teste og komme med råd før "vanlige" sluttbrukere tester.

7.5. Opplæring og dokumentasjon

Sørg for at opplæring tar høyde for at systemet kan brukes på ulike måter.
Brukere med spesielle behov må kanskje tilbys alternativ opplæring.
Skriv forståelig dokumentasjon.
Dokumentasjon må testes av brukere, spesielt av de som ikke har deltatt i utviklingsprosjektet.
Lag dokumentasjon som tar høyde for alternative brukergrensesnitt.
Minst en superbruker bør gis opplæring og ha et spesielt ansvar i forhold til den eller de brukerne som benytter spesielle hjelpemidler.
Lag teknisk dokumentasjon for all tilgjengelighetsfunksjonalitet.

7.6 Drift

UU skal fortsette inn i driftfasen.
Lag gode rutiner for oppsett og vedlikehold av spesielt klientutstyr.

8. Referanser

1. Authoring Tool Accessibility Guidelines (ATAG)
http://www.w3.org/TR/ATAG/

2. User Agent Accessibility Guidelines (UAAG)
http://www.w3.org/TR/UAAG/

3. Web Content Accessibility Guidelines (WCAG)
http://www.w3.org/TR/WCAG/

4. Accessible Rich Internet Applications (WAI-ARIA)
http://www.w3.org/TR/wai-aria/

5: W3C/WAI
Involving Users in Web Projects for Better, Easier Accessibility
Sjekket (17.12.2010): http://www.w3.org/WAI/users/involving

6: W3C/WAI
Involving Users in Evaluating Web Accessibility
Sjekket (17.12.2010): http://www.w3.org/WAI/eval/users

7: Tynne klienter og hjelpemiddelteknologi
Sjekket (06.01.2011): http://www.medialt.no/tynne-klienter-og-hjelpemiddelteknologi/930.aspx

8: Universell teknologi
http://www.medialt.no/redirect/629.aspx

10. Hva er universell utforming innen IKT?
http://www.medialt.no/hva-er-universell-utforming-innen-ikt/242.aspx

11: Kunderelasjonshåndtering
http://no.wikipedia.org/wiki/CRM

12: Lovdata (2009)
Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne
Sjekket (30.11.2010): http://www.lovdata.no/all/nl-20080620-042.html

13: Center for Universal Design
Sjekket (16.12.2010): http://www.design.ncsu.edu/cud/

14: SHDIR
Universell utforming over alt!
Sjekket (16.12.2010):
http://www.helsedirektoratet.no/publikasjoner/veiledere/universell_utforming_over_alt____artikkelsamling_2942

15: SHDIR
Tilgjengelige møter, kurs og konferanser
Sjekket (17.12.2010): http://www.helsedirektoratet.no/vp/multimedia/archive/00001/IS-1137_1120a.pdf

16: Universal User Competence (UUC)
Sjekket (20.12.2010): http://www.medialt.no/universal-user-competence-uuc/733.aspx

17: Universell utforming i offentlige anskaffelser
http://www.universelleanskaffelser.no/

18: Rudolph Brynn og Haakon Aspelund (2006)
Universell utforming i offentlige anskaffelser
Sjekket (21.12.2010): http://ww.helsedirektoratet.no/vp/multimedia/archive/00013/Veileder_Universell__13513a.pdf

19: DIFI
Krav til utforming av nettsteder i forhold til Referansekatalogen
Sjekket (21.12.2010): http://standard.difi.no/artikler/2010/02/krav-til-utforming-av-nettsteder-i-forhold-til-referansekatalogen

20: Aditya Agrawal
Accessibility in CRM 2011 lists
Sjekket (04.01.2011): http://blogs.msdn.com/b/crm/archive/2010/12/27/accessibility-in-crm-2011-lists.aspx

21: Wikipedia
Scrum
sjekket (04.01.2011): http://no.wikipedia.org/wiki/Scrum

22: Nettborger
Sjekket (04.01.2010): http://www.medialt.no/nettborger/951.aspx

23: Tom Vavik
Brukervennlighet i produktdesign
Sjekket (06.01.2011): http://itfunk.org/docs/Nyheter/Artikkel-brukervennlighet.htm

Vedlegg 1: Noen aktuelle standarder

Standard Norges Handlingsplan for universell utforming innen standardisering fra 2004 ga følgende oversikt:
EN 1332-1 Identification card systems – Man-Machine Interface Part 1: Design principles for the user interface
EN 1332-2 Identification card systems – Man-Machine Interface Part 2: Dimensions and location of a tactile identifier for ID-1 cards 2002
EN 1332-3 Identification card systems – Man-Machine Interface Part 3: Key pads
EN 1332-4 Identification card systems – Man-Machine Interface Part 4: Coding of user requirements for people with special needs
PREN 1332-5 Identification card systems – Man-Machine Interface – Part 5: Raised tactile symbols for differentiation of applications on ID-1 cards (under arbeid)
prEN 1332-6 Identification card systems – Man-Machine Interface – Part 6: Provisions for physical accessibility, including wheelchair user access, to card reading devices
ISO/IEC 19778-1 ITLET – Collaborative Technology – Collaborative Workplace
ISO/IEC 19779-1 ITLET - Collaborative Technology – Agent to Agent Communication
ISO/IEC 19780-1 ITLET - Collaborative Technology – Learner to Learner Interaction Scheme.
ISO/IEC 24703 Information Technology – Participant identifiers
ISO/IEC 19786 ITLET – Participant accommodation information
ISO/IEC 19787 ITLET – Participant performance information
ISO/IEC xxxx ITLET – Competency, impairments, and performance metrics NP Ballot For ITLET Description of language capabilities
ISO/IEC 19783 ITLET Management and delivery – Framework for data models and binding
ISO/IEC 19788 ITLET Metadata for Learning Resources NP Ballot For ITLET Specification and use of extensions anf profiles [technical report]
ISO/IEC 19796 ITLET Quality Management, Assurance and Metrics NP Ballot For ITLET Descriptive framework for learning, education and training
ISO/IEC xxxxx ITLET Profiles of standards and specifications
ISO/IEC xxxx-N ITLET Profiles of standards and specifications – Part N: Profile of Rights Expression Language
ISO/IEC 18035 Information technology -- Icon symbols and functions for controlling multimedia software applications
ISO/IEC 18021 Information technology -- User interfaces for mobile tools for management of database communications in a client-server model
ISO/IEC 9995-7 Information technology -- Keyboard layouts for text and office systems -- Part 7: Symbols used to represent functions
ISO/IEC 9995-4 Information technology -- Keyboard layouts for text and office systems -- Part 4: Numeric section
ISO/IEC 9995-3 Information technology -- Keyboard layouts for text and office systems -- Part 3: Complementary layouts of the alphanumeric zone of the alphanumeric section
ISO/IEC 9995-2 Information technology -- Keyboard layouts for text and office systems -- Part 2: Alphanumeric section
ISO/IEC 9995-3 Amd Information technology -- Keyboard layouts for text and office systems -- Part 3: Complementary layouts of the alphanumeric zone of the alphanumeric section – Amendment 1
ISO/IEC 9995-2 Information technology - Keyboard layouts for text and office systems - Part 2: Alphanumeric section AMENDMENT 1
ISO/IEC 11581-1 Information technology - User system interfaces and symbols - Icon symbols and functions - Part 1: Icons - General
ISO/IEC 11581-2 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 2: Object icons
ISO/IEC 11581-3 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 3: Pointer icons
ISO/IEC 11581-6 Information technology - User system interfaces and symbols - Icon symbols and functions – Part 6: Action icons
ISO/IEC 14755 Information technology – Pen based interfaces – Common gesture for text editing with Pen-based systems
ISO/IEC 14754 Information technology – Pen based interfaces – Common gesture for text editing with Pen-based systems
ISO/IEC 15412 Information technology – Portable computer keyboard layouts
ISO/IEC 15411 Information technology – Segmented keyboard layouts
TR 19765 Survey of existing icons and symbols for elderly and disabled persons
TR 19766 Design requirements concerning icons and symbols in IT for elderly and disabled persons
TR 19764 Guidelines, methodology and reference criteria for cultural and linguistic adaptability in information technology products
CWA 14661 Guidelines to Standardisers of ICT products and service in the CEN ICT domain
CWA 14835:2003 Guidelines for making information accessible through sign language on the web
CWA Availability of alternative language versions of a learning resource in IEEE LOM
CWA 14094 European Culturally Specific ICT Requirements
CWA 14051-1 Information Technology – European generic locales Part 1: General specifications
CWA 14051-2 Information Technology – European generic locales Part 2: Narrative cultural specifications, POSIX locales and repertoiremap
CWA 13873 Information Technology – Multilingual European Subsets in ISO/IEC 10646-1
CWA 14838 – Fastest (Multipart)
CWA 14838-3:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 3: Catalogue of Technical and Business Process Requirements
CWA 14838-2:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 2: Development of Smart Card Based Interoperable Ticketing Systems
CWA 14838-1:2003 Facilitating Smart Card Technology for Electronic Ticketing and Seamless Travel – Part 1: EU Policy and User Requirements
CWA 13987-1:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 1: Definition of User Related Information and Implementation
CWA 13987-2:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 2: Implementation Guidelines
CWA 13987-3:2003 Smart Card Systems: Interoperable Citizen Services: Extended User Related Information – Part 3: Guidelines to Creating, Operating and Maintaining an Interoperable Card Community

Vedlegg 2: MS DYNAMICS CRM / Jaws 10

Main Issue Areas:

Searching records in the system
Lookup fields
Sometimes function work properly, sometimes not

Prerequisites for using the system:

Jaws version 10

Jaws virtual mode is used as default.

Jaws virtual mode is usually most appropriate.

Scenarios:

New case to existing relation
New case to new relation

Scenario 1: New case to existing relation

The relation calls inn and the user opens the outlook interface
Selects the outlook CRM menu and navigates to cases and opens a new case
A title is typed in and by using the tab button navigates to the relation lookupfield
By pressing enter the search for relation pops up and the name is typed in and search is started
Challenge 1: When the search result shows the user experience is different when the result is one record or many records. When the result is one record the user does not see any table at all, however when there are more than one record the table shows, but does not show any column headers because these are stored outside the table. Some (probably the full) explanation for this is that column titles (-tags) are not used. When there is one record jaws present this by saying there are 20 columns and tre records in a table. When navigating in this is not read as a real table and jaws commands cannot be used. The user must in this case just understand that there is one hit and go directly to the OK button.
Challenge 2: When there are more than one record, the first record is presented as column header. The user navigates into the table until the right record. The problem now is to select this record. There are no links in the table to the specific record to be selected. This means that the user must “drag” the jaws cursor (mouse pointer) to the pc cursor (focus in the virtual mode) which means bringing the mouse to the right record jaws is reading. Then a left mouse click is needed before navigating to the OK button. By doing this the user has no real confirmation that the right record is selected.
Challenge 3: After selecting a relation coming back to the case, jaws does no longer keep focus in the field when navigating through the case window. When navigating in the window one would normally use jaws commands to move from field to field through jaws command F, but MS CRM does only accept this command in certain situations (between picklists, freetexts, numbers and bit fields). It does not work moving in and out of lookups or notes areas. In those cases the user must hit the tab button.
Challenge 4: When using tab into lookup fields jaws does not present which field it is (ex. Owner and relation lookup)
Challenge 5: Jaws has functionality to show all form fields and values in a list. This list is used to perform quick navigation to a spesific field by using the initial letter(s) in the field name. This functionality is very important: both to check values and for the screen reader to quickly focus on a spesific field. Values and names of lookup fields and notes are not shown in the list (See screenshot).
Challenge 6: When using shift tab to navigate from the “Saksopprinnelse” picklist below the notes field and into the notes area, jaws will read the last note correctly, but will present the note as being a value in the “Saksopprinnelse” field.

Scenario 2: New case to new relation

Challenge 7: The user navigates to the relation table and performs a search for Aatangen, Stig. There is one record hit, but the user does not see and table. Standard Jaws does not read search results with one record as a table which is the same result as when there are no hits at all. The information on how many results the search presents is hard to navigate to.
Challenge 8: When the Aatangen, Stig relation is selected one might want to move into the relations cases or history to see what mail have been tracked to the relation. This is fine to navigate into, but when these lists are presented it is hard to get any information on the result. How many records, If the activity I an email or task, and no column headers.

General conclusions:

Jaws commands and keyboard commands must be used alternately through the system.
There is a lack of information to the user regarding where in the system he/she is placed. One solution (perhaps the best) is to use the <title>-tag for this.
When opening a new area in the system (ex. Cases, relations etc) the user does not see that one has actually entered the right register.
The names of hidden links in the system are not available.
There is a general lack of structure from a screen reader point of view.
Lookup fields and notes are time consuming and too hard mentally (remember what to search for, when search is necessary etc). This (search results) and several other things should have been structured using <h>-tags.
The lack of structure (headings) is one of the most important problems for screen reader users.
For a screen reader user without much knowledge on MS CRM it is difficult to know when windows open inside Outlook or as standalone IE windows.
Search results and navigation into tables is hard and results and method varies when one or more records is the result of a search.
The information about number of hits in search is hard to find.
The system is possible to use but demand a lot of navigation, many rutines and commands and is generally hard and confusing to use.

Del på Facebook Del på Twitter Del på e-post

Hovedmeny