Hopp til innhold

Skjemadesign

Skjemaer er viktige i Fremtinds løsninger og vi ønsker at de skal være konsekvente. Her finner du noen regler for skjemaoppsett og hvordan vi bruker skjemakomponentene.

Skjemaseksjoner

I Jøkul har vi flere skjemakomponenter. En eller flere skjemakomponenter sammen, utgjør en skjemaseksjon, og et skjema kan bestå av en eller flere seksjoner.

Hvem er eier av forsikringen?

Kjønn
Stilling
Er klient

Hver skjemakomponent har en ledetekst. Det kan være en overskrift med et spørsmål, et ord eller en setning, som sier noe om hva vi ønsker at brukeren skal oppgi eller gjøre. Deretter er det selve komponenten som brukeren skal gjøre noe med, og eventuelt en hjelpetekst eller melding.

Forsikringseier

Hjelpetekst eller feilmeldingstekst

Vi avgrenser seksjoner tydelig fra hverandre. Hvis seksjonene ligger på en felles bakgrunn, bruker vi luft til å vise dette skillet. Ellers kan vi ramme dem inn i egne kort. Hvis det er nødvendig, kan vi ha en overskrift på hver seksjon.

De interne løsningene vi lager, kan ha mer kompakte skjemakomponenter. Det kan være nyttig hvis det er viktig å komprimere informasjonen vi gir i et skjermbilde, men hovedregelen er at vi skal følge prinsippene for skjemaoppsett.

Hvilken størrelse skal ledetekstene ha i et dynamisk skjema?

I et dynamisk skjema kommer underordnede spørsmål frem når brukeren har tatt stilling til ett eller flere steg i skjemaet. Velg størrelse på ledeteksten ut fra det brukeren ser i standardmodus. Det vil si at hvis en seksjon starter med bare ett spørsmål, velger du stor ledetekst, mens spørsmålene som dukker opp når du har svart på dette ene spørsmålet, får normal ledetekst. Svar på ett spørsmål kan også starte en ny skjemaseksjon.

Skjemavalidering

Det er vanskelig å komme med en ferdig mal for validering som fungerer for alle skjema i alle sammenhenger. Det som beskrives her er en anbefaling og et godt utgangspunkt. Om du opplever at deler av anbefalingen ikke fungerer godt for deg er det helt lov å gjøre noe annet.

Som hovedregel følger vi i stor grad det funksjonelle i uutilsynets løsningsforslag for skjema. Vi beskriver noen av disse temaene i vår egen oppslagsguide for universell utforming også.

Kort fortalt:

  • Vi validerer skjemaet for første gang når brukeren prøver å sende inn skjemaet eller det gjeldende steget
  • Hvert skjemafelt merkes med statusfargen vår for feil og får en beskrivende feilmelding
  • Vi lister også alle feilmeldingene i skjemaet i en FormErrorMessageBox i starten av skjemaet
  • Vi scroller opp til denne listen automatisk og flytter tastaturfokus til første skjemafelt
  • Når brukeren retter feilen skjuler vi feilmeldingen med én gang begge steder, og går tilbake til standard farge
  • Når alle feil er rettet fjerner vi oppsummeringen fra starten av skjemaet

Valider skjemaet ved forsøk på innsending

Mange skjemaer er delt inn i flere sider eller steg, mens andre er korte nok til at alt er på samme side. Om et skjema har flere steg skal hvert steg valideres for seg selv. Et steg må være uten feil for at brukeren skal kunne gå videre til neste steg.

Vi viser ingen valideringsfeil før brukeren har prøvd å trykke seg videre i skjemaet.

Et unntak gjøres dersom et valg gjort i skjemaet gjør at vi vet at brukeren ikke får lov til å gå videre i flyten. I disse tilfellene viser vi en InfoMessageBox under skjemafeltet som forklarer hvorfor brukeren ikke trenger fortsette med utfyllingen av skjemaet, og hva neste steg er for dem. Beskjeden dukker opp med en gang valget er gjort så brukeren slipper fylle ut unødvendig informasjon.

Liste med feilene i skjemaet

Et skjema kan ofte ha flere feil, og noen ganger feil som er knyttet til hverandre, gjerne kalt kryssvalidering. For å gi brukeren en oversikt over feilene lister vi opp samtlige feil i en ErrorMessageBox som vises over skjemaet (se FormErrorMessageBox for en variant med ferdige animasjoner).

Innholdet i denne meldingsboksen skal være selve feilmeldingene. Det holder ikke å liste ledeteksten til skjemafeltene det gjelder. Innholdet blir lest opp av skjermlesere.

Vi scroller automatisk opp så toppen av meldingsboksen er synlig for brukeren. Første inputfelt under oppsummeringen får tastaturfokus, sånn at tastaturbrukere enklere kan komme i gang med rettingen av feil.

Feilmeldinger under skjemafelt

Om et skjemafelt har feil viser vi en feilmeldingstekst under feltet. Vi har valgt at valideringsteksten skal erstatte hjelpeteksten. Derfor er det veldig viktig at feilmeldingen også tar med seg informasjonen fra hjelpeteksten, i tillegg til å forklare hva som er feil.

Du må fylle ut fødselsnummer, 11 siffer

Riktig

Feilmeldingen inkluderer hjelpeteksten.

Fødselsnummeret er feil

Feil

Feilmeldingen mangler hjelpeteksten.

Retting av feil

Feilmeldingene forsvinner og skjemaet går tilbake til vanlig farge med én gang feilen er rettet. Brukeren skal ikke trenge å gå videre til neste skjemafelt for at statusen skal oppdateres.

Vi fjerner feilmeldingen fra oppsummeringen på samme måte som for skjemafeltet. Den forsvinner med én gang feilen er rettet. Når siste feil er rettet skjuler vi selve meldingsboksen.

Vertikal bevegelse

Siden høyden på oppsummeringen av feil endrer seg underveis er det en fare for at scrollposisjonen til brukeren endres.

Moderne nettlesere har støtte for CSS Scroll Anchoring uten at vi trenger å foreta oss noe, med unntak av Safari som ikke har støtte i skrivende stund. Dette er en del av CSS-spesifikasjonen, så Safari kommer til å få støtte på sikt.

Det vil uansett kunne bli noe vertikal bevegelse når vi fjerner feilmeldingene fra skjemafeltene, dersom det ikke er noen hjelpetekst til vanlig.

Eksempel på skjemavalidering

Det er mange detaljer her, og mye å sette seg inn i. Et bilde sier mer enn tusen ord, og et interaktivt eksempel sier enda mer enn det!

Gå til eksempelet