– Mange feil er rett foran deg
– Du trenger ikke være ekspert for å finne tilgjengelighetsfeil, skriver Uu-tilsynet. De forteller hvordan du kan oppdage dem før brukerne gjør det.
Dette leserinnlegget er basert på foredraget Tilsynet for universell utforming av ikt (Uu-tilsynet) holdt på Yggdrasil-konferansen i vår.
De fleste tilgjengelighetsproblemer er ikke spesielt avanserte. Men konsekvensene kan være store.
Det er nemlig ikke brukerne det er noe “galt” med. Det er vi som lager løsninger som ikke alltid tar høyde for mangfoldet av mennesker som skal bruke dem.
Som vi ofte sier: Don’t fix the user – fix the solution.
Små tester, stor effekt
I workshopen på Yggdrasil tok vi utgangspunkt i hvordan vi selv jobber i Uu-tilsynet. Vi tester risikobasert, gjør stikkprøver og bruker en kombinasjon av manuell testing og verktøy.
Men det viktigste budskapet vi ønsker å formidle er: Mange feil kan oppdages med enkle grep.
For å sikre forutsigbarhet, og at resultatene blir like uavhengig av hvem som tester, har vi laget testprosedyrer basert på suksesskriteriene i WCAG-standarden.
En av testene deltakerne fikk prøve seg på, og som vi ofte finner feil på ved tilsyn, var enkel, men effektiv:
Kan du bruke løsningen kun med tastatur?
Hvis svaret er nei, har du allerede avdekket en barriere for mange brukere.
Test med tastatur
Hvordan oppnå samsvar med kravet:
All funksjonalitet på nettsiden kan nås og brukes med tastatur, uten at det er behov for tidsberegning av de enkelte tastetrykkene.
Slik tester du:
Tab deg gjennom hele siden og bruk kun tastaturet (Tab, Shift+Tab, Enter, Space, piltaster). Har siden menyer, undermenyer, modaler, accordions, faner eller lignende, må disse også testes fullt ut.
Kontroller og vurder om:
• alle interaktive elementer (knapper, lenker osv.) får tastaturfokus og kan aktiveres
• all funksjonalitet kan brukes med tastatur
• det ikke kreves tidsbestemte tastetrykk
Vanlige feil:
• Elementer får ikke tastaturfokus
• Elementer kan ikke aktiveres
• Funksjonalitet krever mus
• Manglende informasjon om alternativ betjening
WCAG krav og veiledning: 2.1.1 Tastatur (A)
Zoom helt inn
Men tastaturtesting er bare ett eksempel. Deltakerne fikk også prøve seg på andre enkle tester som raskt kan avsløre feil.
En av dem var å zoome inn siden – noe mange brukere er helt avhengige av for å kunne lese og navigere. Vi ba deltakerne teste hva som skjer når teksten forstørres til 200 %, og når siden zoomes helt opp til 400 %.
Fungerer løsningen fortsatt? Eller begynner innhold å forsvinne, overlappe eller kreve horisontal scrolling?
Dette er enkle ting å sjekke, men de avdekker ofte problemer som gjør løsningen vanskelig eller umulig å bruke for mange.
Test forstørring
Hvordan oppnå samsvar med kravet:
All tekst kan forstørres opp til minst 200 % visning uten at innhold eller funksjonalitet går tapt. Dersom forstørring tilbys via en mekanisme på den aktuelle nettsiden, skal den være lett å finne.
Slik tester du:
Sett oppløsningen på skjermen du tester med til 1920 x 1080 piksler.
Hvis du ikke har dette som standard, må du endre på oppløsningen, før du starter test.
Slik endrer du innstilling (Windows): System >Skjerm >Skjermoppløsning >1920x1080 >Behold Endringer.
Zoom inn siden til 200 % ved hjelp av nettleserens zoomfunksjon. Kontroller at alt tekstinnhold kan leses uten tap av informasjon eller funksjonalitet.
Sjekk at:
· teksten ikke blir kuttet, skjult eller overlapper annen tekst
· det er mulig å få tilgang til alt innhold og funksjonalitet (eventuelt ved å scrolle)
· ingen tekst eller funksjon krever horisontal scrolling for å kunne brukes
Vanlige feil:
· Tekst blir kuttet av eller skjult når siden zoomes til 200 %.
· Tekst overlapper annen tekst eller elementer ved zoom.
· Brukeren må scrolle horisontalt for å lese vanlig brødtekst.
· Komponenter (f.eks. knapper, skjema eller navigasjon) skalerer ikke sammen med resten av siden.
WCAG-krav og veiledning: 1.4.4 Endring av tekststørrelse (AA)
En av testene som kanskje avslører flest problemer i praksis, handler om skjema.
For det er nettopp i skjemaer brukerne skal få gjort det de kom for: søke, bestille, registrere eller sende inn informasjon. Og det er også her det ofte går galt.
Deltakerne i workshopen fikk derfor teste om det faktisk er mulig å forstå hva som skal fylles ut – og hva som skjer når noe går feil.
Test skjemafunksjonalitet
Hvordan oppnå samsvar med kravet:
Det er opplyst om skjemaelementene er obligatoriske. Eventuell merking med symbol skal være forklart før det blir tatt i bruk.
Slik tester du:
Start med å identifisere hvilke felt i skjemaet som er obligatoriske. Dette kan du gjøre ved visuell gjennomgang (merking med tekst eller symbol), ved å sjekke i koden (for eksempel required), eller ved å forsøke å sende inn skjemaet uten å fylle ut felt og observere feilmeldinger.
Når du har identifisert hvilke felt som er obligatoriske, kontroller at disse også er tydelig merket i grensesnittet. Dette kan være tekst (f.eks. påkrevd) eller symbol (f.eks. *). Dersom symbol brukes, kontroller at dette er forklart med tekst, og at forklaringen er plassert før symbolet tas i bruk første gang.
Vurder til slutt om det er tydelig for brukeren hvilke felt som må fylles ut før innsending, og at informasjonen ikke kun gis etter at brukeren har gjort feil, men er tilgjengelig på forhånd eller under utfylling.
Vanlige feil:
• Obligatoriske felter er ikke merket.
• Kun bruk av farge eller symbol for å indikere obligatoriske felt.
• Symbol (f.eks. *) brukt uten forklaring.
• Forklaring av symbol kommer etter første bruk.
• Informasjon om obligatoriske felt gis først etter innsending.
WCAG krav og veiledning: 3.3.2 Ledetekster eller instruksjoner (A)
Testing trenger ikke alltid å være så avansert, men det avdekker ofte kritiske barrierer.
Kom i gang i dag
Selv om WCAG kan virke overveldende ved første øyekast, så handler det det om noe ganske grunnleggende:
Kan brukeren oppfatte, forstå og bruke det du lager? Og fungerer det som forventet på ulike flater?
Det er lett å tenke at tilgjengelighet er noe man “legger på til slutt”. Erfaringen vår er det motsatte. Testing må være en del av utviklingsprosessen – på lik linje med funksjonelle tester, kvalitetssikring og brukertesting.
Og du trenger ikke være ekspert for å komme i gang. Begynn med ett krav og bygg på med flere etter hvert.
Å teste universell utforming kan starte med én ting. Tab deg igjennom nettstedet ditt, undersøk om alt fungerer selv om du har zoomet inn, og kontroller du skjønner hva du skal fylle ut i et skjema, og hva som gikk galt.
Sjansen er stor for at du vil finne noe.