Test den viktigste brukerreisen uten mus – og finn barrierene som stopper kunden

En nettside kan bestå mange automatiske tilgjengelighetstester og fortsatt være vanskelig å bruke. Problemet er ofte at kontrollen skjer side for side, mens brukeren skal løse en sammenhengende oppgave: finne riktig tjeneste, forstå vilkårene, fylle ut et skjema og motta en bekreftelse.

Derfor bør arbeidet med universell utforming også ta utgangspunkt i brukerreiser. Velg én viktig oppgave og gjennomfør den med tastatur, skjermleser og visuell kontroll. Da finner dere barrierer som isolerte komponenttester lett overser.

Metoden passer særlig godt for kontaktskjemaer, bestillinger, søknader, påmeldinger og kjøpsløp. Den kan brukes under utvikling, før publisering og som del av jevnlig kvalitetsarbeid.

Start med én oppgave som betyr noe

Ikke begynn med å teste hele nettstedet. Velg en oppgave som er viktig både for brukeren og virksomheten. Det kan være å bestille en befaring, melde seg på et kurs eller be om et tilbud.

Beskriv oppgaven uten å forklare hvordan den skal løses. En enkel testoppgave kan være:

Finn tjenesten som gjelder rehabilitering av bad, undersøk hva bedriften tilbyr, og send inn en forespørsel om befaring.

Noter hvilke sider, menyer, knapper, dialogbokser og skjemafelt brukeren må gjennom. Ta også med det som skjer etter innsending. En bekreftelse er en del av brukerreisen, ikke et tillegg.

Lag deretter noen få akseptansekriterier:

• Hele oppgaven skal kunne gjennomføres uten mus.
• Det skal være tydelig hvor tastaturfokuset befinner seg.
• Innhold, kontroller og feilmeldinger skal kunne forstås med skjermleser.
• Tekst og viktige grensesnittelementer skal ha tilstrekkelig kontrast.
• Skjemaet skal forklare hva som kreves, hva som gikk galt og hvordan feilen rettes.

WCAG gir kriteriene dere skal møte. Brukerreisen viser om løsningen faktisk henger sammen i praksis.

Første gjennomgang: Gjør alt med tastaturet

Legg musen til side. Bruk Tab for å gå fremover, Shift og Tab for å gå tilbake, Enter eller mellomrom for å aktivere kontroller og piltaster der komponenten krever det.

Følg reisen fra start til slutt. Ikke test bare om det er mulig å nå en knapp. Vurder om rekkefølgen er forståelig, om fokuset er synlig, og om komponenten oppfører seg som forventet.

Se etter disse problemene

• Usynlig fokus: Dere vet ikke hvilken lenke, knapp eller hvilket felt som er aktivt.
• Ulogisk rekkefølge: Fokuset hopper til sidefelt, bunntekst eller skjulte elementer før det fortsetter i hovedinnholdet.
• Tastaturfelle: Brukeren kommer inn i en meny eller dialogboks, men ikke ut igjen.
• Elementer som hoppes over: Klikkbare kort, egendefinerte nedtrekkslister eller ikoner kan bare brukes med mus.
• Uventet endring: Et valg sender inn skjemaet, åpner en ny visning eller flytter fokuset uten tydelig varsel.

En vanlig feil er å fjerne nettleserens standardmarkering av fokus fordi den ikke passer designet. Hvis markeringen skal erstattes, må den nye være minst like tydelig. Fokus bør være lett å se både på lyse og mørke flater og i alle interaktive tilstander.

Test også menyer og dialogbokser. Når en dialog åpnes, bør fokuset flyttes inn i den. Når den lukkes, bør fokuset normalt gå tilbake til elementet som åpnet den. Det gjør at brukeren kan fortsette uten å lete seg frem på nytt.

Andre gjennomgang: Lytt til reisen med skjermleser

En skjermleser gjengir mer enn teksten på skjermen. Den formidler struktur, roller, navn og tilstander. En visuelt tydelig knapp kan derfor bli uforståelig hvis den bare leses opp som «knapp» eller «les mer».

Start med å lytte til siden i vanlig leserekkefølge. Naviger deretter etter overskrifter, lenker og skjemafelt. Målet er ikke å mestre alle kommandoer, men å oppdage om innholdet har en forståelig struktur.

Kontroller det brukeren faktisk får høre

• Beskriver sidetittelen hvor brukeren har kommet?
• Danner overskriftene en meningsfull innholdsfortegnelse?
• Har lenker og knapper navn som gir mening uten teksten rundt?
• Har bilder alternativ tekst når motivet formidler viktig informasjon?
• Blir dekorative bilder utelatt fra opplesningen?
• Blir åpne menyer, valgte faner og utvidede seksjoner formidlet med riktig tilstand?
• Blir bekreftelser og feilmeldinger lest opp når de vises?

Bruk helst vanlige HTML-elementer når det finnes et element som passer oppgaven. En ekte knapp har innebygd tastaturstøtte og en kjent rolle. En klikkbar tekstflate som etterligner en knapp, krever mer kode og gir flere muligheter for feil.

Vær forsiktig med å bruke skjult hjelpetekst som reparasjon for uklart innhold. Det som er utydelig for en skjermleserbruker, kan også være utydelig for andre. En knapp med teksten «Send forespørsel» er som regel bedre enn «Send», både visuelt og ved opplesning.

Tredje gjennomgang: Kontroller kontrast og visuelle signaler

Kontrast gjelder mer enn brødtekst. Den påvirker lenker, knapper, feltkanter, ikoner, fokusmarkeringer og feilmeldinger. Svak kontrast kan gjøre en funksjon vanskelig å oppdage selv om den teknisk sett virker.

Som praktisk utgangspunkt krever WCAG et kontrastforhold på minst 4,5 til 1 for vanlig tekst. Stor tekst kan ha minst 3 til 1. Viktige komponenter og visuelle tilstander, som feltkanter og fokusmarkeringer, må også kunne skilles fra omgivelsene.

Bruk et kontrastverktøy til å måle fargekombinasjonene. Ikke vurder dem bare med øyet. Kontroller alle tilstander, ikke bare standardvisningen:

• Vanlig, besøkt og aktiv lenke
• Knapp i normal, fokusert og deaktivert tilstand
• Tomt, utfylt og feilmarkert skjemafelt
• Menyvalg ved peker, tastaturfokus og aktiv side
• Tekst som ligger over fotografier eller fargede flater

Farge bør heller ikke være det eneste signalet. Hvis et felt med feil bare får rød kant, kan problemet være vanskelig å oppfatte. Kombiner fargen med tekst, et tydelig symbol og en konkret forklaring.

Skjemaet er ofte der brukerreisen stopper

Skjemaer samler mange tilgjengelighetskrav på liten plass. Feltene må ha navn, instruksjonene må være forståelige, og feil må håndteres uten at brukeren mister oversikten.

Et godt skjema har synlige etiketter over eller ved feltene. Plassholdertekst inne i feltet bør ikke være eneste forklaring. Den forsvinner når brukeren begynner å skrive, har ofte svak kontrast og kan bli tolket ulikt av hjelpemidler.

Gjør kravene tydelige før brukeren sender inn

• Marker obligatoriske felt både visuelt og maskinlesbart.
• Forklar formatkrav før feltet, for eksempel hvordan dato eller organisasjonsnummer skal skrives.
• Bruk riktig felttype slik at nettleser og mobile tastaturer kan hjelpe brukeren.
• Be bare om informasjon dere faktisk trenger.
• Unngå tidsgrenser, eller gi mulighet til å forlenge tiden når en grense er nødvendig.

Når innsendingen feiler, bør brukeren få en oppsummering og konkrete meldinger ved de aktuelle feltene. «Ugyldig verdi» er lite nyttig. «Skriv telefonnummeret med åtte siffer» forklarer hva som må rettes.

Ikke slett korrekt utfylte opplysninger etter en feil. Flytt gjerne fokuset til feiloppsummeringen, og la brukeren gå direkte til hvert problem. Etter vellykket innsending må bekreftelsen være tydelig både visuelt og for skjermleseren. Fortell hva som ble sendt, og hva som skjer videre.

Skill mellom alvorlighetsgrad og arbeidsmengde

Ikke prioriter feil bare etter hvor enkle de er å rette. Vurder først konsekvensen for brukerreisen.

1. Blokkerende: Oppgaven kan ikke fullføres, for eksempel fordi sendeknappen ikke kan nås med tastatur.
2. Alvorlig: Oppgaven kan fullføres, men krever gjetting eller unødvendig omvei.
3. Forstyrrende: Løsningen virker, men gir svak orientering, uklare signaler eller ekstra arbeid.
4. Forbedring: Endringen vil gjøre løsningen enklere uten at dagens løsning nødvendigvis blokkerer bruk.

Registrer hvert funn med plassering, fremgangsmåte, forventet resultat og faktisk resultat. Legg gjerne ved skjermbilde, men ikke la skjermbildet erstatte beskrivelsen. En utvikler må kunne gjenskape problemet uten å tolke en løs kommentar som «fungerer dårlig med tastatur».

Gjør testen til en del av arbeidsflyten

Universell utforming blir mer håndterlig når teamet tester små brukerreiser jevnlig. Designere kan kontrollere kontrast, fokus og feilmønstre før utvikling. Utviklere kan teste komponenter med tastatur og skjermleser. Innholdsansvarlige kan kvalitetssikre overskrifter, lenketekster, felttekster og alternative bildetekster.

Ved større endringer bør den valgte brukerreisen testes på nytt fra start til slutt. En ny meny, informasjonsboks eller samtykkeløsning kan skape barrierer et helt annet sted enn der endringen ble gjort.

Automatiske verktøy er nyttige for å oppdage enkelte kode- og kontrastfeil, men de kan ikke avgjøre om fokusrekkefølgen er logisk, om en feilmelding er forståelig eller om oppgaven oppleves sammenhengende. Det krever manuell kontroll.

Begynn med den reisen som betyr mest. Når den fungerer uten mus, gir mening ved opplesning og håndterer feil på en forståelig måte, har dere forbedret mer enn etter en lang liste med isolerte smårettinger.