Gjør skjemaet mulig å fullføre: Universell utforming fra felt til feilmelding

Kategori: Universell utforming

Et skjema kan se enkelt ut og likevel være vanskelig å bruke. Et manglende feltnavn, en utydelig fokusmarkering eller en feilmelding som bare vises med rød farge, kan stoppe brukeren fra å sende en forespørsel, registrere seg eller gjennomføre et kjøp.

Derfor bør universell utforming av skjemaer behandles som en sammenhengende brukerreise. WCAG gir kravene, men den praktiske oppgaven er å sikre at brukeren forstår hva som skal fylles ut, kan bevege seg gjennom feltene, oppdager feil og klarer å rette dem.

Start med oppgaven, ikke komponentene

Før dere vurderer kontrast, kode og skjermleseratferd, bør dere spørre hva skjemaet faktisk krever av brukeren. Lange og uklare skjemaer skaper problemer for alle, men særlig for personer som bruker hjelpemidler, har nedsatt syn, motoriske utfordringer eller konsentrasjonsvansker.

Fjern felt som ikke er nødvendige for å løse oppgaven. Hvis bedriften ikke trenger telefonnummer for å svare, bør feltet normalt ikke være obligatorisk. Hvis et skjema har flere trinn, må brukeren forstå hvor langt vedkommende har kommet og hva som gjenstår.

En god første gjennomgang består av tre spørsmål:

• Hvilke opplysninger er nødvendige for å behandle henvendelsen?
• Er rekkefølgen logisk sett fra brukerens ståsted?
• Kan instruksjoner og faguttrykk skrives enklere?

Dette er inkluderende design i praksis: Reduser belastningen før dere forsøker å forklare kompleksiteten.

Gi hvert felt et tydelig og varig navn

Alle skjemafelt trenger et synlig feltnavn som er teknisk koblet til riktig felt. Plassholdertekst inne i feltet er ikke en god erstatning. Den forsvinner gjerne når brukeren begynner å skrive, kan ha svak kontrast og blir ikke alltid formidlet på en nyttig måte av hjelpemidler.

Feltnavnet bør være konkret. Bruk for eksempel «E-postadresse» fremfor «Kontaktinformasjon». Hvis et bestemt format kreves, kan en kort instruksjon stå ved feltet. Denne instruksjonen må være tilgjengelig også for skjermlesere.

Obligatoriske felt bør merkes med tekst, ikke bare med en stjerne eller farge. En formulering som «Obligatorisk» er tydeligere enn en visuell kode brukeren først må lære. Dersom de fleste feltene er obligatoriske, kan det være mer oversiktlig å merke de valgfrie feltene.

Bruk standardkomponenter når de passer

Vanlige HTML-felt, avkrysningsbokser, radioknapper og knapper har innebygd funksjonalitet som nettlesere og hjelpemidler kjenner. Spesialbygde komponenter kan være nødvendige, men krever mer arbeid for å støtte navn, rolle, tilstand, fokus og tastaturbetjening.

En visuelt elegant nedtrekksliste er ikke vellykket hvis brukeren ikke kan åpne den med tastaturet eller forstå valgt alternativ med skjermleser. Velg derfor standardkontroller med mindre en spesialløsning gir en reell brukerfordel og blir grundig testet.

Sørg for at hele skjemaet fungerer med tastatur

Brukeren skal kunne nå og betjene alle felt, valg, hjelpetekster og knapper uten mus. Tabulatortasten brukes normalt til å flytte mellom interaktive elementer, mens andre taster brukes til å gjøre valg i enkelte komponenter.

Test rekkefølgen fra starten av skjemaet. Fokus skal følge den visuelle og logiske rekkefølgen. Et hopp til en knapp nederst på siden eller tilbake til et tidligere felt kan gjøre skjemaet vanskelig å forstå.

Det aktive elementet må ha en tydelig fokusmarkering. En svak fargeendring er ofte utilstrekkelig. Bruk en markering som skiller seg klart fra både komponenten og bakgrunnen, og som fungerer på tvers av sidens farger.

Pass også på at faste toppmenyer, samtykkebokser eller andre lag ikke dekker feltet som har fokus. Teknisk sett kan feltet være valgt selv om brukeren ikke ser det.

Bruk kontrast til mer enn lesbar tekst

WCAG stiller krav til kontrast, men kontrollen bør ikke begrenses til brødtekst. I et skjema må dere også vurdere feltrammer, ikoner, fokusmarkering, hjelpetekster, knappetekst og informasjon om feil.

Et felt med en svært lys kant kan være vanskelig å oppfatte mot hvit bakgrunn. En deaktivert knapp kan bli så svak at brukeren ikke ser den, samtidig som det mangler en forklaring på hva som må gjøres for å aktivere den.

Farge skal heller ikke være eneste informasjonsbærer. Et felt med feil kan få rød kant, men trenger i tillegg et symbol eller en tekstlig beskjed. Det samme gjelder markering av obligatoriske felt, valgte alternativer og statusmeldinger.

Lag feilmeldinger som hjelper brukeren videre

«Ugyldig verdi» beskriver systemets reaksjon, ikke brukerens løsning. En nyttig feilmelding forklarer hvilket felt som har et problem, hva som er galt, og hvordan det kan rettes.

For eksempel er «Skriv inn e-postadressen med navn, krøllalfa og domene» mer handlingsrettet enn «Feil e-post». Samtidig bør valideringen akseptere gyldige variasjoner og ikke kreve et snevrere format enn nødvendig.

Når innsendingen mislykkes, bør skjemaet:

1. Vise en tydelig oppsummering av feilene nær starten.
2. Markere hvert problem ved det aktuelle feltet.
3. Koble feilmeldingen teknisk til feltet.
4. Beholde opplysninger som allerede er fylt ut, når det er forsvarlig.
5. Flytte eller styre oppmerksomheten slik at brukeren oppdager feilen.

Unngå å fjerne hele skjemaet og erstatte det med en generell beskjed. For en skjermleserbruker kan en visuelt tydelig melding forbli ubemerket dersom endringen ikke blir formidlet teknisk.

Test med skjermleser uten å glemme strukturen

En skjermleser formidler siden sekvensielt og bygger forståelsen på struktur, navn og tilstander. Det er derfor ikke nok at teksten ser riktig ut visuelt. Feltnavn, grupper, instruksjoner og feil må ha tydelige tekniske forbindelser.

Radioknapper som «Ja» og «Nei» trenger eksempelvis et felles gruppenavn, som «Ønsker du å bli kontaktet på telefon?». Ellers kan alternativene bli lest opp uten nødvendig sammenheng.

Test minst at skjermleseren oppgir:

• hva feltet heter
• hvilken type kontroll det er
• om feltet er obligatorisk
• hvilket alternativ som er valgt
• relevante instruksjoner og feilmeldinger
• om innsendingen var vellykket

Skjermlesertesting bør kombineres med visuell kontroll og tastaturtesting. Ett verktøy avslører ikke alle barrierer.

Gjør skjemaet robust ved forstørring og på små skjermer

Brukere må kunne forstørre innholdet uten at felt, tekster eller knapper overlapper eller forsvinner. Skjemaet bør tilpasse seg smal visning uten at vannrett rulling blir nødvendig for å forstå og fylle ut vanlige felt.

Unngå å plassere feltnavn og inndata så langt fra hverandre at sammenhengen blir uklar ved forstørring. Felt i én kolonne er ofte enklere å følge enn tette oppsett med flere kolonner. Unntak kan være opplysninger som naturlig hører sammen, men også disse må fungere når plassen blir begrenset.

Knapper og valg må ha tilstrekkelig størrelse og avstand til at de kan betjenes presist. Dette er særlig viktig på mobil og for personer med redusert finmotorikk.

Kontroller hele forløpet før publisering

Ikke test bare det tomme skjemaet. Gå gjennom situasjonene brukeren faktisk kan møte: riktig utfylling, manglende obligatoriske felt, feil format, avbrudd og vellykket innsending.

En praktisk kontroll kan gjennomføres slik:

1. Fullfør skjemaet med bare tastatur.
2. Gjenta testen med tydelig forstørring.
3. Kontroller tekst, komponenter, fokus og feilmarkering for kontrast.
4. Bruk skjermleser og lytt til hvert feltnavn, valg og statusbudskap.
5. Send inn med flere bevisste feil og vurder om veien videre er forståelig.
6. Test på mobil med berøring og skjermtastatur.
7. Kontroller at bekreftelsen forklarer hva som skjer videre.

Ta vare på testtilfellene og bruk dem etter endringer i design, validering eller skjemaløsning. Da blir universell utforming en del av forvaltningen, ikke en engangskontroll før lansering.

Fordel ansvar mellom design, utvikling og innhold

Tilgjengelige skjemaer blir sjelden gode hvis ansvaret ligger hos én person til slutt. Designeren må definere kontrast, fokus og feilstil. Utvikleren må sikre korrekt struktur, tastaturstøtte og formidling til hjelpemidler. Innholdsansvarlig må skrive forståelige feltnavn, instruksjoner og feilmeldinger.

Den som eier forretningsprosessen, må samtidig utfordre hvilke opplysninger skjemaet ber om. Et teknisk tilgjengelig skjema kan fortsatt være unødvendig krevende hvis det inneholder for mange spørsmål eller uklare krav.

Målet er ikke bare å krysse av for enkeltkrav i WCAG. Målet er at flere mennesker faktisk kan forstå oppgaven, fullføre den og vite at informasjonen er sendt. Det er den mest nyttige testen på om skjemaet fungerer inkluderende.