Januar 2010
Denne veilederen har blitt utarbeidet på vegne av Helsedirektoratet / Deltasenteret. Utførende organer var forskningsstiftelsen Norsk Regnesentral og rådgivningsbedriften Karde AS. Forfattere er:
Veilederen har blitt kvalitetssikret blant annet ved hjelp av brukerundersøkelser og evaluering av fageksperter. Forfatterne takker alle medvirkende og relevante brukerorganisjoner.
Deler av fagstoffet om kognitive funksjonshemminger er hentet fra fritt tilgjengelige nettkilder slik som Wikipedia og NAV. Fagstoffet er skrevet om for å gjøre det lett å forstå og mulig å benytte av andre enn fageksperter innen kognitiv psykologi.
Takk går til Brønnøysundregistrene og ÅstvedtGruppen AS for bistand i utarbeidelsen av personasene.
Målgruppen for denne veilederen er først og fremst profesjonelle nettredaktører og -utviklere samt bestillere av nettsider og -steder. Vi tror også mange selvlærte utviklere vil ha nytte av denne, for eksempel de som lager nettsider for frivillige organisasjoner eller klubber på dugnadsbasis, eller rett og slett for seg selv.
Hensikten med veilederen er å støtte redaktører og utviklere i deres arbeid for å gjøre elektroniske tjenester og innhold tilgjengelig for alle, men særlig for personer med kognitive utfordringer, slik som svekket hukommelse, lese- og skrivevansker, generelle lærevansker, og problemer med oppmerksomhet og kommunikasjon. Vi tror veilederens råd vil være mest verdifulle for å øke tilgjengeligheten for de nevnte målgruppene, men ellers for alle typer brukere.
Veilederen dekker en rekke ulike emner og bør egne seg spesielt godt som oppslagsverk. Veilederen dekker alle faser i et utviklingsprosjekt, fra planlegging og design til implementering og testing.
Det er ikke nødvendig å lese og lære alt fra begynnelse til slutt for å kunne dra nytte av veilederen. Det er selvsagt ingenting i veien for å gå rett til et konkret avsnitt dersom det er det man har behov for. Men mange vil sikkert også ha behov for mer kunnskap og ideer om metoder i design- og systemutvikling og kan gå rett på dette.
Det skal være lett å finne fram i veilederen. Gå inn i innholdsfortegnelsen og klikk på det emnet du er interessert i. Man vil finne kryssreferanser til beslektede emner gjennom hele dokumentet.
Veilederen er ment å være et levende dokument som kan utvikles, revideres og påbygges etter hvert. Spesielt gjelder dette de praktiske rådene for utviklere. Et nettbasert dokument gir mulighet for å gjøre oppdateringer og endringer raskt og effektivt. Spesielt nyttig vil det være å få erfaringer og synspunkter fra utviklere og personer i målgruppene.
Veilederen forutsetter en grunnleggende forståelse av teknologi som HTML og CSS, men man må ikke være ekspert i disse teknologiene for å kunne lage kognitivt tilgjengelige sider.
Utforming av nettsider for brukere med nedsatt funksjonsevne har lenge konsentrert seg om støtte til personer med sensoriske (for eksempel synshemming) og motoriske utfordringer (for eksempel Parkinsons sykdom). Dette er vel og bra, men det har lenge vært behov for mer støtte til personer med ulike typer av kognitive utfordringer. Denne sammensatte gruppen brukere er svært stor. Skal man følge kravene til universell utforming, må nettsider også gjøres tilgjengelig for denne gruppen. Det er dette denne veilederen tar sikte på å gjøre noe med.
Veilederen skal kunne brukes av alle som utvikler og utformer nettsider og nettsteder, og av nettredaktører, altså de som lager innhold for nettet.
Denne veilederen skal ses på som et tillegg til serien av veiledere utgitt av Deltasenteret de siste årene. Her er det mye nyttig informasjon med konkrete utformingstiltak og anbefalinger:
Med nedsatt funksjonsevne menes tap av eller skade på en kroppsdel eller i en av kroppens funksjoner. Dette kan for eksempel dreie seg om nedsatt kognitiv funksjon, eller ulike andre funksjonsnedsettelser. Men det er ikke slik at alle personer med nedsatt funksjonsevne blir reelt funksjonshemmet:
En funksjonsnedsettelse behøver ikke resultere i begrensninger i samfunnsmessig deltakelse. Funksjonshemning oppstår når det foreligger et gap mellom individets forutsetninger og omgivelsenes utforming eller krav til funksjon [referanse].
Funksjonshemming avhenger med andre ord av omgivelsenes og andre menneskers krav og forventninger. Funksjonshemmingen kan minskes ved at omgivelsene endres slik at tilgjengeligheten blir bedre.
Funksjonsnedsettelser kan være varige eller midlertidige. Mange mennesker har varig nedsatt funksjonsevne som kan skyldes skade eller sykdom. Antallet som får nedsatt funksjonsevne kan reduseres ved å sette fokus på forebyggende tiltak. Hjelpemidler vil ofte kunne bidra til å øke ytringsevnen og muligheten til deltakelse, men ofte vil ikke disse være tilstrekkelige for å kunne gjøre det man ønsker. Kravene fra samfunnet kan bli for store.
Alle mennesker vil oppleve funksjonshemming en eller annen gang. Her nevnes noen typiske kognitive utfordringer alle kan komme ut for som IKT-bruker:
Når en nettside skal utformes, må det tas hensyn til en rekke forhold. Mange med nedsatt funksjonsevne vil ha behov for særskilt tilrettelegging, men for at løsningene skal være universelt utformet må slike spesielle tilpasninger kunne integreres i de løsningene som tilbys alle. Universell utforming av IKT innebærer at utstyr og programvare kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for ytterligere tilpassing.
Universell utforming i Norge reguleres i all hovedsak av to lover: Loven om offentlige anskaffelser med tilhørende forskrift, og diskriminerings- og likestillingsloven. Utenom lovgivning i Norge har FN-konvensjonen [PDF-format] om rettighetene til mennesker med nedsatt funksjonsevne en svært viktig rolle.
Den er mer overordnet enn Norges lover i og med at den skal være gyldig i alle land, akkurat som menneskerettigheter. Etter at Norge har vedtatt konvensjonen, vil den gjelde som en lov selv om det er få som henviser til slike bestemmelser i hverdagens lovtvister. Norge har signert FN-konvensjonen, men ikke ratifisert den ennå. Undertegning innebærer en forpliktelse til ikke å handle i strid med konvensjonens formål. Det betyr at man tar sikte på å ratifisere på et senere tidspunkt.
Nedenfor omtaler vi lovene som stiller krav til universell utforming av IKT i bred forstand (herunder produkter, tjenester, informasjon og omgivelser som IKT er en del av). Nettstedet lovdata.no inneholder lovene i fulltekst.
I Norge står Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne sentralt.
Det er viktig å legge merke til at loven kun gjelder ved såkalt hovedløsning. Hva denne avgrensningen betyr er uklart før forskriften om universell IKT kommer. Denne er planlagt å bli ferdigstilt sommeren 2010. Videre gjelder loven for all IKT, det vil si TV, automater, nettbanker, minibanker og så videre. Loven skal anvendes når ingen annen lov gjelder, det vil si ikke på arbeidsplasser, skoler, kringkasting og telefoni fordi det der gjelder egne lover. Avgrensningen er særdeles uklar ved konvergerte medier/teknologier, for eksempel nett-TV. Enda en avgrensning er at løsningen skal være rettet mot allmennheten, det vil si til folk flest.
Det er grunn til å anta at internett i juridisk forstand er del av allmennheten, og selvbetjeningsautomater likeså. I begge sammenhenger vil loven da åpenbart gjelde for tjenester for informasjon, kjøp/salg, ekspedering av saker og så videre. Den vil også gjelde for nødvendig ekstrautstyr, for eksempel diverse hjelpemidler. Loven har også en avgrensning mot programvare som produkt (for eksempel programvare som kjøpes via nettbutikk: butikkens nettside reguleres av loven, men ikke produktet man kjøper).
Difi har det praktiske forvaltningsansvaret for loven, og holder på med å bygge opp en stab. Difi arbeider med å utarbeide forskriften, og å samle standarder som skal følges. (Slike finnes, men de må operasjonaliseres.) Difi blir lovens tilsyns- og klageorgan.
Her gjengir vi de viktigste utdragene fra Lov om offentlige anskaffelser og forskrift om offentlige anskaffelser. Utdragene nevner universell utforming og er spesielt interessante for bestillere av IKT-løsninger.
Statlige, kommunale og fylkeskommunale myndigheter og offentligrettslige organer skal under planleggingen av den enkelte anskaffelse ta hensyn til livssykluskostnader, universell utforming og miljømessige konsekvenser av anskaffelsen.
(8) Oppdragsgiver skal under planleggingen av den enkelte anskaffelse ta hensyn til livssykluskostnader, universell utforming og miljømessige konsekvenser av anskaffelsen.
I denne forskrift menes det med: I. universell utforming: utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene slik at virksomhetens alminnelige funksjon kan benyttes av flest mulig.
1. ved vare- og tjenestekontrakter: en spesifikasjon fastsatt i et dokument, som fastsetter de egenskaper, ved en vare- eller tjenestekontrakt, som oppdragsgiver krever. Dette omfatter for eksempel kvalitetsnivå, miljøkrav, universell utforming, overensstemmelsesvurdering, funksjonsdyktighet, bruken av produktet, sikkerhet, dimensjoner, herunder forskrifter som gjelder handelsbetegnelse og terminologi for produktet, symboler, tester og testmetoder, emballering, merking og etikettering, bruksanvisning, produksjonsprosesser og -metoder, samt prosedyrer for overensstemmelsesvurdering.
(1) Anskaffelsen bør spesifiseres ved en behovsspesifikasjon eller angivelse av funksjonskrav. Ved utformingen av kravene skal det legges vekt på livssykluskostnader og miljømessige konsekvenser av anskaffelsen. Det skal så langt det er mulig stilles konkrete miljøkrav til produktets ytelse eller funksjon. Når det er mulig skal spesifikasjonene utformes slik at det tas hensyn til kriterier for tilgjengelighet for funksjonshemmede og universell utforming.
(1) Anskaffelsen bør spesifiseres ved en behovsspesifikasjon eller angivelse av funksjonskrav. Ved utformingen av kravene skal det legges vekt på livssykluskostnader og miljømessige konsekvenser av anskaffelsen. Det skal så langt det er mulig stilles konkrete miljøkrav til produktets ytelse eller funksjon. Når det er mulig skal spesifikasjonene utformes slik at det tas hensyn til kriterier for tilgjengelighet for funksjonshemmede og universell utforming.
Kognisjon betyr erkjennelse. Begrepet kognisjon blir brukt om det å tilegne seg og bruke kunnskap. Hjernen mottar inntrykk og informasjon via sansene syn, hørsel, lukt, smak og berøring. Kognisjon refererer til prosesser som skjer i hjernen når vi mottar, lagrer og bearbeider inntrykk og informasjon. Den gjør at vi forstår og kjenner igjen ting, tenker og tilegner oss kunnskap.
Forskere innen IKT og brukergrensenitt for ulike typer brukere skiller ofte mellom to ulike typer av tilnærminger til kognitive funksjonshemminger:
Noen av de viktigste funksjonelle kognitive kategorier av funksjonshemminger omfatter problemer eller svikt når det gjelder:
En viktig grunn til at disse funksjonelle kategoriene av
funksjonshemminger er relevante med hensyn til tilgjengelighet, er
at de gir utviklere av
IKT-systemer
en bedre forståelse av utfordringer og
løsningsmuligheter.
Å si til en utvikler
at noen har en erhvervet hjerneskade
eller lærevansker
er ikke
særlig meningsfylt hvis ikke utvikleren får vite mer konkret hva denne
skaden eller nedsettelsen betyr, og hvilke konkrete hindringer en person
med slik skade eller nedsettelse vil møte.
På den annen side, hvis utvikleren får vite at noen har problemer med lesing, så kan dette straks gi utvikleren en forståelse og et rammeverk for å kunne tenke og planlegge IKT-løsninger overfor en slik gruppe. Tilsvarende, hvis utvikleren får vite at brukeren har klare hukommelsesproblemer så vil dette være meningsfylt for utvikleren, og et godt utgangspunkt for videre konkretisering av hvordan disse problemene viser seg i praksis. En mer funksjonsorientert tilnærming kommuniserer på denne måten bedre, og er mer relevant for utviklere og redaktører.
Kognitiv svikt gir problemer med å bearbeide informasjon, det vil si med det å velge ut, forstå, lagre, gjenfinne, resonnere og kommunisere i forhold til den informasjonen man har mottatt. Derfor finnes det mange typer av kognitive funksjonsnedsettelser. Noen eksempler kan nevnes:
En person med kognitiv funksjonsnedsettelse har gjerne en kombinasjon av ovenfor nevnte problemer. Kognitive funksjonsnedsettelser kan skyldes medfødte eller ervervede hjerneskader, psykisk utviklingshemming, eller spesifikke problemer som dysleksi. Graden av mestring varierer med omfanget av problemet, den enkeltes erfaring og hvor godt omgivelsene er tilrettelagt. Normal aldring av hjernen fører også med seg kognitiv svikt [referanse]. Det samme gjelder for noen sykdommer.
Utfra et funksjonelt perspektiv på kognitive funksjonshemminger, er det klart at en stor andel av befolkningen møter ulike former for kognitive utfordringer. Det finnes ikke sikre tall for Norge, men det høye antallet personer med funksjonelle lesevansker ― én av tre [referanse] ― er en pekepinn på at også antallet IKT-brukere som har kognitive utfordringer, er betydelig. Det er derfor all grunn til å ta hensyn til de ovennevnte målgruppene under utforming av tilgjengelige nettsider, og ikke kun tilrettelegge for personer med sensoriske eller motoriske funksjonsnedsettelser.
I det følgende eksemplifiseres IKT-brukerens kognitive utfordringer innenfor tre viktige områder: konsentrasjonsvansker, nedsatt hukommelse, og lese- og skrivevansker.
Konsentrasjonsevne er evnen å avgrense oppmerksomheten, som gjør at man bevisst kan styre sine tanker og handlinger. Konsentrasjonsevne består av tre områder som spiller sammen:
For en IKT-bruker vil konsentrasjonsvansker gjøre det utfordrende å gjennomføre lengre prosedyrer. Dette vil bli synlig når man for eksempel skal tilegne seg kunnskap gjennom tekster og oppgaver (for eksempel e-læring), eller når man skal gjennomføre en interaktiv prosess hvor dialogen forutsetter nøyaktig informasjon på riktig sted og på riktig tidspunkt (som e-handel eller e-dialog med offentlige etater).
Hukommelse kan defineres som evnen til å lære ny informasjon, lagre denne og å hente den fram i ulike situasjoner senere. Hukommelse og læring henger derfor nøye sammen. Man skiller vanligvis mellom (inn-)læring av kunnskap, for eksempel fakta om et emne, og (inn-)læring av ferdigheter som sykling, skigåing, sying eller spilling på et instrument.
Det er også vanlig å inndele hukommelsen i korttidshukommelse og langtidshukommelse. Informasjon lagret i korttidshukommelsen er midlertidig. Dersom noe skal huskes over lengre tid, må informasjonen lagres i langtidshukommelsen. Rim og regler som huskes fra barndommen er et eksempel på informasjon i langtidshukommelsen. Det finnes mange husketeknikker for å lagre informasjon i langtidshukommelsen på en effektiv måte.
Et tredje begrep
innen hukommelse er arbeidsminne. Det er evnen til samtidig lagring og
bearbeiding av informasjon, i en parallell prosess
[referanse].
Et eksempel på dette
er en oppgave som denne:
Trekk 7 fra 100 og igjen 7 fra det svaret du får
.
Nedsatt hukommelse kan ramme både korttidshukommelse, langttidshukommelse og arbeidsminnet. For en IKT-bruker vil nedsatt hukommelse kunne bety mange problemer. Grunnleggende kunnskap om bruken av et IKT-program lagres i langtidshukommelsen. Det er dermed overveiende sannsynlig at arbeidet eller oppgavene ikke flyter som de skal dersom en bruker har svekket langtidshukommelse på dette området.
Det hender ofte at en IKT-bruker må overføre informasjon han/hun har slått opp et sted til et annet sted. Slik informasjon lagres i korttidshukommelsen. Dersom denne er svekket, kan overføring av nylig oppslått informasjon til ny sammenheng blir svært vanskelig.
Lese- og skrivevansker kan inndeles i generelle vansker og spesifikke vansker. Spesifikke lese- og skrivevansker kalles også dysleksi. Generelle lese- og skrivevansker kan ses ved generelle lærevansker, som ved psykisk utviklingshemming. Lese- og skrivevansker kan være forbundet med syn- og/eller hørselsproblemer.
Dyslektikere har gjerne problemer med å oppfatte, huske og bearbeide språklyder. De har problemer med å skille ut lydene i et ord, å huske bokstavenes lyder og å trekke lyder sammen til ord. De vil også kunne ha problemer med å huske ordbilder (hele ord). Noen har også problemer med å forstå innholdet i det de leser, og å formulere seg skriftlig. Selv om lesingen evt. blir bedre, vedvarer gjerne problemene med å skrive ord riktig [referanse]. Dyslektikere har ofte ingen andre kognitive problemer enn dette med lesing og skriving, men noen har også andre problemer, for eksempel med matematikk. Da kan det vare snakk om dyskalkuli, altså vanskeligheter med å forstå størrelsen av abstrakte mengder og tall.
Mennesker med lese- og skrivevansker sliter med forståelsen av sammenhengen mellom talt og skrevet språk, ordgjenkjenning og de spesifikke språklige kravene som ligger i en tekst. Slike vansker kan dreie seg om å lære bokstavene, å skille dem fra hverandre, å lære bokstavlydene eller å forme bokstavene. Dyslektikere leser ofte langsomt eller usikkert, skriver enkelte ord feil og strever med å skrive lengre tekster [referanse].
Bruken av IKT-baserte systemer utfordrer mennesker med lese- og skrivevansker. Både nettet og de aller fleste elektroniske eller interaktive tjenester innholder svært mye tekst. Ofte finner man lange setninger, komplisert språk, mange forkortelser og så videre.
Her vil vi minne om at alle
i blant har nedsatt
funksjonsevne på et eller annet vis.
Mennesker som ikke er kyndige i
IKT
mangler viktige ferdigheter for å kunne løse
tekniske problemer.
En bruker kan dessuten bli helt oppslukt av det tekniske og på denne
måten miste oversikten over hva som er viktig til ethvert
tidspunkt.
Noen (ofte eldre) brukere har dårlig korttidshukommelse og oppmerksomhetsvansker, altså en kombinasjon av flere kognitive hindringer. Til og med ekspertbrukere og personer med gode dataferdigheter kan møte utfordringer i situasjoner som er nye for dem.
For å oppsummere, så er tilgjengelig utforming som er skreddersydd for én spesiell brukergruppe, også til hjelp for alle andre brukere. Man må ikke glemme at en persons kognitive ferdigheter ikke er noe som aldri forandres. Ferdighetene kan øves opp og tilpasses omgivelsene, slik at man mestrer oppgaven bedre. Funksjonshemming er i realiteten svært situasjonsavhengig.
De følgende avsnittene dreier seg om forhold i planleggingsfasen og under utviklingen av selve løsningen. Vi presenterer metoder og teknikker som kan gjøre det lettere å forstå og ta hensyn til brukere med kognitive utfordringer.
Med brukermedvirkning menes at de som berøres av en beslutning, eller er brukere av tjenester, herunder IKT-baserte systemer og tjenester, får innflytelse på beslutninger og utforming som gjelder systemer eller tjenestetilbudet. Hensikten med brukermedvirkning er at utviklerne skal lære av brukerne. Brukermedvirkning handler om å utnytte kunnskap om brukere til å gjøre hensiktsmessige valg når det gjelder teknologi i bred forstand. Slik bidrar man til utvikling av inkluderende IKT. Grunntanken er at brukermedvirkning og brukersentrert systemutvikling gir brukervennlige systemer og tjenester. Brukerne får også eierskap til systemet gjennom medvirkning. Den brukersentrerte tilnærmingen forsøker å sikre at brukerne er med i systemutviklingsløpet for å bli informert, involvert og hørt, og at de kan bidrar til at systemet blir bra.
Brukersentrert systemutvikling innebærer å involvere brukere i alle faser av systemutviklingen fra kravspesifikasjon til testing og evaluering. Prosessen begynner med en systematisk analyse av brukernes ønsker, krav og behov før utviklingen starter. Brukere er meget sentrale når man skal lage kravspesifikasjoner som forteller blant annet hvilken informasjon som skal gis til systemet, hvilken rekkefølge oppgavene skal gjennomføres og hvilken informasjon brukeren skal motta. Man kan samle inn tilbakemeldinger fra brukerne for eksempel gjennom fokusgrupper, gjennomganger av eksisterende tjenester eller (papir)prototyper. Det er sentralt at man starter med brukernes behov, muligheter og begrensninger i stedet for de teknologiske mulighetene. Spesielt viktig er dette når det er snakk om brukere med spesielle behov, for eksempel personer med kognitive utfordringer.
Grundig brukbarhetstesting er viktig når produktet eller tjenesten begynner å ta form. Brukeropplevelsen av en tjeneste eller et system skapes gjennom brukergrensesnittet og dets interaktivitet. Man kan hevde at jo mindre brukeren legger merke til brukergrensesnittet og dialogen med systemet eller tjenesten, jo mer vellykket er utformingen. Brukere må derfor kunne gi innspill til hvordan informasjonen skal se ut og presenteres (brukergrensesnitt), og hvordan brukeren samhandler med datasystemet (interaktivitet).
Brukersentrert systemutvikling bidrar til høy brukskvalitet. Dette betyr at:
Brukermedvirkning gir også andre effekter, herunder følgende:
Når brukere med nedsatt funksjonsnivå ― for eksempel brukere med kognitive utfordringer ― er med i systemutviklingen, bidrar man til inkluderende utforming av systemer eller tjenester. Brukere med spesielle behov er derfor særdeles viktige medspillere i en systemutviklingsprosess. Økt tilgjengelighet gjennom inkluderende utforming har flere effekter:
Brukermedvirkning øker med andre ord tilgjengeligheten, og tilgjengelighet er lønnsomt.
Utvikling og bruk av personas er en velkjent metode for å gjøre seg kjent med en
brukergruppe. Innen
IKT-området
benyttes personas ofte for å
representere målgruppen brukere
. Personas kan benyttes i
forbindelse med kravspesifikasjon, utvikling, testing eller
markedsmessige avgjørelser for
IKT-baserte
produkter eller
tjenester. Persona-metoden kan dog aldri erstatte arbeid med ekte
brukere. Metoden er et tillegg til andre brukersentrerte metoder.
Personas er altså ikke ekte brukere, men oppdiktede portretter
av brukere. Det man faktisk vet om ekte brukerne dokumenteres i form av
personas. Malen for personas varierer en del. Her er ett mulig oppsett som kan
anvendes når man modellerer
personas som skal representere brukere
av
IKT-baserte
produkter eller tjenester:
I det følgende kan du laste ned beskrivelser på persona-eksempler.
Kartlegging av behov er avgjørende når man utformer personas for å gjøre brukergrensesnittet best mulig for brukere med kognitive utfordringer. Det er mulig å utvikle en persona med diagnosen dysleksi, men det er mer formålstjenlig å si at en persona har lese- eller skrivevansker. På tilsvarende måte trenger man kanskje ikke bruke begrepet begynnende demens eller MCI når det er nok å si at en persona sliter litt med å huske ting. Mange kan identifisere seg med en rotekopp, selv om det i virkeligheten kan dreie seg om konsentrasjonsvansker på grunn av ADHD. Utviklingshemming kan være grunnen til at abstrakt tenking eller problemløsing er krevende, men kanskje en hvilken som helst nybegynner har tilsvarende utfordringer som bruker?
Aller viktigst er å lære brukere å kjenne gjennom treffende
personas. Personas blir på mange måter arketyper, og de beskriver ofte
særegenheter innen den aktuelle målgruppen. Dette kan være spesielt interessant i
forhold til kravspesifikasjon for og testing av
IKT-baserte
produkter og
tjenester, fordi ekstrembrukere
vil avdekke behov som kommer alle
brukere til gode.
Ved hjelp av intervjuer, fokusgrupper, observasjoner, workshops,
statistikk og så videre henter man inn informasjon om representanter av
målgruppen. Deretter lager man fiktive brukere ― personas ― som
uttrykker forskjellige krav, ferdigheter, ønsker og behov. Observasjon
av brukere som hører til ekte
målgrupper er en metode som kan være
til stor hjelp når man skal lage troverdige personas. Ved å observere
de relevante brukerne over kortere eller lengre tid vil man få et
realistisk bilde av deres situasjon, og man kan
lettere se mulige løsninger som man ikke ville oppdaget kun på
bakgrunn av intervjuer aller andre analyser.
Minst like viktig som å bli kjent med brukeren, er det å bli kjent med brukssituasjonen der man kan sette produktet eller tjenesten i en realistisk sammenheng. Organisasjoner som har brukerstøttefunksjon vil kunne gi verdifull materiale om brukernes problemer hvorav mange kan bero på kognitive utfordringer.
En mulighet for å angripe brukernes kognitive utfordringer gjennom
persona-metoden er å benytte et rammeverk
som vi har valgt å kalle
RANDI. Hver bokstav representerer en brukerprofil, altså slik:
Helle, Johan, Linn og Thomas er eksempler på to rotekopp-personas og to dyslektiker-personas. Disse personas ble utformet som potensielle brukere av elektroniske registertjenester og et logistikksystem.
Når personas er utviklet vil de spille rollen
som brukere enten i
fasen når kravspesifikasjonen lages eller i testsituasjoner, eller begge. Da vil
scenarioer
kunne danne rammen for dette ― personas er jo ikke levende
brukere som man kan snakke med eller som kan sette seg foran skjermen
på ordentlig! Scenarioer kan i denne sammenheng være korte
fortellinger som nettopp peker på, og begrunner de brukerkravene eller
bruksegenskapene man er på jakt etter.
Personas engasjerer og øker bevisstheten om hele spekteret av
potensielle brukerne når målgruppen kan gjøres mer levende
.
Når det gjelder å finne mer informasjon på nettet om persona-metoden vil
mange resultater vises ved søkeord personas
.
Vi ønsker imidlertid å rette oppmerksomheten mot forfatterne
Pruitt og Grudin
[referanse]
samt
Quesenbery
[referanse]
når det gjelder internasjonalt anerkjente
publikasjoner om personas.
Scenario-metoden kan brukes for å strukturere og kommunisere tanker om
framtiden eller situasjoner. Slike situasjoner kan i vår sammenheng handle om
IKT-brukerens
hverdag eller en arbeidsdag der
IKT
blir brukt for å løse
(arbeids)oppgaver.
I scenarioer inngår utviklingsbaner
eller mulige hendelser som illustrerer framtiden på en troverdig
måte. De er med andre ord helhetlige fortellinger
som belyser situasjoner
eller sammenhenger på en realistisk måte. I forbindelse med
persona-metoden kan scenarioer brukes for å gi personasene omgivelser
som kaster lys på bruken av
IKT,
og utfordringer knyttet til denne. I
forbindelse med utvikling av
IKT-baserte
systemer kan scenario-metoden
bidra til utformingen av løsninger som tar høyde for spesielle
målgruppers ønsker, krav og behov, for eksempel unge personer med lese-
og skrivevansker, eller eldre personer med hukommelsessvikt.
I en prosess der man benytter scenarioer søker man å avdekke samspill og
avhengigheter mellom elementer innen et relevant temaområde, for
eksempel elektroniske tjenester til innbyggere (for eksempel offentlige
portaler), eller
IKT-systemer
til profesjonelle brukere (for eksempel
registrering av kundeinformasjon). Denne type scenarioer er gjerne
fokuserte korte fortellinger som beskriver situasjoner på en konkret
måte. En mer omfattende teknikk er å utarbeide flere ulike scenarioer
som er klart forskjellige alternativer, men samtidig realistiske. To helt
ulike, større scenarioer vil kunne være for eksempel
Informasjonssamfunn for alle
og Informasjonssamfunn for de flinke og
vellykkede
. I hvert samfunn vil
IKT-baserte
tjenester framstå helt
ulikt. Hvilken tilnærming til bruken av scenario-metoden man benytter, er avhengig av behov og tilgjengelige ressurser.
Uavhengig av valget mellom scenarioer som situasjonsbeskrivelser eller scenarioer som større alternative fortellinger, skiller scenario-metode seg fra andre, mer formelle metoder. Scenarioer presenteres vanligvis som prosa, gjerne krydret med treffende illustrasjoner. Scenario-metoden er tidskrevende, men den har til gjengjeld mange gode egenskaper:
avanserteidéer.
stammespråk.
Nedenfor gir vi en liten smakebit av scenario-metoden i forbindelse
med utforming av nettbaserte tjenester.
Da disse fortellingene ble laget var oppgaven å tenke på
kognitive utfordringer og
IKT.
For å få fram brukerkrav for
tilgjengelige nettjenester, ble brukssituasjonen flyttet til bilen og
til stuen. På skjermen ser både Tom og Aud en nettside
, selv om Tom
har mobiltelefonen som sluttbrukerutstyr, og Aud har
digital-TV.
Etter de to scenarioene finnes spørsmål som ble brukt i analysen av hva
tilgjengelighet egentlig
betyr.
Scenario-metode blir brukt i mange sammenhenger. Den har blitt dokumentert i boks form og som notater på nettet. Et nettsøk vil gi mange interessante treff.
Rent og pent fra dør til dør
Tom startet i Nordisk Frakt i august 1992. Han hadde fått utmerkelsen
Månedens Sjåfør tre ganger i løpet av de siste årene, senest i oktober
2008. Han hadde aldri hatt kundeklager eller uhell med
kjøretøyet. På grunn av gammeldags, nedslitt bilpark og byråkratiske rutiner
gikk Nordisk Frakt konkurs, og Tom var uten arbeid i flere måneder.
I april 2009 besøkte han arbeidskontoret og fikk registrert seg i
Jobbmail som er en tjeneste som varsler arbeidssøkeren på e-postadresse
når det kommer inn sjåførjobber som passer ham. Det tok ikke mange dager
før telefonen ringte. Tom fikk ny jobb på dagen hos vaskeriet Rent og
Pent fra Dør til Dør. Det var akkurat Toms erfaring, kompetanse og
personlighet de var på jakt etter.
Rent og Pent fra Dør til Dør er del av en arbeidsmarkedsbedrift, og
den tilbyr vask og rens av tekstiler inkludert henting og
levering. Størsteparten av kunder er firmaer, hoteller og sykehus, men
også enkelte private kunder benytter seg av tjenestene. Spesielt
gardinvask for private kunder er en populær tjeneste. Man tar ned
gardinene, tar dem til vaskeriet, og henger dem opp igjen. Tom synes at
akkurat denne delen av kundetjenesten er spesielt hyggelig når man
oftest sitter alene i bilen uten å ha noen å snakke med.
Ellers består jobben av å gå gjennom dagens rute, og å registrere
henting, levering og avvik. For alt dette bruker Tom
mobiltelefonen. Selve de digitale kartene på mobilen er greie, men han
synes at ruteberegning og navigeringsfunksjonalitet er litt krøkkete å
bruke. Aller verst er endringer i kjøreruten om han selv vil kjøre i
annen rekkefølge enn hva den ferdige ruten viser, og det å skrive inn
meldinger om avvik for eksempel når kunden ikke er
tilstede. Hjelpetekstene er lange og vanskelige å forstå, og skriving er
nesten umulig. Tom har dysleksi, og det hele ender ofte i at han må
ringe til kontoret for å fortelle hva problemet er, og få dem til å
skrive inn avviksrapporten. Kanskje dette skyldes dysleksi, men faktisk
klager andre sjåfører over samme problem.
Uansett, DigiKart fungerer ikke helt som sjåførene ønsker, og det
oppstår mye krøll. Informasjonen i systemet blir ikke oppdatert, og
inneholder mange feil og mangler. Kundene blir sure, og
kontormedarbeiderne hisser seg opp. Noe bør gjøres, men hva?
Spørsmål for god tilgjengelighet for brukere med lese- og skrivevansker, og når det ikke skal vises mye informasjon av gangen (her illustrert med mobiltelefonens lille skjerm):
medieforbruker
Aud har nylig erstattet sitt gamle
TV-apparat
med moderne flatskjerm,
og abonnert på en digital kanalpakke. Bildekvaliteten er helt
fantastisk, og det er mulig å velge blant mange tilbud. Ved
hjelp av fjernkontrollen kan Aud velge både blant mange
TV-kanaler
og kommunale tjenester som også vises på
TV-skjermen.
Aud har klart å installere den såkalte set-top-boksen, og hun vet at
det er mulig å justere framvisningen til flere samtidige kanaler,
bestille spesialprogram, lagre
TV-program og så videre. Hun har lyst til å
prøve ut alle nye muligheter. Aud er en habil
TV-forbruker, men sliter
med både hukommelse, syn og hørsel. Den nye
TV-guiden
er krevende å bruke. Man skal kunne se hva som går nå,
eller hva som går snart og lete etter spesifikke program, men den virker
rett og slett alt for komplisert for Aud, og hun roter seg bort. Det hun
ønsker å få til er først og fremst teksting av alle program, og valg som
blir lagret slik at hun ikke trenger å foreta innstillinger om og om
igjen. Hun lykkes til slutt, men hun husker over hodet ikke hvordan hun
fikk det til.
Heldigvis fant Aud knappen
'Din TV-dag',
og våget å trykke på
den. Her kunne hun krysse av ulike alternativer som beskrev hennes
preferanser både med hensyn til innhold og presentasjon.
'Din TV-dag'
er ment for brukere som ikke ønsker å bla gjennom alle mulige alternativer
hele tiden, og justere på innstillinger.
'Din TV-dag'
var Auds redning. Hun kunne velge teksting av alle program, og velge
NRK
som startkanal når hun slår på TVen,
og vise en klokketavle øverst til høyre på
TV-skjermen.
Det var alt hun ville. I tillegg fikk hun adgang til
kommunens tjenester som hun trengte daglig eller månedlig ― ikke
minst en kobling til hjelpemiddelsentralen.
Spørsmål for god tilgjengelighet for brukere med orienteringsvansker og nedsatt hukommelse, det vil si når det ikke skal vises mye informasjon av gangen:
akkurat meg?
Papirprototyper er modeller laget av fysiske materialer. Papirprototyper brukes ofte i dialogen med brukerne når man ønsker å utforme IKT-baserte systemer og tjenester. Særlig utforming av brukergrensesnittet sammen med brukere er et anvendelsesområde av denne metoden. Da brukes papirprototyper for eksempel for å:
Papirprototyp er faktisk laget av papir eller lignende materiale i
stedet for å for å være programmert ved hjelp av en datamaskin. En slik
prototyp kan naturligvis ikke inneholde illustrasjoner av alle
funksjoner som det ferdige systemet skal ha, men det er likevel mulig
å illustrere sentrale elementer i utformingen. På overflaten kan papirprototypen
se nokså fullstendig ut, men den mangler vanligvis mange funksjoner
som den ferdige løsningen til slutt kommer til å ha.
Papirprototyper er på lik linje med andre prototyper nyttige hjelpemidler for å illustrere og kommunisere utformingsidéer til de involverte i en utviklingsprosess. Prototypene konkretiserer muligheter, og gjør det lett for de involverte å gi tilbakemeldinger.
Papirprototyper er lett å lage i forhold til programmerte prototyper, og de krever ingen spesiell dybdekunnskap om selve teknologien som man til slutt skal benytte. Det uferdige utseendet av papirprototyper forteller klart at utformingen ikke er ferdig. Dette gjør det også lettere for de involverte å kommentere prototypen.
Papirprototyper egner seg godt til å undersøke om brukere forstår betydningen av de ulike elementene i skissen til brukergrensesnittet (for eksempel knapper, overskrifter og så videre.), De egner seg også godt til å se om utformingen inneholder alle de opplysningene testpersonene behøver, eller om det er mulig å mate informasjon inn i systemet på en logisk måte. Gjennomgangen av en slik prototyp kan også gi informasjon om dette er det brukerne trenger.
Det er også morsomt
å lage papirprototyper sammen med
andre. Kreativiteten blir stimulert, og deltakerne henger seg ikke så
lett opp i detaljer og tekniske begrensninger. Deltakerne kan til og med
definere sine egne arbeidsmåter, symboler og teknikker. Det finnes ingen
regler som sier hva gule lapper kan eller skal representere,
eller om man skal bruke teip eller tråd for å illustrere
navigering.
Papirprototyper har selvsagt også sine begrensninger. Det er mange ting
som ikke så lett lar seg illustrere på papir. Eksempler på dette er
multimedia og interaktivitet generelt, animasjon, lyder og skrolling
.
Papir lever ikke. Det er heller ikke lett å måle hvor raskt
systemet vil fungere, nettopp fordi papirprototypen mangler de tekniske
begrensningene som reelle
IKT-systemer
har. Videre må deltakerne klare å
forestille seg at papirprototypen er et virkelig system eller
tjeneste, selv om det kun er laget av papir. Målet med
papirprototypen er å komme fram til et godt utgangspunkt for
videre utvikling.
Her er noen illustrasjoner av papirprototyper:
Vi viser også til forfatteren Carolyn Snyder med utfyllende informasjon [referanse].
Målet med brukertesting er å komme fram til et mest mulig feilfritt og
brukervennlig system, produkt eller tjeneste. Veien fram dit går via
kravspesifikasjoner og utvikling, til testing og forbedring. Brukertesting
av kan legges opp og vinkles på mange ulike måter. Nedenfor presenteres en
huskeliste
som kan benyttes når man skal planlegge og gjennomføre
testingen av et
IKT-basert
system, produkt eller tjeneste.
Brukertesting kan deles opp i fire hovedfaser:
Hovedbudskapet er at det er viktig å planlegge testingen godt, og gjennomføre den på en systematisk måte. I tillegg til det praktiske som presentert ovenfor, bør man fokusere på følgende momenter i den konkrete planleggingen av brukertesting:
like gode som rekrutteringen. Den lettvinte løsningen blir alt for ofte å rekruttere venner, kolleger, studenter eller familiemedlemmer. Dette er risikofylt med hensyn til påliteligheten av resultatene. Testbrukere skal representere framtidige brukere på en realistisk måte. Spesielt viktig er dette når testingen skal avdekke bruksegenskaper for brukere med kognitive utfordringer.
laboratorieaktige, og det er uvanlig å måtte snakke høyt om det man gjør. Mange testbrukere kan være redde for å gjøre
dummeting. For å skape en så god testsituasjon som mulig er brukerveiledningen viktig. Denne dekker alt fra beskrivelsen av hva testingen går ut på og hvor lang tid det kan ta, til den menneskelige siden av saken. I all skriftlig og muntlig kommunikasjon bør fagsjargong unngås.
Myk landing
tungetestoppgavene, kan det være lurt å spørre testbrukere hva deres forventninger til et slikt system eller teknologi er. I selve testsituasjonen vil spørsmål om førsteinntrykk være en praktisk vei videre. En myk avslutning vil være like verdifull for brukeren. En måte å gjøre dette på er å be om brukerens generelle kommentarer og eventuelle forslag.
Du har fått ny arbeidsgiver. For å unngå 50% skatt i første lønning, må du bestille nytt skattekort. Det du skal gjøre for å komme i gang er ...Dersom brukssituasjonen i virkeligheten ville kreve input fra omverdenen, som for eksempel epost som inneholder et passord, et brev eller lignende, må dette gis til testbrukeren så realistisk som mulig.
skyldfor dårlig utførte oppgaver. For å avdekke svakheter bør testbrukeren vanligvis ikke hjelpes videre med småtips eller forslag, med mindre testen fortsetter på en naturlig måte etterpå. Kommunikasjon for å få testbrukeren til å uttrykke seg klarere er selvsagt tillatt.
Brukertesting kan for eksempel dreie seg om å utføre tester innenfor ett eller flere av følgende emneområder (med eksempler):
luftignok (ikke
tettpakket).
Innenfor hvert emneområde bør man bestemme seg for hvilke temaer eller
egenskaper som skal stå i fokus.
Derfor er det viktig å avgrense testingen, og å utforme klare
kriterier for karaktersetting
. Dette kan gjøres ved hjelp av et
skjema som observatører eller testleder bruker mens testbrukere
gjennomfører sine oppgaver, for eksempel slik:
| Nummer | Krav/kriterium | Kilde | Prioritet | Vurdering | Forklaring på hva som skjer i testsituasjonen | Handling for å rette opp feil eller mangler |
|---|---|---|---|---|---|---|
| Eksempel | Universell utforming, prinsipp 4 | H (høy) / L (lav) | J (ja) / N (nei) eller karakter | |||
| 1 | ||||||
| 2 | ||||||
| ... | ||||||
| n |
Resultatene skal presenteres gjennom grafiske sammendrag som følger:
Per utformingsprinsipp eller prinsippkategori (for eksempel navigering eller
feilmeldinger) kan fordeling av karakterer vises visuelt. Ulike
varianter av trafikklys
blir ofte benyttet i presentasjonen av
testresultater:
| Prinsipp | Kategori 1 | |||
|---|---|---|---|---|
| Mangler | Dårlig | Middels | God | |
| 1.1 | x | |||
| 1.2 | x | |||
| 1.3 | x | |||
| 1.4 | x | |||
| 1.5 | x | |||
| 1.6 | x | |||
| 1.7 | x | |||
| 1.8 | x | |||
| 1.9 | x | |||
| 1.10 | x | |||
I den samlede evalueringen vil fordelingen av karakterene gi en pekepinn på hvor god utformingen er.
Det er selvsagt mulig å utvikle mange ulike presentasjoner av systemets eller tjenestens egenskaper. Det viktigste er dog å kunne peke på det som er vellykket, og å kunne gjøre forbedringer der hvor problemene vises tydeligst. Innenfor problemområdene må vurderingene rettes både mot innholdet av de ulike prinsipper og anvendelsen av dem.
De følgende rådene retter seg spesifikt mot utvikling av nettsider
for mennesker med kognitive vansker.
Rådene vil også være
relevante og nyttige for alle typer av brukere,
som forklart i
eget avsnitt.
Et råd skal ses på som en
anbefaling.
Rådene er basert på
ulike kilder. Noen råd er basert på erfaringer fra ulike tildligere
forskningsprosjekter som forfatterne har deltatt i. Andre er basert på
utprøvinger og tester som er foretatt i forbindelse med utarbeidelsen av
denne veilederen. Enkelte råd er også basert på annen forskning og
beste praksis
-erfaringer.
Hvert råd består av områdestikkord/emne, problembeskrivelse, løsningsforslag og konkrete eksempler.
Konkrete eksempler er basert utelukkende på HTML siden arbeidet med XHTML er blitt stoppet. Ved alle eksempler har vi lagt vekt på tilgjengelighet, bruk av standarder og samspill mellom ulike typer nettlesere og operativsystem (interoperabilitet). Alle eksempler forutsetter grunnleggende kunnskap om nettstandardene HTML og CSS, samt noe DOM og JavaScript. For sistnevnte vil et enkelt nettsøk resultere i mye nyttig informasjon.
Det som gjør en side uoversiktlig, er ofte utydelige skillelinjer mellom sideelementer og innhold som er for spredt. Dette kan gjøre det vanskelig å orientere seg på siden. Dessuten hindrer ustrukturert tekst en kjapp og effektiv tekstforståelse.
Tekstinnhold bør presenteres på en strukturert måte. Eksempler på dokumentstrukturer er avsnitt og lister som danner små, logiske og lett forståelige enheter. En overskrift bør oppsummere strukturens tema slik at brukeren lett kan skille relevant fra irrelevant innhold.
Lister kan være definisjonslister med et nøkkelord foran og forklaring bak, opptellinger, kulepunkter eller rett og slett en vannrett eller loddrett rekke av listepunkter i bokser med tydelige skillelinjer.
Tydelige marger og rom mellom elementene bør sørge for klare skillelinjer.
Bruk passende HTML-elementer tydelig for å markere dokumentstrukturen som vist i følgende eksempel. Overskrift bør stilles foran tekstavsnitt dersom det er hensiktsmessig.
Koding:
For innhold det ikke finnes passende
HTML-elementer
til,
kan de generiske elementene
div og
span
benyttes som vist i det
følgende.
Marger kan effektivt lages ved hjelp av stilreglene
margin, margin-top og så videre.
og
padding, padding-top og så videre:
Lange avsnitt med mange setninger gjør det ofte vanskelig å forstå teksten. Mange brukere "hopper" over lengre avsnitt med tekst og tar seg ikke bryet med å lese gjennom.
Unngå for mye sammenhengende tekst og hold avsnitt korte. Bruk kun få setninger per avsnitt. Det finnes ikke fasitsvar når det gjelder et maksimalt antall setninger per avsnitt, og det er derfor viktig å bruke skjønn.
Lange og uforståelige setninger, kompleks setningsstruktur og upresise formuleringer kan være vanskelig å forstå.
Del opp lange og kompliserte setninger i flere kortere og enklere setninger. Bruk andre formuleringer hvis de er kortere og lettere å forstå. Husk at det er ingen skam å sette punktum.
Norsk tillater vilkårlig sammensatte ord. Lange, sammensatte ord kan være vanskelig å forstå.
Bruk korte og ikke sammensatte ord, der det er mulig. Noen betydninger kan gjøres lettere forståelig ved hjelp av bindestrek der grammatikken tillater det.
Unngå lange ord som i denne setningen:
Den informerer om hvor i nettstedshierarkiet man befinner seg.Bruk heller denne formen:
Den informerer om hvor i hierarkiet i et nettsted man befinner seg.Bruk av lange ord er også problematisk når det gjelder orddeling. Mange nettlesere foretar ikke orddeling med bindestrek. Det kan føre til at ordet stikker ut over sin tilmålte plass (her illustrert ved et rektangel):
Dette eksemplet skyldes følgende koding:
Det kan altså bli overlapp med annet innhold.
Det er også mulig at ordet blir flyttet på slik at en setning mister sin sammenheng:
Dette eksemplet skyldes denne kodingen:
For å unngå slikt må delingspunkter markeres i lange eller sammensatte ord. Resultat blir da:
Koding:
Alternativt for
­ kan
­ brukes.
Svært lange linjer med tekst, det vil si tekst i svært brede kolonner er vanskelige å lese.
Lag korte linjer eller smale kolonner med tekst. Det finnes ikke fasitsvar når det gjelder et optimalt gjennomsnittlig antall bokstaver per linje. Vi mener 60-100 tegn (inkludert mellomrom) er fornuftig ved lettlest innhold.
Gi avsnitt eller sideelementer som inneholder avsnitt en maksimal bredde. Dette gjøres i stilarket. Først tar vi for oss selve avsnittet:
Resultat:
Koding:
Stilark:
For et div som inneholder en eller flere
p blir stilarket:
For et helt dokument, hvilket garanterer at ingen linjer blir bredere enn spesifisert (med mindre det skjer at et ord ikke kan brekkes over flere linjer), ser stilarket slik ut:
body{max-width:42em}
Eksperimenter med verdien (her: 42) og tell antall
bokstaver på noen få linjer for å oppnå ønsket
resultat.
I motsetning til width tillater
bruk av max-width mindre
vindusbredder uten at den horisontale
scrollbaren
vises.
Muntlig språk, metaforer og slanguttrykk
kan være vanskelig å forstå.
Et eksempel er bruk av ordet vannspeil
i stedet for
stille vannoverflate
.
Unngå bruk av all form for tekst med overført betydning. Unngå bruk av muntlig språk, så vel som ord og uttrykk som ikke er vanlige. Må/vil du absolutt bruke dette, må alt som eventuelt kan føre til uklarheter, kommuniseres på alternativt vis.
I steden for å skrive
Dette var en kapital skuffelse!kan du formulere
Dette var en meget stor skuffelse!Er det ikke mulig å unnlate å bruke vanskelige begreper og vendinger, bør det legges til en forklaring. Denne kan stå enten i parentes eller skytes inn etter det vanskelige ordet/den vanskelige vendingen.
Dette var en kapital (meget stor) skuffelse! Dette var en kapital ― altså meget stor ― skuffelse! Dette var en kapital, det vil si meget stor, skuffelse!For noen brukere er fagterminologi og ekspertuttrykk ikke lett å forstå. Det samme gjelder uttrykk som utelukkende brukes på et annet språk. Mange brukere er dessuten ikke språkmektige og har vanskelig for å forstå låneord.
Unngå faguttrykk og kompliserende fremmedspråk. Dersom man ikke kommer utenom, bør alltid forklaring skrives.
Forklaring kan skrives som foreslått i eget emnepunkt. Alternativt kan problement løses slik:
Bruk en kombinasjon av
dfn og
a-elementet, og sett
title-attributen på
a-elementet.
Slik blir en kort forklaring vist i grafiske nettlesere
(som såkalt tooltip),
og uttrykket blir til en lenke som fører til en
definisjon.
Resultat:
Koding:
Stilark:
Forkortelser (som f.eks.) og akronymer (forkortelse med kun første bokstav per ord, som NRK) kan gjøre teksten vanskelig å forstå.
Bruk så få forkortelser og akronymer som mulig. Dersom disse ikke kan unngås, bør det alltid skrives en forklaring.
Unngå bruk av
acronym
ettersom den ikke er støttet i
XHTML 2
eller
HTML 5.
Bruk kun
abbr.
Bruk en kombinasjon av
abbr og
a-elementet, og sett
title-attributen til
begge.
Slik blir forkortelsen lest opp rett i en skjermleser,
og den blir vist korrekt som
tooltip
i en grafisk nettleser.
Videre blir uttrykket en lenke som fører til et avsnitt der
forkortelsen blir skrevet ut i sin helhelt og eventuelt
forklart.
Resultat:
Koding:
Stilark:
Ofte finnes innhold kun i én eneste form eller såkalt modalitet, for eksempel tekst. Dette er en ulempe for brukere som sliter med akkurat den aktuelle formen.
Presenter så mye av informasjonen som mulig på flere former/modaliteter. I tillegg er det viktig at alle modaliteter har høy kvalitet, og at bruken er gjennomtenkt. For eksempel må betydningen av et lite symbolbilde i tillegg til tekst være intuitivt forståelig. Bildet må være stort nok, det må være rett plassert og så videre. Andre eksempler på flere innholdsformer:
Det kan også være en fordel for noen brukere å ha tigjengelig flere varianter av samme modalitet. Et eksempel er avspilling av innholdsekvenser med forskjellige hastigheter. Varianter kan være
eller
En kombinasjon av to eller flere modaliteter fører til sterkere sanseinntrykk og at innholdet dermed oppfattes raskere. Dette gjelder spesielt for kombinasjonen bilde og tale.
Inkluder én (ofte brukt) modalitet på siden og i nærheten noen lenker til
sider med samme innhold i andre former.
Det skal være én form per side, og
en lenke per side/modalitet.
Det er en fordel med hjelp til navigering som Tilbake
-knapper
på disse sidene.
Da kan man raskt finne tilbake til den opprinnelige
siden.
Se også
eget emnepunkt.
Tiden innhold vises på kan være for kort til å oppfatte alt av relevans.
Hvis tekst blir vist i et avgrenset tidsrom, som for eksempel undertekst til film, bør varigheten av visningen være tilstrekkelig lang til at personer som leser sakte kan lese og forstå alt. Brukeren bør ha muligheten til å repetere innholdet, ta en pause under avspillingen, og kunne endre innstillinger som for eksempel avspillingshastiget.
I noen tilfeller er det nyttig å tilby flere valgmuligheter. Samtidig er det problematisk å presentere for mange alternativer om gangen og slikt bidra til at brukeren blir forvirret.
I situasjoner der brukeren må velge mellom flere alternativer, bør det vises så få alternativer om gangen som mulig. Dette gjelder nedrullister/rullgardin (drop-down lists), avkrysningsbokser (checkboxes) og enten-eller-knapper (radio buttons). Vi anbefaler å forsøke å redusere antall alternativer ved å strukturere informasjonen for eksempel i kategorier.
Sider som bryter med utforming som folk er vant til fra andre steder, er vanskelige å bruke.
En side bør være forutsigbar både når det gjelder utseende og oppførsel. Eksempler på dette er å vise innhold i rekkefølgen ovenfra-ned og venstre til høyre. Eksempelet gjelder dog kun når målgruppen har en vestlig kulturbakgrunn. Andre eksempler er søkefunksjon, datofelt, kontaktinformasjon med flere.
Internasjonale og nasjonale konvensjoner og regler bør følges. De nasjonale reglene bør vektes sterkere enn de internasjonale der de kommer i konflikt. Et eksempel er å følge retningslinjen ELMER for utforming av elektroniske skjemaer i Norge.
Bruk kjente
testverktøy,
følg
standarder
og andre
beste praksis
-regler
(et nettsøk på best practices
vil gi mye nyttig
informasjon).
Følg også med på diskusjonsfora på nettet og
fagtidsskrifter som
A List Apart.
Et nettsted hvor sidene har forskjellig utforming og oppførsel for identiske sideelementer, er vanskelig å lære og bruke.
Alle sider på et nettsted bør ha konsistent utforming og funksjonalitet, altså samme sideoppbygging, utseende, og virkemåte. Det brukeren har lært om hvordan nettstedet fungerer, skal hun/han kunne bruke overalt på samme nettsted.
Skill mellom innholdsstruktur (selve kodingen) og utforming (stilark). Legg opp til et system der ett stilark skal gjelde for alle sider på et nettsted, og et tilleggsstilark skal brukes for kun én spesifikk side.
Eksempel på et slikt hierarki:
<link rel="stylesheet" type="text/css" href="generisk.css"> <link rel="stylesheet" type="text/css" href="innlogging.css">Når problemer oppstår, er ofte brukeren overlatt til seg selv, uten mulighet for tilstrekkelig hjelp eller informasjon.
Det er viktig at brukeren får informasjon om en oppgave hele veien, som forklart i eget emnepunkt. I tilfellet problemer bør det finnes hjelp tilgjengelig med så relevant og spesifikk informasjon som mulig. Hjelpen bør inneholde mulige årsaker til problemet og mulige løsninger, og bør by på tiltak som hjelper til å løse problemet.
Hjelpen brukeren kan få, bør være løsninger med enveis informasjonsflyt og løsninger som gjerne er interaktive. Eksempler på det første er enkle hjelpesider som legger opp til at brukeren hjelper seg selv, og demonstrasjoner i form av instruksjonsfilmer (screencasts). Eksempel på det siste er ekspertsystemer som tillater at brukeren spør for eksempel ved å taste inn et spørsmål i tekstform.
Hjelpen brukeren får bør tilpasses brukerens behov. Det kan være alt fra tilbud om enkle hjelpesider til mer spesifikke demonstrasjoner, og hvis nødvendig også å tilby kontakt med brukerstøtte, det vil si mennesker. Terskelen for å kunne møte et menneske bør ikke være høy.
Eksempel på hjelpesystem med flere hierarkier:
Noen brukere får ofte for lite tilbakemelding/støtte fra en nettside, for eksempel i form av visuell hjelp, indikasjon av innhold og funksjonalitet som ligger bak et sideelement, og annen hjelp.
Et responsivt brukergrensesnitt støtter bruk av siden med visuelle tilbakemeldinger og annen form for help. Dette er ikke begrenset til de følgende eksemplene.
Erfaringer med brukertester viser at det er viktig at interaktiviteten ikke forvirrer brukeren. Dette gjelder spesielt når deler av siden eller hele siden blir påvirket av endringene utløst av brukerens handlinger.
En typisk fokuseffekt er skifte av bakgrunnsfarge:
Koding:
Stilark:
Det er viktig at fokuseffekten ikke fører til større sideforandringer som kan forvirre brukeren.
En implementasjon av verktøyhjelp kan se slik ut:
Koding:
For JavaScript-genererte faner vil et nettsøk resultere i mye nyttig informasjon.
Når det gjelder dynamisk forandring av formen på musepekeren, se knappeksempelet i et annet emnepunkt.
Nedenfor vises hvordan et felt brukeren skal taste inn data på, kan vise et eksempel som forsvinner når feltet får fokus.
Koding:
Store mengder med data kan være vanskelig å håndtere.
Store mengder med data bør kunne sorteres/kategoriseres etter valgte kriterier, og med pekere fra hvert kriterium inn i databasen. Slik vil en del brukere kunne velge den foretrukne måten å nærme seg dataene på. Vi ønsker å også å nevne at andre brukere med betydelige kognitive utfordringer vil oppleve slike valg som forvirrende og frustrerende fordi det blir for mye å forholde seg til. Det gjelder altså å bruke skjønn.
Data kan sorteres etter:
Også et fritekstsøk bør være mulig. For de som måtte fortrekke dette, bør hele databasen være tilgjengelig i liste- eller tabellform.
Det er samtidig viktig å begrense antall klassifiseringsmåter som beskrevet i eget emnepunkt.
I situasjoner der for eksempel kun ett utsnitt av en større datamengde blir vist,
kan det også være en fordel å antyde størrelsen med
fortsettelsestegn (...
).
Det er egentlig kun fantasien som setter begrensinger her. Et implementasjonsforslag er gjengitt i det følgende:
Koding:
Stilark:
Lenken bak fortsettelsetegnene bør føre til en opplisting av hele den alfabetiske kategoriseringen, mens de andre lenkene bør peke mot selve tjenestene.
Av ulike grunner tar svært mange nettsider ikke hensyn til brukerens generelle behov (for eksempel svaksynthet), eller konkrete behov (for eksempel søk etter bestemt informasjon).
Et nettsted bør helst tilby sine tjenester i personalisert
form, det vil si skreddersydd for enhver
bruker.
Innhold og funksjonalitet bør presenteres avhengig av
data som er lagret om brukeren i såkalte
brukerprofiler.
Et besøk av brukeren bør lagres, slik at funksjonalitet som
... brukt sist
og
... sett på forrige gang
,
samt forhåndsutfylling av data (som brukernavn) og annen
funksjonalitet (som tidspunkt for forrige besøk
og så videre) blir mulig.
De tekniske og funksjonelle mulighetene som brukerprofiler åpner
må dog alltid avveies med hensyn til
personvern.
Implementasjonen av profiler er teknologiavhengig. Såkalte informasjonskapsler (cookies) brukes svært ofte til å skape brukerprofiler. Til alternativene hører:
Mens noen brukere fortrekker navigering for å finne fram til den ønskete informasjonen, bruker andre heller søk for rask å innhente informasjon.
Et nettsted bør ha minst én søkefunksjon som tillater
raske oppslag av søkebegrep.
Brukeren bør kunne velge om søket skal foregå kun
innefor visse kategorier, som for eksempel
Hjelp
,
Produkter
,
Dokumentasjon
og så videre.
Det som kan hjelpe brukeren med å navigere er menyer, nettstedkart og navigasjonsknapper og andre tiltak som nevnt i eget emnepunkt.
Det viktigste med søk er at den bør føre til relevante og nyttige resultater.
I mange situasjoner må en person som er ute etter spesielt innhold eller en viss tjeneste, sile bort mye irrelevant informasjon. Dette koster mye krefter og tid, og betyr ofte også betydelige kostnader.
Det bør foreligge lettleste versjoner av kompliserte tekster, som lovtekster og fagartikler. Den lettleste varianten bør være førstevalg. Pekere bør så lede brukeren videre til informasjonen i sin helhet.
Store sider eller sideelementer med mye innhold betyr ofte at den ønskete informasjonen ikke er synlig i sin helhet. Følgelig er brukeren nødt til å rulle siden fram til den ønskete informasjonen. Dette gjelder spesielt vannrett rulling, men også loddrett rulling.
Unngå at man må rulle altfor mye ved å lage flere mindre sider og overskuelige sideelementer. Bruk så lenker som tillater lett navigering mellom delene med informasjon.
Overflødig informasjon og innhold som ikke er relevant i en gitt sammenheng virker forvirrende på mange brukere. Dette gjelder for eksempel innhold som er halvt gjennomsiktig eller vises med svakere farger fordi det ikke er relevant.
Vis kun innhold som er relevant i en gitt kontekst. Ikke vis irrelevant informasjon selv om den kan skilles fra relevant innhold. Ikke vis funksjonalitet (for eksempel knapper eller felter til utfylling) som ikke kan brukes på et gitt tidspunkt.
Når det gjelder skjemafunksjonalitet, unngå bruk av attributene
disabled og
readonly i
kodingen som i
eller
<input readonly name="navn" value="Ola">Mange brukere blir forstyrret av at mye på en side er i kontinuerlig forandring. Dynamiske sideelementer kan være animert grafikk, rullende eller blinkende elementer (flashing). Dette gjelder altså elementer som ikke nødvendigvis må være i fokus.
Unngå forandring av sideelementer som ikke må være i fokus, det vil si gjør disse statiske.
Bruk animasjoner i aGIF- eller Flash-format med omtanke.
Bruk dynamiske sideendringer implementert ved hjelp av JavaScript med måte.
Unngå bruk av blinkende sideelementer som tekst.
Når det gjelder sistnevnte, unngå bruk av stilregelen
text-decoration: blink.
Noen ganger er det lett å miste oversikt i kompliserte eller omfangsrike prosesser.
Lange eller komplekse oppgaver som brukeren må løse,
bør deles opp i flere mindre og enklere deloppgaver etter prinsippet
del og hersk
.
Hver av disse skal kunne løses med kun liten
tidsbruk.
Antatt at det finnes en mekanisme for innlogging bestående av valg av innloggingsmåte og selve innloggingen, som inntasting av brukernavn og passord. Da er det naturlig å dele innlogging opp i to deloppgaver.
Med andre ord skal ikke alt skje på én og samme side.
Det kan være en utfordring å få med seg viktige endringer på siden dersom disse skjer langt unna brukerens fokus eller til og med er usynlige. Dette er et problem særlig når mye på siden er i forandring samtidig.
Forandringer av deler av siden som vises bør skje gradvis og i nærheten av brukerens antatte fokus. Det er videre en fordel om endringer signaliseres ved å rette brukerens oppmerksomhet mot dette, som nevnt i eget emnepunkt.
Vises for eksempel en video med undertitler og tekstbokser med hjelpetekster sentrert i nettleservinduet, så skal undertitlene og tekstboksene ikke plasseres altfor langt unna midtpunket.
En bruker som skal loses gjennom komplekse prosesser, er ofte avhengig av hukommelsen for å finne seg til rette og orientere seg, og for å løse en gitt oppgave. Dette gjelder spesielt for oppgaver som er fordelt over flere trinn som beskrevet i eget emnepunkt.
Hukommelsesstøtte vil være til hjelp når brukeren skal forstå komplekse prosesser. Hukommelsesstøtten bør si noe om den generelle sammenhengen og forklare den konkrete deloppgaven brukeren holder på med. Samtidig bør den forklare hvorfor brukeren må gå gjennom oppgavedeler som brukeren ikke har valgt selv.
Gi også informasjon om gangen i hele prosessen, muligens også et beskrivende navn for deloppgaven. Brukeren må også få vite kravene til deloppgaven som skal løses, inkludert nøyaktige instruksjoner.
Generell sammenheng / overordnende prosess:
Du er i gang med å levere selvangivelsen.Konkret deloppgave:
I denne sammenheng må du logge deg på.Gangen i hele prosessen, sammen med et beskrivende navn på deloppgaven:
Steg 2 av 4: Valg av innloggingsmåteKrav:
Du trenger fødsels- og personnummer, ditt personlige passord og engangskode fra melding på telefon.Konkrete instruksjoner:
Velg et av alternativene for hvordan du vil logge inn.Skal brukeren loses gjennom flere oppgaver som henger sammen som beskrevet i eget emnepunkt, er det ofte vanskelig å huske hva de andre deloppgavene besto av. Mange brukere mister oversikten og navigeringsevnen ikke bare på store nettsteder, men også allerede på steder som omfatter kun noen få sider.
Navigeringen mellom de enkelte prosessene tillater brukeren å finne informasjon raskt ved å kunne gå fram og tilbake. De bør være mulig å gå til vilkårlige deloppgaver i en større prosess. Dette kan implementeres som knapper, og i noen tilfeller er det hensiktsmessig å vise deloppgavene under separate såkalte faner.
En annen mulighet er hierarkistien. Den inneholder informasjon om hvor i hierarkiet i et nettsted en bruker befinner seg.
Knapper til navigering:
Koding:
Stilark:
En enkel implementasjon av faner, som krever JavaScript for å
fungere, er vist i det
følgende.
Det er også fullt mulig å lage en versjon uten
JavaScript.
Implementasjonen viser hvordan en fane kan se ut i
steg 2 av 3 mulige steg.
Hvis lenken til en annen fane blir aktivert, bør et skript
flytte active-klassen
til det tilsvarende steget.
Koding:
Stilark:
Hierarkisti til navigering:
Koding:
Stilark:
Hierarkisti kalles også breadcrumb trail på engelsk.
For noen brukere kan det være vanskelig å forstå hva som er neste steg for å bli ferdig med en gitt oppgave.
Skal brukeren gjøre et eller annet konkret, er det nyttig å dra oppmerksomheten dit. Dette kan gjøres ved hjelp av dynamiske sideelementer (animerte grafikker/bilder og så videre) eller ved å presentere et sideelement i en stil som skiller det fra andre elementer.
Et eksempel på det siste er å utheve feltet som venter på input fra brukeren.
Et annet eksempel er et farget areal rundt musepekeren som beveger seg i en instruksjonsvideo som viser et opptak av skjermen.
Et forslag til hvordan framheve brukerfokus på felt for brukerdata
er vist i det følgende.
Merk at onfocus- og
onblur-attributene er lagt til av et skript
slik at de kun ligger i dokumenttreet om JavaScript
fungerer.
Koding:
Stilark:
Ved avspilling av multimediainnhold kan det gå altfor fort slik at brukeren ikke kan følge eller oppfatte innholdet.
Video, tale og andre innholdssekvenser bør presenteres med en hastighet som tillater brukeren å oppfatte og forstå informasjonen som skal formidles. Eventuelt bør innholdet kunne avspilles med flere hastigheter.
Avspilling av multimediainnhold, som animert grafikk, video- eller lydopptak, kan sette brukerens hukommelse på prøve.
Det er avgjørende at avspilling ikke varer lenger enn strengt tatt nødvendig. Hva som er nødvendig avhenger selvsagt av sammenhengen. En illustrasjon på dette er en instruksjonsvideo som viser hvordan man bruker interaktive skjemaer. Et opptak som viser den overordnete framgangsmåten kan ha en varighet på flere minutter uten at avspillingen vil oppleves som for lang å huske. En filmsnutt som viser informasjon om en spesifikk funksjonalitet bør derimot være kort.
Avspillingslengde av multimediainnhold bør tilpasses innholdets omfang og sammenheng. Det bør være lett for brukeren å stoppe og starte avspillingen og/eller spille av på nytt. Når det gjelder for eksempel screencasts og andre former for instruksjon i multimediaform, så bør videosnuttens lengde i hovedsak være noen få titalls sekunder, og ikke overstige et par minutter. Uansett: Her gjelder det å bruke skjønn.
Ved bruk av visuelle modaliteter, altså bilder/grafikk eller video, blir ofte unødvendig mye informasjon vist. Bilder og video kan bli for store, og de viser kanskje mye mer enn kun det arealet som bør være i brukerens fokus. Dette er spesielt problematisk når man viser bilder/video av nettsider (screendump/screencast). Da forvirrer man lett brukeren som ikke klarer å skille mellom bilde/video og resten av nettsiden. En annen feil er å lage video/bildefeltene for små slik at de ikke kommer til sin rett.
Bilder og video skal være passelig store, og de skal kun vise innhold av interesse for formålet. For en lysbildesekvens eller en video kan det være aktuelt å bruke zoom for å illustrere at kun et utsnitt vises.
Når likevel et større areal i et bilde skal vises, bør man markere de områdene der brukerens fokus skal være, for eksempel med rød farge. Se også eget emnepunkt.
Undertitler og tekstbokser i en video kan noen ganger være vanskelig å skille fra selve innholdet.
Undertitler og tekstbokser bør ha en lett identifiserbar grense og en bakgrunn som ikke er helt gjennomsiktig.
I det følgende eksemplet blir det vist et bilde som er innrammet av en streklinje. Slik kan et bilde lett skilles fra omgivelsen, selv om bakgrunnsfargene i bilde og omgivelsene eventuelt er like.
Opp på bildet er det lagt verktøyhjelp som en liten fane med forklaring. Også den framheves tydelig over selve bildet gjennom farge- og skriftbruk, samt kantlinjen, som denne gangen er gjennomgående.
Koding:
Stilark:
Det å åpne en lenke i en ny fane eller et nytt vindu forvirrer mange brukere, også de med gode IT-kunnskaper. Dette gjelder spesielt for lenker på samme nettsted som fører til sider med hjelp og assistanse.
Sider på samme nettsted bør åpnes i samme fane/nettleservindu. Nettsider bak lenker som peker mot andre nettsteder, kan åpnes i egne vinduer, men brukeren må varsles om dette på egnet vis.
Sider med veiledende innhold om andre sider bør ha lenker som guider brukeren tilbake dit de kom fra.
Vi viser tre muligheter for å varsle om at en side bak lenken åpner i et nytt vindu:
Koding:
Stilark:
Merk at bruk av
target-attributen
krever en såkalt
Transitional
Doctype.
For å gi mulighet til å navigere tilbake fra hjelpesiden, kan følgende løsning lages (følg lenken). Dette krever at begge sider åpnes i samme vindu.
Koding:
Knappens funksjonalitet baserer seg på JavaScript og blir derfor laget av et skript slik at den kun er tilgjengelig dersom JavaScript fungerer.
Tallmateriale kan være utilgjengelig for mennesker med dyskalkuli. Spesielt i forbindelse med interaktive skjematjenester på web må brukere ofte gi tallbasert input (taste inn tall), slik som datoer, PIN-koder og så videre. Nettbank kan være umulig å bruke for personer med dyskalkuli.
Når tall presenteres til bruker, vil syntetisk tale kunne
hjelpe. Oppleste tall kan være adskillig lettere å oppfatte enn
skriftlige tall. Når brukeren skal skrive inn tall, for eksempel
dato, vil visuelle hjelpemidler slik som pek og klikk
-kalender med
automatisk datoformattering kunne hjelpe.
Også når brukeren skal gi fra seg talldata vil
syntetisk tale kunne øke tilgjengeligheten. Det er imidlertid viktig
å sørge for sikkerhet og personvern når personlig informasjon (for
eksempel
PIN-koder)
leses opp. Brukeren bør bli gjort oppmerksom på
dette i forveien, og han/hun må kunne velge bort talefunksjonen.
Et eksempel på opplesning av tallmateriale er illustrert i det følgende. Funksjonaliteten for selve avspilleren bør også ligge bak knappen som vist, men er ikke tatt med her.
Koding:
Eksempel for inntasting av data med kalender-funksjonalitet:
Koding:
Eksempelet er basert på datepick
,
et programtillegg (plugin)
i JavaScript-biblioteket
JQuery.
Se dokumentasjonen der.
Selvsagt kan også andre JavaScript-bibliotek brukes, eller man kan
skrive JavaScript-koden selv.
Noen personer med funksjonsnedsettelser har tendens til å tro at
det de ikke forstår, skyldes deres egne begrensninger. Det kan gjelde
vanskelige eller rare
ord og uttrykk eller problemer med å bruke
funksjonaliteter på en nettside.
Andre reagerer med utålmodighet og frustrasjon når ting ikke
fungerer som de skal.
Teknologien en nettside og dens funksjonalitet bygger på, bør være basert på standarder. Nettsidene bør testes i en rekke ulike, moderne nettlesere i forskjellige versjoner, og i forskjellig versjoner av ulike operativsystemer.
Det må presiseres at det er det underliggende utseende og den generelle oppførselen som skal være den samme i alle nettlesere. Det skal derimot ikke forventes at sidene vises og oppfører seg likt til punkt og prikke overalt.
Følger man standarder som WCAG, vil man øke tilgjengeligheten for personer med funsjonsnedsettelser, også når det gjelder kognitive utfordringer.
Kvalitetssikring av innhold og funksjonalitet er viktig så ikke brukerne skal tro de selv er skyld i eventuelle vansker og problemer. Før publisering eller oppdatering av en nettside bør minst én annen person enn den som har skrevet siden/oppdateringen ha sett kritisk gjennom det hele.
Test løsningen med flere testverktøy, som HTML validator, CSS validator, Achecker, Wave og andre.
Test løsningen i flere av de mest populære nettlesere.
Test løsningen om mulig med scenarioer og fiktive brukere som beskrevet i eget avsnitt eller reele brukere.
En kvalitetssikrer bør kontrollere at alt fungerer som det skal før publisering. Han/hun bør også sikre seg at retningslinjer i denne veilederen er fulgt for å gjøre det lettest mulig for den som ser på siden, å forholde seg til innholdet.
En liten oppsummering til slutt. Den røde tråden som går gjennom alle anbefalinger, er at en nettside bør bli så oversiktlig og enkel som mulig. Løsningen bør bli sett fra brukerens perspektiv og ikke med teknologien som utgangspunkt. Når denne tenkningen legges til grunn for utviklings- og utformingsprosessen, vil også den endelige løsningen blir mye mer tilgjengelig. Slikt vil man også unngå store ekstra kostnader og bruk av ekstra tid for å gjøre løsningene universelt utformet.
Det finnes en rekke standarder innenfor tilgjengelighet og brukbarhet, både nasjonale og lenker internasjonale. I det følgende nevner vi de standardene som er relevante i denne sammenhengen. Standardene som kommer først anses som viktigst.
WCAG er en internasjonal standard for å gjøre nettinnhold tilgjengelig for personer med funksjonsnedsettelser. Deler av WCAG er laget med tanke på kognitive funksjonsnedsettelser.
WCAG lages av WAI, som igjen er en del av organisasjonen W3C. W3C er en internasjonal institusjon som utvikler nettstandarder, mens WAIs ansvarsområdet dekker tilgjengelighet og inkludering.
Den nyeste versjonen av standarden er 2.0 (per desember 2009).
Den internasjonale standarden ARIA er innrettet mot å gjøre nettinnhold mer tilgjengelig for personer med funksjonsnedsettelser. Hovedfokus for denne standarden er nettprogramvare og dynamiske nettsider.
Som WCAG lages ARIA av WAI-gruppen i W3C.
Den nyeste versjonen av standarden er 1.0 (per desember 2009).
ELMER er en retningslinje for utforming av offentlige skjemaer på nett, det vil si elektroniske skjemaer. Anbefalingen gjelder på nasjonalt plan.
Forvaltningsansvaret for ELMER er lagt til Brønnøysundregistrene.
Den nyeste versjonen av standarden er 2.0 (per desember 2009).
Referansekatalogen er en spesifikasjon av IT-standarder for bruk i norsk offentlig sektor. Den er etablert
[...] for å bedre samhandlingen mellom IT-systemer i offentlig sektor, for å redusere bindinger til enkeltleverandører og for å bidra til likebehandling og inkludering av alle innbyggere, uavhengig av hva slags programvare eller programvareplattform hver enkelt benytter.
Katalogen er kun delvis relevant for universell utforming, og der WCAG og ELMER.
Referansekatalogen faller under Standardiseringrådets ansvarsområde. Dette rådet skal ta initiativ til og tilrettelegge for systematisk bruk av IT-standarder. Rådet skal gi anbefalinger til Fornyings- og administrasjonsdepartementet om hvilke standarder som bør anbefales eller gjøres obligatoriske å bruke i offentlig sektor, det vil si bli såkalte forvaltningsstandarder. Rådet skal primært ta for seg standarder som har relevans for en stor bredde av offentlige aktører.
Den nyeste versjonen av katalogen er 2.0 (per desember 2009).
Denne standarden er ment for dem som er ansvarlige for planlegging, utforming, utvikling og evaluering av IKT-utstyr og -tjenester. Den inneholder retningslinjer for tilgjengelighet for IKT på arbeidsplassen, i hjemmet, i mobile omgivelser og på offentlige steder. Den dekker tilgjengelighet for mennesker på ulike sensoriske, motoriske eller kognitive funksjonsnivåer, mennesker med midlertidig funksjonsnedsettelse, og eldre.
Ansvarlig for standarden er arbeidsgruppe TC 159 Ergonomics (Standardization in the field of ergonomics, including terminology, methodology, and human factors data) ved organisasjonen ISO. Gruppens arbeidsområde er internasjonale standarder for industri, myndigheter og selskapet.
Den nyeste versjonen av standarden er fra 2008 (per desember 2009).
Design for All.
Teknisk rapport som inneholder en rik beskrivelse av IKT-baserte produkter og tjenester som det offentlige i EU- og EØS-land typisk anskaffer. Dokumentet gir en oversikt over funksjonelle tilgjengelighetskrav, og det gir en oversikt over tilgjengelighetsstandarder. Dokumentet er et utmerket oppslagsverk for alle som arbeider med IKT og tilgjengelighet.
De som jobber med denne standarden, er arbeidsgruppen Specialist Task Force 333 i organisasjonen ETSI. ETSI lager internasjonale IKT-standarder. Arbeidsgruppens ansvarsområder dekker tilgjengelighetsbehov ved offentlige innkjøp av IKT-produkter og -tjenester på et europeisk plan.
Den nyeste versjonen av standarden er 1.2.2 fra mars 2009 (per desember 2009).
Denne anbefalingen gjelder telekommunikasjon for eldre mennesker og mennesker med funksjonshemminger. Anbefalingen gir en generell veiledning for arbeid med standardisering, og planlegging, utforming og distribusjon av alle former for telekommunikasjonsutstyr, -programvare og -tjenester for å sikre tilgjengelighet for flest mulig. Den gir også en generell beskrivelse av tilgjengelighet, og hvordan denne kan oppnås.
Det er arbeidsgruppen Study Group ITU-T SG 16 (Work on Accessibility) ved organisasjonen ITU. som er ansvarlig for standarden.
En underorganisasjon i ITU med relevante arbeidsområder er ITU-T. I denne delen av organisasjonen jobbes det med standardisering for telekommunikasjonssektoren.
Den nyeste versjonen av standarden er fra januar 2007 (per desember 2009).
Denne standarden kommer i tre deler: ISO/IEC TR 29138-1 (Part 1) User needs summary, ISO/IEC TR 29138-2 (Part 2) Standards inventory og ISO/IEC TR 29138-3 (Part 3) Guidance on user needs mapping. Disse innholder retningslinjer, standarder og veiledning om hvordan man kan møte behovene for mennesker med funksjonshemminger. Den primære målgruppen er utviklere av standarder, men den kan også anvendes av IKT-utviklere, bestillere av IKT og så videre. I tillegg til behovene gir dokumentet en oversikt over problemer som mennesker med funksjonshemming opplever i møtet med IKT. IKT.
Standarden hører til ansvarsområdet av ISO/IEC JTC 1 SWG-A (Special Working Group on Accessibility). Denne arbeidsgruppen jobber med begrensninger av eksisterende standarder, evalueringer av behovet for nye standarder, spesifikasjoner for brukerkrav, utarbeiding av nye standarder og promotering av disse.
Den nyeste versjonen av standarden er versjon 60.60 fra juni 2009 (per desember 2009).
Dette er en anbefaling som er relevant for bestillere av offentlige løsninger som skal være tilrettelagt for eldre og personer med redusert funksjonsevne.
Ansvaret for CEN ligger hos CEN, en europeisk organisasjon som utarbeider standarder og tekniske spesifikasjoner.
Den nyeste versjonen av standarden er versjon 50 fra august 2008 (per desember 2009).
Retningelinjer for utviklere av standarder for eldre personer og mennesker med funksjonshemminger. Anbefalingen er identisk med ISO/IEC Guide 71.
Arbeidsgruppen som er ansvarlig for Guide 6 er CENELECs TC 206 ― Consumer equipment for entertainment and information and related sub-systems. CENELEC er en ikke-kommersiell europeisk organisasjon som utarbeider standarder på området elektroteknikk.
Den nyeste versjonen av standarden er Edition 1 fra januar 2002 (per desember 2009).
I tillegg til standarder er kjennskap til nasjonalt standardiseringsarbeid og relaterte institusjoner nyttig. Standard Norge arbeider innefor tilgjengelighet og deltar via sine representanter i flere internasjonale komiteer.
Lenkene peker på yttligere informasjon og er delt inn i fire hovedområder.
Enklere og mer effektiv rapportering.
for eksempel.
Utforming av produkter og omgivelser på en slik måte at de kan benyttes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing eller spesiell utforming [referanse].
