Kilde: Designsystemet.no Lesetid: 9 minutter

Feilmeldinger kan komme fra systemet eller være utløst av noe brukerne har gjort. Denne artikkelen handler om brukerutløste feilmeldinger i selvbetjeningsløsninger og skjema. Hvordan kan vi unngå å gi feilmeldinger, og hvordan kan vi hjelpe brukerne å komme seg videre når det likevel har oppstått en feil?

Når brukerne har gjort en feil som hindrer dem i å komme videre, skal vi varsle dem om feilen slik at de kan rette opp:

• Beskriv problemet på en lettforståelig måte.
• Forklar hva brukerne må gjøre for å komme videre.
• Passe på at feilmeldingen er lett synlig.

Feilmeldinger kan være knyttet til ett enkelt felt eller til flere. Vi viser en oppsummering av flere feil hvis brukeren forsøker å gå videre uten å ha fylt ut alt.

Feilmeldinger på enkeltfelt

Vi skal kunne vise feilmeldinger sammen med alle typer felt i et skjema. Meldingen skal stå nært feltet som feiler.

Oppsummering av flere feilmeldinger

En oppsummering kan gjelde for én eller flere feil. Hvis brukerne prøver å gå videre uten å ha fylt ut alt, eller de har gjort feil, oppsummerer vi like over Neste/Send inn-knappen.

Vi anbefaler å vise oppsummeringen i nærheten av Neste-knappen for at brukerne skal forstå sammenhengen mellom feilen og hvorfor de blir hindret i å gå videre. I noen tilfeller kan det likevel være bedre å vise oppsummeringen i toppen, for eksempel hvis:

• Den tekniske løsningen laster siden på nytt når brukerne velger Neste.
• Brukerne har vært ute av et skjema og går inn igjen.
• Løsningen ikke stopper brukerne fra å gå til neste side selv om de har feil på en side.

Pass på at:

• Oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet.
• Brukerne kan gå direkte til feilene de må rette opp, og fokuset blir flyttet dit.
• Lenkene i oppsummeringen stemmer med feilmeldingene de lenker til.
• Feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem.
• Feilmeldingen i oppsummeringen har med nøkkelord fra ledeteksten.

Det er best om vi kan unngå å gi feilmeldinger

Når vi planlegger en løsning, bør målet være å hindre at det oppstår feil. Disse punktene kan hjelpe i planleggingen:

• Gi all relevant informasjon før brukerne starter, i klart og tydelig språk.
• Bruk ledetekster og beskrivelser for å hjelpe brukerne underveis.
• Unngå hjelpetekster bak spørsmålstegn om du kan, men bruk dem om nødvendig.
• Gi brukerne mulighet til å endre svar i felt eller gå tilbake.
• La brukerne ta en pause i utfyllingen eller avbryte den.
• Sørg for at feltene godtar ulik formatering, for eksempel for datoer og telefonnummer.
• Legg inn en bestemt rekkefølge på svaralternativene, for å hindre at brukeren tar valg som fører til feil.
• Vis informasjon om maks. antall tegn under ledeteksten hvis feltet har tegnbegrensning.

Ulike typer feilmeldinger

Systemgenererte meldinger

Vi bruker systemmeldinger, eller systemvarsler, for å varsle brukeren om feil i systemet eller gi dem viktig informasjon de bør få med seg. Vi har en egen artikkel om systemvarsler.

Infomeldinger til brukeren

Infomeldinger som vises på grunn av noe brukerne gjør, stopper ikke brukerne fra å sende inn eller gå videre til neste steg.

Vi viser infomeldinger når vi skal informere om konsekvenser av et valg. Slike meldinger kan vi for eksempel presentere i en alert av typen “info” eller “success”. Disse meldingene vises etter at brukeren har oppgitt informasjon i et skjemafelt, og oppfører seg på samme måte som feilmeldinger.

Eksempler:

• Du starter en bedrift og skal registrere navnet. Du får beskjed om at bedriftsnavnet allerede er i bruk av noen andre. Du kan bruke navnet du har valgt, men du kan få problemer med domenenavn eller at foretaket ditt blir forvekslet med et annet.

• Du gjør et valg i et søknadskjema som fører til lengre behandlingstid. Du får en infomelding om lengre ventetid.

Skriv gode feilmeldinger

Den viktigste jobben til en feilmelding er å hjelpe brukerne videre:

• Skriv vennlig, klart og tydelig.
• Hold feilmeldingen så kort som mulig.
• Vær konkret. Hvis vi skriver “Feltet er ikke fylt ut korrekt”, får brukeren ingen forklaring på hva som er feil.
• Gjenta nøkkelord fra ledeteksten/feltnavnet så tidlig som mulig i feilmeldingen.

Noen tekniske løsninger gjør at vi kan ta inn feltnavnet som en variabel i feilmeldinger, da blir feltnavnet i ubestemt form, som i disse eksemplene:

• “Postnummer må ha 4 siffer”
• “Fødselsnummer må ha 11 siffer”
• “Velg minst ett leveringsalternativ”

Hvis løsningen ikke tar inn feltnavnet som variabel i feilmeldinger, anbefaler vi å skrive substantivet med bestemt form: Postnummeret må ha fire siffer.

Design og opplevelse

Utseendet på feilmeldinger

Når det oppstår feil i et felt er det viktig at feltet blir godt synlig, slik at det er lett for brukerne å se hvor de må fylle ut eller rette opp noe.

Når den tekniske løsningen sjekker for feil, det vi kaller validerer, ønsker vi å vise hvilke felt som har feil. Til det kan vi bruke flere virkemidler.

Visuelle endringer

Vis feilmeldingsteksten nært feltet det gjelder. Vi anbefaler å ha med et ikon som en visuell indikator i tillegg til tekst. For skjemakomponenter som tillater det, kan vi også endre tykkelsen på rammen rundt, som vist i eksempelet over.

Fargevalg

Vi bruker rød som varselfarge for feil, det vi si at feltet og selve feilmeldingen blir røde. Dette er et godt etablert mønster, som hjelper med å skille feltet fra andre felt. Feltet må ha 3:1 kontrast til bakgrunnsfargen. Hvis vi også bruker rød tekst til feilmeldingen, må den minst ha kontrasten 4.5:1. Les mer om kontraster hos Tilsynet for universell utforming av IKT.

Plassering

Vi viser feilmeldingen under feltet med feil. Dette er det vanligste mønsteret, selv om det også diskuteres om den skal stå mellom ledeteksten og feltet.

Når skal vi vise en feilmelding?

Vi kan vise feilmeldinger når brukerne forlater feltet, når de velger å gå videre, eller sender inn. Vi unngår å vise feilmeldinger mens brukeren fyller ut et felt.

Når brukerne har gjort en feil når de fyller ut et felt og de går videre, viser vi feilmeldinger når vi kan se at brukeren ikke har fylt ut det vi forventer. Et eksempel kan være at de har lagt inn bokstaver i et fødselsnummer, eller at en e-postadresse mangler krøllalfa (@).

Brukerne bør ikke få feilmelding for et tomt obligatorisk felt før de går til neste side eller sender inn skjemaet. Vi vet ikke alltid når brukeren er ferdig med å fylle ut feltene, så da venter vi til brukeren selv er klar til å gå videre. Det er spesielt viktig når brukere benytter tastaturet til å navigere i løsningen.

Kryssvalidering

Noen ganger vil det brukeren velger i ett eller flere felt påvirke felt som kommer senere i skjemaet. For eksempel kan et valg brukerne gjør i en radiogruppe, gjøre at et frivillig felt lenger ut i skjemaet blir obligatorisk. Et valg på ett sted kan også gjøre at et valg et annet sted må være innenfor en viss verdi. I slike tilfeller snakker vi om kryssvalidering.

Her må vi gjøre det så tydelig som mulig for brukeren at flere felt påvirker hverandre:

• Merk alle feltene visuelt og med feilmelding.
• Forklar hva som utløste feilen. Vær tydelig på at feilen skyldes kryssvalidering.
• Fortell brukerne hva de kan gjøre for å rette feilen.

Ikke deaktiver submit-knappen

Vi bruker ikke deaktivert “Gå videre/Send inn”-knapp til å validere skjema. Noen brukere forstår ikke hvorfor knappen er deaktivert og blir forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukerne prøver å gå videre mens det fortsatt er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over “Gå videre/Send inn”-knappen.

HTML og Aria

For at alle brukere skal oppfatte feilmeldinger, er det viktig med et tydelig forhold mellom feilmeldingene og feltene de tilhører, også for dem som ser på innhold med ulike hjelpemidler.

Vi kan bruke disse aria-attributtene og rollene:

• Vi setter aria-invalid="true" på felt med feil, for å si fra om at det er en feil der.
• Vi bruker aria-describedby for å koble feilmelding til feltet.

Vi kan også gi automatiske beskjeder når vi vil at brukeren så snart som mulig skal få opplest viktig informasjon. Det kan for eksempel være når det blir en stor visuell endring, eller nytt innhold.

For feilmeldinger som dukker opp dynamisk må vi bruke aria-live for at meldingen skal bli lest opp av skjermlesere. Pass godt på om du setter aria-live til å være assertive eller polite. I de fleste tilfeller er det best å bruke polite, for da venter skjermleseren med å lese opp feilmeldingen til den er ferdig med å lese opp innholdet.

Eksempel

<div class="mockup-browser border  bg-base-200 border-base-300 w-full">
  <div class="mockup-browser-toolbar">
    <div class="input">https://design.ntnu.no</div>
  </div>
  <div class="p-4">
    <div class="join join-vertical rounded-box bg-base-100 w-full shadow">
      <div class="border-b-2 border-base-300 p-4 flex items-center justify-between"><span>Søknad om ...</span><span>2 av 4</span></div>
      <div class="p-4">
        <h1 class="text-3xl">Kontaktinformasjon</h1>
        <form class="flex flex-col gap-6">
          <fieldset class="fieldset">
            <legend class="fieldset-legend text-lg">Fødselsdato</legend>
            <p class="label"><span class="bg-warning text-warning-content text-md px-1">Må fylles ut</span></p>
            <input type="date" class="input validator" aria-invalid="true" value="2022-12-22" />
            <p class="validator-hint">Fødselsdato kan ikke være etter år 2005</p>
          </fieldset>
          <fieldset class="fieldset">
            <legend class="fieldset-legend text-lg">Fakturaadresse</legend>
            <p class="label"><span class="bg-warning text-warning-content px-1">Må fylles ut</span></p>
            <label class="label"><input type="radio" name="radio-1" class="radio radio-primary" checked="checked" /> Samme som bostedsadresse</label>
            <label class="label"><input type="radio" name="radio-1" class="radio radio-primary" /> Oppgi annen adresse for faktura</label>
            <label class="label"><input type="radio" name="radio-1" class="radio radio-primary" /> Jeg skal slette eller overdra underenhetene på forskjellige tidspunkt eller til forskjellige eiere.</label>
          </fieldset>
          <fieldset class="fieldset">
            <legend class="fieldset-legend text-lg">Telefonnummer</legend>
            <p class="label"><span class="bg-warning text-warning-content px-1">Må fylles ut</span></p>
            <label class="input validator">
              <svg class="h-[1em] opacity-50" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">
                <g fill="none">
                  <path
                    d="M7.25 11.5C6.83579 11.5 6.5 11.8358 6.5 12.25C6.5 12.6642 6.83579 13 7.25 13H8.75C9.16421 13 9.5 12.6642 9.5 12.25C9.5 11.8358 9.16421 11.5 8.75 11.5H7.25Z"
                    fill="currentColor"
                  ></path>
                  <path
                    fill-rule="evenodd"
                    clip-rule="evenodd"
                    d="M6 1C4.61929 1 3.5 2.11929 3.5 3.5V12.5C3.5 13.8807 4.61929 15 6 15H10C11.3807 15 12.5 13.8807 12.5 12.5V3.5C12.5 2.11929 11.3807 1 10 1H6ZM10 2.5H9.5V3C9.5 3.27614 9.27614 3.5 9 3.5H7C6.72386 3.5 6.5 3.27614 6.5 3V2.5H6C5.44771 2.5 5 2.94772 5 3.5V12.5C5 13.0523 5.44772 13.5 6 13.5H10C10.5523 13.5 11 13.0523 11 12.5V3.5C11 2.94772 10.5523 2.5 10 2.5Z"
                    fill="currentColor"
                  ></path>
                </g>
              </svg>
              <input
                type="tel"
                class="tabular-nums"
                required
                placeholder="Telefonnummer"
                pattern="[0-9]*"
                minlength="8"
                maxlength="8"
                title="Telefonnummeret kan kun inneholde 8 siffer"
              />
            </label>
            <p class="validator-hint">Telefonnummeret kan kun inneholde 8 siffer</p>
          </fieldset>
          <div role="alert" class="alert alert-error">
            <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6 shrink-0 stroke-current" fill="none" viewBox="0 0 24 24">
              <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 14l2-2m0 0l2-2m-2 2l-2-2m2 2l2 2m7-2a9 9 0 11-18 0 9 9 0 0118 0z" />
            </svg>
            <div>
              <p class="text-xl">
                For å gå videre må du rette opp følgende feil:</p>
              <ul>
                <li>Fødselsdato kan ikke være etter år 2005</li>
                <li>Telefonnummer kan kun inneholde siffer</li>
              </ul>
            </div>
          </div>
          <div class="flex gap-2">
            <button class="min-w-[8rem] btn btn-primary btn-outline">Forrige</button>
            <button class="min-w-[8rem] btn btn-primary">Neste</button>
          </div>
        </form>
      </div>
      <div class="border-t-2 border-base-300 p-4 text-center lg:text-left">Avbryt</div>
    </div>
  </div>
</div>