Begrepet universell utforming begynner å bli mer kjent i IKT-bransjen, men det er fortsatt et stort behov for kunnskap, effektive metoder og verktøy for å oppnå̊ dette. Universell utforming av IKT forutsetter at løsningen er både teknisk tilgjengelig og brukervennlig for flest mulig.
For å oppnå teknisk tilgjengelighet må man blant annet sørge for kompatibilitet med IKT-hjelpemidler. Det finnes mange typer IKT-hjelpemidler (se mer om dette i et eget avsnitt. Det er nødvendig å teste løsningen sammen med de ulike hjelpemidlene for å sikre best mulig kompatibilitet i praksis. Men, manglende tilgang til og kunnskap om de ulike hjelpemidlene er en stor utfordring for å få dette til.
Med denne håndboken vil vi gi leseren innsikt i aktuelle problemstillinger rundt teknisk tilgjengelighet og IKT-hjelpemidler. Her får du informasjon om typer av IKT-hjelpemidler, hvordan en skjermleser fungerer og testing med IKT-hjelpemidler.
I tillegg skal boken gi en innføring i et nytt verktøy for tilgjengelighetstesting, VHL-verktøyet, som utvikles parallelt med denne håndboken.
Målgruppen for håndboken er alle som utvikler IKT, men også innkjøpere og andre som har behov for kunnskap om teknisk tilgjengelighet. Håpet er at håndboken og VHL-verktøyet kan brukes til opplæring og utdanning innen universell utforming av IKT, samt av lærere og annet støttepersonell for de som bruker hjelpemiddelteknologi. Målgruppe for VHL-verktøyet er først og fremst utviklere.
Dette dokumentet er skrevet og utformet av:
Om du finner en feil, eller om du mener at det mangler noe eller bare ønsker å si din mening, så send en e-post til oss.
Vision2Access (V2A) arbeider med analyse, rådgivning og opplæring innen universell utforming av IKT. V2A har mange års erfaring fra arbeid med hjelpemiddelteknologi og universell utforming av IKT, samt innenfor opplæring av brukere og fagpersonell.
Norsk Regnesentral (NR) er en forskningsstiftelse med flere tiårs erfaring innen IKT-forskning. NRs e-inkluderingsgruppe har både teknologi- og metodekompetanse innen universell utforming av IKT. NR har bred erfaring med ulike metoder for teknisk tilgjengelighetstesting og brukerundersøkelser, både i lab og i feltet. Til dette bruker NR og egenutviklede verktøy og prosedyrer, blikksporing (Tobii Eyetracker), og verktøy for logging av brukerens handlinger (Morae), i tillegg til sjekklister og prosedyrer for håndtering av etikk og personvern.
Virtuell hjelpemiddellab (VHL) er et prosjekt finansiert gjennom UnIKT-midlene fra Deltasenteret i Barne-, ungdoms- og familiedirektoratet.
På tross av at løsninger overholder WCAG-retningslinjene (se eget avsnitt), kan det være problemer med kompatibilitet med ulike hjelpemidler, spesielt med skjermlesere. Ideelt sett kunne man tenke seg at dersom en IKT-løsning virker med ett hjelpemiddel, vil det også virke med andre tilsvarende hjelpemidler. Det er ikke nødvendigvis tilfellet. Det har vist seg at en løsning som fungerer med én skjermleser ikke nødvendigvis fungerer tilfredsstillende med andre skjermlesere.
Årsakene til dette kan være mange og sammensatte. For det første fungerer de ulike skjermleserne litt forskjellig, og de fungerer forskjellig sammen med ulike nettlesere. Dessuten, når nettleserne oppdateres, må vanligvis også hjelpemidlene oppdateres. Det er imidlertid ofte ulik takt på oppdateringer, både med hensyn til type nettleser, nettleser-versjoner og type skjermleser. Dette fører til en uoversiktlig situasjon. Hvilke versjoner av hvilke nettlesere, og IKT-hjelpemidler bør testes for å sikre universell utforming?
Det er svært få utviklermiljøer som har tilgang til mange forskjellige IKT-hjelpemidler, og problematikken rundt versjoner og oppdateringer er en stor utfordring. Hjelpemidlene kan ofte være svært kostbare. Derfor er det ganske urealistisk for flesteparten av utviklermiljøene å anskaffe og holde orden på mange forskjellige hjelpemidler i ulike versjoner.
Det å teste med IKT-hjelpemidler krever også kompetanse om hvordan hjelpemidlene brukes. Testing med hjelpemidler er likevel en forutsetning for å oppnå reell tilgjengelighet. Det er derfor et skrikende behov for mer samordning og effektive verktøy som gjør det mulig og realistisk for utviklere å teste løsningen mot forskjellig IKT-hjelpemidler innenfor de gitte kostnads- og tidsrammer.
Tanken er at VHL-verktøyet på sikt skal kunne brukes til å teste med ulike hjelpemidler og i ulike versjoner, og at det også skal hjelpe til med å holde styr på dette.
Begrepet universell utforming (uu) ble først tatt i bruk for å beskrive en prosess for å sikre best mulig tilgjengelighet for funksjonshemmede i fysiske omgivelser, dvs. tilgjengelighet til bygninger og uteområder.
Begrepet universell utforming springer ut fra det utviklingsarbeidet som er gjort ved The Center for Universal Design ved North Carolina State University (CUD). CUDs definisjon av uu er:
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.
Miljøverndepartementet oversetter dette slik:
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.
Hensikten med uu er altså å forenkle livet for alle ved å lage produkter og omgivelser som kan brukes av flest mulig. Ved hjelp av konseptet universell utforming (engelsk: universal design) ville man endre synet på tilgjengelighet. Istedenfor å se på tilgjengelighet som et ekstra kostnadsdrivende og begrensende aspekt i arkitekt- og byggearbeidet, ville man rette fokus mot hvordan man kunne utvikle løsninger som fungerer for flest mulig, enten de har en funksjonsnedsettelse eller ikke.
Det er viktig å merke seg at begrepet universell utforming både betegner en målsetting for produktet eller omgivelsene, nemlig at den skal kunne brukes av alle, og et fokus på utviklingsprosessen, nemlig hvordan man skal kunne oppnå dette målet. Hva slags resultat man får, er selvsagt svært avhengig av hvilken utviklingsprosess man har.
I tillegg til definisjonen av uu har CUD utviklet syv prinsipper for uu, og disse utgjør en viktig del av konseptet. Prinsippene viser hvilke egenskaper ved produktet eller omgivelsene som er viktige for å oppnå universell utforming. De kan sånn sett ses på som overordnede krav til løsningen. Prinsippene kan også brukes til å veilede og påvirke utviklingsprosessen, og som et utgangspunkt for evaluering av eksisterende og nye løsninger. De syv prinsippene er:
Deltasenteret har en fullstendig versjon av de syv prinsippene for universell utforming.
Begrepet universell utforming inneholder et sterkere likestillingskrav enn det som ligger i begrepet tilgjengelighet for personer med nedsatt funksjonsevne. Dette kommer vi nærmere inn på i et eget avsnitt om forholdet mellom universell utforming og tilgjengelighet.
En av grunntankene i universell utforming er at man ved å ta hensyn til mangfoldet blant mennesker, vil ende opp med å utvikle løsninger som fungerer enda bedre for alle.
Selv om definisjonen og prinsippene for universell utforming er utarbeidet med tanke på det fysiske miljø, blir begrepet også brukt i sammenheng IKT og web, og der ligger fokuset for denne håndboken.
For å kunne bruke informasjons- og kommunikasjonsteknologi (IKT) må vi kunne oppfatte og forstå informasjon og kommunikasjon.
For at vi skal kunne oppfatte informasjonen må den presenteres i en form som kan oppfattes via sansene våre, dvs. via syn, hørsel eller berøring. I framtiden kan det kanskje oppfattes via andre sanser som lukt og smak. Det er dette teknisk tilgjengelighet dreier seg om. Dernest bruker vi våre kognitive funksjoner, slik som hukommelse, oppmerksomhet, gjenkjennelse og problemløsning, til å prosessere og forstå informasjonen. Måten informasjonen presenteres på, dvs. i hvilken grad løsningen er kognitivt tilgjengelig, eller sagt på en annen måte, i hvilken grad løsningen er brukervennlig, er en helt sentral del av universell utforming av IKT.
Kort sagt, universell utforming av IKT krever teknisk tilgjengelighet for at vi skal kunne oppfatte informasjonen, og brukervennlighet for at vi skal kunne forstå informasjonen.
Man kan gjenkjenne elementer fra de syv prinsippene for universell utforming i retningslinjer for tilgjengelighet av IKT, noe vi skal komme nærmere inn på i et eget avsnitt. Men, uu handler vel så mye om en måte å tenke, planlegge, designe, utvikle og teste en løsning på, som et sett med målbare krav eller retningslinjer. Se mer om dette i et eget avsnitt.
Diskriminerings- og tilgjengelighetsloven (DTL) ble vedtatt 10. juni 2008 og trådte i kraft 1. januar 2009. Formålet med denne loven er å
fremme likestilling og likeverd, sikre like muligheter og rettigheter til samfunnsdeltakelse for alle, uavhengig av funksjonsevne, og hindre diskriminering på grunn av nedsatt funksjonsevne.
Loven skal bidra til nedbygging av samfunnsskapte funksjonshemmende barrierer og hindre at nye skapes.
DTL legger vekt på universell utforming som en strategi for å sikre like muligheter og rettigheter for alle. Universell utforming er i denne loven definert som
utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene, herunder informasjons- og kommunikasjonsteknologi (IKT), slik at virksomhetens alminnelige funksjon kan benyttes av flest mulig.
Paragraf 11 i DTL, omhandler plikt til universell utforming av IKT. Her står det at nye IKT-løsninger, som underbygger virksomhetens alminnelige funksjoner og som er hovedløsninger rettet mot eller stillet til rådighet for allmennheten, skal være universelt utformet.
Forskrift om universell utforming av IKT-løsninger gir detaljer om hva som kreves for å oppfylle kravene i DTL på IKT-området. Det går ut på å følge bestemte standarder. Websider skal følge Web Content Accessibility Guidelines (WCAG) 2.0 (se mer om denne i et eget avsnitt). For universell utforming av automater gjelder flere standarder, men de omtales ikke i denne håndboken.
IKT-løsninger som omfattes av forskriften må oppfylle kravene fra 1. juli 2014, dvs. 12 måneder etter at forskriften trådte i kraft. Eksisterende IKT-løsninger må oppfylle kravene innen 1. januar 2021.
Begrepene universell utforming og tilgjengelighet for mennesker med nedsatt funksjonsevne, eller bare tilgjengelighet, blir ofte brukt om hverandre, men brukes ikke alltid synonymt.
Hovedforskjellen på tilgjengelighet og universell utforming ligger i at tilgjengelighet ikke nødvendigvis er inkluderende. Man kan lage spesialprodukter som er tilgjengelige. Når man benytter universell utforming som begrep, forutsettes det at utformingen gjør at alle kan benytte den samme løsningen, uansett om de har en funksjonsnedsettelse eller ikke.
Et svært vanlig eksempel på en tilgjengelig løsning som ikke kan kalles universelt utformet, er der hvor man har utviklet en forenklet tekstbasert versjon av en webside som skal være enklere for blinde å bruke. Denne løsningen gir blinde tilgang til en del informasjon, men det må skje på andre vilkår enn for seende brukere. Det kan derfor ikke kalles universell utforming, men må betraktes som spesiell tilrettelegging for én enkelt gruppe.
Med tilgjengelighet til IKT for personer med nedsatt funksjonsevne forstås ofte det vi refererer til som teknisk tilgjengelighet. Det vil si at det teknisk sett er mulig å bruke f.eks. en webside med skjermleserprogramvare, eller at det teknisk sett er mulig å betjene en webside kun ved bruk av tastatur. Men en løsning som overholder WCAG-retningslinjene og som teknisk sett er kompatibel med hjelpemidler, er ikke nødvendigvis universelt utformet. Det kan være at utformingen av løsningen gjør at den i praksis svært vanskelig, tungvint eller umulig å bruke for personer med nedsatt funksjonsevne. For å være universelt utformet må løsningen, i tillegg til å være teknisk tilgjengelig, også være brukervennlig for personer med nedsatt funksjonsevne, inkludert de som bruker IKT-hjelpemidler.
Kravet til brukervennlighet kommer ofte mye tydeligere fram i engelske
definisjoner av universell utforming og tilgjengelighet enn i de norske
oversettelsene. En viktig grunn til dette er at det engelske ordet
usable
,
som i denne sammenheng kan oversettes med
brukervennlig, istedenfor har blitt oversatt med kan brukes
. (Se
f.eks. definisjonen i
et eget avsnitt
og
et annet avsnitt).
TilgjenGeligHet kan i følge ISO 9241–171 2008 også defineres som
usability of a product, service, environment or facility by people with
the widest range of capabilities.
Her er brukervennlighetsaspektet og mangfoldsaspektet inkludert. Denne definisjonen av tilgjengelighet overlapper i stor grad med definisjonen av universell utforming utarbeidet av The Center for Universal Design ved North Carolina State University; se eget avsnitt.
Noen personer med nedsatt funksjonsevne er avhengige av å bruke spesialisert programvare, kalt IKT-hjelpemidler, sammen med ordinære IKT-løsninger for å kunne bruke dem. Et typisk eksempel på dette er en skjermleser som sammen med en leselist brukes av blinde eller personer med sterkt nedsatt syn. Skjermleseren konverterer den teksten som normalt vises på skjermen, slik at den kan leses opp som syntetisk tale eller vises som punktskrift på en elektronisk leselist. Svaksynte bruker gjerne ekstra programvare for å endre skrifttyper, farger og kontraster og størrelse på innholdet på skjermen. Dette brukes ofte sammen med syntetisk tale og ekstra stor skjerm. Det er mange andre grupper som også bruker IKT-hjelpemidler. Bevegelseshemmede kan for eksempel bruke spesielle typer tastatur, mus eller øyestyring. Dyslektikere bruker ofte spesiell programvare for rettskriving sammen med tekst til tale funksjoner. Eksempler på teknologi som er mye brukt av hørselshemmede er chattefunksjoner og SMS. Døve har også ofte nytte av video med forklaringer på tegnspråk.
Selv om målsettingen med uu er at hovedløsningen skal kunne brukes av alle uten behov for spesiell tilpassing, er det også allment akseptert at enkelte grupper vil ha behov for å bruke IKT-hjelpemidler sammen med universelt utformede løsninger, for å få tilgang til dem. I følge Forente Nasjoners konvensjon om rettighetene til mennesker med nedsatt funksjonsevne, skal uu ikke utelukke hjelpemidler for bestemte grupper når det er behov for det. På samme måte som man ved universell utforming av bygninger og uteområder legger til rette for at det skal være framkommelig med rullestol alle steder, vil man i den elektroniske verdenen legge til rette for at alle funksjoner i IKT-løsninger skal kunne benyttes med IKT-hjelpemidler.
Vi ser i økende grad at noe av den funksjonaliteten som finnes i
IKT-hjelpemidler bygges inn i vanlige IKT-løsninger. Eksempler på dette
er innebygd tekst-til-tale-funksjonalitet, endring av kontraster og
tekststørrelse. Se f.eks. Lytt
-funksjonen, Høykontrast
eller Mindre
og Større
på nettstedet
Universell utforming
som drives av Deltasenteret. Men vanligvis dekker ikke vanlige
IKT-løsninger alle de funksjonene som IKT-hjelpemidlene dekker på en så
god måte at det er et alternativ for de som trenger hjelpemidler. De
fleste IKT-løsningene leveres for eksempel ikke med innebygd leselist,
skjermleser eller skjermtastatur. IKT-løsninger må derfor kunne brukes
sammen med slike IKT-hjelpemidler for å bli tilgjengelige. Det kreves
med andre ord
kompatibilitet
med IKT-hjelpemidler.
Se
mer om IKT-hjelpemidler i
et eget avsnitt.
I denne håndboken konsentrerer vi oss om hjelpemidler som er nødvendige for personer med nedsatt funksjonsevne. Det er hjelpemidler som gjør vedkommende i stand til å benytte en IKT-løsning, som han eller hun ville ha vanskelig for, eller ingen mulighet til, å bruke uten hjelpemiddelet.
Forskrift om universell utforming av IKT-løsninger krever kompatibilitet med IKT-hjelpemidler. Se mer om dette i et eget avsnitt.
Det finnes ulike standarder og retningslinjer som kan være til god hjelp i arbeidet med universell utforming av IKT. I dette kapittelet nevnes noen sentrale standarder og retningslinjer på dette området.
WCAG-retningslinjene er utarbeidet av World Wide Web Consortium (W3C) i samarbeid med enkeltpersoner og organisasjoner rundt om i verden. Formålet har vært å utvikle et enkelt sett med retningslinjer for å gjøre webinnhold tilgjengelig. WCAG 2.0 er nå en stabil teknisk standard (også publisert som ISO/IEC 40500:2012 Information technology – W3C Web Content Accessibility Guidelines (WCAG) 2.0). Som nevnt i avsnittet om diskriminerings- og tilgjengelighetsloven kreves det at nettløsninger rettet mot allmennheten følger disse retningslinjene, med noen få presiseringer som vi kommer inn på nedenfor.
WCAG 2.0 har til sammen 12 retningslinjer som er organisert under fire hovedprinsipper:
For hver retningslinje er det et eller flere suksesskriterier. Suksesskriteriene er inndelt i tre nivåer: A, AA, og AAA, hvor AAA er det nivået med best tilgjengelighet. DTL krever at man oppfyller alle suksesskriteriene på nivå A og AA, med unntak for suksesskriteriene 1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt), 1.2.4 Teksting (direkte), og 1.2.5 Synstolking (forhåndsinnpilt).
En del av suksesskriteriene kan testes ved hjelp av automatiske test-verktøy. Disse verktøyene kan gi ulike svar, og det reflekterer både at det er rom for tolkning om kravene er oppfylt, og at ikke alle kravene egner seg like godt for automatisk testing (se også et eget avsnitt).
Som vi har vært inne i
et eget avsnitt
handler universell
utforming både om å presentere informasjonen slik at den kan oppfattes
og slik at den kan forstås. At informasjonen skal være mulig å oppfatte
dekkes i stor grad av WCAG Punkt 1 Mulig å oppfatte
, deler av punkt
2 Mulig å betjene
(f.eks. 2.1 Gjør all funksjonalitet tilgjengelig med
tastatur
), samt punkt 4.1 om kompatibilitet, se
eget avsnitt.
For at vi skal kunne forstå informasjonen må den presenteres på en
forståelig og brukervennlig måte. Dette kommer fram gjennom WCAG, deler
av punkt 2. Mulig å betjene
(f.eks. 2.4 Mulig å navigere og finne
innhold
), samt punkt 3 Forståelig
.
WCAG-retningslinje 4.1 omhandler kompatibilitet med hjelpemidler:
Retningslinje 4.1Kompatibel: Sørg for best mulig kompatibilitet med aktuelle og framtidige brukeragenter, inkludert kompenserende teknologi.
Eksempler på brukeragenter er nettlesere, e-postlesere, mediespillere og IKT-hjelpemidler; se også User Agent Accessibility Guidelines (UAAG). En person som er avhengig av IKT-hjelpemidler for å bruke IKT, kan søke det offentlige (dvs. nav) om støtte til dette. Retten til å få dekket hjelpemidler under Lov om folketrygd, vurderes individuelt etter visse kriterier.
For å vurdere hvilke hjelpemidler som en IKT-løsning bør være kompatibel med, mener vi det er naturlig å ta utgangspunkt i de hjelpemidlene som nav gir støtte til. nav inngår rammeavtaler med hjelpemiddelleverandører og har oversikt over hvilke hjelpemidler som til enhver tid er i bruk. Se mer om hjelpemidler i et eget avsnitt.
Hvor grensen går for hvilken funksjonalitet som dekkes av IKT-hjelpemidler og hvilken funksjonalitet som dekkes av vanlige IKT-løsninger, vil antakelig endre seg på sikt. Det er både avhengig av brukskontekst og den teknologiske utviklingen. Dette er det tatt høyde for i WCAG-retningslinje 4.1, som krever best mulig kompatibilitet med aktuelle og framtidige brukeragenter.
Det kan være flere fordeler med at funksjoner som tradisjonelt sett har blitt dekket av IKT-hjelpemidler, blir integrert i vanlige IKT-løsninger. For det første er det flere enn de som har rett til støtte til hjelpemidler som kan ha nytte av slike funksjoner. For det andre kan denne funksjonaliteten bli billigere per bruker, fordi kostnaden blir integrert i allmennteknologi. Det betyr at kostnaden blir fordelt på alle brukerne. For det tredje kan man unngå problemer som oppstår fordi man ikke vet hvem som er ansvarlig for å finne og rette opp feil, og problemer knyttet til forsinkede og usynkroniserte oppdateringer. På den andre siden kan det være fordeler med at funksjonalitet som er helt nødvendig for enkeltgrupper, utvikles av spesialister på denne gruppens behov og utfordringer.
Det er bred enighet blant eksperter, forskere og brukere om at det å følge WCAG-retningslinjene er en viktig forutsetning for å oppnå universell utforming, men at det på ingen måte er tilstrekkelig.
I tillegg til å følge standarder og retningslinjer bør universell
utforming som prosess baseres på en brukersentrert
utviklingsprosess. Standarden Menneskeorientert design for
interaktive systemer
(NS–EN ISO 9241-210:2010) er et godt
utgangspunkt. De viktigste prinsippene i en menneskesentrert
utviklingsprosess er:
For å oppnå universell utforming må brukere med nedsatt funksjonsevne
innoveres i denne prosessen. En nærmere beskrivelse av universell
utforming og brukermedvirkning finnes i standarden Universell
utforming og brukermedvirkning – IKT
(NS 11040) som
ble ferdigstilt i 2013.
Det første prinsippet handler i stor grad om å tenke nøye gjennom det mangfoldet av brukere som skal kunne bruke løsningen, og ha fokus på dette i gjennom hele utviklingsforløpet.
Allerede når man definerer og setter rammene for prosjektet, bør man planlegge hvordan man kan involvere brukere med nedsatt funksjonsevne tidligst mulig i utviklingsprosessen og hvordan man skal teste løsningen.
Et viktig prinsipp i brukersentrert utvikling er evaluering av løsningen med brukere. For å oppnå universell utforming innebærer det at man bør gjennomføre brukertester med personer med nedsatt funksjonsevne. Se mer om testing av tilgjengelighet i et eget avsnitt. Iterativ utvikling betegner en syklisk prosess hvor produktet forbedres gradvis gjennom å gjenta en rekke trinn (f.eks. avdekke brukerkrav, design, utvikling og testing) inntil produktet har den ønskede kvalitet.
For mer enn ti år siden fant forskere. på mellom 200-300 retningslinjer for å gjøre produkter mer tilgjengelige. Siden har antallet slike retningslinjer økt ytterligere. For eksempel har det kommet retningslinjer for mobil tilgjengelighet og tilgjengelig web 2.0. Nedenfor lister vi opp noen utvalgte standarder og retningslinjer som vi mener er viktige og relevante for webutvikling.
Hjelpemidler brukes ofte av personer med nedsatt funksjonsevne. Funksjonsnedsettelsene grupperes ofte i tre hovedkategorier:
Nedenfor gis noen eksempler på typer av funksjonsnedsettelser innenfor hver av de tre hovedkategoriene og på hva man bør tenke på hva gjelder utforming av IKT.
Sensoriske funksjonsnedsettelser eller sansetap omfatter aller grader, variasjoner og kombinasjoner av nedsatt sanseevne. Dette kan f.eks. være nedsatt syn og hørsel, berøring, balanse, smak og lukt.
Når det gjelder bruk av IKT er en av de største utfordringene for mennesker med sansetap å kunne oppfatte informasjon og tilbakemeldinger man får fra en datamaskin, mobiltelefon eller andre enheter. Hvordan man utformer betjening, interaksjon og hvordan informasjon og tilbakemeldinger skjer, har derfor stor betydning for personer med sensoriske funksjonsnedsettelser.
Snakk litt høyere!© Photos.com
Eksempelvis kan det for en svaksynt person være vanskelig å lese skriften på en skjerm når den er for liten, fordi kontrasten mellom forgrunn og bakgrunn er for dårlig osv. For personer med sterkt nedsatt syn må betjening, styring, interaksjon og tilbakemelding kunne foregå som auditiv kommunikasjon via skjermleser og tekst-til-tale/tale-til-tekst, og eventuelt som punktskrift via punktlist for de som bruker dette.
For en person med nedsatt hørsel vil det være vanskelig å høre de auditive tilbakemeldingene som enheten gir, for eksempel ringetoner eller varslingslyder som gis når en feil oppstår. For personer med sterkt nedsatt hørsel vil ofte tegnspråk være den primære kommunikasjonsformen. Dette kan bety at interaktivitet og tilbakemelding i IKT-løsningen må ivaretas gjennom vibrasjon eller visuelle signaler, samt at løsningen tilrettelegges for formidling av tegnspråk.
Motoriske funksjonsnedsettelser eller bevegelseshemninger kjennetegnes ved at en eller flere kroppsdeler har mer eller mindre redusert funksjon. Det omfatter også tap av en eller flere kroppsdeler. Hel eller delvise lammelse, koordinasjonsvansker, ufrivillige bevegelser, samt stivhet eller treghet i bevegelser er andre eksempler. Det omfatter også tilstander som medfører redusert kapasitet eller utholdenhet i bevegelsesapparatet.
Det å kunne betjene IKT-løsningen er en av hovedutfordringene innenfor denne kategorien. Det vil si å kunne benytte et tastatur, klikke på små områder på en pekeskjerm, aktivere en funksjon med dynamisk innhold før den forsvinner igjen osv. Dette innebærer at det vil være viktig å ta hensyn til antall aktiveringer, tempo, koordinering og presisjon. For brukeren kan det være aktuelt å benytte direkte peking, samt hjelpemidler som brytere, spesialmus, spesialtastatur, taleinput eller øyestyring.
Betegnelsen kognitive funksjonsnedsettelser brukes ofte svært vidt, og sett under ett anses dette som den største gruppen av de tre hovedkategoriene. Kognitive funksjonsnedsettelser omfatter atferdsmessige, tankemessige og følelsesmessige funksjonsnedsettelser som følge av svekkelser i en eller flere av hjernens funksjoner eller som følge av negativ miljøpåvirkning. Det inkluderer vansker med hukommelse, konsentrasjon, språk, oppmerksomhet, utholdenhet, planlegging og/eller initiering av aktiviteter, rom- og retningsforståelse, sosiale ferdigheter og impulskontroll. Lese- og skrivevansker nevnes også i denne sammenheng, i tillegg til visuell forståelse og tallforståelse.
Kognitive funksjonsnedsettelser kan virke inn på evnen til å behandle informasjon og på vurderings- og beslutningsevne. Det er stor variasjon i grad og sammensetning av kognitive funksjonsnedsettelser. Funksjonsnivået vil også kunne påvirkes av struktur og andre forhold i omgivelsene.
For å ta hensyn til brukere i denne kategorien må man legge vekt på tydelig og enkel informasjon, god struktur og logisk organisering. Det er viktig med tydelige forskjeller på elementer som logisk sett er forskjellige, slik at de lett kan skilles fra hverandre, samt tydelige tilbakemeldinger. Personer med språkvansker kan benytte alternativ eller supplerende kommunikasjon, som f.eks. symbolspråk. For disse er det viktig at informasjon og kommunikasjon i løsningen kan bli tilrettelagt for det aktuelle symbolspråket.
Grensen mellom hva som er allmennteknologi og hjelpemidler for personer med kognitive funksjonsnedsettelser er ofte flytende. I mange tilfeller vil allmennteknologi som ikke er spesielt utviklet med hensyn til denne brukergruppen, kunne være til ekstra stor nytte, og kan dermed betraktes som et IKT-hjelpemiddel for den det gjelder. Det kan eksempelvis være programvare som hjelper brukeren med å organisere og huske informasjon, eller ordrettingsprogrammer. I andre tilfeller er det behov for spesialutviklet programvare med forsterkede hjelpefunksjoner. Programvarer med ekstra lese- og skrivestøtte er et eksempel på IKT-hjelpemidler som er mye brukt av dyslektikere.
Det er vanskeligere å tilrettelegge for personer med sterkt nedsatt kognitiv funksjonsevne enn det er å tilrettelegge for personer med sterkt nedsatte sensoriske eller motoriske evner, i alle fall med dagens kunnskap og teknologi. For de to sistnevnte gruppene kan bruk av IKT-hjelpemidler være avgjørende, mens tilretteleggingen for personer med kognitive funksjonsnedsettelser i stor grad handler om særdeles god brukervennlighet, enkelhet, forutsigbarhet og gode tilbakemeldinger.
For utfyllende informasjon om kognitiv funksjonsevne og hvordan lage nettsider for personer med nedsatt kognitiv funksjonsevne, se Utformingsveileder for kognitiv tilgjengelighet av elektroniske tjenester og innhold.
De fleste opplever nedsatt funksjonsevne fra tid til annen på grunn av sykdom eller skade. For eksempel kan en brukket arm eller musesyke gjøre det vanskelig å bruke tastatur på vanlig måte, og en halsinfeksjon kan påvirke bruk av programvare for stemmestyring.
Forhold i brukskonteksten vil også ofte føre til at man må stille lignende krav til en IKT-løsning som om man hadde en funksjonsnedsettelse. En bilfører som ikke kan flytte blikket fra trafikken eller andre aktiviteter, kan ha lignende krav til IKT som en synshemmet person, som for eksempel å få lest opp meldinger. Dersom det er dårlige lysforhold eller refleksjon på skjermen, vil gode kontraster ha ekstra stor betydning. På møter, konserter eller lignende ønsker man ikke å forstyrre andre med ringetoner og alarmer fra mobiltelefonen. Da har man nytte av vibrering og visuelle meldinger. Dette er funksjoner som også er viktige for hørselshemmede.
Det er med andre ord lett å forestille seg situasjoner som gjør at man har behov for universelt utformede IKT-løsninger. Derfor er det overlapp mellom design for personer med nedsatt funksjonsevne og design for bruk i ulike kontekster, noe som er typisk for design for mobile enheter og bruk i ulike omgivelser.
Mange personer har mer enn én type funksjonsnedsettelse. Dette er ofte tilfellet for eldre personer. Statistikk tyder på at det er minst like mange mennesker med to eller flere funksjonsnedsettelser som med kun en type. Det er imidlertid en svært liten andel av personer med nedsatt funksjonsevne som mangler en eller flere funksjoner fullstendig. Oftest handler det om grader av nedsatt funksjonsevne. Det er selvsagt viktig å tilrettelegge for personer med en type høy grad av funksjonsnedsettelse, f.eks. de som er helt blinde, men det er også viktig å være klar at universell utforming handler om å tilrettelegge for veldig mange forskjellige mennesker med stor variasjon i typer, grader og sammensetninger av funksjonsnedsettelser.
IKT-hjelpemidler (AT på engelsk) er maskin- eller programvarer som er anskaffet kommersielt, tilpasset eller spesialutviklet, og som har som formål å støtte, forbedre eller opprettholde menneskelige funksjoner. Det finnes hjelpemidler som kan benyttes alene eller sammen med andre IKT-løsninger.
IKT-løsninger som er rettet mot allmennheten kan også omtales som allmennteknologi. Skillet mellom allmennteknologi og hjelpemiddelteknologi er noe flytende. Dette skillet er i prinsippet kun skapt av kulturelle oppfatninger. Et eksempel på dette er apper som viser sanntidsinformasjon om kollektivtrafikk. Disse er i utgangspunktet utviklet for alle reisende, uavhengig av funksjonsevne, men er av ekstra stor betydning for personer som ikke kan se skiltene med sanntidsinformasjon på holdeplassen, eller ikke kan se hvilken buss som kommer. På denne måten har allmennteknologi krysset grensen til hjelpemiddelteknologi.
Med IKT-hjelpemidler mener vi altså i denne håndboken programvare, maskinvare eller en kombinasjon av disse som skal dekke det gapet som oppstår mellom en persons funksjonsevne og de kravene en IKT-løsning stiller til den som skal bruke den. Vi begrenser oss også til hjelpemidler som enkeltpersoner med nedsatt funksjonsevne har behov for og får offentlig støtte til under Lov om folketrygd.
Vi kan dele inn IKT-hjelpemidler i hjelpemiddelmaskinvarer og hjelpemiddelprogramvarer. Hjelpemiddelmaskinvarer er typisk enheter som brukes som alternativ til standard inn- og utmatingsenheter. Det kan eksempelvis være et spesialtastatur, som kan betjenes med én hånd. Det kan også være en leselist som viser tekst i punktskrift, slik at den kan leses med fingrene av en person som ikke kan se.
Hjelpemiddelprogramvare kan på samme måte som maskinvare hjelpe til med inn- eller utmating fra en enhet. Det kan eksempelvis være stemmestyringsprogramvare som gjør at man kan styre en datamaskin eller mobiltelefon kun ved bruk av stemmen. Eller det kan være en skjermforstørrer som gjør brukeren i stand til å øke skriftstørrelse og kontrast tilstrekkelig til at han eller hun kan lese det på en skjerm.
I tillegg til å støtte betjening og oppfattelse av informasjon, hjelper også hjelpemiddelprogramvarer ofte til med å tolke den informasjonen brukeren mater inn eller får ut av allmennteknologi. En skjermleser oversetter informasjon på skjermen til syntetisk tale eller punktskrift, men tolker i tillegg informasjonen på skjermen for å kunne finne den måten som er best å presentere informasjonen på for brukeren. For eksempel leser en skjermleser ikke alltid alt innholdet på skjermen hver gang noe endrer seg, men kun den nye informasjonen, samt annen informasjon som brukeren har nytte av for å kunne forstå hva som foregår.
Et annet eksempel på denne tolkningen er såkalte ordprediksjonsløsninger som brukes til skrivestøtte. Programvaren forsøker å forutsi hva brukeren vil skrive, og retter dermed automatisk stave- og tastefeil etter hvert som brukeren skriver.
Som alle designere og utviklere kjenner til, er kompatibilitet med forskjellige nettlesere en av de store utfordringene når man jobber med å utvikle webløsninger. Man vil gjerne ha kontroll ned til minste detalj over hvordan løsningen ser ut og fungerer i de forskjellige nettleserne brukerne benytter seg av.
Dette oppnår man best ved å følge gjeldende webstandarder. Men det er ikke en garanti for at en webside ser nøyaktig ut som man ønsker i enhver nettleser. Jo mer avansert funksjonalitet man ønsker å benytte seg av, jo mer kunnskap kreves det om måten de ulike nettleserne håndterer forskjellige elementer.
Nettlesere er forskjellige, og det er operativsystem, skjermer og andre innstillinger brukeren har lagret på sin maskin også (som f.eks. foretrukket tekststørrelse). På samme måte er det variasjoner i hvordan hjelpemiddelprogramvarer fungerer sammen med forskjellige nettlesere.
Utviklingen innenfor både webstandarder og nettleserversjoner går raskt, og hjelpemiddelprogramvareprodusentene forsøker fortløpende å oppdatere sine produkter til å støtte ny funksjonalitet og nye standarder. For hver endring som gjøres i nettleserne for å støtte et nytt element i en vedtatt, eller ikke vedtatt webstandard, må hjelpemiddelprogramvaren videreutvikles for å kunne ta i bruk den nye funksjonaliteten.
Det er derfor viktig å finne et nivå for hvor man legger seg både med henblikk på kompatibilitet med tidligere versjoner og implementering av ny funksjonalitet. Et eksempel på dette er HTML5-standarden som fortløpende implementeres i nettleserens nyeste versjoner. Nye endringer implementeres så ofte som i daglige utgivelser av enkelte nettlesere.
Det er vanskelig å gi noe standardsvar på hvilke versjoner av både nettlesere og skjermlesere man bør teste for kompatibilitet med og sørge for støtte til. Viktige elementer i denne vurderingen er:
WCAG-retningslinje 4.1 krever best mulig kompatibilitet med aktuelle og framtidige brukeragenter, inkludert kompenserende teknologi. I utgangspunktet kan man oppfylle kravene i retningslinje 4.1 ved å:
Et annet viktig aspekt er å sikre at hjelpemiddelprogramvaren får informasjon om hvilket element på en webside som til enhver tid har fokus. En seende bruker vil vanligvis oppdage at et element har fokus ved hjelp av musemarkøren, og fordi det endrer seg visuelt. Man bør også sørge for at alle interaksjonselementer kan få fokus ved bruk av ulike inputenheter, som tastatur, pekeskjerm og mus.
En annen måte å gi brukeren ekstra informasjon om et element på en webside, er å benytte seg av standarden WAI-ARIA. Se mer om det i et eget avsnitt.
Hvis man sørger for at den nevnte informasjonen er tilgjengelig for IKT-hjelpemiddelet, har man sikret teknisk tilgjengelighet. Imidlertid har man ingen garanti for at løsningen er effektiv og brukervennlig også for brukere av hjelpemiddelprogramvarer. Den beste måten å sikre seg at løsningen er brukervennlig på, er å teste med virkelige brukere i realistiske kontekster. Imidlertid vil man kunne avdekke mange utfordringer ved selv å gjennomføre enkle tester med hjelpemiddelprogramvare. En grunnleggende kjennskap til hvordan de ulike hjelpemidlene interagerer med både bruker og andre brukeragenter (som nettlesere), vil også gjøre det lettere å designe og kode riktig fra start.
I forbindelse med konkurransen mellom Internet Explorer og Netscape Navigator på 1990-tallet om å bli den beste nettleseren, oppstod et behov for å kunne lese og modifisere innholdet i HTML- og XML-dokumenter fra skript på klientsiden. Som en konsekvens av dette, og etter flere runder med konkurrerende spesifikasjoner og implementasjoner, ble Document Object Model versjon 1.0 (DOM level 1) vedtatt som standard av W3C i oktober 1998.
I 2004 ble DOM level 3, som er den aktuelle standarden i dag vedtatt. Den inneholder mange endringer og utvidelser i forhold til den opprinnelige DOM, men prinsippene er de samme.
Når en nettleser henter et HTML- eller XML-dokument fra en webserver behandles det i de fleste tilfeller lokalt på klienten. Nettleseren tolker da dokumentet og plasserer dets forskjellige objekter i en trestruktur, slik at de blir gjort tilgjengelige for omverdenen, f.eks. for skript. På denne måten kan skript og annen programvare hente og manipulere informasjon fra det aktuelle dokumentet. DOM-treet inneholder informasjon om det man kan kalle innholdselementene fra dokumentet. Utseende- og layoutrelatert informasjon blir samlet parallelt i et render-tre. Dette er en tilsvarende trestruktur som inneholder de visuelle elementene. Det finnes imidlertid ingen en-til-en-relasjon mellom disse to trestrukturene, og ikke alle elementer fra render-treet har et motstykke i DOM-treet. Det er blant annet derfor det er viktig å være nøye med å adskille innhold fra utseende når man lager webløsninger.
Det er viktig å kjenne til DOM fordi det er her hjelpemiddelprogramvarer får mye av informasjonen fra, og særlig i de tilfeller hvor tilgjengelighetsgrensesnittene (APIene) ikke tilgjengeliggjør nok informasjon. Du kan lese mer om dette i neste kapittel.
Et tilgjengelighetsgrensesnitt er et API som gjør det mulig for hjelpemiddelprogramvarer å kommunisere med en applikasjon for å hente eller manipulere informasjon om elementer som vises på skjermen. For å forstå behovet for tilgjengelighetsgrensesnittene er det nødvendig å se på hvordan hjelpemiddelprogramvarer har utviklet seg. Her er skjermlesere og utviklingen av dem et godt eksempel.
En skjermleser er et program som leser informasjon fra skjermbildet, tolker og presenterer denne informasjonen som enten syntetisk tale eller som punktskrift på en leselist. Da skjermlesere ble introdusert, var kommunikasjonen mellom bruker og datamaskin basert på et kommandolinjegrensesnitt (CLI på engelsk). Brukeren tastet den gang inn kommandoer i et fullstendig tekstbasert grensesnitt, og fikk en tilbakemelding fra datamaskinen, typisk på neste linje på skjermen. På dette tidspunktet bestod et skjermbilde ofte av 25 linjer av 80 tegn, og skjermleserens primære oppgave var å hente teksten fra det såkalte videominnet i datamaskinen, for så å oversette det til tale eller punktskrift.
Etter at grafiske brukergrensesnitt (GUI på engelsk) ble innført med operativsystemer som Windows for PC og OS/X for Macintosh, ble skjermleserens oppgave mye mer kompleks. Skjermleseren begynte å tolke og bearbeide informasjon i tillegg til å hente tekst fra videominnet. Det ble nødvendig å kunne formidle informasjon om hvilke elementer som fantes i skjermbildet, hvilken posisjon de hadde, hva de inneholdt og hvilken type de var. Skjermleseren ble nødt til å hente inn så mye informasjon som mulig om det aktuelle skjermbildet, og elementene det inneholdt. Denne informasjonen ble hentet fra mange steder, og stilte krav om at skjermleseren hadde tilgang dypt inn i operativsystemet. Noe informasjon ble hentet ved å koble seg opp mot grafikkortets driver, mens annen informasjon ble samlet inn ved å analysere informasjonsflyten mellom applikasjon og operativsystem.
Det er her tilgjengelighetsgrensesnittene kommer inn i bildet. For å unngå at hjelpemiddelprogramvaren selv skulle samle inn all denne informasjonen, ble det forsøkt utviklet standardiserte APIer. APIene skulle gi applikasjoner mulighet til å tilgjengeliggjøre den nødvendige informasjonen direkte til hjelpemiddelprogramvaren.
Eksempelvis ble Microsoft Active Accessibility (MSAA) utgitt i 1997, og ble inkludert som standard i Windows 98 og nyere. MSAA ble senere inkludert i Microsofts UI Automation (UIA). MSAA ble også videreutviklet til det såkalte IAccessible2, som blant annet forsøkte å gjøre APIet mer plattformuavhengig, samt å tilpasse det til de nye krav som fulgte utviklingen av nettlesere og den økte bruken av dynamiske websider og webapplikasjoner.
På samme måte finnes det tilgjengelighetsgrensesnitt for andre operativsystem og plattformer. De vanligste og mest aktuelle i forbindelse med nettlesere er:
I Microsoft Windows:
På Mac OS:
På Linux:
Etter at en nettleser har lastet inn og tolket en webside, som beskrevet i et eget avsnitt, eksponeres informasjonen fra DOM-treet til tilgjengelighetsgrensesnittet, som igjen videreformidler den til hjelpemiddelprogramvaren. Dette skjer i en sekvens av forespørsler fra hjelpemiddelprogramvaren. I noen tilfeller tilgjengeliggjør ikke nettleseren all den nødvendige informasjonen. I disse tilfellene må hjelpemiddelprogramvaren forsøke å finne den manglende informasjonen i DOM. Dette er spesielt aktuelt for Internet Explorer for Windows.
WAI-ARIA, Web Accessibility Initiative – Accessible Rich Internet Applications, er en spesifikasjon av hvordan utviklere kan gjøre dynamisk innhold og webbaserte applikasjoner mer tilgjengelige for brukere med nedsatt funksjonsevne. Dette gjøres ved å gi nettleser og IKT-hjelpemiddel ekstra informasjon om semantikk, struktur og muligheter for interaksjon.
HTML-standarden ble opprinnelig utviklet for å presentere statiske hyperkoblede dokumenter. Standarden har utviklet seg som følge av den raske utviklingen innenfor webdesign og den økte bruken av internett generelt. Det oppstod et behov for å kunne skape dynamisk innhold, og for å kunne etterligne programvare som man kjører direkte på datamaskinen. Webutviklere brukte derfor sine kreative evner til å utvide omfanget av hva HTML kunne brukes til for å oppnå dette.
Ettersom HTML i seg selv kun har et begrenset utvalg av kontroller, var utviklerne nødt til å finne opp sine egne egendefinerte kontroller. Dette ble gjort ved å bruke HTML, CSS og andre lignende teknologier til å skape en visuell representasjon av kontrollen de ønsket å utvikle, for deretter å bruke Javascript til å gi den liv. For eksempel har disse standardene ikke definert glidebrytere, så her måtte programmerere bruke sin kreativitet. Dette skapte store problemer for brukere av hjelpemiddelprogramvarer. De som ble hardest rammet av denne nye bruken av teknologien var trolig skjermleserbrukere. Årsaken er at skjermleserne ikke hadde noen innsikt i de endringene som skjedde i dokumentet etter at det var lastet inn og formidlet til skjermleseren første gang. Dette resulterte i flere utfordringer:
For å forsøke å løse disse problemene ble ARIA utviklet. WAI-ARIA er et rammeverk for å angi attributter som identifiserer funksjonalitet for brukerinteraksjon, hvilke relasjoner som finnes mellom dem, og deres aktuelle tilstand.
WAI-ARIA tilbyr kort sagt følgende:
har undermenyfor et menyelement.
live regions
. Det vil
si områder hvor det er sannsynlig at oppdateringer vil skje,
eksempelvis et innholdsområde for aksjekurser. I tillegg kan man
sette opp regler for hvordan endringer skal formidles. For eksempel
kan kritiske oppdateringer vises i en egen dialogboks mens mindre
viktige oppdateringer vises som en del av den gjeldende siden.
Med andre ord kan man si at WAI-ARIA tilbyr en måte å gi hjelpemiddelprogramvarer og nettlesere ekstra semantisk informasjon, som man ellers kun ville få tilgang til ved å se på hvordan en webside blir presentert på en skjerm. Slik kan både nettlesere og hjelpemiddelprogramvare tilby ekstra funksjonalitet for å gjøre navigasjon eller interaksjon mer effektivt. I noen tilfeller er bruk av WAI-ARIA nødvendig for i det hele tatt å gjøre det mulig å betjene en kontroll eller en hel webside for en person med funksjonsnedsettelse.
En skjermleser er, som navnet tilsier, et program som kan lese skjerminnhold for en person som ikke kan oppfatte eller fortolke den informasjonen som vises på skjermen. Skjermlesere brukes som oftest av mennesker med en synsnedsettelse, men kan også være nyttige for mennesker med lesevansker eller andre kognitive utfordringer.
En skjermleser forsøker å identifisere og avlese skjerminnholdet, for deretter å presentere det på en måte som er egnet for skjermleserbrukeren, for eksempel som syntetisk tale, lydsignaler og/eller punktskrift via en ekstern leselist.
Skjermleseren har to viktige oppgaver. For det første å presentere selve teksten fra skjermen for brukeren på en måte han eller hun kan oppfatte. For det andre å fortolke ikoner, grafiske elementer, knapper, tekstfelt og andre kontroller, for deretter å samle og presentere den informasjonen brukeren har mest behov for i en gitt situasjon.
Når man beveger seg rundt i et skjermbilde kan skjermleseren identifisere det elementet som har fokus, samt viktig informasjon om dets type, tilstand og innhold.
Det finnes et stort utvalg av tastekombinasjoner som skjermleserbrukeren kan benytte for å få opplest spesifikk informasjon eller for å utføre spesifikke handlinger. Det finnes hurtigtaster for å flytte fokus til neste overskrift på en webside, eller for klikke med høyre musetast på et bestemt objekt, og mange flere.
Skjermlesere har mange innstillinger hvor brukeren kan justere hvilken informasjon som leses opp om hvilke type elementer, hvordan informasjon skal presenteres, hvordan den syntetiske talen skal høres ut osv. Slike innstillinger, samt hurtigtaster og tastekombinasjoner, varierer fra skjermleser til skjermleser, men mye av hovedfunksjonaliteten er den samme.
Måten man navigerer og leser webinnhold på med en skjermleser er fundamentalt forskjellig fra hvordan man gjør dette visuelt. En skjermleser forholder seg til innholdet lineært, dvs. i den rekkefølgen det oppstår i kildekoden. Derfor er det ikke sikkert at innhold som ser sentralt og iøyenfallende ut, er like lett å oppdage for en skjermleserbruker.
Når en skjermleserbruker åpner en webside vil hun typisk få opplest en oppsummering av den aktuelle websiden. Det vil si sidens tittel, antall overskrifter, lenker, skjemafelter osv. Dette gir et overblikk over sidens omfang, og muligheter for å navigere direkte mellom spesielle typer elementer.
De fleste skjermlesere viser websider i en virtuell buffer eller et virtuelt fokus e.l. Virtuell buffer eller virtuelt fokus er variasjoner over samme funksjonalitet med forskjellige navn.
Websiden presenteres lineært, element for element, i den virtuelle
bufferen. For hvert element brukeren navigerer til får han/hun
opplest eller vist informasjon om innhold, tilstand og type. For
eksempel vil skjermleseren formidle at noe er en lenke, og deretter
selve teksten fra lenken, som Lenke, Les mer om prosjektet
virtuell hjelpemiddellab
.
Funksjonalitet i skjermleseren gir brukeren muligheter utover bare å lese framover eller bakover på en webside. Man kan hoppe til neste eller forrige overskrift, liste, skjemafelt, bilde og mye mer. Slik kan man raskere danne seg et overblikk over en nettside, og finne fram til den informasjonen man har bruk for. Veldig få skjermleserbrukere vil lese alt på en side. Man hopper typisk over kjent og gjentagende innhold som menyer, opphavsrett-informasjon, reklame osv. Det er helt individuelt hvordan hver enkelt arbeider med en skjermleser, og mange utvikler sine egne strategier for å bli mest mulig effektive. Hvilke taster som utfører hvilke funksjoner i de enkelte skjermleseren varierer, men funksjonaliteten er ofte svært lik.
Brukeren kan bruke taster for å navigere til forrige eller neste element. Noen ganger vil dette være piltastene på tastaturet, og i andre skjermlesere piltaster sammen med andre taster som Alt og Ctrl. En annen måte å navigere raskt gjennom f.eks. en meny eller et skjema er med Tab-tasten. Den fungerer slik Tab-tasten gjør uten skjermleser, det vil si å hoppe til neste element som kan få fokus. Det er viktig at skjermleserbrukeren får tilstrekkelig informasjon når hun beveger seg gjennom en webside på denne måten. Eksempelvis er det ikke særlig nyttig å få informasjon om at man står på et tomt tekstfelt, hvis man ikke får vite hva man skal fylle inn i feltet.
Når brukeren kommer til en tabell vil skjermleseren normalt informere brukeren om tabellens størrelse, antall rader og kolonner, samt evt. tabellbeskrivelse eller tabelloverskrift. Deretter kan brukeren navigere fra celle til celle i tabellen, og på den måten lese innholdet effektivt. I en tabell som er riktig oppmerket vil skjermleseren kunne lese kolonne- og radoverskrifter sammen med innholdet i den aktuelle cellen ettersom man navigerer rundt i tabellen. Dette gjør det enklere å få oversikt over komplekse datatabeller.
Når skjermleseren kommer til et bilde vil den lese opp den alternative teksten (alt-teksten) som er tilknyttet bildet. Dersom en alternativ tekst ikke finnes, vil den forsøke å gi brukeren nok informasjon til å gjette hva bildet inneholder. Dette kan være filnavnet på bildefilen eller lignende. Dette varierer mellom de forskjellige skjermleserne og brukerens innstillinger. Hvis derimot alt-teksten er tom, det vil si "", leser skjermleseren ingenting. Dette tolkes som at bildets innhold ikke er relevant.
Noe av det viktigste å huske på når man skal forsøke å forstå hvordan en skjermleserbruker arbeider, er at hun ikke har oversikt over konteksten et element befinner seg i. Seende brukere vil ofte få mye informasjon ved å se på de omkringliggende elementene. Som skjermleserbruker er man mye mer avhengig av semantisk informasjon om hvert enkelt element.
I det følgende vil vi gå nærmere inn på hvordan skjermlesere fungerer på Windows. Måten skjermlesere fungerer på i Windows har mange fellestrekk, mens skjermlesere på andre plattformer fungerer på andre måter. Imidlertid er det også forskjeller mellom de enkelte skjermlesere på Windows-plattformen. Skjermleserens oppførsel kan også være forskjellige hvis man bruker samme skjermleser i ulike nettlesere eller ulike versjoner av samme nettleser.
Generelt har skjermlesere på Windows to hovedmodi eller måter å fungere på. Disse har ulike navn og betegnelser i ulike skjermlesere, men for enkelhets skyld kaller vi dem her for dokumentmodus og applikasjonsmodus.
I dokumentmodus presenteres websiden i en flat lineær form hvor brukeren kan navigere omtrent som i et tekstdokument. Her kan markøren flyttes til all tekst og alle elementer på en webside uavhengig om den kan få programmatisk fokus eller ikke. I dokumentmodus brukes de fleste taster på tastaturet til å gi kommandoer direkte til skjermleseren. Det kan for eksempel være h for å gå til neste overskrift eller k for å gå til neste bokmerke. Dette betyr for det første at skjermleserbrukeren kan navigere effektivt mellom ulike elementer på en side. For det andre betyr det at hvis en webapplikasjon benytter seg av hurtigtaster – f.eks. L og J for å spole framover og bakover i en video, vil disse tastetrykkene bli stoppet av skjermleseren, og dermed ikke nå fram til webapplikasjonen og utføre de aktuelle handlingene, som spoling framover eller bakover. Det finnes måter å unngå at skjermleseren stopper enkelte tastetrykk, men normalt vil man gå ut av dokumentmodus og over i applikasjonsmodus for å benytte hurtigtaster for å interagere med en webside.
I applikasjonsmodus, som noen skjermlesere kaller skjemamodus, fungerer skjermleseren mer som den ville gjort i en vanlig skrivebordsapplikasjon. Det vil si at skjermleseren kun kan fokusere på elementer som kan få fokus i nettleseren, og alle tastetrykk sendes videre til webapplikasjonen. I applikasjonsmodus navigerer man primært med tab og shift-tab for å gå til neste eller forrige element, eller piltaster, mellomromstast og enter for å bla i lister, bekrefte, krysse av osv.
Normalt åpnes websider i dokumentmodus med mindre man aktivt velger noe annet ved å gjøre innstillinger i skjermleseren. De fleste skjermlesere skifter til applikasjonsmodus når man f.eks. trykker enter for å skrive inn tekst i et redigeringsfelt. Noen skjermlesere har også funksjoner for automatisk å veksle mellom dokumentmodus og skjemamodus ettersom man flytter fokus ut og inn av skjemafelter.
Hvis hele eller deler av en webside har ARIA-attributtet role=application tvinges skjermleseren over i applikasjonsmodus. Dette gjøres typisk i webapplikasjoner hvor det er mer naturlig å forholde seg til løsningen som en applikasjon enn som et dokument, og hvor man typisk har bruk for å kunne benytte hurtigtaster for å betjene applikasjonen.
En skjermforstørrer er en hjelpemiddelprogramvare som viser skjerminnhold i forstørret og tilpasset form. Den forstørrer et utsnitt av det opprinnelige skjermbildet og viser den forstørrede og tilpassede utgaven på hele eller deler av skjermen.
Skjermforstørrere brukes av mennesker som har så nedsatt syn at de har behov for å forstørre tekst og annet skjerminnhold for å kunne lese og oppfatte det. Det forstørrede området følger typisk fokus sånn at brukeren til enhver tid kan oppdage og se endringer som skjer i skjermbildet. I tillegg kan brukeren selv bevege det forstørrede området rundt, for eksempel med mus, for å utforske andre deler av det opprinnelige skjermbildet.
I tillegg til selve forstørringen har skjermforstørrere også andre funksjoner. Det kan være funksjoner for tilpasning av farger og kontraster, utheving av fokus og musepeker, konsentrerte visninger av informasjon samlet inn fra forskjellige områder i skjermbildet og støtte for syntetisk tale.
Skjermforstørrere har også ulike forstørringsmodi, altså måter å vise forstørring på skjermen på. Det vanligste er fullskjermforstørring, hvor det forstørrede området fra det opprinnelige skjermbildet dekker hele skjermen. Et annet alternativ er en linse som kan flyttes rundt for å forstørre deler av det opprinnelige skjermbildet. Dette gir bedre oversikt fordi deler av det opprinnelige skjermbildet stadig vises omkring det forstørrede området i linsen. Et tredje alternativ er at det forstørrede området dekker en del av skjermen, for eksempel nederste halvdel. På denne måten kan øverste halvdel brukes til å vise opprinnelig skjermbilde i uforstørret versjon, eller noe helt annet som et bilde fra et eksternt kamera som brukes til å lese tekst på papir osv.
For mange med nedsatt syn er god kontrast like viktig som større tekst. Dette er ikke bare viktig for å kunne lese tekst, men også for å kunne arbeide effektivt, og ikke minst for å øke utholdenheten. Noen grupper med nedsatt syn kan være overfølsomme for lys, eller ha et ekstra stort behov for skarpe kontraster mellom forgrunn og bakgrunn. Behovene er svært individuelle, og de fleste skjermforstørrere har derfor mange muligheter for justering av farger og kontraster. Man har mulighet for å invertere fargene i skjermbildet, sette faste forgrunns- og bakgrunnsfarger, eller bruke såkalte fargeskjemaer for å sikre god kontrast.
Det vanligste området for forstørring er mellom 1 og 16 ganger. Forstørringsgraden kan brukeren selv justere, og behovet for forstørring kan variere etter hvilken arbeidsoppgave hun utfører, hvor tilgjengelige ulike websider er eller hvor god kontrast det aktuelle skjermbildet har.
Med en forstørring på 8 vil brukeren kun se 1/64 av skjermbildet om gangen. Dette gir naturligvis utfordringer når det gjelder å beholde oversikten over skjermbildet, og å kunne navigere raskt fra et sted på skjermen til et annet.
Blant de største utfordringene for bruk av websider med skjermforstørrere er:
Mange skjermforstørrere gjør også bruk av funksjonalitet kjent fra skjermlesere for å navigere effektivt mellom ulike elementer på en webside, samt mulighet for å få deler av skjermbildet opplest ved hjelp av syntetisk tale.
I dette kapitlet lister vi opp noen av de vanligste problemene knyttet til teknisk tilgjengelighet til websider, og mulige forslag til løsninger.
klikk her. Prøv også å unngå at mange lenketekster på en webside begynner med de samme ordene.
Trykk på den røde knappen for å fortsette, ikke nok informasjon.
Som vi har vært inne på krever universell utforming både teknisk tilgjengelighet og brukervennlighet. I hvilken grad løsningen er brukervennlig evalueres best gjennom brukertesting. Det er viktig å forsøke å fjerne flest mulig tilgjengelighets- og brukervennlighetsproblemer før man gjennomfører brukertesting. Teknisk tilgjengelighet oppnås gjennom å følge standarder og retningslinjer og å teste for kompatibilitet med hjelpemidler. Man kan bruke automatiske evalueringsverktøy og ekspertevaluering i dette arbeidet.
Brukervennligheten kan forbedres ved gjennomgang av eksperter i brukskvalitet, ved selv å bruke IKT-hjelpemidler kan eksperter til en viss grad også evaluere løsningens brukervennlighet med slike hjelpemidler. Best resultat oppnås ved å kombinere flere metoder, se et eget avsnitt.
I de neste avsnittene omtales forskjellige metoder for å teste tilgjengelighet. Ettersom det er teknisk tilgjengelighet som er hovedfokuset for denne håndboken, omtales brukertesting kun kort i neste avsnitt.
For å oppnå god brukskvalitet og brukervennlighet for personer med nedsatt funksjonsevne bør man gjennomføre brukertesting med personer med ulike kategorier av funksjonsnedsettelser, se også eget avsnitt. Men før personer med nedsatt funksjonsevne involveres i evaluering av IKT-løsninger, er det viktig å rydde flest mulig tekniske og opplagte tilgjengelighetsproblemer av veien. Dersom ikke løsningen er teknisk tilgjengelig, risikerer man at brukertesteren ikke kan bruke løsningen i det hele tatt, og man vil ikke få noe særlig ut av brukertesten. Det vil i så fall bety svært dårlig bruk av tiden til alle som er involvert i testingen. Derfor anbefales det sterkt å gjennomføre teknisk tilgjengelighetstesting og eksperttesting før man gjennomfører brukertesting. Dette utelukker selvsagt ikke at brukere med nedsatt funksjonsevne kan gi innspill til løsningen på et tidligere stadium i utviklingsprosessen.
Teknisk tilgjengelighetstesting innebærer å sjekke at løsningen minst oppfyller:
Det første steget i tilgjengelighetstesting er vanligvis å bruke automatiske evalueringsverktøy. Kontroll med automatiske verktøy kunne avdekke en del avvik fra WCAG-retningslinjene, men langt fra alle. Undersøkelser viser at automatiske evalueringsverktøy har en del begrensninger. Blant annet kan de ikke avdekke hele spekteret av tilgjengelighetsproblemer. I en del sammenhenger er konteksten viktig, noe som automatiske verktøy i liten grad tar hensyn til.
Ulike verktøy har forskjellige styrker og svakheter. Derfor kan det være en fordel å bruke flere evalueringsverktøy for å få en best mulig sjekk. I en undersøkelse fant man at automatiske evalueringsverktøy for å kontrollere WCAG i beste fall kunne avdekke inntil halvparten så mange avvik som eksperter på WCAG avdekket. Derfor er det nødvendig med ekspertgjennomgang av WCAG-retningslinjene, i tillegg til kontroll ved bruk av automatiske evalueringsverktøy (se eget avsnitt). W3Cs sider har en ganske omfattende liste med verktøy for å sjekke tilgjengelighet. Her finner man flere forskjellige WCAG-sjekkere, HTML-sjekker, CSS-sjekker og kontrast-sjekker, sjekker av brutte lenker med mer. Man finner også verktøy for å sjekke lesbarhet. Dette kontrollerer i hvilken grad man har lange setninger og mange lange vanskelige ord.
Ekspertgjennomgang av tilgjengelighet innebærer at en ekspert går gjennom løsningen og evaluerer tilgjengelighet. En slik gjennomgang baseres ofte på retningslinjer (som WCAG), heuristikker og andre verktøy (f.eks. VHL og Personas) samt ekspertens egen erfaring.
Undersøkelser tyder på at en ekspertgjennomgang for å sjekke om WCAG-retningslinjene er oppfylt, kan avdekke i størrelsesorden 30–50% av bruksproblemene i en IKT-løsning, i forhold til antall bruksproblemer avdekket gjennom brukertester med personer med nedsatt funksjonsevne.
For å bedre brukervennligheten for IKT-hjelpemidler kan man gjøre ekspertgjennomgang med slike hjelpemidler. Det kan for eksempel innebære å gjennomføre et sett med tekstoppgaver med en skjermleser. Testoppgavene vil typisk være de samme som man bruker ved vanlig brukertesting.
En personabeskrivelse er en beskrivelse av en potensiell bruker av løsningen. Personas utvikles basert på informasjon om brukere i målgruppen. En personagjennomgang (persona walkthrough) innebærer at eksperten forsøker å løse testoppgaver fra perspektivet til hver persona. Man spiller altså hver persona mens man bruker løsningen. For at dette skal ha verdi fra et tilgjengelighetsperspektiv, må man ha personaer med ulike typer funksjonsnedsettelser.
For å kunne gjøre en realistisk personagjennomgang er det også en forutsetning at eksperten har praktisk erfaring med den/de typer funksjonsnedsettelser som man skal spille. Simulering av funksjonsnedsettelser kan være et alternativ eller supplement til en slik gjennomgang. For eksempel kan man bruke briller innmurt med fett for å simulere nedsatt syn, og man kan bruke hansker for å simulere dårlig håndfunksjon. Det er imidlertid svært vanskelig å simulere kognitive funksjonsnedsettelser på en pålitelig måte. Det å ha erfaring med hvordan personer med ulike typer funksjonsnedsettelser interagerer med teknologi er også viktig i arbeidet med å oppnå kognitiv tilgjengelighet. Det kan være nyttig å lese Utformingsveileder for kognitiv tilgjengelighet av elektroniske tjenester og innhold.
Som forklart i et eget avsnitt innebærer universell utforming både teknisk tilgjengelighet og brukervennlighet. Forskning tyder på at
Dette betyr at dersom målet er reell tilgjengelighet og brukskvalitet for flest mulig, er det lite klokt å basere seg på en enkeltvurdering av WCAG. Innkjøpere bør kreve at leverandør gjennomfører teknisk tilgjengelighetstest inkludert testing av kompatibilitet med hjelpemidler, ekspertevaluering og brukertesting med personer med nedsatt funksjonsevne. Eventuelt bør man planlegge med en uavhengig tilgjengelighetsevaluering.
Den viktigste måten å sikre både god teknisk tilgjengelighet og brukervennlighet i en IKT-løsning er å benytte seg av en brukersentrert utviklingsprosess hvor brukertester på virkelige personer i realistiske kontekster er en naturlig del av utviklingsforløpet. Imidlertid kan det i mange sammenhenger være nyttig og ønskelig å gjøre en rask evaluering av både tilgjengelighet og brukervennlighet av en IKT-løsning f.eks. for brukere av hjelpemiddelprogramvare uten å involvere brukere.
Det kan det være flere grunner til dette:
Når man arbeider med testing med ulike kombinasjoner av nettlesere og hjelpemiddelprogramvare kan testingen ha flere formål, og det er viktig å avklare dette før man begynner planlegging og gjennomføring av tester ettersom det har betydning for hvilken metode og tilgang man velger.
De to hovedtypene er:
I type 1 er det primære formålet å avdekke tekniske utfordringer som hindrer brukeren i å få informasjon om, eller interagere med, spesifikke elementer i IKT-løsningen. Eksempler på dette kan f.eks. være knapper som ikke har riktig semantisk oppmerking – altså at de ikke er merket som knapper, men bare ser ut som knapper rent visuelt. Da kan elementet ikke oppfattes som knapp av en skjermleser. Det kan også være elementer som ikke kan få fokus med tastatur, men kun ved hjelp av mus eller pekeskjerm.
I type 2 er målet å gjøre en helhetlig vurdering av brukervennlighet i en løsning slik den oppleves for en bruker av hjelpemiddelprogramvare. Dette innebærer å gjør en evaluering av brukervennligheten samtidig som man bruker hjelpemiddelprogramvaren. Det kan ellers foregå slik det vanligvis gjør, men man vil ta spesielt hensyn til de strategier som brukerne av hjelpemidler benytter seg av.
Vi vil her primært fokusere på systematisk teknisk tilgjengelighetstesting, men også forsøke å gi noen tips til generell brukervennlighetsvurdering med skjermleser.
Hovedmålet med teknisk tilgjengelighetstesting med skjermleser er å sikre at all informasjon på en webside er tilgjengelig for skjermleseren, og dermed for brukeren av skjermleseren. Skjermlesere leser ikke all informasjon på skjermen til enhver tid, men forsøker å gi brukeren den mest relevante informasjonen i den konteksten hvor brukeren er. For å kunne gjøre dette har skjermleseren bruk for mest mulig informasjon om de ulike elementene på en webside – se eget avsnitt.
Det er også stor forskjell på hvordan ulike skjermlesere viser og interagerer med innhold på en webside. Det er derfor viktig å sette seg godt inn i den skjermleseren man ønsker å teste med og hvordan det påvirker testingen. F.eks. flytter skjermleserne NVDA på Windows og VoiceOver på Mac fokus i nettleseren, mens skjermleseren JAWS for Windows ikke flytter nettleserfokus før man interagerer med et element eller går inn i skjemamodus.
Som en konsekvens av denne forskjellen kan et dynamisk element som en radioknapp oppføre seg annerledes i JAWS enn i NVDA. Det kan f.eks. skje fordi webløsningen forstår at NVDA-brukere flytter fokus og dermed utfører en gitt handling knyttet til at et bestemt valg får fokus, mens det samme ikke skjer med JAWS fordi webløsningen ikke forstår at brukeren endrer fokus. Det er for øvrig ikke å anbefale å utføre handlinger basert på fokusendring, men kun når brukeren selv bekrefter at hun er klar ved å trykke ”Ok”, ”Submit” eller lignende.
I denne sammenheng handler semantikk om å gi ekstra informasjon om elementer i brukergrensesnittet. Det betyr at det gis informasjon om elementets navn, rolle, egenskaper og status. Det kan for eksempel være at avkrysningsboksen er avkrysset, eller at et element er en lenke til et annet nettsted. Litt forenklet kan man si at semantikken gir informasjon om hva elementet er og hva man kan gjøre med det.
Når en skjermleserbruker beveger seg gjennom en webside leser skjermleseren informasjon om de enkelte elementene man navigerer til. Den kan f.eks. si ”Meld deg på her. Lenke”. eller ”Jeg godtar vilkårene. Avkryssingsboks ikke avkrysset”.
Hvis et element er feil kodet vil skjermleseren ikke ha tilgang til all den nødvendige informasjonen, og dermed heller ikke kunne lese den riktig opp for brukeren. F.eks. kan skjermleseren si ”redigeringsfelt” uten noe mer informasjon. Dette tyder på at skjemafeltet ikke har en label (etikett) som forklarer hva feltet er eller hvilken type input som er forventet.
Hvis skjermleseren kun sier ”søk” når den burde ha sagt ”søk. Knapp” tyder dette på at elementet mangler den nødvendige semantiske oppmerkingen.
Alle skjermlesere har sin egen måte å navigere og betjene websider på. Ettersom man blir mer erfaren i testing med skjermlesere tillegger man seg vaner og måter å løse problemer på som er mer effektive. Imidlertid kan det være lurt å starte med å gå helt systematisk til verks.
Ved å starte øverst på hver side og bevege seg nedover, for så å sjekke hvert element vil man ganske raskt få en oversikt over om skjermleseren gir brukeren tilstrekkelig med informasjon om de enkelte elementene – altså om de er riktig semantisk oppmerket, og f.eks. om de har gode tekstlige alternativer for bilder.
Det er også andre ting som er viktige å undersøke. Elementene på en webside står sjelden helt for seg selv, og det er viktig å se om rekkefølge og sammenheng er fornuftig. Mange elementer kan også interageres med, og her er det viktig å sjekke at også dette kan gjøres ved hjelp av skjermleser og tastatur.
Vi vil her gå gjennom noen av de vanligste elementtypene, og nevne noen av de viktigste tingene å se etter for hver type element. Deretter vil vi gi noen tips for hvordan man kan undersøke om elementer kan betjenes, og om rekkefølgen av informasjonen på websiden er hensiktsmessig.
Hvis siden har landemerker/regioner:
Det er viktig at språk alltid angis programmatisk. Det skal som minimum angis en gang per side. Dersom deler av siden – f.eks. et avsnitt er skrevet på et annet språk enn det som er angitt for siden som helhet skal dette merkes opp med bruk av lang-attributtet for det aktuelle avsnittet. Dette fører normalt til at skjermleseren skifter til den riktige syntetiske stemmen for den delen av dokumentet som er på et annet språk – forutsatt at den har en tilgjengelig stemme for språket.
Skjermleseren leser opp informasjonene på en webside i samme rekkefølge som det oppstår i koden. Dvs. at rekkefølgen ikke alltid er den samme som på skjermen. Noen ganger kan dette være en fordel. Det er to ting det er viktig å sjekke i forhold til dette:
De fleste skjermlesere har funksjonalitet for å liste opp alle overskrifter, lenker, skjemafelter osv. Disse funksjonene kan være nyttig for å sjekke at strukturen som framstår for brukere av skjermlesere er logisk, og samsvarer med den visuelle strukturen på en side.
Bruk skjermleserens funksjonalitet for å liste opp alle overskrifter, og sjekk følgende:
Du kan også bruke skjermleserens funksjonalitet for å liste opp landemerker og regioner eller skjemafelter for raskt å sjekke at alle elementer av en type er riktig kodet.
interoperabilitetbrukes også i denne sammenheng, dvs. hvor bra ulike tekniske enheter fungerer sammen.
Norsk standard.
operativsystem.
universell utforming.