Mønstre
Plassering, rekkefølge og språk i knapper
Hvordan kan vi skape en mer forutsigbar og inkluderende opplevelse ved å standardisere plassering og rekkefølge på knapper?
Ulik plassering og rekkefølge på knapper skaper unødvendig friksjon. Det øker risikoen for feil og gjør oppgavene tyngre, spesielt for personer med nedsatt syn, motoriske utfordringer eller kognitive barrierer. Når vi bruker samme plassering, rekkefølge og språk på tvers av løsninger, blir opplevelsen mer forutsigbar. Brukerne finner raskere fram og gjør færre feil.
Design og opplevelse
Begrens antall knapper
Begrens antall knapper til det brukeren faktisk trenger i situasjonen. Når hvert valg er tydelig og entydig, blir det enklere å forstå hva som skjer og tryggere å trykke.1
Bruk rekkefølgen primær, sekundær, tertiær
Som hovedregel skal knapper som står i en gruppe alltid presenteres i rekkefølgen primærknapp → sekundærknapp → tertiærknapp.
Plasser knapper til venstre
Plasserer knapper til venstre i grensesnittet. Da blir de enklere å finne for alle brukere, og særlig for dem med nedsatt synsfelt eller de som bruker skjermforstørrelse.2
Praktiske eksempler
Modal (dialog)
For å skape en forutsigbar opplevelse skal knappene i en modal plasseres og følge samme rekkefølge som ellers.
Lukk-knappen (X) skal være plassert øverst til høyre i modalen. Knappen skal ha samme funksjon som når brukeren klikker utenfor modalen eller trykker på Esc-tasten. Modalen lukkes og dersom et spørsmål krever svar er det alltid det minst inngripende eller minst destruktive valget for brukeren det faller tilbake på.
Popover
En popover brukes for korte, avgrensede valg eller bekreftelser som krever en umiddelbar handling uten å ta brukeren bort fra konteksten. Knapper i en popover skal følge samme plassering og rekkefølge som ellers.
Skjema med én side
I skjemaer der alt fylles ut på én side, vil «Send inn»-knappen som regel være den eneste primærhandlingen.
Skjema med flere sider
Ikke bruk deaktivert "Forrige"-knapp på første side i et skjema med flere sider.3
På de resterende sidene i skjemaet skal "Forrige"-knappen være plassert i nærheten av Neste-knappen. Elementer som står nær hverandre, oppfattes som relatert.4 Alternative valg som «Fortsett senere» eller «Slett skjemaet» er andre type handlinger som ikke bør være i samme gruppe som Neste/Forrige.
På små skjermer skal "Forrige" ligge under "Neste", og følge hovedprinsippet for rekkkefølge. På større skjermer er det ulike syn på om det bør være et unntak fra regelen her eller ikke. Noen velger å gjøre et unntak til fordel for lese- og handlingsretningen, men vi har foreløpig ikke noe dokumentert innsikt på at dette faktisk er en fordel.
Mer innsikt kreves
Har du innsikt om plassering av Neste/Forrige-knapper, del gjerne i pågående diskusjon på Github.
Hvis du gjør unntak her, bør unntaket kun gjøres for større skjermer, ikke små skjermer der knappene ligger under hverandre. Det er viktig at den visuelle fremstillingen speiler DOM-en. Dette kan løses ved å sette inn en ekstra knapp som skjules med display: none; og fjerner innholdet fullstendig for skjermlesere. Se kodeeksempel med ekstra knapp (nav.no).
Siste steg i et skjema
På siste steg i et skjema skal det være tydelig at brukeren sender inn skjemaet. “Send inn” er primærknappen.
Språk
Tekst i knapper skal alltid beskrive hva som skjer når brukeren trykker. Knappeteksten skal være kort og konsis, helst ikke mer enn tre ord. Velg verb i oppfordringsform (imperativ), for eksempel "send" og "signer".
Unngå abstrakte begreper som “Ok“ eller ”Avbryt“ når det finnes alternativer som beskriver nøyaktig hva som skjer. Brukeren skal slippe å tolke knappene. Det skal være åpenbart hva som skjer når man trykker.
Bruk ordlyden "Forrige steg"
Bruk ordlyden «Forrige steg» i skjema i stedet for “Tilbake”. Det gjør det tydelig at handlingen kun fører brukeren tilbake til det foregående steget i skjemaet, ikke ut av prosessen.
Bruk “Avbryt” konsekvent
“Avbryt” skal alltid bety at brukeren avbryter en handling uten at noe lagres eller endres. Om det finnes risiko for tap av data, vurder å spørre brukeren “Er du sikker på at du vil avbryte? Endringene du har gjort vil gå tapt.” Når funksjonen er noe annet, bruk begreper som beskriver handlingen, f.eks “Lagre og fortsett senere”. Da slipper brukerne å tolke hva som skjer.
Kode
Fokusrekkefølge
Tab-rekkefølgen skal som hovedregel alltid følge leseretningen. Det betyr at når en bruker navigerer med tastatur, skal fokus gå gjennom elementene i samme rekkefølge som de presenteres visuelt.5-6
Hvis «Neste» er plassert til høyre for «Forrige», kan det være fristende å endre fokusrekkefølgen i koden slik at brukeren hopper til «Neste» først. Dette skal unngås, da det skaper en uforutsigbar oppførsel for tastaturbrukere. Det er bedre at fokusrekkefølgen i koden samsvarer med den visuelle rekkefølgen. Dette gir en forutsigbar og tilgjengelig brukeropplevelse.
Relevante kilder
- [1] Simplicity Wins over Abundance of Choice (baymard.com)
- [2] Forstå synsnedsettelse
- [3] Deaktiverte tilstander (nav.no)
- [4] Proximity Principle in Visual Design (nngroup.com)
- [5] Understanding SC 2.4.3: Focus Order (w3.org)
- [6] 2.4.3 Fokusrekkefølge (uutilsynet.no)
