Validering i formulär
Validering ska hjälpa våra användare att fylla i formulär rätt. Syftet är att ge tydlig återkoppling vid fel och samtidigt underlätta för användaren att rätta till dessa.
När och hur ska vi validera?
För att undvika att användaren blir överväldigad av felmeddelanden krävs att vi har en balans mellan att ge snabb återkoppling och att låta användaren jobba ostört. Vissa fält ska ge omedelbar återkoppling när användaren lämnar dem, medan andra bara ska valideras efter att formuläret skickats.
Fält som är obligatoriska men inte kan valideras mot format
Fält som användaren måste fylla i men inte har ett bestämt format eller regel valideras efter att användaren försökt skicka in formuläret. Att validera dessa fält när användaren lämnar dem här riskerar att ge onödig stress och distraktion.
Exempel: Namn, fritextfält
Fält med validerbart format eller regel
Fält där vi har ett bestämt format eller regel valideras när användaren lämnat fältet. Eftersom det går att avgöra direkt om värdet är ogiltigt kan snabb återkoppling ges, vilket sparar tid för användaren och förhindrar fel längre fram. När användaren har rättat felet så återgår fältet till ursprungsläget och har inte längre något felmeddelande.
Exempel: e-postadress, telefonnummer, organisationsnummer/personnummer och postnummer
Fält som kräver kontroll mot databas eller extern källa
Fält som kontrolleras mot databas eller extern källa valideras efter att användaren lämnat fältet. Visa en spinner om systemet behöver ladda.
Exempel: Kontrollera om kortnummer är giltigt
Återkoppling
Felmeddelande
Alla inmatningskomponenter har ett felmeddelande som kan visas vid valideringsfel. Felmeddelandet kan visas antingen ovanför eller under inmatningsfältet. Som standard visas felmeddelandet ovanför fältet, vilket också är det som rekommenderas eftersom det ger en logisk läsordning.
Riktlinjer för felmeddelandet
- Försök så långt det är möjligt att beskriva vad användaren ska göra för att det ska bli rätt. Undvik att skriva generella felmeddelanden som ”fel format”.
- Undvik teknisk jargong och använd ett språk som användare förstår och känner igen.
- Använd en positiv och en inte dömande ton, undvik att skylla på eller antyda att användaren har gjort fel. Undvik till exempel ord som ogiltigt, otillåtet eller felaktigt.
- Använd samma ord i felmeddelandet som i övriga användargränssnittet.
Felmeddelandelista
I tjänster som primärt består av formulär som användaren ska fylla i, t.ex. e-ansökningar, ska det utöver felmeddelande på varje kontroll även visas en Felmeddelandelista ovanför formuläret. Felmeddelandelistan är inte någon egen komponent utan består av en Infobanner med ankarlänkar till de komponenter som behöver rättas till.
I exemplet är båda fälten obligatoriska men valideras först när användaren försöker skicka in formuläret. När det finns valideringsfel visas Felmeddelandelistan.
const [validationErrors, setValidationErrors] = useState({})
<Form
validationErrors={validationErrors}
onSubmit={e => {
e.preventDefault()
// Beräkna fel och uppdatera state — hur detta görs beror på formulärbibliotek
setValidationErrors(errs)
if (Object.keys(errs).length === 0) {
// Hantera lyckad inskickning
}
}}
>
{/* href måste matcha id på respektive fält */}
{Object.keys(validationErrors).length > 0 && (
<InfoBanner type='warning' title='Justera dessa fält'>
<ul>
{Object.entries(validationErrors).map(([field, msg]) => (
<li key={field}><Link href={`#${field}`}>{msg}</Link></li>
))}
</ul>
</InfoBanner>
)}
<TextField id='name' name='name' label='Namn' />
<TextField id='email' name='email' label='Mejladress' />
<Button type='submit'>Skicka</Button>
</Form>