Test hele brukerreisen uten mus: En praktisk tilgjengelighetsøvelse

Kategori: Universell utforming

En nettside kan ha god kontrast, riktige overskrifter og tydelige skjemafelt, men fortsatt være vanskelig å bruke. Problemene oppstår ofte i overgangen mellom sidene: når brukeren åpner menyen, filtrerer innhold, velger et alternativ, fyller ut et skjema og skal forstå bekreftelsen.

Derfor bør tilgjengelighet testes som sammenhengende brukerreiser, ikke bare som enkeltkomponenter. En nyttig øvelse er å velge én viktig oppgave og gjennomføre den uten mus, med forstørret visning og med skjermleser. Det gir teamet et konkret bilde av hvordan design, innhold og teknikk virker sammen.

Start med en oppgave som betyr noe

Ikke begynn testen på en tilfeldig underside. Velg en oppgave som er viktig både for brukeren og virksomheten. Det kan være å finne kontaktinformasjon, bestille en tjeneste, melde seg på et arrangement eller sende en forespørsel.

Beskriv oppgaven med et tydelig startpunkt og sluttpunkt. Et eksempel kan være:

Finn riktig tjeneste fra forsiden, les hva den innebærer, fyll ut kontaktskjemaet og kontroller at henvendelsen er sendt.

En slik formulering gjør det mulig å vurdere om brukeren faktisk kommer i mål. Den avdekker også hindringer som en isolert kontroll av knapper, kontrast eller feltnavn lett overser.

Velg gjerne tre brukerreiser:

• En enkel informasjonsoppgave, som å finne åpningstider eller priser.
• En navigasjonsoppgave, som å finne riktig tjeneste eller produkt.
• En handlingsoppgave, som å sende inn et skjema eller fullføre en bestilling.

Test først på datamaskin. Gjenta deretter de viktigste delene på mobil, fordi rekkefølge, zoom, menyer og skjemaer kan oppføre seg annerledes på en smal skjerm.

Første gjennomgang: Legg bort musen

Tastaturnavigasjon er en enkel og effektiv inngang til universell utforming. Legg bort musen og bruk Tab for å gå fremover, Shift og Tab for å gå bakover, Enter for å aktivere lenker og knapper og piltaster der komponenten krever det.

Følg med på fire spørsmål:

• Ser dere hvor fokus er? Den aktive lenken, knappen eller feltet må ha en tydelig fokusmarkering.
• Er rekkefølgen logisk? Fokus bør følge innholdets visuelle og meningsbærende rekkefølge.
• Kan alt betjenes? Menyer, nedtrekksfelt, dialogvinduer, filtre og skjemaer må fungere uten mus.
• Kommer dere videre? Fokus skal ikke bli fanget i en komponent eller forsvinne til et usynlig element.

Et vanlig problem er at hovedmenyen kan åpnes med tastaturet, men ikke lukkes. Et annet er at en dialogboks åpnes visuelt, mens tastaturfokuset blir liggende på siden bak. Da risikerer brukeren å navigere i innhold som ikke lenger er synlig.

Kontroller også om det finnes en praktisk måte å hoppe forbi gjentatt navigasjon på. Brukeren bør slippe å gå gjennom hele toppmenyen for hver nye side.

Andre gjennomgang: Forstørr og utfordre det visuelle designet

God kontrast handler ikke bare om vanlig brødtekst. Test også hjelpetekster, knapper, lenker, skjemakanter, feilmeldinger, ikoner og tekst som ligger over bilder. Svak grå tekst og diskrete feltkanter kan se ryddige ut i en designskisse, men bli vanskelige å oppfatte i praktisk bruk.

Forstørr siden betydelig i nettleseren og gjennomfør samme oppgave på nytt. Innholdet skal fortsatt kunne leses og brukes uten at tekst forsvinner, knapper overlapper eller brukeren må lete etter funksjoner som har flyttet seg ut av synsfeltet.

Se spesielt etter:

• Tekst som kuttes fordi boksen har fast høyde.
• Knapper der teksten brytes eller forsvinner.
• Menyer som dekker innhold uten å kunne lukkes.
• Skjemaer som krever vannrett rulling for å forstå felt og instruksjoner.
• Informasjon som bare formidles med farge.

En rød kant rundt et felt er for eksempel ikke nok som feilmelding. Brukeren trenger tekst som forklarer hva som er feil og hvordan det kan rettes. Tilsvarende bør ikke aktive faner, valgte produkter eller statusmeldinger skille seg fra resten kun gjennom farge.

Tredje gjennomgang: Lytt til siden med skjermleser

En skjermlesertest viser om sidens struktur og navn gir mening uten det visuelle laget. Start gjerne med å lytte gjennom overskriftene. De bør beskrive innholdet og danne en forståelig disposisjon. Hvis alle seksjoner heter «Les mer», eller viktige mellomtitler bare er visuelt formatert tekst, blir siden vanskelig å orientere seg i.

Gå deretter gjennom lenker, knapper og skjemafelt. Kontroller at hvert element har et navn som forklarer funksjonen. En knapp som kun leses opp som «knapp» eller et felt som bare annonseres som «redigeringsfelt», gir for lite informasjon.

Bilder som formidler viktig innhold, trenger et tekstalternativ som dekker formålet. Dekorative bilder bør ikke skape unødvendig støy. Målet er ikke å beskrive hver piksel, men å formidle informasjonen brukeren trenger i sammenhengen.

Vær også oppmerksom på dynamiske endringer. Hvis et produkt legges i handlekurven, et søk oppdateres eller et skjema viser en feil, må brukeren få vite at noe har skjedd. En visuell melding øverst på siden hjelper lite dersom skjermleserbrukeren står langt nede i skjemaet og ikke blir varslet.

Fjerde gjennomgang: Fremprovoser feil i skjemaet

Ikke test skjemaet bare med perfekte opplysninger. Send det inn med tomme obligatoriske felt, ugyldig format og manglende samtykke. Det viser om feilhåndteringen faktisk hjelper brukeren tilbake på rett spor.

Et tilgjengelig skjema bør ha synlige og teknisk tilknyttede ledetekster, forståelige krav og presise feilmeldinger. Plassholdertekst inne i feltet bør ikke være eneste forklaring, fordi den forsvinner når brukeren begynner å skrive.

Når skjemaet avvises, bør dere kontrollere:

• Om brukeren får en tydelig oppsummering av hva som må rettes.
• Om hvert problem forklares ved det aktuelle feltet.
• Om tastaturfokus flyttes eller styres på en forutsigbar måte.
• Om informasjon som allerede er skrevet inn, blir bevart.
• Om bekreftelsen etter innsending er tydelig og forståelig.

Denne testen handler ikke bare om skjemaet. Den kontrollerer også om overskrifter, fokusmarkering, kontrast, statusmeldinger og tastaturnavigasjon fungerer samlet.

Knytt funnene til WCAG uten å gjøre testen til en avkrysningsøvelse

WCAG gir kriterier for blant annet tastaturbruk, kontrast, struktur, tekstalternativer, fokus og feilhåndtering. Kriteriene er nødvendige når dere skal stille krav og dokumentere kvalitet, men de bør ikke være eneste utgangspunkt for selve testingen.

Registrer hvert funn med fire opplysninger:

1. Hvilken brukerreise og hvilket steg problemet oppstod i.
2. Hva brukeren forsøkte å gjøre.
3. Hva som faktisk skjedde.
4. Hvilket WCAG-område eller internt krav funnet gjelder.

Da får utvikleren både en praktisk feilbeskrivelse og en faglig ramme. «Dårlig tilgjengelighet i menyen» er vanskelig å rette. «Undermenyen åpnes med Enter, men tastaturfokus flyttes ikke inn i menyen og den kan ikke lukkes med tastaturet» er konkret og testbart.

Prioriter etter konsekvens, ikke etter hvor lett feilen er å rette

Tilgjengelighetsfunn bør prioriteres ut fra hva de hindrer brukeren i å gjøre. En manglende fokusmarkering i en dekorativ lenke er ikke nødvendigvis like alvorlig som en bestillingsknapp som ikke kan aktiveres med tastatur.

En enkel prioritering kan være:

• Blokkerende: Brukeren kan ikke fullføre oppgaven.
• Alvorlig: Oppgaven kan fullføres, men krever omveier, gjetting eller hjelp.
• Forstyrrende: Problemet skaper unødvendig friksjon eller uklarhet.

Rett først feil som går igjen i felles komponenter. Én forbedring i menyen, skjemakomponenten eller knappestilen kan løse problemer på mange sider samtidig.

Gjør øvelsen til en del av leveransen

Testen bør gjennomføres før lansering og etter større endringer i navigasjon, design eller funksjonalitet. Fordel gjerne rollene mellom innholdsansvarlig, designer og utvikler. De ser ulike problemer og kan avklare løsninger mens brukerreisen fortsatt er fersk.

En slik øvelse erstatter ikke full WCAG-kontroll, automatiserte tester eller testing med personer som bruker hjelpemidler til daglig. Den gir likevel teamet en konkret metode for å oppdage sammenhengende problemer tidlig.

Det viktigste resultatet er ikke en lang liste med avvik. Det er at en sentral oppgave kan gjennomføres med tastatur, forstørring og skjermleser, og at brukeren forstår både innhold, valg, feil og bekreftelser underveis. Da blir universell utforming en egenskap ved hele brukerreisen, ikke et lag som legges på til slutt.