Bruk nettsiden uten mus: Test hele brukerreisen med tastatur
En tastaturtest av en reell brukeroppgave avdekker problemer med navigasjon, fokus, skjemaer, kontrast og skjermlesere som enkeltkontroller ofte overser.
Kategori: Universell utforming
Mange tilgjengelighetstester tar utgangspunkt i enkeltsider eller isolerte komponenter. Det kan gi en ryddig avviksliste, men sier ikke nødvendigvis om en bruker faktisk klarer å utføre en oppgave. En kunde skal kanskje finne en tjeneste, sammenligne alternativer, fylle ut et skjema og forstå bekreftelsen. Hvis ett trinn svikter, er hele brukerreisen i praksis brutt.
En gjennomgang uten mus er en enkel og effektiv måte å undersøke dette på. Testen synliggjør mer enn tastaturstøtte. Den avdekker også uklare tekster, ulogisk rekkefølge, svake fokusmarkeringer, skjemaer som er vanskelige å forstå, og innhold som fungerer visuelt, men dårlig med skjermleser.
Velg en oppgave som betyr noe
Ikke start med å trykke deg tilfeldig rundt på forsiden. Velg én konkret oppgave med tydelig start og slutt. Oppgaven bør være viktig både for brukeren og virksomheten.
Aktuelle oppgaver kan være å:
- finne riktig tjeneste og sende en forespørsel
- melde seg på et arrangement
- finne kontaktinformasjon til en bestemt avdeling
- legge en vare i handlekurven og fullføre kjøpet
- laste ned et dokument etter å ha filtrert en liste
- logge inn og endre en opplysning
Beskriv oppgaven uten å avsløre fremgangsmåten. Skriv heller «Finn prisen på tjenesten og be om et tilbud» enn «Åpne menyen, velg Tjenester og trykk på kontaktskjemaet». Da tester dere om grensesnittet faktisk leder brukeren fremover.
Start med bare tastaturet
Legg musen til side. Bruk Tab for å gå fremover, Shift og Tab for å gå bakover, Enter for å aktivere lenker og knapper, og piltaster der komponenten krever det. Escape brukes ofte til å lukke menyer, dialogbokser og andre åpne elementer.
Følg hele oppgaven fra start til slutt. Noter hvor dere er usikre på hvilket element som har fokus, hvor rekkefølgen virker ulogisk, og hvor en funksjon ikke kan brukes uten peker. Ikke begrens notatene til rene tekniske feil. Friksjon og tvil er også verdifull informasjon.
Fokus må være synlig hele veien
En tastaturbruker må kunne se hvor på siden neste handling skjer. Fokusmarkeringen bør derfor være tydelig på lenker, knapper, skjemafelt, faner og andre interaktive elementer. En svak fargeendring er ofte utilstrekkelig, særlig når elementene har ulike bakgrunner.
Kontroller fokusmarkeringen på både lyse og mørke flater. Den må ha tilstrekkelig kontrast mot området rundt og ikke bli skjult av grafikk, kantlinjer eller fastplasserte elementer. En tydelig kontur kombinert med en visuell endring i selve elementet fungerer ofte bedre enn bare én av delene.
Pass også på at fokus ikke forsvinner bak et fast toppfelt eller et samtykkepanel. Et element kan teknisk sett ha fokus uten at brukeren ser det. Da er løsningen fortsatt vanskelig å bruke.
Rekkefølgen skal følge oppgaven
Fokusrekkefølgen bør samsvare med den visuelle og logiske rekkefølgen. Hvis tastaturet hopper fra hovedinnholdet til sidemenyen, videre til bunnteksten og deretter tilbake til skjemaet, blir siden krevende å forstå.
Slike problemer oppstår gjerne når elementer flyttes visuelt med stilregler uten at strukturen i koden følger samme rekkefølge. De kan også skyldes positive tabulatorverdier eller skjulte elementer som fortsatt kan motta fokus.
Ikke forsøk å reparere en ulogisk struktur ved å detaljstyre hvert enkelt tabulatorstopp. Start heller med en fornuftig innholdsrekkefølge i koden og bruk standard oppførsel der det er mulig.
Undersøk meny, dialoger og dynamiske komponenter
Vanlige lenker og knapper fungerer som regel godt med tastatur når de er bygget med riktige HTML-elementer. Egendefinerte menyer, nedtrekksfelt, datovelgere, karuseller og dialogbokser krever mer omtanke.
Når en dialogboks åpnes, bør fokus flyttes inn i den. Brukeren må kunne navigere mellom relevante valg uten å havne på innholdet bak dialogen. Når den lukkes, bør fokus normalt returnere til elementet som åpnet den.
Test også hva som skjer når Escape trykkes, når brukeren navigerer bakover, og når en komponent åpnes på nytt. En løsning som fungerer første gang, kan miste fokus eller låse tastaturet etter gjentatt bruk.
La skjemaet være en del av testen
Skjemaer bør testes som oppgaver, ikke som en samling enkeltfelt. Fyll inn gyldige og ugyldige verdier, hopp over obligatoriske felt og send inn skjemaet. Undersøk om brukeren forstår hva som gikk galt, hvor feilen ligger og hvordan den kan rettes.
Ledetekster må være tydelige
Hvert felt trenger en synlig og presis ledetekst. Plassholdertekst inne i feltet bør ikke være eneste forklaring. Den forsvinner når brukeren begynner å skrive, og kan ha svak kontrast.
Instruksjoner bør stå før de trengs. Hvis passordet må følge bestemte krav, bør kravene være tilgjengelige før innsending. Ikke vent med å forklare dem til brukeren har gjort en feil.
Feilmeldingen må hjelpe brukeren videre
«Ugyldig verdi» er sjelden nok. En bedre beskjed forklarer både problemet og forventet format, for eksempel at datoen skal skrives med dag, måned og år.
Etter innsending bør brukeren få en tydelig oppsummering av feilene. Det bør være enkelt å finne feltene som må korrigeres, også med tastatur og skjermleser. Ikke bruk bare rød farge for å vise feil. Kombiner farge med tekst, symbol eller annen tydelig markering.
Gjenta oppgaven med skjermleser
Tastaturtesten viser om elementene kan nås og brukes. En skjermlesertest viser om strukturen og informasjonen gir mening uten den visuelle presentasjonen.
Start gjerne med samme brukeroppgave. Lytt til hvordan overskrifter, lenker, knapper og feltnavn blir lest opp. Kontroller om det er mulig å forstå sidens oppbygning og finne frem uten å høre gjennom alt innholdet i rekkefølge.
Vær særlig oppmerksom på:
- om siden har en tydelig og logisk overskriftsstruktur
- om lenketekster gir mening uten teksten rundt
- om knapper har navn som beskriver handlingen
- om bilder med viktig innhold har passende tekstalternativer
- om dekorative bilder blir hoppet over
- om statusmeldinger og skjemafeil blir formidlet
- om åpne og lukkede tilstander blir annonsert
En knapp med et forstørrelsesglass kan være åpenbar visuelt, men må fortsatt ha et forståelig navn. Tilsvarende bør flere knapper ikke hete «Les mer» dersom skjermleserbrukeren ikke får vite hva de gjelder.
Kontroller kontrast i riktig sammenheng
Kontrast handler ikke bare om brødtekst. Kontroller også hjelpetekster, menypunkter, feltrammer, feilmeldinger, ikoner, diagrammer, fokusmarkering og knapper i ulike tilstander.
Test komponentene slik de faktisk brukes. En knapp kan ha god kontrast i normaltilstand, men bli uleselig når den får fokus eller er deaktivert. Tekst som ligger over et bilde, kan fungere på ett utsnitt og forsvinne på et annet.
Automatiske verktøy kan måle mange fargekombinasjoner, men de forstår ikke alltid hvilken bakgrunn teksten faktisk ligger på, eller om farge alene formidler mening. Kombiner derfor målinger med visuell vurdering av den virkelige siden.
Knytt funnene til WCAG uten å miste brukerreisen
WCAG gir kriterier som gjør tilgjengelighet mulig å spesifisere og kontrollere. Kriteriene er nyttige når funn skal beskrives, prioriteres og verifiseres. De bør likevel ikke være den eneste strukturen i rapporten.
Registrer først hvor i oppgaven problemet oppstår og hva konsekvensen er. Knytt deretter funnet til relevant krav. Et eksempel kan være: «Brukeren får ikke åpnet datovelgeren med tastatur og kan derfor ikke sende bestillingen.» Denne formuleringen gjør både problemet og forretningskonsekvensen tydeligere enn en kode alene.
En praktisk registrering bør inneholde:
- hvilken oppgave som ble testet
- trinnet der problemet oppsto
- forventet og faktisk oppførsel
- hvilke brukere som kan bli berørt
- alvorlighetsgrad og konsekvens
- forslag til retting
- hvordan rettingen skal testes på nytt
Rett flyten, ikke bare enkeltdetaljene
Når testen er ferdig, bør funnene grupperes etter rotårsak. Ti uklare knapper kan skyldes manglende regler for knappetekster. Flere fokusproblemer kan komme fra én dialogkomponent som brukes over hele nettstedet. Feil i mange skjemaer kan ha samme opphav i en felles feltkomponent.
Dette gir mer varige forbedringer enn å rette hver forekomst manuelt. Oppdater designmønsteret, komponenten og de redaksjonelle retningslinjene samtidig. Gjenta deretter den samme oppgaven med tastatur og skjermleser.
Målet er ikke bare at hvert element skal bestå en isolert kontroll. Målet er at en person skal kunne forstå valgene, navigere i riktig rekkefølge, oppdage feil og fullføre oppgaven uten mus. Når dere tester hele brukerreisen, blir universell utforming en del av kvaliteten på tjenesten, ikke en egen kontroll på siden av utviklingsarbeidet.
