Skip to content

Commit 194b5af

Browse files
IldestmimarzmrosvikBarsnes
authored
docs: article about error messages (#1188)
Co-authored-by: Michael Marszalek <mimarz@gmail.com> Co-authored-by: Marianne Røsvik <marianne.rosvik@digdir.no> Co-authored-by: Tobias Barsnes <tobias.barsnes@digdir.no>
1 parent 33c693b commit 194b5af

File tree

3 files changed

+81
-34
lines changed

3 files changed

+81
-34
lines changed
Original file line numberDiff line numberDiff line change
@@ -1,62 +1,109 @@
1-
import { Figma } from 'mdx-embed';
2-
1+
import { Meta, Image } from '@components';
32
import { MenuPageLayout } from '@layouts';
4-
import { Meta } from '@components';
53

64
<Meta
7-
title='Validering og feilmeldinger'
8-
description='Slik forteller du brukeren at noe har gått galt eller mangler.'
5+
title='Feilmeldinger i skjema'
6+
description='Slik forteller du brukeren at noe har gått galt eller mangler i et skjema.'
97
/>
108

119
export default ({ children }) => (
1210
<MenuPageLayout
1311
content={children}
1412
data={{
15-
title: 'Validering og feilmeldinger',
16-
date: '5. april 2023',
13+
title: 'Feilmeldinger i skjema',
14+
date: '12. januar 2024',
1715
}}
1816
/>
1917
);
2018

21-
Mønsteret er under arbeid og krever mer innsikt og samarbeid på tvers. Sitter du innsikt som er relevant for validering og feilmeldinger? [Ta kontakt](mailto:designsystem@digdir.no) så kan vi dele innsikt og diskutere dette mønsteret sammen!
19+
Det er best om vi klarer å hindre at det oppstår feil. Da må vi forhånd oppgi tydelig hva brukeren må gjøre for å fylle ut feltene i skjemaet riktig. Vi må godta ulik formatering, for eksempel på felt med tall, som i telefonnummer eller datoer. Brukerne må alltid få mulighet til å redigere felter eller gå tilbake, og kunne pause utfyllingen eller avbryte.
2220

23-
## Feilmeldinger
21+
Når det likevel har oppstått et problem som gjør at brukeren ikke kommer videre, skal vi vise en feilmelding som beskriver problemet og forklarer hva brukerne må gjøre.
2422

25-
Feilmeldinger forklarer brukeren hva som gikk galt og hvordan det kan rettes opp i.
23+
Vi har ulike typer feilmeldinger
2624

27-
Disse retningslinjene bør følges:
25+
- [Detaljerte feilmeldinger](#detaljerte-feilmeldinger), som tilhører et bestemt felt i et skjema.
26+
- [Oppsummerende feilmeldinger](#oppsummerende-feilmeldinger), som kan vise en eller flere feilmeldinger.
2827

29-
- Kravene for å fylle ut feltene riktig skal tydelig fremgå på forhånd uten at brukeren trenger å få noen feilmeldinger fra valideringen for å forstå dette.
30-
- Felt(ene) som er feil skal være lette å finne. Feilmeldingen bør plasseres i nærheten av feltet som er feil, og koblet til feltet ved hjelp av `aria-describedby`.
31-
- Feilmeldingen skal være lett å legge merke til og forstå. Bruk rød farge, grafiske midler, `aria-invalid` og forklarende tekst.
32-
- Brukere skal ikke måtte huske instruksjonene for å fikse feilen.
33-
- Dersom et skjema har feil når brukeren forsøker å gå videre, bør en oppsummering vise alle feilene og lenke til feltene som har feil. Feilene skal forsvinne fra oppsummeringen etterhvert som de blir utbedret.
28+
For andre type feil som ikke tilhører et skjemaelement, og som ikke validerer brukerens inndata, kan du bruke [`alert`](/docs/felles-alert--docs)-komponenten. Det kan for eksempel være for systemfeil, eller til myke valideringer. Myke valideringer er meldinger som ikke stopper brukeren fra å sende inn eller gå videre til neste steg i prosessen, men som bare gir brukeren informasjon.
3429

35-
### Formulering av feilmeldinger
30+
## Detaljerte feilmeldinger
3631

37-
Vær kort og tydelig i formuleringen av feilmeldingene og sørg for at brukeren vet hva som må gjøres for å komme videre. Å skrive “Feltet er ikke fyllt ut korrekt”, gir ikke brukeren en forklaring hva som er feil. Gi spesifikk informasjon som mulig om hva problemet er og gjenta gjerne nøkkelord fra label. Foreslå evt. korrigeringer, f.eks. ved ugyldige tegn eller feilstavinger.
32+
Plasser feilmeldinger som tilhører et bestemt felt siden nært feilen som mulig. Pass på at du kobler den til feltet med `aria-describedby`.
3833

39-
Eksempel på forklarende feilmeldinger:<br/>
34+
Feltet skal tydelig vise at noe er feil. Dette gjør vi med rød farge, [forklarende tekst](#tekst-i-feilmeldinger) og `aria-invalid`. Plasser teksten som viser hva som er feil og hva brukeren må gjøre, rett under selve feltet der feilen er.
35+
36+
<Image
37+
src='/img/errormessage-1.png'
38+
alt='Skjermbilde av skjema med en feilmelding. Brukeren har skrevet "fdgdfgfdg" inn i et felt for fødselsnummer. Feilmeldingen sier at Fødselsnummer skal inneholde 11 siffer.'
39+
boxShadow={false}
40+
/>
41+
42+
### Når skal feilmeldinger presenteres for brukeren?
43+
44+
Vi kan presentere feilmeldinger for brukerne enten når
45+
46+
- Brukeren forlater feltet
47+
- Brukeren trykker "Gå videre" eller "Send inn"
48+
49+
Vi skal ikke vise feilmeldinger mens brukeren fyller ut feltet. Mange bruker nemlig tastatur til å navigere i skjemaet. De vil ikke nødvendigvis starte på toppen og jobbe seg nedover og derfor vil det forstyrre hvis det dukker opp feilmeldinger på felter brukeren ikke har fylt ut enda.
50+
51+
Hvis vi har feilmeldinger som skal vises når brukeren forlater feltet, må vi kode det slik at vi vet om brukeren faktisk har skrevet noe i feltet før vi viser feilmeldingen. Det tryggeste er å vise feilmeldingen når brukeren selv er klar til å gå videre.
4052

41-
- “Postnummer må ha 4 siffer”
42-
- "Fødselsnummer må bestå av fødselsdato (6 siffer) og personnummer (5 siffer)"
43-
- “Du må velge minst ett av leveringsalternativene”
44-
- “For å sende inn skjemaet må du bekrefte at navnet er korrekt ved å huke av i avkrysningsboksen”
53+
Det kan være irriterende for brukerne hvis feilmeldingen vises når de forlater feltet. Brukerne bør først få en feilmelding for et obligatorisk felt når de prøver å gå til neste side eller sende inn skjemaet. Vis tydelig at et felt må fylles ut. Her kan du lese mer om hvordan du markerer [obligatoriske og valgfrie skjemafelt](/monstre/obligatoriske-og-valgfrie-felt).
4554

46-
### Eksempel på feilmelding relatert til avkrysningsbokser
55+
## Oppsummerende feilmeldinger
4756

48-
I dette eksempelet har brukeren forsøkt å trykke “Neste” uten å svart på obligatoriske spørsmål. Den røde boksen i bunnen viser kun når “Neste” er forsøkt klikket på.
57+
I noen tilfeller bør vi oppsummere alle feil øverst på siden eller like over "Gå videre" / "Send inn"-knappen. Oppsummeringen kan gjelde for én eller flere feil. Teksten i en oppsummerende feilmelding skal være lik det du ser i den detaljerte feilen (se eksempelet under).
4958

50-
<Figma
51-
title='Boop'
52-
url='file/vpM9dqqQPHqU6ogfKp5tlr/Felles-komponenter?type=design&node-id=17866%3A57910&mode=design&t=3hD9xEYGKMGecg7Q-1'
59+
<Image
60+
src='/img/errormessage-2.png'
61+
alt='Skjermbilde av skjema der to av seks felter har feilmeldinger. I bunnen, like over "Gå videre" vises det en oppsummeringsboks med de to feilmeldingene som lenker til de feltene som har feil. '
62+
boxShadow={false}
5363
/>
5464

55-
### Plassering av feilmelding
65+
Den løsningen eller tjenesten du lager, bestemmer om du bør plassere oppsummeringen øverst på siden eller lenger nede, før knappen som tar brukerne videre. Se eksempelet over. Det viktigste er at brukeren lett ser oppsummeringen.
5666

57-
Ved feil i besvarelser skal feilmelding komme så raskt som mulig, men ikke før feltet forlates. Det aktuelle svarfeltet skal markeres, og brukeren skal få hjelp til å løse problemet. Brukeren skal ha adgang til å gå videre uten å rette feilen, der det er mulig. Hvis en feil skyldes kryssvalidering mellom felter skal dette forklares, begge felter skal merkes, og hvis feilen ligger på ulike skjemasider skal det lenkes til det andre feltet. I skjema som er lange, eller har flere trinn, skal feil som gjenstår på slutten vises som en liste med lenker til aktuelle felt.<br/> [Elmer 3 - 4.3](https://brukskvalitet.brreg.no/elmer3/)
67+
Pass på at
68+
69+
- oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet
70+
- brukerne kan gå direkte til feilene de må rette og at fokuset blir flyttet dit
71+
- lenkene i oppsummeringen stemmer med feilmeldingen de lenker til
72+
- du skriver feilmeldingen slik at den er lett å forstå, at den gir mening for brukerne når de kun leser feilmeldingen i oppsummeringen
73+
- hvis det er flere feil, så lenker du til den første feilen i rekken
74+
- feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem
75+
76+
## Ikke deaktiver submit-knappen
77+
78+
Vi bruker ikke deaktivert "Gå videre"/"Send inn"-knapp til å validere skjema. Noen brukere forstår ikke hvorfor knappen er deaktivert og kan bli forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukeren prøver å velge knappen mens det er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over "Gå videre"/"Send inn"-knappen.
79+
80+
## Tekst i feilmeldinger
81+
82+
Den viktigste jobben til teksten i en feilmelding er å hjelpe brukerne videre:
83+
84+
- Tenk på målgruppen og skriv vennlig, klart og tydelig. Unngå passivt eller teknisk språk. Meldingen skal være lett å forstå.
85+
- Unngå humor i feilmeldinger. Når folk møter på et problem, vil de heller ha effektive forslag til hvordan de løser det, enn humoristiske «Oops!»
86+
- Vær konkret. Når du skriver “Feltet er ikke fylt ut korrekt”, får ikke brukeren noen forklaring på hva som er feil. Gi konkret informasjon om hva som er problemet og gjenta gjerne nøkkelord fra ledeteksten.
87+
- Noen ganger må vi beskrive hva feilen er før vi beskriver hva brukerne skal gjøre, men det viktigste er å vise løsningen på problemet.
88+
- Tilpass feilmeldingene til ulike situasjoner. Jobben til teksten er å hjelpe brukeren videre.
89+
- Hold feilmeldingen kort, da sparer du brukerne for tid.
90+
91+
Eksempel på forklarende feilmeldinger:<br/>
5892

59-
Øvrige kilder:<br/>
60-
[UU-tilsynet](https://www.uutilsynet.no/veiledning/skjema/38#formidle_feil_i_skjema)<br/>
61-
[NN Group - Error Messages Guidelines](https://www.nngroup.com/articles/error-message-guidelines/)<br/>
62-
[NN Group - How to Report Errors in Forms](https://www.nngroup.com/articles/errors-forms-design-guidelines/)
93+
- “Postnummeret må ha 4 siffer”
94+
- "Fødselsnummeret må ha 11 siffer"
95+
- “Velg minst ett av leveringsalternativene”
96+
- “Kryss av i ruten for å bekrefte at navnet er riktig, før du sender inn skjemaet”
97+
98+
## Kilder
99+
100+
- [Help users to Recover from validation errors, GovUK](https://design-system.service.gov.uk/patterns/validation/)
101+
- [Designing Better Error Messages UX, Smashing Magazine/Vitaly Friedman](https://www.smashingmagazine.com/2022/08/error-messages-ux-design)
102+
- [Formidle feil i skjema, UU-tilsynet](https://www.uutilsynet.no/veiledning/skjema/38#formidle_feil_i_skjema)
103+
- [Use forgiving formatting, NN Group](https://www.nngroup.com/articles/slips/)
104+
- [Error Messages Guidelines, NN Group](https://www.nngroup.com/articles/error-message-guidelines/)
105+
- [How to Report Errors in Forms, NN Group](https://www.nngroup.com/articles/errors-forms-design-guidelines/)
106+
- [Suksesskriterium 3.3.1 Identifikasjon av feil](https://www.w3.org/Translations/WCAG21-no/#error-identification)
107+
- [Suksesskriterium 3.3.3 Forslag ved feil](https://www.w3.org/Translations/WCAG21-no/#error-suggestion)
108+
- [Skjemavalidering, Aksel](https://aksel.nav.no/god-praksis/artikler/skjemavalidering)
109+
- [Fejlmeddelelser, Fælles designsystem](https://designsystem.dk/komponenter/fejlmeddelelser/)
208 KB
Loading
452 KB
Loading

0 commit comments

Comments
 (0)