Brukertesting av tilgjengelighet er respektløst

Skrevet av: Morten Tollefsen

«Universell utforming» (uu) og «tilgjengelighet» brukes synonymt i Norge. Dessverre har universell utforming vunnet, og brukes nå om alt som handler om funksjonshindringer, også innen teknologi. Til og med i den norske oversettelsen av WCAG brukes feil begrep: Retningslinjer for universell utforming av nettsider. WCAG er ikke en uu-standard, men retningslinjer for tilgjengelighet: altså krav som skal hindre at mennesker ekskluderes fra å bruke nettsider. WCAG handler i liten grad om kognisjon, effektivitet, enkelhet, tilfredshet og mange andre ting som gjør produkter og tjenester gode.

Jeg skal ikke tvære ut forskjellen mellom uu og tilgjengelighet (accessibility). Poenget mitt er at uu innebærer mer enn at mennesker med funksjonshindringer ikke ekskluderes. Mens uu er mer et ideal er tilgjengelighet noe alle profesjonelle designere, utviklere og andre som jobber med å lage produkter og tjenester skal kunne.

De aller fleste som jobber med produktutvikling er enige i at brukere skal være med i prosessen: fra planlegging til drift. Dette inkluderer også brukertesting. Jeg er intet unntak, dvs. dette er jeg enig i. Brukere skal derimot ikke teste om teknologi er tilgjengelig for det burde være en selvfølge. Jeg vet naturligvis at det ikke er en selvfølge: det konfronteres jeg med daglig som blind. Mange proffe produktutviklere burde skamme seg, så uproffe er de!

Dette var så lærerikt, altså!

Jeg startet å kode som liten gutt. Fortsatt er jeg interessert i teknologi, og selv om jeg koder mindre nå er jeg fremdeles glad i å lage ting og få noe til å funke. Som nevnt innledningsvis er jeg blind og siden jeg har jobbet med teknologi i hele yrkeslivet mitt har jeg blitt spurt om å teste mange nettsider, apper og programvare. Det er fryktelig kjedelig! Gang på gang har jeg testet og funnet hauger og lass med helt opplagte tilgjengelighetsfeil. Det er knapper uten alternativ tekst, kontroller som ikke kan brukes med tastatur, feil bruk av wai-aria (en standard som kan forbedre tilgjengelighet når den brukes riktig) og så videre. Til og med feil som enkelt kan finnes med validatorer vrimler det av! Sånn testing er noe forbaska dritt! Rett og slett respektløst synes jeg. Det er respektløst fordi jeg vil brukes for å forbedre selve produktet, ikke for å påpeke dårlig kode.

Hvis det er testing med observatører og full pakke synes jeg det er ekstra utilfredsstillende når ikke en gang WCAG-kravene følges. Jeg pleier å spørre om observatørene har brukt en skjermleser og vet sånn noenlunde hvordan det fungerer. Ofte sier de at de har prøvd litt, men at det var veldig vanskelig. Så da starter testingen nesten hver bidige gang med at jeg først må forklare hvordan skjermleseren fungerer. Så tar vi testen. Når jeg er ferdig er gjennomgangsfrasen: «Dette var så interessant, altså. Vi har lært masse.» De har kanskje lært noe, men egentlig tviler jeg på at de har skjønt mer enn at noen oppgaver kunne løses og andre kanskje ikke. Jeg prøver å forklare, selvsagt, men med litt mer kompetanse hadde jo brukertestingen blit så mye mer verdifull. Selv disse opplagte tilgjengelighetsgreiene kommer ofte som overraskelser, og det er veldig liten forståelse for hva som er de viktigste problemene og hva som er mindre viktig. Jeg er så lei av å bli brukt til sånt at jeg nå nesten aldri svarer ja til å delta i brukertesting.

Jeg synes ofte at det er synd på observatørene. Observatørene er ganske ofte testere, designere eller andre uten tung frontend-kompetanse. Det er ikke observatørene sin skyld at kodekvaliteten er dårlig, og det gjør at de også sliter med å forstå grunnen til at ting ikke fungerer med for eksempel skjermleser.

Tilgjengelighet er enkelt

En av mine kjepphester er at «tilgjengelighet er enkelt». De som gidder klarer å lære seg hva som kreves for å imøtekomme WCAG-kravene, og sammenliknet med å lære koding er det ganske så overkommelig.

Det som er lovpålagt for nettsider i Norge er WCAG. Mye av innholdet i WCAG-standarden er enkelt å forstå, og det som ikke er enkelt er ikke så fryktelig vanskelig det heller. I alle fall er det ikke så vanskelig at profesjonelle produktutviklere har noen unnskyldning for å ikke kunne kravene. Jeg kan heller ikke hvert suksesskriterium med detaljer utenat, men hva det betyr å følge WCAG er nokså greit. Mye handler faktisk om å bruke HTML slik det er tenkt, sørge for å ha konsistente nettsider, god kontrast og ting det er naturlig å gjøre uansett universell utforming eller ikke.

Men, alt er ikke enkelt

Selv det å følge WCAG kan være utfordrende! Det kan for eksempel være vrient å implementere tastaturstøtte for komplekse kontroller (hva skal ha fokus når og så videre). Det å lage ting tilgjengelig er ikke alltid plankekjøring. Teste om resultatet er tilgjengelig er derimot lett (hvis ikke kan du bare glemme at vanlige brukere mestrer det du har laget).

Det som virkelig ikke er lett er å teste hva brukere forstår, hvor fornøyde de er og hvor effektiv en løsning er i praksis. Er alle fornøyde, skjønner alt og ting bare funker som tusan: da har du et universelt utformet produkt. Kanskje ikke noe sånt finnes, men poenget er i alle fall at det ikke er så enkelt å teste med alle. Det du kan teste, og det du bør teste med mennesker som har ulike forutsetninger og behov er akkurat denne typen egenskaper. Gitt at tilgjengelighet er på plass vil da også de som trenger at WCAG-krav følges bli verdifulle testere som kan bidra til bedre produkter og tjenester.

Skjermlesere er rarest av alt

Jeg bruker en skjermleser. Den gjør at jeg får lest opp ting med syntetisk tale. Jeg kan også lese tekst i punktskrift. Med skjermleser blir brukergrensesnittet ganske annerledes. Jeg kan for eksempel bare høre ett ord av gangen (eller lese noen få tegn i punktskrift). Ofte sier jeg at: vinduet mot verden er ganske lite. I denne korte artikkelen skal jeg naturligvis ikke forklare i detalj hvordan en skjermleser fungerer. Poenget er at det nok ikke er en måte å bruke teknologi på som er kjent for alle. Utfordringen med å teste noe med skjermleser er også at de som tester har sett eller ser hele skjermbilder. Testingen blir derfor ikke realistisk. Men det du kan teste er at alt leses riktig opp (inkludert grafiske elementer som skal ha en alternativ tekst for skjermlesere). Er du veldig seriøs kan du la noen ekte skjermleserbrukere teste løsningen din når du føler deg trygg på at alt leses opp og kan brukes med tastatur.

WCAG er enkelt. Skjermlesertesting av komponenter er forholdsvis enkelt. Skjermlesertesting av hele løsninger krever derimot mer. Det innebærer navigeringsstrategier (husk det lille vinduet mot verden), funksjonalitet skjermlesere har for å gjøre det mulig å jobbe effektivt og viktigst av alt: hvordan du tenker og jobber som synshemmet når skjermen ikke kan benyttes. Kanskje en ekte blinding må til for å mene noe om hvor brukbart et produkt eller en tjeneste er? Jeg har i alle fall ikke møtt mange som orker å lære seg nok skjermleser til å teste på en fullgod måte. Dette er altså fornuftig brukertesting – gitt at alt er tilgjengelig, altså, hehe!

Det finnes annen hjelpeteknologi som gjør at det vanlige brukergrensesnittet brukes på alternative måter. Skjermlesere er rarest og minst forståelig. Men, for eksempel talegjenkjenning bruker noen av de samme WCAG-kravene for å fungere. «Klikk på søk-knappen» vil eksempelvis ikke fungere med talegjenkjenning hvis knappen er et forstørrelsesglass og det ikke finnes en alternativ tekst: Søk.

Oppsummert: tilgjengelighet er noe du skal kunne og ikke er det så vanskelig heller!

Tja, nå har jeg vel sagt det jeg ønsket å si. På tampen tar jeg likevel med noen tips til de som ikke alt har tilgjengelighet i ryggmargen!

Semantikk: Gjør alt semantisk riktig. I html har for eksempel nesten alle elementer en betydning (overskrifter, avsnitt, lister og så videre). Riktig semantisk koding gjør eksempelvis innhold mer forståelig og mer navigerbart med skjermleser. Dette gjelder også i Word, PDF, epost – over alt der du faktisk har tilgang på semantiske elementer.
Native kontroller: Når du lager nettsider er det best å bruke standard html-elementer (knapper, avkryssingsfelt, …). Jeg vet selvsagt at dette ikke skalerer helt i en moderne verden (jeg jobber med å utvikle NAVs designsystem). Kan du bruke native html får du imidlertid mye gratis. Det er langt mer å tenke på når du bruker egenutviklede komponenter.
Validatorer: Det finnes validatorer som kan brukes for å finne en del tilgjengelighetsfeil og gi tips om beste praksis. Axe er et slikt verktøy (det jeg bruker mest), men det finnes mange andre.
Hjelpemiddeltesting: Test løsningen din med hjelpemiddelteknologi. Du bør for eksempel teste at alt leses opp på en fornuftig måte og at alle kontroller kan brukes med skjermleser. Det enkleste er ofte å teste med mobil der skjermleser og annen hjelpeteknologi lett kan skrues på og av.
Brukertesting: Ikke be mennesker med funksjonshindringer om å teste før det du har laget er tilgjengelig. Det er en god start å følge WCAG, og gjør du det vil brukertestingen bli mye mer verdifull.
Opplæring: Det finnes mye informasjon om tilgjengelighet på web. Les deg opp på den måten som fungerer best for deg. Jeg anbefaler spesielt kursene fra dequeuniversity.com. Tilsynet for universell utforming av ikt har også mye bra informasjon.

Tilgjengelighet kan du teste selv. Brukere må hjelpe til med testing av universell utforming.