Hopp til hovedinnhold
Designsystemet logoDesignsystemet logo

Hva leter du etter?

Prøv å søke etter…

Mønstre

Spør brukerne om dato og klokkeslett

Det å spørre brukerne om dato og klokkeslett blir ofte løst mer komplisert enn nødvendig. I mange situasjoner er vanlige input-felt både raskere å bruke og lettere å forstå enn egenbygde datovelgere.

Digdir, BrønnøysundregistreneOppdatert 5. mars 2026

Denne artikkelen er utviklet av designsystem-teamet i Digdir i samarbeid med Brønnøysundregistrene. Den har ikke gått gjennom den samme samarbeidsprosessen som mønstrene i Mønster-samarbeidet. Vi vil gjerne ha tilbakemeldinger på artikkelen. Del dem i Slack eller i denne diskusjontråden på github.com.

Hvordan du ber brukerne om dato og klokkeslett, bør ta utgangspunkt i hvilken informasjon du faktisk trenger. Noen datoer er enkle å huske, som fødselsdatoer, mens andre datoer må brukerne lese fra dokumenter eller kort. I noen situasjoner holder det med en omtrentlig dato, eller et tidspunkt i forhold til i dag. Andre ganger skal brukerne velge en dato eller et tidspunkt fra et forhåndsdefinert utvalg.

Unngå å gjøre oppgaven mer komplisert enn nødvendig. Egenbygde datovelgere gir ofte lavere tilgjengelighet og mer friksjon enn enkle tekstfelt. De kan være vanskelige å bruke med tastatur, gir dårlig støtte for skjermleser og krever unødvendig navigering når brukerne allerede kjenner datoen.

Kjente datoer

Når du spør om kjente datoer, som fødselsdato eller bryllupsdato, fungerer enkle tekstfelt godt. Brukerne vet allerede svaret og ønsker ofte å skrive det direkte, uten å måtte navigere i en kalender.

Del gjerne datoen opp i separate felt for dag, måned og år. Det gjør det enklere å skrive inn datoen korrekt og gir bedre støtte for hjelpemidler. Når du ber brukerne om en dato slik den står i et bankkort, pass eller annet dokument, bør feltene samsvare med formatet i dokumentet. Det gjør det enklere å overføre datoen korrekt og reduserer risikoen for feil.

I eksempelet over bruker vi inputmode="numeric" for å gi brukeren numerisk tastatur på mobil og nettbrett. Vi velger bevisst å ikke bruke type="number" for dag, måned og år. type="number" er utviklet for numeriske verdier som kan økes og reduseres. Det gir funksjonalitet som spinnknapper og automatisk validering. Dette er ikke alltid hensiktsmessig når brukeren skal skrive inn en dato, og kan gi tilgjengelighetsutfordringer (mozilla.org).

Dato fra et forhåndsdefinert utvalg

Hvis du vet at brukerne skal velge en dato eller et tidspunkt fra et begrenset utvalg, for eksempel ledige timer den kommende uken, kan det være mer effektivt å tilby disse datoene som ferdige valg.

Når utvalget er svært begrenset, for eksempel noen få datoer eller tidspunkter, kan Radio være et godt valg. Det gjør det raskt og enkelt å velge et alternativ, uten å måtte skrive noe selv.

La brukerne begrense utvalget

Når antall valg øker, kan en Select være nyttig for å begrense utvalget. Da kan brukerne velge blant uker, dager eller klokkeslett de foretrekker, og deretter se de tilgjengelige alternativene for det valget. NB: Eksempelet under fungerer ikke. Det ikke er koblet til et faktisk utvalg av datoer eller klokkeslett, men illustrerer hvordan du kan la brukerne begrense utvalget før de ser de tilgjengelige alternativene.

Du bør kun vise valg som har ledige timer. Unngå for eksempel å deaktivere uker som ikke har ledige timer, da det kan skape forvirring. Forklar på forhånd at brukerne kun ser uker med ledige tidspunkt, slik at de forstår hvorfor det er noen uker de ikke kan velge.

Konkret dato i nær fremtid eller fortid

Noen ganger når brukerne skal velge en konkret dato tett opp mot dagens dato, kan det være nyttig å gi visuell støtte. En Input med type="date" lar brukerne enten skrive datoen direkte eller bruke nettleserens innebygde datovelger. Dette gir ofte en god balanse mellom fleksibilitet og støtte. Støtten varierer mellom nettlesere og enheter, både når det gjelder funksjonalitet, utseende og interaksjon, men løsningen er ofte mer tilgjengelig og robust enn egenbygde alternativer.

Vær oppmerksom på at type="date" styres av brukerens operativsystem og regionale innstillinger, ikke av språket på nettsiden. Det kan føre til at datoen vises i et annet format enn brukeren forventer. Vurder om det er behov for ekstra tydelighet, for eksempel ved å vise valgt dato i klartekst med måned skrevet med bokstaver, eller på annen måte bekrefte datoen før den lagres.

Start- og sluttdato

Når brukerne skal oppgi en periode, bør startdato og sluttdato vises tydelig sammen. Bruk to separate felt, og gjør det klart hvilken dato som er hvilken.

Plasser feltene i logisk rekkefølge, og valider at sluttdato ikke er før startdato. Hvis datoene avhenger av hverandre, bør feilmeldinger forklare hva som er galt og hvordan brukerne kan rette det.

Klokkeslett – start og slutt

Når brukerne skal oppgi et tidsintervall, som åpningstid eller varighet på et møte, kan du bruke en Input med type="time". Det lar brukerne skrive klokkeslettet direkte, samtidig som nettleseren tilbyr støtte.

Bruk separate felt for start- og sluttid, og vis dem tydelig sammen.

Omtrentlig tidspunkt

Hvis brukerne bare trenger å oppgi måned og år, bør det være mulig å gjøre nettopp det. Dette er særlig relevant når hendelsen ligger langt tilbake i tid, og brukerne ikke nødvendigvis vet nøyaktig tidspunkt.

For eksempel kan du la brukerne oppgi omtrentlig tid i et fritekstfelt, eller tilby egne felt for kun måned og år, som i eksempelet under.

Dato relativt til en annen dato

I noen situasjoner er det mer naturlig å spørre om tidspunkter relativt til en annen dato, for eksempel når brukerne setter opp en påminnelse. Da kan det være bedre å bruke en Select for å gi brukerne valg om «i morgen», «om 3 dager» eller «1 dag før». Hvis ukedag er viktig for oppgaven, bør denne vises tydelig i tillegg.

Oppsummering

Start med behovet, og velg den løsningen som lar brukerne løse oppgaven raskest mulig. Ofte er vanlige tekstfelt både mer tilgjengelige og raskere å bruke enn avanserte datovelgere.

  • Vis ferdige valg når alternativene er begrensede
  • La brukerne skrive når svaret er kjent
  • Spør bare om så presis dato og tid som situasjonen krever
  • Bruk innebygd nettleserstøtte fremfor egenbygde løsninger

Kilder og relevant informasjon

Designsystemet logo

Bidragsytere

Marianne Røsvik (Digdir)Ole Martin Tangen Vad (Brønnøysundregistrene)Roy Halvor Frimanslund (Brønnøysundregistrene)Lasse Febakke Straum (Digdir)Frank Dahle (Digdir)Tobias Barsnes (Digdir)Oddbjørn Øvernes (Digdir)Michael Marszalek (Digdir)Gørild Døhl (Digdir)

Rediger denne siden på github.com (åpnes i ny fane)