Skjemarevisjonen: Slik gjør du veien fra felt til bekreftelse tilgjengelig

Et kontaktskjema kan se enkelt ut, men samler mange av de vanligste hindringene for universell utforming på ett sted. Brukeren skal forstå hva som etterspørres, navigere mellom feltene, oppdage feil og vite om innsendingen lyktes. Det må fungere uten mus, med forstørret visning og med skjermleser.

Derfor er skjemaet et godt sted å starte når en bedrift vil gjøre universell utforming konkret. I stedet for å kontrollere WCAG som en lang liste med enkeltkrav, kan dere følge én reell oppgave fra start til slutt. Denne skjemarevisjonen passer for kontaktskjemaer, bestillinger, registreringer, søknader og andre viktige henvendelser.

Start med oppgaven, ikke bare komponentene

Et tilgjengelig tekstfelt hjelper lite dersom brukeren ikke finner skjemaet, ikke forstår formålet eller mister informasjon etter en feil. Revisjonen bør derfor omfatte hele forløpet:

1. Finne riktig skjema.
2. Forstå hva som skal fylles ut.
3. Fylle ut feltene med ønsket betjeningsmåte.
4. Oppdage og rette feil.
5. Sende inn skjemaet.
6. Få en tydelig bekreftelse.

Velg gjerne skjemaet som er viktigst for virksomheten. Det kan være bestilling av befaring, påmelding til et kurs eller forespørsel om tilbud. Noter hvilken oppgave dere tester, hva som må fylles ut, og hva brukeren skal oppleve når oppgaven er fullført.

Fjern felt som ikke har en tydelig funksjon

Det enkleste feltet å gjøre tilgjengelig er feltet dere ikke trenger. Hvert ekstra spørsmål øker den kognitive belastningen og gir en ny mulighet for feil.

Be skjemaeieren forklare hvorfor hvert felt finnes. Trenger dere både fornavn og etternavn, eller holder det med navn? Må telefonnummer være obligatorisk når svaret kan sendes på e-post? Er organisasjonsnummer nødvendig før en innledende samtale?

Skill tydelig mellom obligatoriske og valgfrie felt. Ikke baser dette bare på en stjerne eller farge. Skriv for eksempel Telefonnummer, valgfritt i etiketten. Dersom nesten alle feltene er obligatoriske, kan dere forklare dette før skjemaet og merke unntakene som valgfrie.

Gi hvert felt en synlig og presis etikett

Plassholdertekst inne i feltet er ikke en god erstatning for en etikett. Teksten forsvinner når brukeren begynner å skrive, kan ha svak kontrast og blir ikke alltid formidlet på en forutsigbar måte av hjelpemidler.

Bruk en synlig etikett som er teknisk koblet til riktig felt. Etiketten bør beskrive informasjonen, ikke bare vise et eksempel. E-postadresse er en etikett. navn@bedrift.no er et eksempel som eventuelt kan stå i tillegg.

Instruksjoner bør plasseres før brukeren trenger dem. Hvis et passord må oppfylle bestemte regler, må reglene være synlige før innsending. Hvis datoen skal skrives i et bestemt format, oppgi formatet ved feltet. Sørg også for at instruksjonen har en teknisk forbindelse til feltet, slik at den blir lest opp av skjermlesere.

Test hele skjemaet uten mus

Tastaturtesten handler om mer enn å kunne komme inn i et tekstfelt. Brukeren må kunne nå, forstå og betjene alle interaktive elementer.

Start på siden og bruk Tab for å gå fremover og Shift og Tab for å gå tilbake. Bruk Enter og mellomrom der det er relevant. Test nedtrekkslister, avkrysningsbokser, radioknapper, datovelgere, opplastingsfelt og sendeknappen.

Kontroller følgende underveis:

• Fokusrekkefølgen følger den visuelle og logiske rekkefølgen.
• Det er lett å se hvilket element som har tastaturfokus.
• Fokus forsvinner ikke bak en fast toppmeny eller et popup-vindu.
• Alle funksjoner kan betjenes uten presis musebruk.
• Brukeren blir ikke fanget i et felt, en meny eller en dialogboks.
• Enter sender ikke inn skjemaet uventet mens brukeren velger et alternativ.

En tydelig fokusmarkering bør ha god kontrast mot både komponenten og bakgrunnen rundt. Ikke fjern nettleserens standardmarkering uten å erstatte den med noe som er minst like synlig.

Kontroller kontrast i alle tilstander

Kontrasttesten må omfatte mer enn brødtekst. Et skjema har flere tilstander som ofte blir oversett: standard, fokus, utfylt, deaktivert, feil og bekreftet.

Kontroller etiketter, hjelpetekster, tekst i knapper, kantlinjer som viser hvor feltet er, fokusmarkeringer og feilmeldinger. Svak grå tekst på hvit bakgrunn er særlig vanlig i hjelpetekster og plassholdere.

Farge skal heller ikke være den eneste måten å formidle betydning på. En rød kant rundt et felt forteller ikke nødvendigvis hva som er galt, og kan være vanskelig å oppfatte. Kombiner visuell markering med tekst som beskriver feilen. Ikoner kan støtte budskapet, men bør ikke stå alene.

Gjør feilmeldingen til en rettledning

En god feilmelding svarer på tre spørsmål: Hva er galt, hvor er feilen, og hvordan kan den rettes? Ugyldig verdi er lite nyttig. Skriv inn e-postadressen med navn, krøllalfa og domene gir brukeren en vei videre.

Validering mens brukeren skriver kan være forstyrrende hvis feltet markeres som feil før det er ferdig utfylt. Vent til brukeren har forlatt feltet, eller til skjemaet sendes inn, avhengig av oppgaven. Ikke fjern informasjon som allerede er riktig utfylt når en feil oppstår.

Hvis innsendingen avdekker flere feil, bør det vises en oppsummering øverst i skjemaet. Oppsummeringen skal forklare at skjemaet ikke ble sendt, liste feilene og hjelpe brukeren til de aktuelle feltene. Hvert felt må fortsatt ha sin egen melding.

Flytting av tastaturfokus kan være riktig når innsendingen feiler, men må gjøres bevisst. Før fokus til feiloppsummeringen eller første felt med feil, slik at tastatur- og skjermleserbrukere merker at situasjonen har endret seg.

Test med skjermleser uten å se på skjermen

En skjermlesertest avdekker om den visuelle strukturen også finnes i koden. Det er ikke nok at etiketten står ved siden av feltet. Skjermleseren må kunne formidle feltets navn, type, status, instruksjon og eventuelle feil.

Gå gjennom skjemaet med skjermen avslått eller tildekket. Lytt etter om hvert felt gir mening uten visuell sammenheng. Et felt som bare leses opp som redigeringsfelt, obligatorisk, mangler sannsynligvis et tilgjengelig navn.

Kontroller særlig at:

• Overskrifter beskriver delene av skjemaet.
• Grupper med alternativer har et felles spørsmål.
• Obligatorisk status blir formidlet.
• Hjelpetekst og feilmelding leses sammen med riktig felt.
• Endringer etter innsending blir kunngjort.
• Bekreftelsen forklarer hva som er registrert og hva som skjer videre.

Ikke forsøk å reparere mangelfull HTML med mange tekniske attributter. Start med riktige standardelementer og riktig struktur. Spesialbygde felt, nedtrekkslister og datovelgere krever mer utvikling og grundigere testing enn nettleserens vanlige skjemakontroller.

Prøv forstørrelse og smal visning

Brukere kan forstørre innholdet kraftig eller øke tekststørrelsen uten å endre resten av grensesnittet. Da må etiketter, felt og knapper fortsatt være lesbare og mulige å bruke.

Test skjemaet i en smal visning og med betydelig forstørrelse. Se etter tekst som kuttes, felt som havner utenfor skjermen, knapper som dekker innhold, og behov for vannrett rulling. To kolonner kan fungere på en stor skjerm, men bør ofte bli én kolonne når plassen blir begrenset.

Pass også på at zoom ikke skjuler feilmeldinger bak en fast topp eller et samtykkefelt. Skjemaet må tåle større tekst uten at informasjon eller funksjonalitet forsvinner.

Avslutt med en bekreftelse som faktisk bekrefter

Et skjema er ikke ferdig testet når sendeknappen kan aktiveres. Brukeren trenger et tydelig svar på om innsendingen lyktes.

Bekreftelsen bør være synlig, forståelig og tilgjengelig for skjermlesere. Skriv hva som er mottatt, forventet videre behandling og hva brukeren bør gjøre hvis det haster. Unngå en kort melding som bare sier Takk.

For transaksjoner med større konsekvenser bør brukeren kunne kontrollere opplysningene før endelig innsending. Det gjelder særlig kjøp, avtaler, søknader og andre handlinger som kan være vanskelige å reversere.

Gjør funnene mulige å prioritere

Registrer hvert funn med skjermbilde, trinn for å gjenskape problemet, berørte brukere og forventet løsning. Prioriter først hindringer som stopper oppgaven: sendeknapper som ikke kan nås, felt uten navn, feil som ikke formidles, eller innhold som forsvinner ved forstørrelse.

Deretter kan dere rette problemer som skaper unødvendig friksjon, som uklare etiketter, svak kontrast og lite presise instruksjoner. Knytt hvert funn til en ansvarlig rolle. Noe må løses i designet, noe i teksten og noe i kode eller skjemaløsningen.

Gjenta hele oppgaven etter retting. En teknisk endring kan påvirke fokusrekkefølge, visning eller skjermleseropplevelse andre steder. Legg de viktigste kontrollene inn i akseptansekriteriene for nye skjemaer, slik at samme feil ikke bygges på nytt.

En skjemarevisjon gir et avgrenset og målbart utgangspunkt for WCAG-arbeidet. Samtidig tester den det som betyr mest: om mennesker med ulike forutsetninger faktisk kan gjennomføre en viktig henvendelse på egen hånd.