Prioriter barrierene som stopper brukeren – ikke avvikene som er enklest å telle

Kategori: Universell utforming

En tilgjengelighetskontroll kan gi en lang liste med avvik. Problemet er at listen sjelden forteller hva virksomheten bør rette først. En svak kontrast i en dekorativ detalj, en uforståelig feilmelding i bestillingsskjemaet og en meny som ikke kan brukes med tastatur, kan alle være avvik. Konsekvensene er likevel svært forskjellige.

En mer nyttig prioritering starter derfor ikke med antall feil, men med spørsmålet: Hvilke barrierer hindrer mennesker i å fullføre de viktigste oppgavene på nettsiden?

Denne tilnærmingen erstatter ikke WCAG. Retningslinjene gir nødvendige og testbare krav. Men når tid og budsjett er begrenset, trenger dere også en metode for å velge riktig rekkefølge på arbeidet.

Start med oppgaver, ikke enkeltsider

Brukere kommer sjelden til nettsiden for å vurdere én isolert side. De skal finne en tjeneste, forstå vilkårene, fylle ut et skjema og få bekreftet at henvendelsen er sendt. En barriere tidlig i denne kjeden kan gjøre resten av løsningen irrelevant.

Velg først tre til fem oppgaver som er viktige både for brukeren og virksomheten. Det kan være å:

• bestille en tjeneste eller et produkt
• sende inn en søknad eller forespørsel
• finne pris, åpningstid eller kontaktinformasjon
• endre en eksisterende avtale
• lese viktig informasjon om rettigheter eller frister

Beskriv deretter hele løpet for hver oppgave. Ta med navigasjon, informasjonssider, innlogging, skjemaer, feilmeldinger og bekreftelser. Da blir det tydelig hvor en teknisk eller visuell svakhet faktisk bryter brukerreisen.

Vurder hver oppgave gjennom fire brukerbehov

For hver kritiske oppgave bør dere undersøke om brukeren kan oppfatte innholdet, forstå det, betjene løsningen og rette opp feil. Disse fire spørsmålene gjør WCAG-arbeidet lettere å koble til praktisk design og utvikling.

1. Kan brukeren oppfatte innholdet?

Se etter informasjon som bare formidles gjennom syn, farge eller lyd. Lav kontrast kan gjøre tekst, knapper og skjemafelt vanskelige å oppdage. Manglende tekstalternativer kan skjule meningen i bilder for skjermleserbrukere. Instruksjoner som bare peker på den røde boksen, fungerer dårlig for personer som ikke oppfatter fargen.

Kontroller kontrasten med måleverktøy, men vurder også løsningen i faktisk bruk. Tekst som teknisk består et minstekrav, kan fortsatt være krevende når den ligger over et bilde, bruker svært tynne bokstaver eller blir lest på en mobilskjerm i dagslys.

2. Kan brukeren forstå hva som skal skje?

Universell utforming handler også om språk, rekkefølge og forventninger. En knapp merket «Fortsett» sier lite dersom brukeren ikke vet om neste steg er betaling, bekreftelse eller flere spørsmål. Lange avsnitt, uklare overskrifter og uventede endringer gjør oppgaven vanskeligere for mange.

Bruk konkrete feltnavn og handlingsorienterte knapper. Forklar hvorfor dere ber om informasjon når behovet ikke er åpenbart. Del omfattende skjemaer inn i forståelige deler, og vis hvor brukeren befinner seg i prosessen.

3. Kan brukeren betjene løsningen?

Alle sentrale funksjoner må kunne brukes uten mus. Test med Tab, Shift og Tab, Enter, mellomrom og piltaster der det er relevant. Fokusmarkeringen må være synlig, og fokusrekkefølgen må følge en logisk vei gjennom innholdet.

Vær særlig oppmerksom på menyer, dialogbokser, datovelgere, filtre og egendefinerte nedtrekkslister. Slike komponenter kan se riktige ut, men mangle nødvendig tastaturstøtte. Et typisk faresignal er at fokus forsvinner, blir fanget i en komponent eller flyttes til et uventet sted.

4. Kan brukeren oppdage og rette feil?

Feilhåndtering er ofte avgjørende i skjemaer. Det holder ikke å markere et felt med rød ramme. Feilen bør forklares med tekst, knyttes til riktig felt og bli gjort tilgjengelig for skjermlesere. Brukeren må få vite både hva som er feil og hvordan det kan rettes.

Hvis innsendingen mislykkes, bør allerede utfylte opplysninger bevares så langt det er mulig. Det er særlig viktig i lange skjemaer. Å måtte begynne på nytt er mer enn en irritasjon; det kan føre til at brukeren gir opp hele oppgaven.

Lag et barrierekart med konsekvens og omfang

Når oppgavene er testet, kan funnene samles i et enkelt barrierekart. Hvert funn bør inneholde mer enn en teknisk beskrivelse.

• Oppgave: Hva forsøker brukeren å gjøre?
• Barriere: Hva hindrer eller forsinker oppgaven?
• Berørte bruksmåter: Gjelder det for eksempel tastatur, skjermleser, forstørring eller redusert fargesyn?
• Konsekvens: Blir oppgaven vanskelig, svært krevende eller umulig?
• Omfang: Forekommer problemet ett sted eller i en komponent som brukes over hele nettstedet?
• Tiltak: Hva må endres i design, kode eller innhold?
• Ansvar: Hvem kan faktisk få rettet problemet?

Dette gir et bedre beslutningsgrunnlag enn en liste med generelle formuleringer som «dårlig kontrast» eller «mangler etikett». Utvikleren trenger å vite hvilken komponent det gjelder. Designeren må forstå den visuelle sammenhengen. Innholdsansvarlig må kunne se om teksten bidrar til problemet.

Prioriter kombinasjoner av barrierer

Enkelte feil blir langt mer alvorlige når de opptrer sammen. Et skjema kan for eksempel ha svake feltetiketter, lav kontrast, utydelig fokus og feilmeldinger som ikke leses opp. Hver svakhet kan registreres separat, men for brukeren oppleves de som ett sammenhengende hinder.

Prioriter derfor høyt når flere av disse forholdene er til stede:

1. Barrieren stopper en viktig oppgave.
2. Den rammer flere brukergrupper eller bruksmåter.
3. Den forekommer i en gjenbrukt komponent.
4. Brukeren får ingen forklaring eller alternativ vei videre.
5. Feilen kan føre til tap av informasjon, tid eller penger.

En utilgjengelig hovedmeny bør normalt komme før en liten visuell feil på en sjelden besøkt informasjonsside. En feil i et felles skjemafelt kan være viktigere enn flere enkeltavvik, fordi rettingen forbedrer mange skjemaer samtidig.

Test skjemaet som en sammenhengende samtale

Skjemaer bør ikke bare vurderes felt for felt. Les dem som en samtale mellom virksomheten og brukeren. Er spørsmålene stilt i en naturlig rekkefølge? Er obligatoriske felt tydelige før brukeren sender inn? Er eksempler og formater forklart? Får brukeren bekreftelse etter innsending?

Test deretter hele skjemaet med tastatur og skjermleser. Lytt til hvordan etiketter, hjelpetekster, valg og feilmeldinger blir presentert. Det visuelle designet kan antyde sammenhenger som ikke finnes i koden. To felt kan ligge under samme overskrift på skjermen, men bli lest opp uten denne konteksten.

Prøv også å sende inn skjemaet med manglende eller feil informasjon. Kontroller hvor fokuset flyttes, om feilene blir lest opp, og om det er lett å navigere til feltene som må rettes.

Bruk WCAG som kvalitetsgrunnlag, ikke som hele prioriteringen

WCAG gir et felles språk for hva som skal være mulig å oppfatte, betjene og forstå. Det gjør kravene etterprøvbare og reduserer rommet for synsing. Samtidig bør ikke samsvar med enkeltkrav bli det eneste målet.

En løsning kan oppfylle mange formelle krav og fortsatt være unødvendig tung å bruke. Lange instruksjoner kan være korrekt kodet, men vanskelige å forstå. En fokusmarkering kan være synlig, men så diskret at den er krevende å følge gjennom en lang prosess. En knapp kan ha tilstrekkelig kontrast, men en uklar tekst.

Den praktiske kvalitetsvurderingen bør derfor kombinere tre perspektiver:

• WCAG: Oppfyller løsningen konkrete og testbare krav?
• Oppgave: Kan brukeren fullføre det vedkommende kom for å gjøre?
• Bruksopplevelse: Er veien forståelig, forutsigbar og rimelig effektiv?

Fordel tiltakene mellom design, utvikling og innhold

Universell utforming blir fort stående hvis alle funn sendes til utviklerne. Mange barrierer krever andre typer tiltak. Lav kontrast kan skyldes fargepaletten. Uklare feilmeldinger kan være et innholdsproblem. Mangelfulle etiketter kan kreve både tekstendringer og teknisk kobling i skjemaet.

Sorter derfor tiltakene etter hvem som må bidra:

• Design: kontrast, fokusmarkering, visuell struktur, berøringsflater og tilstander
• Utvikling: semantikk, tastaturstøtte, fokusstyring og teknisk formidling av status
• Innhold: overskrifter, instruksjoner, knappetekster, etiketter og feilmeldinger
• Produkteier: prioritering, akseptansekriterier og avveiing mellom tiltak

Avslutt hvert tiltak med en tydelig kontroll: Hvilken oppgave skal testes på nytt, med hvilken bruksmåte, og hva må fungere før saken kan lukkes?

Målet er færre stopp, ikke bare færre avvik

En nettside blir ikke inkluderende fordi avvikslisten blir kortere. Den blir inkluderende når flere mennesker kan finne informasjon, forstå valgene og fullføre oppgavene uten å bli stoppet av designet.

Ved å organisere arbeidet rundt kritiske brukeroppgaver får dere en prioritering som både ledelse, designere, utviklere og innholdsansvarlige kan forstå. WCAG viser hvilke krav som må ivaretas. Tastatur, skjermleser og kontrastmåling avdekker konkrete barrierer. Oppgaveperspektivet viser hvilke av dem som bør løses først.