Innledning

Dette mønsteret beskriver hvordan skjemavalidering bør gjøres for å gi en best mulig opplevelse for brukeren. Mønsteret dekker ikke hvordan validering bør implementeres rent teknisk eller hvordan du håndterer sikkerheten, selv om du kan finne litt inspirasjon til dette i demoene.

Demo

Generelt

Første validering skal gjøres når brukeren prøver å gå til neste steg. Hvis det da oppdages feil skal det vises en feilmelding ved feltene det gjelder og komponenten ErrorSummary skal brukes for å oppsummere alle feilene. Feilmeldingen må gi informasjon om hvordan brukeren kan rette feilen. Mer om feilmeldinger.

Etter at brukeren har prøvd å gå til neste steg, bør feltene valideres litt oftere. For felter der man skriver inn verdien (f.eks. fritekst eller dato) bør validering skje når feltet mister fokus (onBlur). For felter der man velger verdien (f.eks. sjekkbokser eller Combobox), bør validering skje når en verdi velges (onToggleSelected i Combobox, ellersonChange). Husk å holde ErrorSummary i synk med feilmeldingene i hvert enkelt felt.

ErrorSummary trenger ikke brukes hvis det aldri er mer enn ett skjemafelt på siden. I så fall er det feltet som skal få fokus ved feil.

Les mer om hvordan ErrorSummary skal brukes.

Skjemafelter

Så langt det lar seg gjøre skal det brukes Aksel-komponenter i skjemaet. Dette sikrer at mange krav og retningslinjer dekkes automatisk. Feilmeldinger sendes inn i propen error som da viser feilen og den kodes opp på riktig måte.

Les mer om krav til utforming av feilmeldinger.

Reduser sjansen for feil

Reduser sjansen for at feil oppstår i utgangspunktet ved å

Underskjemaer

Et underskjema (eller nestet skjema) er et lite skjema inne i skjemaet. Det vises ofte i et panel eller en modal, og brukes for å legge til informasjon om noe det kan være flere av, for eksempel barn.

Hvis underskjemaet vises i en modal, bør modalen oppføre seg som om det var et eget steg i søknadsdialogen. Det vil si at første validering bør gjøres når man prøver å gå videre (typisk primærknapp med tekst "Lagre" eller "Legg til") og ErrorSummary bør brukes. Man bør ikke få lov til å gå videre før alle feil er rettet.

Hvis underskjemaet vises i et panel gir det ikke mening å bruke en egen ErrorSummary i panelet, men behandle feltene i underskjemaet omtrent på samme måte som feltene i hovedskjemaet. Husk å nevne i ErrorSummary hvilken instans feilen gjelder (f.eks. "Navn på barn 1 må fylles ut").

Unngå

Sjekkliste

FAQ

Kan jeg bruke role eller aria-live på ErrorSummary?

Bruk av aria-live eller role="alert" gjør at skjermlesere automatisk leser opp innholdet når det endrer seg. Dette kan bli overveldende siden ErrorSummary potensielt kan inneholde mange feilmeldinger. Vi anbefaler heller å flytte fokus til komponenten som forklart over, men du bør iallfall ikke gjøre begge deler.

Hvorfor ikke validere på onBlur fra start?

Dette er for at brukeren skal kunne jobbe i skjemaet i fred og ro, uten å bli distrahert av potensielt overflødige feilmeldinger. Hvis du likevel velger å validere på onBlur fra start, er det viktig at du ikke viser noen feilmelding før brukeren har jobbet i feltet. Noen utforsker skjemaer før de starter å fylle dem ut ved å tabbe gjennom alle feltene, og mange fyller ut skjemaer ved å starte med feltene som er lettest å fylle ut.

Hva med validering mens man skriver?

Vi fraråder å validere mens brukeren skriver i feltet. Dette er fordi det kan være forstyrrende med feilmeldinger som dukker opp og endrer seg mens man skriver, samt irriterende å få feilmeldinger som bare skyldes at du ikke er ferdig med å skrive. Dette er vil kunne være spesielt ille for skjermleserbrukere.

Det eneste tilfellet det kan være greit å vise en feilmelding mens man skriver, er dersom du er helt sikker på at brukeren er i ferd med å skrive inn en ugyldig verdi. Dette kan for eksempel være hvis brukeren begynner å skrive inn bokstaver i et felt for personnummer, eller har skrevet inn for mange tegn.

Så validering onBlur, men etter submit, er den perfekte løsningen?

Validering onBlur har også sine ulemper. For eksempel får man en layout shift når en feilmelding vises eller skjules. Hvis brukeren prøver å trykke på noe mens et felt er i fokus, kan layout shift føre til at brukeren bommer på knappen.

Alternativt kunne man holdt seg til validering kun på submit, men da blir det vanskeligere å holde oversikt over hvilke felt som er rettet og ikke (hvis det er flere felt med feil).