Formularer

Inline-validering

Inline-validering giver feedback på formularfelter, mens brugeren udfylder dem — typisk når et felt forlades — i stedet for at samle alle fejl til indsendelse. Gjort rigtigt er det et af de bedst dokumenterede greb i formular-UX. Gjort forkert skader det.

5 min læsning

Definition

Inline-validering giver feedback på et felt, når brugeren forlader eller udfylder det — ofte med en grøn/rød markør og en kort forklaring.

Hvorfor det virker

I Luke Wroblewskis test med Etre præsterede den bedste inline-validerede formular markant bedre end præcis samme formular valideret først ved indsendelse: 22% højere succesrate, 22% færre fejl, 31% højere tilfredshed, 42% kortere udfyldningstid og 47% færre øjenfikseringer.¹

Men timingen er afgørende. Baymards test viser, at for tidlig, aggressiv validering skader oplevelsen: brugerne får at vide, at deres input er forkert, før de overhovedet har haft chancen for at taste det færdigt.²

Fejl, der vises klart og tæt på det felt, de hører til, reducerer belastningen af arbejdshukommelsen — brugeren kan læse fejlen samtidig med, at den rettes.³

Hvornår du bruger det — og hvornår ikke

Hvornår du bruger det

Felter har regler, der er nemme at bryde (email, kodeord, CPR).
Fejl tidligt sparer brugeren for at rette hele formularen bagefter.
Feedbacken kan gives roligt uden at blinke ved hvert tastetryk.

Hvornår du bør undgå det

Validering først giver mening, når flere felter ses samlet.
Reglerne er så trivielle, at feedback blot støjer.

Best practices

Validér når feltet forlades — ikke ved hvert tastetryk
Tjek som udgangspunkt et felt, når brugeren forlader det (on blur), så du ikke flager input, de stadig er ved at skrive.²
»Beløn tidligt, straf sent«
Er et felt allerede i fejltilstand, så opdatér valideringen live ved hvert tastetryk og fjern fejlen i det øjeblik, input bliver gyldigt. Giver øjeblikkelig positiv feedback under rettelsen uden at afbryde aktiv skrivning.²⁶
Brug positiv bekræftelse — sparsomt
Bekræft korrekte felter, hvor validering reelt hjælper (adgangskode, brugernavn, kontonummer). Undgå grønne flueben på trivielle felter som navn — det forvirrer om, hvad »gyldig« betyder.¹
Skriv klare, specifikke og høflige fejlbeskeder
Fortæl, hvordan fejlen rettes — »Indtast din adresse«, ikke »Feltet er tomt«. Beskeder skal være præcise, menneskelige og give konstruktiv vejledning.³
Placér beskeden ved det felt, der fejler
Hold fejlen op ad feltet, så brugeren kan se beskeden, mens fejlen rettes. Det minimerer belastningen af arbejdshukommelsen.³
Signalér aldrig med farve alene
Kombinér farve med et ikon og en tekstbesked, så farveblinde brugere også får signalet.³
Lev op til WCAG
Identificér fejl i tekst (SC 3.3.1, niveau A), og foreslå en rettelse, når den kendes (SC 3.3.3, niveau AA). Giv desuden labels og format-instruktioner på forhånd, så fejl undgås fra start.⁴⁵

Typiske fejl

Validér for tidligt og for aggressivt
At flage et felt som forkert, før brugeren er færdig med at taste (fx fra første tegn), frustrerer og forvirrer.
Efterlad en forældet fejl
Fjern fejlen i det øjeblik input bliver gyldigt. En besked, der bliver hængende efter rettelsen, får brugeren til at tro, at rettelsen mislykkedes.
Vag eller bebrejdende fejltekst
»Ugyldigt input« i stedet for en specifik, høflig anvisning på, hvordan fejlen rettes.
Farve-kun signalering
Rød/grøn uden ikon eller tekst er usynligt for farveblinde og falder igennem WCAG.
Grønne flueben på trivielle felter
Positiv validering på felter, systemet ikke reelt kan verificere (fx navn), skaber tvivl om, hvad »gyldig« betyder.

Eksempler i praksis

Adgangskode-styrke i realtid

Løbende feedback på password-feltet, mens der skrives, er et klassisk, ofte fremhævet eksempel på nyttig inline-validering — feedbacken hjælper genuint brugeren fremad.

GOV.UK Design System

Ofte fremhævet som en tilgængeligheds-first tilgang: fleksible input-formater og tydelige, inline fejlbeskeder tæt på feltet.

Ofte stillede spørgsmål

Hvad er inline-validering?

Det er, når formularfelter valideres løbende — typisk når brugeren forlader et felt — så fejl vises med det samme i stedet for først ved indsendelse.

Skal man validere på hvert tastetryk eller når feltet forlades?

Validér som udgangspunkt, når feltet forlades (on blur). Er feltet allerede i fejltilstand, opdateres valideringen live ved hvert tastetryk, og fejlen fjernes, så snart input bliver gyldigt — »beløn tidligt, straf sent«.

Er inline-validering dokumenteret?

Ja. Wroblewski og Etres bedste testformular viste 22% højere succesrate, 22% færre fejl, 31% højere tilfredshed, 42% kortere udfyldningstid og 47% færre øjenfikseringer.

Kan inline-validering skade brugeroplevelsen?

Ja — hvis den er for tidlig eller for aggressiv. Baymard og NN/g fandt, at fejl, der vises, før brugeren er færdig med feltet, frustrerer og forvirrer.

Bør man vise grønne flueben på korrekte felter?

Kun på felter, hvor validering reelt hjælper (fx adgangskode eller brugernavn). På trivielle felter som navn skaber flueben forvirring om, hvad »gyldig« betyder.

Hvad kræver WCAG af fejlhåndtering?

At fejl identificeres i tekst (3.3.1, niveau A), at der gives labels og instruktioner (3.3.2, niveau A), og at der foreslås en rettelse, når den kendes (3.3.3, niveau AA). Signalér aldrig fejl med farve alene.