Input wrapper

Retningslinjer for bruk

Labels/etikett

Labels bør være korte, tydelige og plassert slik at de er enkle å oppfatte. Brukeren skal umiddelbart forstå hva som skal fylles ut. Vi anbefaler at du holder deg til 1 til 3 ord i label, unngå kolon og bruk labels konsekvent på tvers av løsningen.

Dersom du må skjule en label visuelt, for eksempel i tabeller, må den fremdeles være programmert inn slik at skjermlesere kan lese den. Det er også viktig å teste at brukeren forstår hva de skal fylle inn i et slikt tilfelle.

Ikke bruk plassholder som eneste instruksjon. Den forsvinner når brukeren skriver, og er ikke alltid tilgjengelig for skjermlesere. Gi heller nødvendig veiledning med en label og/eller hjelpetekst.

Gjør slik

Skriv tydelig og konsise labels

Unngå

Unngå unødvendig innhold og kolon på slutten av label

Merking av valgfrie eller obligatoriske felt

I Punkt bruker vi kun merkingen “Valgfritt” og “Må fylles ut”. Vi anbefaler alltid å unngå stjerne (*) som markering, fordi den kan være uklar for brukerne og vanskelig å oppfatte med hjelpemidler.

Som hovedregel bør du unngå valgfrie felter og bare be om informasjon du faktisk trenger. Når du likevel må ha en kombinasjon, bør feltene merkes konsekvent:

• Hvis alle felter på en side er obligatoriske, kan du utelate merkingen og heller skrive det i hjelpeteksten eller over skjemaet
• Hvis alle felter er valgfrie, markerer du feltene med “Valgfritt”
• Hvis du har en blanding av obligatoriske og valgfrie felter, markerer du hvert felt individuelt med “Må fylles ut” eller “Valgfritt”.

Gjør slik

Bredden til inputfeltet bør gi brukeren en indikasjon på hva som forventes at de fyller inn

Unngå

Unngå for brede eller for smale felt for forventet innhold

Hjelpetekst

Hjelpetekst skal alltid bidra til å avklare, ikke gjenta. Den skal forklare hvordan brukeren skal fylle ut feltet, for eksempel hvilket format som gjelder, eller hvor de finner informasjonen. Hjelpetekst bør plasseres tett ved feltet og være lett å oppdage, ellers blir den oversett. Skriv alltid i setningsstil, og bruk hele setninger når det er mulig. Hjelpeteksten bør plasseres over feltet slik at den ikke kolliderer med feilmeldinger.

Ekspanderende hjelpetekst

Dersom du trenger mer plass, kan du bruke ekspanderende hjelpetekst. Dette gjør det mulig å gi utfyllende forklaringer eller legge inn lenker uten å skape for mye støy for brukeren. Husk at utvidet hjelpetekst skal være et supplement, det viktigste må alltid stå tilgjengelig uten ekstra klikk.

Feilmeldinger og validering

Feilmeldinger skal være konkrete og hjelpe brukeren videre. De bør forklare hva som er galt, og så langt som mulig foreslå hvordan det kan rettes opp.

Feilmeldinger i Punkt kombinerer rød ramme, ikon og tekst. Teksten skal inneholde essensen av hjelpeteksten, slik at brukeren får all nødvendig informasjon samlet.

For å fungere godt må feilmeldinger oppfylle følgende prinsipper:

1. Spesifikk og hjelpsom

Gi klar informasjon om problemet, og foreslå løsning dersom det er mulig, for eksempel riktig format eller korrigering ved feilstavinger.

2. Ikke for tidlig

Unngå å vise feilmeldinger før brukeren har begynt å fylle ut feltet, eller mens hen fortsatt skriver. Vent til brukeren har forlatt feltet eller prøvd å sende inn skjemaet.

3. Feiloppsummering

I skjemaer med flere felter bør feil presenteres både i nærheten av hvert enkelt felt og samlet i en feiloppsummering øverst på siden. Bruk gjerne messagebox i rød variant til dette.

4. Behold gyldig data

All informasjon som er skrevet inn riktig må bli stående. Det er svært frustrerende å måtte fylle ut hele skjemaet på nytt etter en feil.

Universell utforming

Alle felt skal ha label

Alle skjemaelementer må ha en label. Den kan være synlig, eller skjult med pkt-sr-only dersom layouten krever det. Selv når label skjules visuelt, må den være til stede i koden slik at skjermlesere kan lese den opp.

Korrekt kobling i koden

Labels må alltid være koblet til det riktige inputfeltet i koden. Dette gjør at skjermlesere kan presentere informasjonen på en forståelig måte, og gir brukeren riktig kontekst når de fyller ut skjemaet.

Feilmeldinger skal være tilgjengelige

Feilmeldinger må være kodet som tekst, plassert tett på feltet der feilen har oppstått. Bruk en ARIA live region (aria-live="assertive" eller role="alert") for å informere når feil oppstår. Denne må være en del av DOM-en fra starten for å fungere. Punkt sine skjemakomponenter har dette innebygget.

Unngå unødvendige deaktiverte felt

Ikke bruk deaktivert tilstand (disabled) hvis det ikke er helt nødvendig. Felt som ikke kan fylles ut skaper ofte forvirring. Bruk heller ren tekst eller readonly for å informere brukeren uten å hindre interaksjon.

Unngå kun plassholder

Plassholdertekst er ofte utilgjengelig for skjermlesere og forsvinner ved innskriving.

Inndata

For å sikre en god brukeropplevelse er det viktig å velge riktig input-type og bruke autocomplete der det er relevant. Dette gjør skjemaet enklere å fylle ut og mer tilgjengelig.

• Tillat variasjoner: Brukerne skriver inn informasjon på ulike måter. Tillat variasjoner så lenge innholdet er forståelig (telefonnummer med mellomrom, personnumre med punktum, e-post med mellomrom til slutt)
• Velg riktig input-type: Bruk inputtyper som passer til informasjonen du ber om, for eksempel tel, search eller email. Dette gir mobilbrukere et tilpasset tastatur (merk at noen typer kan aktivere klientsidevalidering)
• Bruk av autocomplete: autocomplete skal brukes i felter som mottar personlig informasjon. Hvis feltet ber om opplysninger om en annen person enn brukeren, sett autocomplete="off"
• Automatisk formatering: Dersom du formaterer data automatisk mens brukeren skriver, må formateringen være synlig uten å forstyrre