Håndbok i testing av websider med hjelpe­middel­program­vare (utkast)

Innledning

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 bruker­vennlig for flest mulig.

For å oppnå teknisk tilgjen­gelig­het må man blant annet sørge for kompatibilitet med IKT-​hjelpe­midler. Det finnes mange typer IKT-​hjelpe­midler (se mer om dette i et eget avsnitt. Det er nødvendig å teste løsningen sammen med de ulike hjelpe­midlene for å sikre best mulig kompatibilitet i praksis. Men, manglende tilgang til og kunnskap om de ulike hjelpe­midlene er en stor utfordring for å få dette til.

Med denne håndboken vil vi gi leseren innsikt i aktuelle problemstillinger rundt teknisk tilgjen­gelig­het og IKT-​hjelpe­midler. Her får du informasjon om typer av IKT-​hjelpe­midler, hvordan en skjerm­leser fungerer og testing med IKT-​hjelpe­midler.

I tillegg skal boken gi en innføring i et nytt verktøy for tilgjen­gelighets­testing, 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 tilgjen­gelig­het. 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 hjelpe­middel­teknologi. Målgruppe for VHL-verktøyet er først og fremst utviklere.

Forfattere, kontakt & bakgrunn

Dette dokumentet er skrevet og utformet av:

• Kristin Skeide Fuglerud (Norsk Regnesentral)
• Stein Erik Skotkjerra (Vision2Access)
• Till Halbach (Norsk Regnesentral)

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 hjelpe­middel­teknologi 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 tilgjen­gelighets­testing og bruker­under­sø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 hjelpe­middellab (VHL) er et prosjekt finansiert gjennom UnIKT-​midlene fra Deltasenteret i Barne-, ungdoms- og familiedirektoratet.

Hvorfor er det behov for VHL?

På tross av at løsninger overholder WCAG-retnings­linjene (se eget avsnitt), kan det være problemer med kompatibilitet med ulike hjelpe­midler, spesielt med skjerm­lesere. Ideelt sett kunne man tenke seg at dersom en IKT-​løsning virker med ett hjelpe­middel, vil det også virke med andre tilsvarende hjelpe­midler. Det er ikke nødvendigvis tilfellet. Det har vist seg at en løsning som fungerer med én skjerm­leser ikke nødvendigvis fungerer tilfredsstillende med andre skjerm­lesere.

Årsakene til dette kan være mange og sammensatte. For det første fungerer de ulike skjerm­leserne litt forskjellig, og de fungerer forskjellig sammen med ulike nettlesere. Dessuten, når nettleserne oppdateres, må vanligvis også hjelpe­midlene oppdateres. Det er imidlertid ofte ulik takt på oppdateringer, både med hensyn til type nettleser, nettleser-versjoner og type skjerm­leser. Dette fører til en uoversiktlig situasjon. Hvilke versjoner av hvilke nettlesere, og IKT-​hjelpe­midler bør testes for å sikre universell utforming?

Det er svært få utviklermiljøer som har tilgang til mange forskjellige IKT-​hjelpe­midler, og problematikken rundt versjoner og oppdateringer er en stor utfordring. Hjelpe­midlene kan ofte være svært kostbare. Derfor er det ganske urealistisk for flesteparten av utviklermiljøene å anskaffe og holde orden på mange forskjellige hjelpe­midler i ulike versjoner.

Det å teste med IKT-​hjelpe­midler krever også kompetanse om hvordan hjelpe­midlene brukes. Testing med hjelpe­midler er likevel en forutsetning for å oppnå reell tilgjen­gelig­het. 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-​hjelpe­midler innenfor de gitte kostnads- og tidsrammer.

Tanken er at VHL-verktøyet på sikt skal kunne brukes til å teste med ulike hjelpe­midler og i ulike versjoner, og at det også skal hjelpe til med å holde styr på dette.

Innhold

Universell utforming og tilgjen­gelig­het

Begrepet universell utforming (uu) ble først tatt i bruk for å beskrive en prosess for å sikre best mulig tilgjen­gelig­het for funksjons­hemmede i fysiske omgivelser, dvs. tilgjen­gelig­het til bygninger og uteområder.

Begrepet universell utforming springer ut fra det utviklings­arbeidet 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å tilgjen­gelig­het. Istedenfor å se på tilgjen­gelig­het 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 funksjons­nedsettelse 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å utviklings­prosessen, nemlig hvordan man skal kunne oppnå dette målet. Hva slags resultat man får, er selvsagt svært avhengig av hvilken utviklings­prosess 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 utviklings­prosessen, og som et utgangspunkt for evaluering av eksisterende og nye løsninger. De syv prinsippene er:

1. Like muligheter for bruk
2. Fleksibel bruk
3. Enkel og intuitiv bruk
4. Forståelig bruk
5. Toleranse for feil
6. Lav fysisk anstrengelse
7. Størrelse og plass for tilgang og bruk

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 tilgjen­gelig­het for personer med nedsatt funksjons­evne. Dette kommer vi nærmere inn på i et eget avsnitt om forholdet mellom universell utforming og tilgjen­gelig­het.

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.

Universell utforming og IKT

For å kunne bruke informasjons- og kommuni­kasjons­teknologi (IKT) må vi kunne oppfatte og forstå informasjon og kommuni­kasjon.

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 tilgjen­gelig­het 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 bruker­vennlig, er en helt sentral del av universell utforming av IKT.

Kort sagt, universell utforming av IKT krever teknisk tilgjen­gelig­het for at vi skal kunne oppfatte informasjonen, og bruker­vennlighet for at vi skal kunne forstå informasjonen.

Man kan gjenkjenne elementer fra de syv prinsippene for universell utforming i retnings­linjer for tilgjen­gelig­het 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 retnings­linjer. Se mer om dette i et eget avsnitt.

Diskrimi­nerings- og tilgjen­gelig­hetsloven og Forskrift om universell utforming av IKT

Diskrimi­nerings- og tilgjen­gelig­hetsloven (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 samfunns­deltakelse for alle, uavhengig av funksjons­evne, og hindre diskrimi­nering på grunn av nedsatt funksjons­evne.

Loven skal bidra til nedbygging av samfunns­skapte funksjons­hemmende 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 hoved­løsningen i de fysiske forholdene, herunder informasjons- og kommuni­kasjons­teknologi (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 hoved­lø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.

Forholdet mellom universell utforming og tilgjen­gelig­het

Begrepene universell utforming og tilgjen­gelig­het for mennesker med nedsatt funksjons­evne, eller bare tilgjen­gelig­het, blir ofte brukt om hverandre, men brukes ikke alltid synonymt.

Hoved­forskjellen på tilgjen­gelig­het og universell utforming ligger i at tilgjen­gelig­het ikke nødvendigvis er inkluderende. Man kan lage spesial­produkter 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 funksjons­nedsettelse 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 tilgjen­gelig­het til IKT for personer med nedsatt funksjons­evne forstås ofte det vi refererer til som teknisk tilgjen­gelig­het. Det vil si at det teknisk sett er mulig å bruke f.eks. en webside med skjerm­leserprogram­vare, eller at det teknisk sett er mulig å betjene en webside kun ved bruk av tastatur. Men en løsning som overholder WCAG-retnings­linjene og som teknisk sett er kompatibel med hjelpe­midler, 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 funksjons­evne. For å være universelt utformet må løsningen, i tillegg til å være teknisk tilgjengelig, også være bruker­vennlig for personer med nedsatt funksjons­evne, inkludert de som bruker IKT-​hjelpe­midler.

Kravet til bruker­vennlighet kommer ofte mye tydeligere fram i engelske definisjoner av universell utforming og tilgjen­gelig­het enn i de norske oversettelsene. En viktig grunn til dette er at det engelske ordet usable, som i denne sammenheng kan oversettes med bruker­vennlig, istedenfor har blitt oversatt med kan brukes. (Se f.eks. definisjonen i et eget avsnitt og et annet avsnitt).

Tilgjen­Gelig­Het 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 bruker­vennlighets­aspektet og mangfolds­aspektet inkludert. Denne definisjonen av tilgjen­gelig­het overlapper i stor grad med definisjonen av universell utforming utarbeidet av The Center for Universal Design ved North Carolina State University; se eget avsnitt.

Kompatibilitet med IKT-​hjelpe­midler

Noen personer med nedsatt funksjons­evne er avhengige av å bruke spesialisert program­vare, kalt IKT-​hjelpe­midler, sammen med ordinære IKT-​løsninger for å kunne bruke dem. Et typisk eksempel på dette er en skjerm­leser som sammen med en leselist brukes av blinde eller personer med sterkt nedsatt syn. Skjerm­leseren 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 program­vare 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-​hjelpe­midler. Bevegelses­hemmede kan for eksempel bruke spesielle typer tastatur, mus eller øyestyring. Dyslektikere bruker ofte spesiell program­vare 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 hoved­lø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-​hjelpe­midler sammen med universelt utformede løsninger, for å få tilgang til dem. I følge Forente Nasjoners konvensjon om rettighetene til mennesker med nedsatt funksjons­evne, skal uu ikke utelukke hjelpe­midler 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-​hjelpe­midler.

Vi ser i økende grad at noe av den funksjonaliteten som finnes i IKT-​hjelpe­midler 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-​hjelpe­midlene dekker på en så god måte at det er et alternativ for de som trenger hjelpe­midler. De fleste IKT-​løsningene leveres for eksempel ikke med innebygd leselist, skjerm­leser eller skjermtastatur. IKT-​løsninger må derfor kunne brukes sammen med slike IKT-​hjelpe­midler for å bli tilgjengelige. Det kreves med andre ord kompatibilitet med IKT-​hjelpe­midler. Se mer om IKT-​hjelpe­midler i et eget avsnitt.

I denne håndboken konsentrerer vi oss om hjelpe­midler som er nødvendige for personer med nedsatt funksjons­evne. Det er hjelpe­midler 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 hjelpe­middelet.

Forskrift om universell utforming av IKT-​løsninger krever kompatibilitet med IKT-​hjelpe­midler. Se mer om dette i et eget avsnitt.

Standarder og retnings­linjer

Det finnes ulike standarder og retnings­linjer som kan være til god hjelp i arbeidet med universell utforming av IKT. I dette kapittelet nevnes noen sentrale standarder og retnings­linjer på dette området.

Web Content Accessibility Guidelines / WCAG

WCAG-retnings­linjene 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 retnings­linjer 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 diskrimi­nerings- og tilgjen­gelig­hetsloven kreves det at nettløsninger rettet mot allmennheten følger disse retnings­linjene, med noen få presiseringer som vi kommer inn på nedenfor.

WCAG 2.0 har til sammen 12 retnings­linjer som er organisert under fire hoved­prinsipper:

1. Mulig å oppfatte
2. Mulig å betjene
3. Forståelig
4. Robust

For hver retnings­linje er det et eller flere suksess­kriterier. Suksess­kriteriene er inndelt i tre nivåer: A, AA, og AAA, hvor AAA er det nivået med best tilgjen­gelig­het. DTL krever at man oppfyller alle suksess­kriteriene på nivå A og AA, med unntak for suksess­kriteriene 1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt), 1.2.4 Teksting (direkte), og 1.2.5 Synstolking (forhåndsinnpilt).

En del av suksess­kriteriene 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 bruker­vennlig 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 krever kompatibilitet med hjelpe­midler

WCAG-retnings­linje 4.1 omhandler kompatibilitet med hjelpe­midler:

Retnings­linje 4.1 Kompatibel: Sørg for best mulig kompatibilitet med aktuelle og framtidige bruker­agenter, inkludert kompenserende teknologi.

Eksempler på bruker­agenter er nettlesere, e-postlesere, mediespillere og IKT-​hjelpe­midler; se også User Agent Accessibility Guidelines (UAAG). En person som er avhengig av IKT-​hjelpe­midler for å bruke IKT, kan søke det offentlige (dvs. nav) om støtte til dette. Retten til å få dekket hjelpe­midler under Lov om folketrygd, vurderes individuelt etter visse kriterier.

For å vurdere hvilke hjelpe­midler som en IKT-​løsning bør være kompatibel med, mener vi det er naturlig å ta utgangspunkt i de hjelpe­midlene som nav gir støtte til. nav inngår rammeavtaler med hjelpe­middel­leverandører og har oversikt over hvilke hjelpe­midler som til enhver tid er i bruk. Se mer om hjelpe­midler i et eget avsnitt.

Hvor grensen går for hvilken funksjonalitet som dekkes av IKT-​hjelpe­midler 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-retnings­linje 4.1, som krever best mulig kompatibilitet med aktuelle og framtidige bruker­agenter.

Det kan være flere fordeler med at funksjoner som tradisjonelt sett har blitt dekket av IKT-​hjelpe­midler, blir integrert i vanlige IKT-​løsninger. For det første er det flere enn de som har rett til støtte til hjelpe­midler 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.

WCAG er et godt utgangspunkt, men ikke tilstrekkelig

Det er bred enighet blant eksperter, forskere og brukere om at det å følge WCAG-retnings­linjene er en viktig forutsetning for å oppnå universell utforming, men at det på ingen måte er tilstrekkelig.

I tillegg til å følge standarder og retnings­linjer bør universell utforming som prosess baseres på en bruker­sentrert utviklings­prosess. Standarden Menneskeorientert design for interaktive systemer (NS–EN ISO 9241-210:2010) er et godt utgangspunkt. De viktigste prinsippene i en menneskesentrert utviklings­prosess er:

1. Utformingen er basert på en eksplisitt forståelse av brukerne, oppgaver og omgivelser
2. Aktiv involvering av brukere gjennom hele design og utviklings­prosessen
3. Utformingen drives og forbedres gjennom bruker­sentrert evaluering
4. Utviklingen av designløsningen foregår i iterasjoner (gjennom gjentakelse av et eller flere steg)
5. Utformingen tar hensyn til hele bruker­opplevelsen
6. Utviklingsgruppen har tverrfaglig kompetanse og perspektiver

For å oppnå universell utforming må brukere med nedsatt funksjons­evne innoveres i denne prosessen. En nærmere beskrivelse av universell utforming og bruker­medvirkning finnes i standarden Universell utforming og bruker­medvirkning – 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 utviklings­forløpet.

Allerede når man definerer og setter rammene for prosjektet, bør man planlegge hvordan man kan involvere brukere med nedsatt funksjons­evne tidligst mulig i utviklings­prosessen 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 bruker­tester med personer med nedsatt funksjons­evne. Se mer om testing av tilgjen­gelig­het i et eget avsnitt. Iterativ utvikling betegner en syklisk prosess hvor produktet forbedres gradvis gjennom å gjenta en rekke trinn (f.eks. avdekke bruker­krav, design, utvikling og testing) inntil produktet har den ønskede kvalitet.

Andre standarder og retnings­linjer

For mer enn ti år siden fant forskere. på mellom 200-300 retnings­linjer for å gjøre produkter mer tilgjengelige. Siden har antallet slike retnings­linjer økt ytterligere. For eksempel har det kommet retnings­linjer for mobil tilgjen­gelig­het og tilgjengelig web 2.0. Nedenfor lister vi opp noen utvalgte standarder og retnings­linjer som vi mener er viktige og relevante for webutvikling.

Accessible Rich Internet Applications (WAI-ARIA)

Målgruppen for disse retnings­linjene er de som utvikler rike internett­applika­sjoner. Se også eget avsnitt.

BBC Mobile Accessibility Guidelines

Disse teknologiuavhengige retningslinjene er utarbeidet for alle som lager mobile websider og applikasjoner.

W3C WAI Mobile Accessibility

Målgruppen for disse retnings­linjene er de som utvikler web­applika­sjoner for mobile enheter som smarttelefoner og nettbrett.

NS–EN ISO 9241-210:2010, Ergonomi for samhandling mellom menneske og system. Del 210: Menneskeorientert design av interaktive systemer

Denne standarden beskriver beste praksis for en iterativ og brukersentrert utviklingsprosess.

NS 11040:2013 Universell utforming – Brukermedvirkning og IKT

Denne standarden beskriver hvordan brukere med nedsatt funksjonsevne kan involveres i en utviklingsprosess for å oppnå universell utforming. Den omhandler de ulike trinnene i utviklingsprosessen, fra planlegging, kravspesifikasjon, til testing og evaluering.

NS 11022:2013 Universell utforming – Automater for allmenn bruk – Krav til fysisk utforming og brukerdialog

Beskriver hvordan fysiske utforming av automater og interaksjon med automaten bør utformes for å oppnå best mulig tilgjengelighet.

Kvalitet på nett

Kriteriesett som forvaltes av Difi (Direktoratet for forvaltning og IKT).

ELMER

Målgruppen for disse retnings­linjene er de som utvikler elektroniske skjemaer. ELMER er en norsk forvaltningsstandard for skjemaer på nett.

User Agent Accessibility Guidelines (UAAG)

Målgruppen for disse retnings­linjene er de som utvikler bruker­agenter, som f.eks. nettlesere og IKT-​hjelpe­midler.

Authoring Tool Accessibility Guidelines (ATAG)

Målgruppen for disse retnings­linjene er utviklere av forfatterverktøy som brukes til å produsere innhold til websider.

NS–EN ISO 9241–171:2008, Ergonomi for samhandling mellom menneske og system – Del 171: Veiledning om tilgjen­gelig­het av program­vare (ISO 9241–171:2008)

Denne standarden har spesielt fokus på tilgjengelighet til input og output elementer i programvare.

NS–EN ISO 9241–20:2009, Ergonomi for samhandling mellom menneske og system – Del 20: Veiledning om tilgjen­gelig­het for informasjons- og kommuni­kasjons­teknologiske innretninger og tjenester (ISO 9241–20:2008)

Denne standarden gir anbefalinger om tilgjengelighet i forhold til ulike brukerkarakteristika, oppgaver, utstyr og tjenester.

Funksjons­nedsettelser

Hjelpe­midler brukes ofte av personer med nedsatt funksjons­evne. Funksjons­nedsettelsene grupperes ofte i tre hoved­kategorier:

Nedenfor gis noen eksempler på typer av funksjons­nedsettelser innenfor hver av de tre hoved­kategoriene og på hva man bør tenke på hva gjelder utforming av IKT.

Sensoriske funksjons­nedsettelser

Sensoriske funksjons­nedsettelser 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 funksjons­nedsettelser.

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 kommuni­kasjon via skjerm­leser 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 kommuni­kasjons­formen. 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 funksjons­nedsettelser

Motoriske funksjons­nedsettelser eller bevegelses­hemninger 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 bevegelses­apparatet.

Det å kunne betjene IKT-​løsningen er en av hoved­utfordringene 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 hjelpe­midler som brytere, spesial­mus, spesial­tastatur, taleinput eller øyestyring.

Kognitive funksjons­nedsettelser

Betegnelsen kognitive funksjons­nedsettelser brukes ofte svært vidt, og sett under ett anses dette som den største gruppen av de tre hoved­kategoriene. Kognitive funksjons­nedsettelser omfatter atferdsmessige, tankemessige og følelsesmessige funksjons­nedsettelser 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 retnings­forståelse, sosiale ferdigheter og impulskontroll. Lese- og skrivevansker nevnes også i denne sammenheng, i tillegg til visuell forståelse og tallforståelse.

Kognitive funksjons­nedsettelser kan virke inn på evnen til å behandle informasjon og på vurderings- og beslutningsevne. Det er stor variasjon i grad og sammensetning av kognitive funksjons­nedsettelser. Funksjons­nivå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 kommuni­kasjon, som f.eks. symbolspråk. For disse er det viktig at informasjon og kommuni­kasjon i løsningen kan bli tilrettelagt for det aktuelle symbolspråket.

Grensen mellom hva som er allmennteknologi og hjelpe­midler for personer med kognitive funksjons­nedsettelser er ofte flytende. I mange tilfeller vil allmennteknologi som ikke er spesielt utviklet med hensyn til denne bruker­gruppen, kunne være til ekstra stor nytte, og kan dermed betraktes som et IKT-​hjelpe­middel for den det gjelder. Det kan eksempelvis være program­vare som hjelper brukeren med å organisere og huske informasjon, eller ordrettingsprogrammer. I andre tilfeller er det behov for spesial­utviklet program­vare med forsterkede hjelpe­funksjoner. Program­varer med ekstra lese- og skrivestøtte er et eksempel på IKT-​hjelpe­midler som er mye brukt av dyslektikere.

Det er vanskeligere å tilrettelegge for personer med sterkt nedsatt kognitiv funksjons­evne 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-​hjelpe­midler være avgjørende, mens tilretteleggingen for personer med kognitive funksjons­nedsettelser i stor grad handler om særdeles god bruker­vennlighet, enkelhet, forutsigbarhet og gode tilbakemeldinger.

For utfyllende informasjon om kognitiv funksjons­evne og hvordan lage nettsider for personer med nedsatt kognitiv funksjons­evne, se Utformingsveileder for kognitiv tilgjen­gelig­het av elektroniske tjenester og innhold.

Midlertidige eller situasjons­bestemte funksjons­nedsettelser

De fleste opplever nedsatt funksjons­evne 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 program­vare 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 funksjons­nedsettelse. 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 funksjons­evne og design for bruk i ulike kontekster, noe som er typisk for design for mobile enheter og bruk i ulike omgivelser.

Sammensatte funksjons­nedsettelser

Mange personer har mer enn én type funksjons­nedsettelse. Dette er ofte tilfellet for eldre personer. Statistikk tyder på at det er minst like mange mennesker med to eller flere funksjons­nedsettelser som med kun en type. Det er imidlertid en svært liten andel av personer med nedsatt funksjons­evne som mangler en eller flere funksjoner fullstendig. Oftest handler det om grader av nedsatt funksjons­evne. Det er selvsagt viktig å tilrettelegge for personer med en type høy grad av funksjons­nedsettelse, 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 funksjons­nedsettelser.

Hva er IKT-​hjelpe­midler?

IKT-​hjelpe­midler (AT på engelsk) er maskin- eller program­varer som er anskaffet kommersielt, tilpasset eller spesial­utviklet, og som har som formål å støtte, forbedre eller opprettholde menneskelige funksjoner. Det finnes hjelpe­midler 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 hjelpe­middel­teknologi 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 funksjons­evne, 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 hjelpe­middel­teknologi.

Med IKT-​hjelpe­midler mener vi altså i denne håndboken program­vare, maskinvare eller en kombinasjon av disse som skal dekke det gapet som oppstår mellom en persons funksjons­evne og de kravene en IKT-​løsning stiller til den som skal bruke den. Vi begrenser oss også til hjelpe­midler som enkeltpersoner med nedsatt funksjons­evne har behov for og får offentlig støtte til under Lov om folketrygd.

Hvordan fungerer IKT-hjelpe­midler

Vi kan dele inn IKT-​hjelpe­midler i hjelpe­middel­maskinvarer og hjelpe­middel­program­varer. Hjelpe­middel­maskinvarer er typisk enheter som brukes som alternativ til standard inn- og utmatingsenheter. Det kan eksempelvis være et spesial­tastatur, 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.

Hjelpe­middel­program­vare kan på samme måte som maskinvare hjelpe til med inn- eller utmating fra en enhet. Det kan eksempelvis være stemmestyringsprogram­vare som gjør at man kan styre en datamaskin eller mobiltelefon kun ved bruk av stemmen. Eller det kan være en skjerm­forstø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å hjelpe­middel­program­varer ofte til med å tolke den informasjonen brukeren mater inn eller får ut av allmennteknologi. En skjerm­leser 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 skjerm­leser 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. Program­varen forsøker å forutsi hva brukeren vil skrive, og retter dermed automatisk stave- og tastefeil etter hvert som brukeren skriver.

Kompatibilitet mellom nettlesere og hjelpe­middel­program­vare

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 operativ­system, 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 hjelpe­middel­program­varer fungerer sammen med forskjellige nettlesere.

Utviklingen innenfor både webstandarder og nettleserversjoner går raskt, og hjelpe­middel­program­vare­produsentene 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å hjelpe­middel­program­varen 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 skjerm­lesere man bør teste for kompatibilitet med og sørge for støtte til. Viktige elementer i denne vurderingen er:

• Hvilken kontroll og innflytelse har man på alle brukeres valg av nettlesere og hjelpe­middel­program­vare?
• Hvilken hjelpe­middel­program­vare innvilges av det offentlige, det vil typisk si hjelpe­middel­sentraler, skoleverket osv.
• Har man behov for å benytte seg av nyeste webteknologi for at ens løsning skal kunne fungere hensiktsmessig?
• Dersom man velger å bruke nyeste webteknologi, kan man likevel benytte løsningens hoved­funksjoner med eldre nettleserversjoner?

WCAG-retnings­linje 4.1 krever best mulig kompatibilitet med aktuelle og framtidige bruker­agenter, inkludert kompenserende teknologi. I utgangspunktet kan man oppfylle kravene i retnings­linje 4.1 ved å:

1. Benytte standardkontroller og komponenter (som gyldig HTML og CSS). På denne måten sikrer man at nødvendig informasjon om hvert enkelt element blir gjort tilgjengelig for hjelpe­middel­program­varen.
2. Sikre at egendefinerte kontroller tilgjengelig­gjør informasjon om navn, rolle og verdi. På denne måten gir man hjelpe­middel­program­varer informasjon om en kontrolls navn, status og innhold, og lar brukeren endre status eller innhold.

Et annet viktig aspekt er å sikre at hjelpe­middel­program­varen 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-​hjelpe­middelet, har man sikret teknisk tilgjen­gelig­het. Imidlertid har man ingen garanti for at løsningen er effektiv og bruker­vennlig også for brukere av hjelpe­middel­program­varer. Den beste måten å sikre seg at løsningen er bruker­vennlig på, er å teste med virkelige brukere i realistiske kontekster. Imidlertid vil man kunne avdekke mange utfordringer ved selv å gjennomføre enkle tester med hjelpe­middel­program­vare. En grunnleggende kjennskap til hvordan de ulike hjelpe­midlene interagerer med både bruker og andre bruker­agenter (som nettlesere), vil også gjøre det lettere å designe og kode riktig fra start.

Document Object Model

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 program­vare 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 hjelpe­middel­program­varer får mye av informasjonen fra, og særlig i de tilfeller hvor tilgjen­gelighets­grensesnittene (APIene) ikke tilgjengelig­gjør nok informasjon. Du kan lese mer om dette i neste kapittel.

Tilgjen­gelighets­grensesnitt

Et tilgjen­gelighets­grensesnitt er et API som gjør det mulig for hjelpe­middel­program­varer å kommunisere med en applikasjon for å hente eller manipulere informasjon om elementer som vises på skjermen. For å forstå behovet for tilgjen­gelighets­grensesnittene er det nødvendig å se på hvordan hjelpe­middel­program­varer har utviklet seg. Her er skjerm­lesere og utviklingen av dem et godt eksempel.

En skjerm­leser er et program som leser informasjon fra skjermbildet, tolker og presenterer denne informasjonen som enten syntetisk tale eller som punktskrift på en leselist. Da skjerm­lesere ble introdusert, var kommuni­kasjonen 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 skjerm­leserens primære oppgave var å hente teksten fra det såkalte videominnet i datamaskinen, for så å oversette det til tale eller punktskrift.

Etter at grafiske bruker­grensesnitt (GUI på engelsk) ble innført med operativ­systemer som Windows for PC og OS/X for Macintosh, ble skjerm­leserens oppgave mye mer kompleks. Skjerm­leseren 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. Skjerm­leseren 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 skjerm­leseren hadde tilgang dypt inn i operativ­systemet. Noe informasjon ble hentet ved å koble seg opp mot grafikkortets driver, mens annen informasjon ble samlet inn ved å analysere informasjonsflyten mellom applikasjon og operativ­system.

Det er her tilgjen­gelighets­grensesnittene kommer inn i bildet. For å unngå at hjelpe­middel­program­varen selv skulle samle inn all denne informasjonen, ble det forsøkt utviklet standardiserte APIer. APIene skulle gi applikasjoner mulighet til å tilgjengelig­gjøre den nødvendige informasjonen direkte til hjelpe­middel­program­varen.

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 plattform­uavhengig, samt å tilpasse det til de nye krav som fulgte utviklingen av nettlesere og den økte bruken av dynamiske websider og web­applika­sjoner.

På samme måte finnes det tilgjen­gelighets­grensesnitt for andre operativ­system og plattformer. De vanligste og mest aktuelle i forbindelse med nettlesere er:

I Microsoft Windows:

• Internet Explorer: MSAA og UIA
• Firefox: MSAA og IAccessible2
• Chrome: MSAA og IAccessible2

På Mac OS:

• Safari: Ax/uiA

På Linux:

• Assistive Technology–Service Provider Interface (AT-SPI) og IAccessible2

Etter at en nettleser har lastet inn og tolket en webside, som beskrevet i et eget avsnitt, eksponeres informasjonen fra DOM-treet til tilgjen­gelighets­grensesnittet, som igjen videreformidler den til hjelpe­middel­program­varen. Dette skjer i en sekvens av forespørsler fra hjelpe­middel­program­varen. I noen tilfeller tilgjengelig­gjør ikke nettleseren all den nødvendige informasjonen. I disse tilfellene må hjelpe­middel­program­varen forsøke å finne den manglende informasjonen i DOM. Dette er spesielt aktuelt for Internet Explorer for Windows.

WAI-ARIA

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 funksjons­evne. Dette gjøres ved å gi nettleser og IKT-​hjelpe­middel 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 program­vare 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 hjelpe­middel­program­varer. De som ble hardest rammet av denne nye bruken av teknologien var trolig skjerm­leser­brukere. Årsaken er at skjerm­leserne ikke hadde noen innsikt i de endringene som skjedde i dokumentet etter at det var lastet inn og formidlet til skjerm­leseren første gang. Dette resulterte i flere utfordringer:

• Skjerm­leseren oppfattet ikke den nye og oppdaterte informasjonen.
• Skjerm­leseren gjorde ikke brukeren oppmerksom på at det hadde skjedd endringer på siden.
• De nye egendefinerte kontrollene fortalte ikke hvilken rolle de hadde, så skjerm­lesere kunne ikke vite hvordan de skulle vises eller interageres med.

For å forsøke å løse disse problemene ble ARIA utviklet. WAI-ARIA er et rammeverk for å angi attributter som identifiserer funksjonalitet for bruker­interaksjon, hvilke relasjoner som finnes mellom dem, og deres aktuelle tilstand.

WAI-ARIA tilbyr kort sagt følgende:

• Roller for å beskrive forskjellige typer av kontroller som f.eks. meny, element i trestruktur, glidebryter eller framdriftsindikator.
• Roller for å beskrive strukturer på en webside, som overskrifter, regioner og tabeller (rutenett).
• Egenskaper for å beskrive hvilken tilstand en kontroll har, for eksempel ”avkrysset” for en avkryssingsboks og har undermeny for et menyelement.
• Egenskaper for å definere såkalte 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.
• Egenskaper som beskriver dra-og-slipp ved å angi hvilke elementer som er dra-kilder og slipp-mål.
• En måte å tilby tastaturnavigasjon til objekter og hendelser, som dem som er nevnt over.

Med andre ord kan man si at WAI-ARIA tilbyr en måte å gi hjelpe­middel­program­varer 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 hjelpe­middel­program­vare 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 funksjons­nedsettelse.

Introduksjon til skjerm­lesere

En skjerm­leser 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. Skjerm­lesere brukes som oftest av mennesker med en synsnedsettelse, men kan også være nyttige for mennesker med lesevansker eller andre kognitive utfordringer.

En skjerm­leser forsøker å identifisere og avlese skjerminnholdet, for deretter å presentere det på en måte som er egnet for skjerm­leser­brukeren, for eksempel som syntetisk tale, lydsignaler og/eller punktskrift via en ekstern leselist.

Skjerm­leseren 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 skjerm­leseren identifisere det elementet som har fokus, samt viktig informasjon om dets type, tilstand og innhold.

Det finnes et stort utvalg av tastekombinasjoner som skjermleser­brukeren 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.

Skjerm­lesere 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 skjerm­leser til skjerm­leser, men mye av hoved­funksjonaliteten er den samme.

Skjerm­lesere og web

Måten man navigerer og leser webinnhold på med en skjerm­leser er fundamentalt forskjellig fra hvordan man gjør dette visuelt. En skjerm­leser 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 skjerm­leser­bruker.

Når en skjerm­leser­bruker å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 skjerm­lesere 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 skjerm­leseren formidle at noe er en lenke, og deretter selve teksten fra lenken, som Lenke, Les mer om prosjektet virtuell hjelpe­middellab.

Funksjonalitet i skjerm­leseren 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å skjerm­leser­brukere 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 skjerm­leser, og mange utvikler sine egne strategier for å bli mest mulig effektive. Hvilke taster som utfører hvilke funksjoner i de enkelte skjerm­leseren 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 skjerm­lesere 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 skjerm­leser, det vil si å hoppe til neste element som kan få fokus. Det er viktig at skjerm­leser­brukeren 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 skjerm­leseren 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 skjerm­leseren 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 skjerm­leseren 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 skjerm­leserne og brukerens innstillinger. Hvis derimot alt-teksten er tom, det vil si "", leser skjerm­leseren 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 skjerm­leser­bruker 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 skjerm­leser­bruker 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.

Slik virker skjermlesere på Windows

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.

Introduksjon til skjerm­forstørrere

En skjerm­forstørrer er en hjelpe­middel­program­vare 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.

Skjerm­forstø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 skjerm­forstø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.

Skjerm­forstørrere har også ulike forstørringsmodi, altså måter å vise forstørring på skjermen på. Det vanligste er fullskjerm­forstø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 skjerm­forstø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.

Skjerm­forstørrere og web

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 skjerm­forstørrere er:

• Manglende oversikt over skjermbildet
• Manglende innsikt i de omkringliggende elementene i forhold til det brukeren fokuserer på
• Vanskeligheter med å flytte effektivt fra et sted i skjermbildet til et annet
• Vanskeligheter med å oppdage endringer andre steder i skjermbildet
• Tekst i grafikk blir kornete og uklar når den forstørres
• Tekst i grafikk endrer ikke nødvendigvis farge selv om brukeren har endret innstillinger for tekst- og bakgrunnsfarge
• Mye "luft" mellom elementer kan gjøre det vanskelig å navigere, eller man oppdager ikke elementer som ligger i utkanten av eller utenfor skjermbildet

Mange skjerm­forstørrere gjør også bruk av funksjonalitet kjent fra skjerm­lesere for å navigere effektivt mellom ulike elementer på en webside, samt mulighet for å få deler av skjermbildet opplest ved hjelp av syntetisk tale.

Vanlige tilgjen­gelighets­problemer og forslag til løsninger

I dette kapitlet lister vi opp noen av de vanligste problemene knyttet til teknisk tilgjengelighet til websider, og mulige forslag til løsninger.

Komplekse sider

En av de største tilgjengelighetsutfordringene er komplekse sider. Reduksjon av antall menyvalg, lenker og elementer på hver side kan bidra til bedre oversikt og enklere navigasjon.

Uklar struktur eller manglende bruk av forskjellige overskriftsnivåer

Start alltid på overskriftsnivå 1 på hver side, og sørg for riktig bruk og oppmerking av overskrifter. En overskrift på nivå 3 kan f.eks. ikke følge en overskrift på nivå 1.

Utilgjengelige plugins og utvidelser

Med mange plugins, sånn som Flash, opplever vi integrasjonsproblemer med nettleseren og eventuelt skjermleseren. Én løsningen kan da være å kutte ut bruk av nettleser-utvidelser, som har så ulike navn som plugin, extension og add-on, og istedenfor bruke nettleser-interne teknologier, der dette er mulig.

Utilgjengelige JavaScript

Dynamiske sider spiller ofte ikke så bra sammen med hjelpemidler som skjermlesere, sammenlignet med statiske/uforanderlige sider. Ofte gjelder dette nettleservinduet eller sideutsnitt som forandrer seg uten å fornye hele siden. Har finnes det flere mulige strategier til løsning, og valgmulighetene avhenger av brukssituasjonen: Å sørge for en adekvat fallback/nødsløsning via noscript-elementet, å bruke flere sider i steden for single page-strategien, å benytte seg utelukkende av testede JavaScript-biblioteker med cross-platform og skjermleser-støtte, eller å teste med løsningen med de mest populære skjermlesere og å sørge for at skriptene fungerer i alle disse.

Bruk av ikke-standardkontroller og elementer

Dersom du i din webapplikasjon har behov for å benytte kontroller eller elementer som ikke finnes i HTML, bør WAI-ARIA benyttes for å gi skjermlesere og annen hjelpemiddelprogramvare ekstra semantisk informasjon om disse.

Pop up-meldinger

Skjermlesere eller skjermforstørrere oppdager ofte ikke at en såkalt pop up-melding har dukket opp. Bruk WAI-ARIA for riktig koding, sørg for å flytte fokus til dialogboksen, eller til første kontroll inne i denne.

Bruk av CAPTCHAs

Teksten i CAPTCHAs kan være vanskelig å lese for mange, og spesielt for personer med nedsatt syn eller med lesevansker. Selv om løsningen vil kunne benyttes av flere hvis man legger til et lydalternativ, bør CAPTCHAs unngås der det er mulig.

Manglende eller dårlig tekst på lenker og knapper

Fordi brukere av skjermlesere og skjermforstørring ofte navigerer ved å hoppe fra element til element, er det viktig at lenketekster i størst mulig grad kan tolkes uten å lese hele konteksten. Et vanlig tilgjengelighetsproblem er at lenketekster har dårlig beskrivelse, f.eks. teksten klikk her. Prøv også å unngå at mange lenketekster på en webside begynner med de samme ordene.

Manglende eller utilgjengelig søkefunksjonalitet

Sørg for å merke søkefelt eller eventuell søkeknapp riktig i henhold til WAI-ARIA.

Uklar eller ulogisk sideoppbygging

Dette kan sjekkes ved å lese siden lineært, ved hjelp av en skjermleser. Skjermlesere leser informasjonen på en webside i den rekkefølgen den er koded i i kildekoden.

Bruk av frames med lite beskrivende navn

Gi frames meningsfulle navn som informerer om hva man kan forvente å finne av innhold. Dette vil være lette navigasjon for skjermleserbrukere.

Manglende eller dårlig alternativ tekst for bilder og illustrasjoner

Bildetekster er ofte kontekstavhengig. For å finne en god bildetekst kan det være nyttig å tenke over hva som ønskes formidlet med bildet, og om bildet er meningsbærende. Dersom bildet kun er dekor og ikke gir noen relevant eller viktig tilleggsinformasjon, kan bildeteksten være blank (alt=""). Man kan også legge det inn på siden som bakgrunnsbilde ved hjelp av CSS.

Utilgjengelige eller komplekse tabeller

Det er vanskelig å forstå sammenhengen i en tabell når man kun hører eller leser innholdet i en tabellcelle av gangen. Sørg derfor for riktig semantisk oppmerking av kolonneoverskrifter, radoverskrifter og andre relevante egenskaper ved tabellen.

Dårlig utformede skjemaer og manglende merking av skjemafelter

Sørg for at alle skjemafelter har programmatisk tilknyttede ledetekster (labels). Sørg for at mest mulig informasjon om de ulike skjemafeltene er tilgjengelig for hjelpemiddelprogramvaren.

Feilmeldinger som er vanskelig å oppdage

Logisk og visuell plassering av feilmeldinger må være gjennomtenkt.

Manglende støtte for tastaturnavigasjon

Sikre at alle funksjoner på din webside eller webapplikasjon kan benyttes kun ved hjelp av tastatur.

Konflikter mellom skjermleser og websiden

Test sidene med forskjellige kombinasjoner av skjermlesere og nettlesere for å unngå kompatibilitetsproblemer.

Utilgjengelige PDF-dokumenter

PDF-dokumenter skal være semantisk oppmerket. Men selv med riktig oppmerkede dokumenter kan PDF være utfordrende for mange skjermleserbrukere. Dette skyldes dels manglende støtte i leseprogramvare og hjelpemiddelprogramvare, samt manglende kompetanse hos brukeren. Det bør man ta hensyn til når man publiserer dokumenter PDF-format. Man bør derfor vurdere å publisere parallelt i andre formater, som HTML.

Multimediainnhold mangler teksting, synstolking og tegnespråk

For å gi alle likeverdig tilgang til multimediainnhold (video/audio/animasjoner), bør man vurdere teksting, synstolking og tegnspråktolking.

Viktig informasjon formidles kun gjennom farge eller utseende

Informasjon kan ikke formidles ene og alene gjennom farge eller utseende, da dette ikke kan oppfattes av fargeblinde og blinde. Ved å forsterke meningen gjennom andre og supplerende virkemidler, f.eks. tekst, gjør man det enklere for alle grupper. Tilsvarende gir instruksjoner som kun referer til farge, f.eks. Trykk på den røde knappen for å fortsette, ikke nok informasjon.

Manglende kontrast mellom forgrunn og bakgrunn

Se kravene i WCAG 2.0 og bruk en kontrastsjekker for riktig valg av forgrunns- og bakgrunnsfarger i dokumentet ditt.

Feil eller manglende merking av språk

Om et dokument mangler oppmerking av språk, kan det ved hjelpemiddelbruk føre til forvirring, og i verste fall kan hele dokumentet ble helt uforståelig. Bruk derfor språk-attributen (lang) på sideelementer der dette er hensiktsmessig, men i det minste på html-elementet.

Testing av tilgjen­gelig­het

Som vi har vært inne på krever universell utforming både teknisk tilgjen­gelig­het og bruker­vennlighet. I hvilken grad løsningen er bruker­vennlig evalueres best gjennom bruker­testing. Det er viktig å forsøke å fjerne flest mulig tilgjen­gelig­hets- og bruker­vennlighets­problemer før man gjennomfører bruker­testing. Teknisk tilgjen­gelig­het oppnås gjennom å følge standarder og retnings­linjer og å teste for kompatibilitet med hjelpe­midler. Man kan bruke automatiske evaluerings­verktøy og ekspert­evaluering i dette arbeidet.

Brukervennligheten kan forbedres ved gjennomgang av eksperter i brukskvalitet, ved selv å bruke IKT-​hjelpe­midler kan eksperter til en viss grad også evaluere løsningens bruker­vennlighet med slike hjelpe­midler. 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 tilgjen­gelig­het som er hoved­fokuset for denne håndboken, omtales bruker­testing kun kort i neste avsnitt.

Bruker­tester med personer med nedsatt funksjons­evne

For å oppnå god brukskvalitet og bruker­vennlighet for personer med nedsatt funksjons­evne bør man gjennomføre bruker­testing med personer med ulike kategorier av funksjons­nedsettelser, se også eget avsnitt. Men før personer med nedsatt funksjons­evne involveres i evaluering av IKT-​løsninger, er det viktig å rydde flest mulig tekniske og opplagte tilgjen­gelighets­problemer 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 bruker­testen. 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 tilgjen­gelighets­testing og ekspert­testing før man gjennomfører bruker­testing. Dette utelukker selvsagt ikke at brukere med nedsatt funksjons­evne kan gi innspill til løsningen på et tidligere stadium i utviklings­prosessen.

Teknisk tilgjen­gelighets­testing

Teknisk tilgjen­gelighets­testing innebærer å sjekke at løsningen minst oppfyller:

• WCAG 2.0-retnings­linjene, og herunder kompatibilitet med ulike hjelpe­midler (se også avsnittet);
• HTML5-standarden. Vi anbefaler å ta utgangspunkt i den til enhver tid nyeste W3C-anbefalingen (W3C recommendation);
• Ulike CSS-standarder. Også her anbefaler vi å ta utgangspunkt i de til enhver tid nyeste W3C-anbefalingene;
• Krav til kontrast og fargesammensetning. Til dette formålet finnes det en liste over en rekke verktøy for å sjekke kontraster og simulere fargeblindhet.
• Krav til konsistens. Sjekk at løsningen er oppbygd på en konsistent måte, f.eks. at det er en konsistent måte å navigere på, og konsistent begrepsbruk.
• Kompatibilitet med IKT-hjelpemidler (se eget avsnitt)
• Klart språk. Bruk korte og tydelige setninger, unngå lange ord og fremmedord etc. Se f.eks. informasjon og sjekklister på nettstedet Klarspråk. (På W3Cs sider finnes det også lenker til verktøy for å sjekke lesbarhet. Disse kan gi en indikasjon på lesbarhet selv om de ikke er utviklet for norsk.)

Automatiske evaluerings­verktøy

Det første steget i tilgjen­gelighets­testing er vanligvis å bruke automatiske evaluerings­verktøy. Kontroll med automatiske verktøy kunne avdekke en del avvik fra WCAG-retnings­linjene, men langt fra alle. Undersøkelser viser at automatiske evaluerings­verktøy har en del begrensninger. Blant annet kan de ikke avdekke hele spekteret av tilgjen­gelighets­problemer. 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 evaluerings­verktøy for å få en best mulig sjekk. I en undersøkelse fant man at automatiske evaluerings­verktø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 ekspert­gjennomgang av WCAG-retnings­linjene, i tillegg til kontroll ved bruk av automatiske evaluerings­verktøy (se eget avsnitt). W3Cs sider har en ganske omfattende liste med verktøy for å sjekke tilgjen­gelig­het. 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.

Ekspert­gjennomgang

Ekspert­gjennomgang av tilgjen­gelig­het innebærer at en ekspert går gjennom løsningen og evaluerer tilgjen­gelig­het. En slik gjennomgang baseres ofte på retnings­linjer (som WCAG), heuristikker og andre verktøy (f.eks. VHL og Personas) samt ekspertens egen erfaring.

Undersøkelser tyder på at en ekspert­gjennomgang for å sjekke om WCAG-retnings­linjene er oppfylt, kan avdekke i størrelsesorden 30–50% av bruksproblemene i en IKT-​løsning, i forhold til antall bruksproblemer avdekket gjennom bruker­tester med personer med nedsatt funksjons­evne.

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 persona­beskrivelse er en beskrivelse av en potensiell bruker av løsningen. Personas utvikles basert på informasjon om brukere i målgruppen. En persona­gjennomgang (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 tilgjen­gelig­hetsperspektiv, må man ha personaer med ulike typer funksjons­nedsettelser.

For å kunne gjøre en realistisk persona­gjennomgang er det også en forutsetning at eksperten har praktisk erfaring med den/de typer funksjons­nedsettelser som man skal spille. Simulering av funksjons­nedsettelser 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 funksjons­nedsettelser på en pålitelig måte. Det å ha erfaring med hvordan personer med ulike typer funksjons­nedsettelser interagerer med teknologi er også viktig i arbeidet med å oppnå kognitiv tilgjen­gelig­het. Det kan være nyttig å lese Utformingsveileder for kognitiv tilgjen­gelig­het av elektroniske tjenester og innhold.

Testing som en del av en utviklings- eller anskaffelsesprosess

Som forklart i et eget avsnitt innebærer universell utforming både teknisk tilgjen­gelig­het og bruker­vennlighet. Forskning tyder på at

• man ved å oppfylle WCAG-retnings­linjene kan unngå i størrelsesorden inntil halvparten av det antall bruksproblemer man kan forvente å finne gjennom bruker­tester;
• automatiske evaluerings­verktøy i beste fall kan avdekke i størrelsesorden halvparten av det antall WCAG 2.0-avvik som man kan finne gjennom ekspert­evaluering;
• hvilke og hvor mange tilgjen­gelighets­problemer som WCAG-eksperter kan avdekke er svært subjektivt, og avhenger av ekspertens erfaring og dyktighet. Det er ofte et ganske stort sprik i resultatene fra ekspert­evalueringer. I en undersøkelse om nøyaktighet og pålitelighet av ekspert­evaluering fant man at to erfarne WCAG-evaluatorer i gjennomsnitt bare vil være enige om litt mer enn halvparten av suksess­kriteriene i WCAG.

Dette betyr at dersom målet er reell tilgjen­gelig­het 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 tilgjen­gelighets­test inkludert testing av kompatibilitet med hjelpe­midler, ekspert­evaluering og bruker­testing med personer med nedsatt funksjons­evne. Eventuelt bør man planlegge med en uavhengig tilgjen­gelig­hetsevaluering.

Tilgjengelighetstesting med skjermleser

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:

• Å introdusere brukere for en uferdig eller svært ustabil løsning kan være frustrerende for brukertestere.
• Det er nyttig å ”luke ut” opplagte tilgjengelighetsproblemer fra en løsning før den testes på virkelige brukere, da får man utnyttet tiden med brukertesterne mer effektivt.
• Ekspertevaluering av tilgjengelighet kan være en tids- og kostnadseffektiv måte å støtte designere og utviklere mellom brukertester.

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:

1. Teknisk tilgjengelighetstesting
2. Evaluering av brukervennlighet for brukere som benytter hjelpemiddelprogramvare (se eget avsnitt)

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.

Teknisk tilgjengelighetstesting av websider 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.

Semantikk og skjermlesere

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.

Fremgangsmåte

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.

Viktige elementtyper å sjekke

Lenker

• Forteller skjermleseren at det er en lenke?
• Er det mulig å forstå hvor lenken fører til uten å kjenne konteksten?
• Hvis lenken åpner et nytt vindu – får man denne informasjonen opplest?
• Burde dette egentlig være en knapp – utfra den visuelle presentasjonen?

Overskrifter

• Forteller skjermleseren at det er en overskrift?
• Står nivået på overskriften i forhold til den visuelle presentasjonen?

Bilder

• Leser skjermleseren opp en erstatningstekst for bildet (alt-tekst)?
• Hvis den ikke gjør det, går brukeren glipp av viktig informasjon? Tilfører bildet mening?
• Hvis en alternativ tekst leses opp, representerer den meningen i bildet på en god måte?

Knapper

• Forteller skjermleseren at det er en knapp?
• Forteller skjermleseren hva knappen gjør? (samme tekst som vises på skjermen, eller et tekstlig alternativ til et ikon eller bilde)

Tabeller

• Når du flytter deg gjennom innholdet i cellene, leser skjermleseren rad- og/eller kolonneoverskrifter?
• Er det mulig å forstå tabellen kun ut fra det skjermleseren leser?

Redigeringsfelt

• Forteller skjermleseren at du har kommet til et redigeringsfelt?
• Forteller skjermleseren hva du skal skrive inn?
• Hvis det dukker opp forslag mens du skriver – forteller skjermleseren om dette?

Avkrysningsbokser

• Forteller skjermleseren at du har kommet til en avkryssingsboks?
• Forteller skjermleseren hva du krysser av for?
• Forteller skjermleseren hvorvidt boksen er avkrysset eller ikke?

Radioknapper

• Leser skjermleseren opp hva man som bruker skal velge? Dvs. en beskrivende tekst for hele gruppen med radioknapper.
• Leser skjermleseren opp innholdet i hver enkelt radioknapp? Dvs. det man faktisk velger hvis man velger denne ene radioknappen.
• Leser skjermleseren opp hvilken radioknapp som er valgt – før og etter du har gjort et valg?

Egendefinerte inndatakontroller

• Er det mulig å forstå hva slags kontroll skjermleseren har kommet til ut fra det den forteller?
• Får du instruksjoner om hvordan du skal betjene kontrollen?
• Får du melding om endringer når du f.eks. endrer verdi eller på annen måte manipulerer med kontrollen?

Innebygde rammer (iframes)

• Leser skjermleseren at du har kommet til en iframe?
• Har iframen et beskrivende navn?
• Leses innholdet i iframen korrekt?

Regioner og landemerker

Hvis siden har landemerker/regioner:

• Samsvarer landemerkene eller regionene skjermleseren forteller om med den måten innholdet oppfattes på visuelt?
• Forteller skjermleseren om innholdet i de ulike regionene eller landemerkene?

Språk

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.

Rekkefølge og struktur

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:

1. At rekkefølgen på innhold, navigasjon osv. gir mening for brukere av skjermlesere. Det kan for eksempel bety at rekkefølgen bidrar til effektiv navigasjon og oppgaveløsning. Det er f.eks. ikke nødvendigvis særlig effektivt for en skjermleserbruker å måtte gå gjennom alle menyer og informasjonselementer på en nettside før vedkommende kommer til hovedinnholdet.
2. At rekkefølgen tilsvarer den rekkefølgen fokus flyttes i visuelt. Dette kan du teste ved å bevege deg gjennom siden med tab, for deretter å bevege deg gjennom siden med skjermleserens markør - f.eks. ved pil ned på Windows. Det er viktig med sammenheng her f.eks. for svaksynte brukere av skjermlesere som også forholder seg til det visuelle innholdet.

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:

• Har siden en overskrift på nivå 1 som beskriver innholdet på siden som helhet?
• Samsvarer strukturen på underoverskrifter med den visuelle strukturen? Man kan eventuelt gjøre unntak for å gjøre navigasjon for skjermleserbrukere mer logisk og effektiv.

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.

Definisjoner, forkortelser, oversettelser og fagtermini

API

Engelsk forkortelse for application programming interface, et begrep brukt under utvikling av programvare.

ARIA

Engelsk forkortelse for Accessible Rich Internet Applications, et initiativ for tilgjengelige tjenester på nett og dynamiske dokumenter. Også kjent som WAI-ARIA.

AT

Engelsk forkortelse for assistive technology, eller hjelpemiddel på norsk.

CAPTCHA

Engelsk forkortelse for completely automated public Turing test to tell computers and humans apart, et samlebegrep for metoder som prøver å skille en menneskelig databruker fra en robot.

CSS

Engelsk forkortelse for Cascading Style Sheets, en teknologi til utforming av elektroniske dokumenter.

DOM

Engelsk forkortelse for document object model, en teknologi som beskriver strukturen av elektroniske dokumenter.

Diskriminerings- og tilgjengelighetsloven

Norsk lov som skal gi juridisk beskyttelse mot diskriminering på grunn av funksjonsnedsettelse.

HTML

Engelsk forkortelse for Hyper-Text Markup Language, en teknologi for semantisk oppmerking av elektroniske dokumenter.

IKT

Forkortelse for Informasjons- og kommunikasjonsteknologi

IKT-​hjelpe­midler

Program­vare eller maskinvare som brukes alene eller sammen med andre IKT-​løsninger for å øke tilgjen­gelig­heten for personer med nedsatt funksjons­evne. Kalles også kompenserende teknologi og assistive technology (AT) på engelsk.

IKT-​løsning

IKT-​baserte systemer, produkter og tjenester som anvendes til å uttrykke, skape, omdanne, tilpasse, innhente, utveksle, lagre, mangfoldig­gjøre og publisere informasjon, eller som på annen måte gjør informasjon anvendbar.

Kompatibilitet

Uttrykket interoperabilitet brukes også i denne sammenheng, dvs. hvor bra ulike tekniske enheter fungerer sammen.

NS

Forkortelse for Norsk standard.

OS

Forkortelse for operativsystem.

Personas

En persona er en fiktiv person, men beskrives gjerne med realistiske trekk som (illustrasjons-)bilde, alder, kjønn, sivilstatus, bosted, utdanning, yrke, hobbyer, interesser, eventuelle funksjonsnedsettelser og opplevde vanskeligheter i hverdagen.

PDF

Engelsk forkortelse for portable document format, et format for elektroniske dokumenter.

SMS

Engelsk forkortelse for short-messaging service, en teknologi for transmisjon av korte tekstmeldinger til mobiler.

uu

Forkortelse av universell utforming.

W3C

Engelsk forkortelse for World Wide Web Consortium, en internasjonal organisasjon med ansvar for standardisering av webteknologi.

WAI

Engelsk forkortelse for Web Accessibility Initiative, en gruppe i W3C med ansvar for tilgjengelighet på nettet.

WCAG

Engelsk forkortelse for Web Content Accessibility Guidelines, en anbefaling for tilgjengelige elektroniske dokumenter.

XML

Engelsk forkortelse for extensible markup language, en teknologi for semantisk oppmerking av data.

Litteratur

1. ^ Arrue, M., Fajardo, I., Lopez, J. M. & Vigo, M. (2007). Interdependence between technical web accessibility and usability; its influence on web quality models. International Journal of Web Engineering and Technology, 3 (3): 307–328
2. ^ Brajnik, G. (2008). Beyond Conformance: The Role of Accessibility Evaluation Methods. Proceedings of the 2008 International Workshop on Web Information Systems Engineering, Auckland, New Zealand: Springer-Verlag
3. ^ Brajnik, G., Yesilada, Y. & Harper, S. (2012). Is accessibility conformance an elusive property? A study of validity and reliability of WCAG 2.0. ACM Trans. Access. Comput., 4 (2): 1–28
4. ^ Cooper, M., Sloan, D., Kelly, B. & Lewthwaite, S. (2012). A challenge to web accessibility metrics and guidelines: putting people and processes first. Proceedings of the International Cross-Disciplinary Conference on Web Accessibility, Lyon, France, p. 1–4. 2207028: ACM
5. ^ Center for Universal Design ved North Carolina State University (1997). The Principles Of Universal Design Version 2.0 – 4/1/97, Center for Universal Design, NC State University (nedlastet: 2013-01-10)
6. ^ Faulkner, S. (2012). Rough Guide: browsers, operating systems and screen reader support. The Paciello Group Blog (nedlastet: 2013-04-04)
7. ^ Fuglerud, K. & Tjøstheim, I. (2012). E-valg, tilgjen­gelig­het og personer med nedsatt funksjons­evne. I Segaard, S. B. & Saglie, J. (eds) Rapport 2012:3, Evaluering av forsøket med e-valg 2011. Tilgjen­Gelig­Het for velgere, tillit, hemmelig valg og valgdeltakelse, s. 85–157. Oslo: Institutt for sammfunnsforskning
8. ^ Gibson, B. (2007). Enabling an accessible web 2.0. Proceedings of the 2007 International Cross-Disciplinary Conference on Web Accessibility (W4A), Banff, Canada: ACM Press
9. ^ ISO 9241–171 (2008). Ergonomics of human-system interaction – Part 171: Guidance on software accessibility. International Organization for Standardization, ISO 9241–171:2008, Geneva, Switzerland: p. 88
10. ^ Keates, S. (2007). Designing for Accessibility: A Business Guide to Countering Design Exclusion. Lawrence Erlbaum Associates, Inc. Mahwah, New Jersey
11. ^ Kelly, B., Sloan, D., Brown, S., Seale, J., Lauke, P., Ball, S. & Smith, S. (2009). Accessibility 2.0: Next steps for web accessibility. Journal of Access Services, 6 (p. 1–2): 265-294
12. ^ Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users. International Journal of Human-Computer Interaction, 22 (3): 247–269
13. ^ Luján-Mora, S. (2013). A comparison of common web accessibility problems. (nedlastet: 2013-12-11)
14. ^ Miljøverndepartementet (2007). Universell utforming – Begrepsavklaring. Temarapport T–1468 B/E. s. 16
15. ^ Barne- og likestillingsdepartementet. Om lov om forbud mot diskrimi­nering på grunn av nedsatt funksjons­evne (Diskrimi­nerings- og tilgjen­gelig­hetsloven). Tilråding fra Barne- og likestillingsdepartemente av 4. april 2008, godkjent i statsråd samme dag. (Regjeringen Stoltenberg II), Ot.prp.nr. 44. (2007–2008)
16. ^ Petrie, H. & Kheir, O. (2007). The relationship between accessibility and usability of websites. Proceedings of the SIGCHI conference on Human factors in computing systems, San Jose, California, USA: ACM Press
17. ^ ^ Power, C., Freire, A. P., Petrie, H. & Swallow, D. (2012). Guidelines are only half of the story: accessibility problems encountered by blind users on the web. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Austin, Texas, USA, p. 433–442. 2207736: ACM
18. ^ ^ Rømen, D. & Svanæs, D. (2011). Validating WCAG versions 1.0 and 2.0 through usability testing with disabled users. Universal Access in the Information Society: p. 1–11
19. ^ Schulz, T. & Fuglerud, K. S. (2012). Creating Personas with Disabilities. Computers Helping People with Special Needs, Springer Berlin Heidelberg, p. 145–152
20. ^ Vanderheiden, G. (2000). Fundamental principles and priority setting for universal usability. Proceedings on the 2000 Conference on Universal Usability, Arlington, Virginia, United States: ACM Press
21. ^ Vigo, M., Brown, J. & Conway, V. (2013). Benchmarking web accessibility evaluation tools: Measuring the harm of sole reliance on automated tests. Proceedings of the 10th International Cross-Disciplinary Conference on Web Accessibility, Rio de Janeiro, Brazil, p. 1–10. 2461124: ACM
22. ^ Deltasenteret/Bufdir (2011). W3C WCAG 2.0 Norsk: Forslag til norsk autorisert overettelse (CAT) av Web Content Accessibility Guidelines 2.0 (nedlastet: 2013-02)
23. ^ WebAIM. Screenreader techniques: Designing for Screen Reader Compatibility (nedlastet: 2013-04-04)
24. ^ WebAIM. Testing with Screen Readers: Questions and Answers (nedlastet: 2013-04-04)