|
1 |
| -import { Figma } from 'mdx-embed'; |
2 |
| - |
| 1 | +import { Meta, Image } from '@components'; |
3 | 2 | import { MenuPageLayout } from '@layouts';
|
4 |
| -import { Meta } from '@components'; |
5 | 3 |
|
6 | 4 | <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.' |
9 | 7 | />
|
10 | 8 |
|
11 | 9 | export default ({ children }) => (
|
12 | 10 | <MenuPageLayout
|
13 | 11 | content={children}
|
14 | 12 | data={{
|
15 |
| - title: 'Validering og feilmeldinger', |
16 |
| - date: '5. april 2023', |
| 13 | + title: 'Feilmeldinger i skjema', |
| 14 | + date: '12. januar 2024', |
17 | 15 | }}
|
18 | 16 | />
|
19 | 17 | );
|
20 | 18 |
|
21 |
| -Mønsteret er under arbeid og krever mer innsikt og samarbeid på tvers. Sitter du på 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 på 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. |
22 | 20 |
|
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. |
24 | 22 |
|
25 |
| -Feilmeldinger forklarer brukeren hva som gikk galt og hvordan det kan rettes opp i. |
| 23 | +Vi har ulike typer feilmeldinger |
26 | 24 |
|
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. |
28 | 27 |
|
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. |
34 | 29 |
|
35 |
| -### Formulering av feilmeldinger |
| 30 | +## Detaljerte feilmeldinger |
36 | 31 |
|
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 på hva som er feil. Gi så 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 på siden så nært feilen som mulig. Pass på at du kobler den til feltet med `aria-describedby`. |
38 | 33 |
|
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. |
40 | 52 |
|
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). |
45 | 54 |
|
46 |
| -### Eksempel på feilmelding relatert til avkrysningsbokser |
| 55 | +## Oppsummerende feilmeldinger |
47 | 56 |
|
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). |
49 | 58 |
|
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} |
53 | 63 | />
|
54 | 64 |
|
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. |
56 | 66 |
|
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/> |
58 | 92 |
|
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/) |
0 commit comments