Plassering og rekkefølge på knapper

Et arbeidsnotat om plassering og rekkefølge på knapper.

Dette er lagret fra Word, så alt ser nok ikke perfekt ut. Last ned Word-fila

Kort introduksjon

Designsystemet.no jobber blant annet med å utarbeide anbefalinger for mønstre som kan brukes på tvers i offentlig sektor. Høsten 2025 skal det lages et mønster for knapper, og dette er et arbeidsnotat jeg laget for å forberede meg til arbeidet i gruppa. Dette er altså ikke mer enn et «personlig» notat, men jeg har lagt det ut i tilfelle noen kan finne nyttige referanser eller tips.

Min hovedrolle i arbeidsgruppa blir å ta høyde for tilgjengelighet og universell utforming (uu). Jeg jobber som ekspert på uu i Nav.

Mye av det som er skrevet om uu og knapper handler om utseende og/eller teknisk tilgjengelighet [1, 2, 3]. I dette notatet har jeg samlet litt informasjon om rekkefølge og plassering av knapper. Mange referanser omhandler ikke uu spesielt, men naturligvis er det mye uu i gode designprinsipper. Til slutt i notatet har jeg tatt med suksesskriterier som kan ha med knapper å gjøre (i litt utvidet forstand).

Generelt om plassering av knapper

I WCAG er det spesielt Fokusrekkefølge[17] og Konsekvent navigering[20] som omhandler rekkefølge av knapper. Disse kravene er nokså romslige og hjelper oss ikke så mye i forhold til plassering og rekkefølge på eksempelvis Forrige- og Neste-knapper i skjemaer. Det WCAG sier noe om er at Tab-rekkefølgen skal være logisk, og at hovedregelen er at Tab-rekkefølgen skal samsvare med leserekkefølgen.

Det finnes argumenter for å plassere primærknappen til venstre i knapperekkefølgen, men også argumenter for å plassere primærknappen til høyre:

Primærknappen til venstre: Knappen leses først og ligger først i Tab-rekkefølgen.
Primærknappen til høyre: Den primære knappen avslutter naturlig leseflyt, for eksempel i et skjema eller modal.

Primærknappen plassert til venstre ser ut til å være en gjennomgående anbefaling [4, 5, 23, 32, 26]. Denne anbefalingen fravikes ofte i skjemaer og modaler (da anbefales det å ha primærknappen til høyre hvis det finnes flere knapper). Dersom Tilbake ligger øverst i skjemaet og Neste nederst kan primærknappen uansett plasseres til venstre, noe som fungerer best for skjermforstørrere.

Hvordan knapper plasseres bør vurderes ut fra brukernes forventning[24]. Plassering og rekkefølge på knapper kan eksempelvis være annerledes på en mobil app og i et native Windows-program. På mobil vet vi at mange kun bruker en hånd, og tommelen er viktigst for å tappe. Da er det hensiktsmessig å legge Primær-handlingen nederst, der det faktisk er enklest å bruke tommelen. I universelt utformede webgrensesnitt tror jeg at de aller fleste argumenterer for at knappeplasseringen skal venstrestilles (fordi det er enklest å oppdage knappene med skjermforstørring), og antakelig har dette liten negativ betydning for andre brukere[34]. Det er mye viktigere hvordan knappene ser ut og at plassering og rekkefølge på knapper er konsistent.

Det finnes krav til teknisk tilgjengelighet: som for eksempel Synlig fokus[19], Tastatur[16] og Navn, rolle, verdi[22]. Som nevnt innledningsvis har jeg tatt med de mest aktuelle (og noen litt mindre aktuelle) wcag-krav i Suksesskriterier i WCAG (side 5).

Neste, Forrige, Send og Avbryt

Skatteetaten[4] sier følgende om lenker og knapper:

Lenker bruker du når folk skal navigere til en ny side for å fullføre en oppgave eller se mer informasjon.
Knapper bruker du når handlingen skjer på siden brukeren allerede er, for eksempel lukke eller sende inn skjema.
Knapper plasser du fra venstre mot høyre av hensyn til dem med begrenset synsfelt. Primærknapp plasseres først, deretter sekundærknapp. Et unntaket er når «Neste» er hovedknappen – den plasseres etter «Forrige» for å unngå språklig forvirring.
Det skal som regel bare være én primærknapp på en og samme side.
Unngå disabled/deaktiverte knapper.

Egentlig skjønner jeg ikke helt hva som menes med «språklig forvirring» i det som står på Skatteetaten, men anbefalingene er ellers tydelige og gode. Anbefalingene på Aksel (Nav)[5] er ganske like, men der foreslås det å gjøre Tab-rekkefølgene annerledes enn leserekkeflgene i skjemaer:

En viktig huskeregel når vi designer og utvikler produkter er at det visuelle uttrykket skal speile DOM-en. Derimot er det viktig å vite når du kan bryte denne regelen. I vår anbefaling vises neste-knappen lengst til høyre, men kommer øverst i DOM-en. Resultatet blir at skjermlesere speiler viktigheten, og ønsket bruk, heller enn visuell framstilling. Teknisk kan dette gjennomføres ved enkle CSS-grep.

Jeg personlig er skeptisk til å trikse med Tab-rekkefølgene og mener at også de som bruker skjermleser har en leserekkefølge som på mange møter tilsvarer den visuelle presentasjonen. Hvis du Tabber mellom skjemakontroller er det da logisk for meg å komme til Tilbake før Neste, og det er uansett kun ett trykk på Tab som skiller disse anbefalingene. Hvis skjermlesere brukes i lesemodus (som kanskje er den vanligste måten å fylle ut skjemaer på) vil leserekkefølgene med skjermleser tilsvare den visuelle presentasjonen. I [28] står det følgende, og det er minst like riktig for de som bruker skjermleser:

Users expect the most important button–your primary action–to appear at the end of the process or form. That might be at the bottom of a modal, the right side of a two-button pair, or the last step of a multi-page flow.

It’s a small detail with a big impact: putting the button where users already are when they’re done thinking makes it easy to act.

Et lite tilleggspoeng her er at dersom Neste kommer før tilbake i Tab-rekkefølgene vil ikke de som bruker Tab og skjermleser egentlig vite om Tilbake-knappen uten å tabbe forbi Neste og så eventuelt bruke Shift+Tab for å gå tilbake.

For å unngå at brukere velger feil knapp foreslår noen [23, 30] å plassere Neste og Tilbake lengst mulig fra hverandre. I skjemaer legges Tilbake øverst og primærknappen (Neste) nederst. Et slikt mønster egner seg nok best i «One Thing Per Page»[31] skjemaer, og i [30] argumenterer Vitaly Friedman for at Tilbake øverst i lange skjemaer kan hindre at brukeren legger merke til Tilbake-knappem:

Another issue I’ve run into with this pattern is that for lengthy forms in busy interfaces, users might be scrolling down too quickly before even noticing a ‘Back’ button on the top of the page. At the point when they actually stop scrolling, the button would be out of view, especially on mobile, and they might have issues discovering a reliable way to go back.

Avbryt kan regnes som en lite ønskelig knapp å velge i mange skjemaer. Derfor bør den ligge under Neste/Send knappen[23]. Viktige sekundær-handlinger, for eksempel Lagre plasseres til høyre for primær-knappen.

Relaterte skjema-funksjoner

Noen skjemaer har relaterte funksjoner som ikke direkte har med utfyllingen av skjemaet å gjøre. Et eksempel kan være et Logg inn-skjema som har en «Glemt passord» funksjon. I [23] argumenteres det for at slik funksjonalitet bør plasseres over skjemaet, og dette er jeg enig i med utgangspunkt i et spesielt fokus på universell utforming. Ofte legges det en «Glemt passord»-lenke rett ved siden av passord-feltet, og begrunnelsen i [23] for å plassere en slik funksjon over skjemaet er:

Forvent at tabulatortasten fokuserer neste felt/knapp
kan måtte bla for å finne lenken
kan kaste bort tid på å skrive inn e-postadressen før de klikker på lenken

Funksjonalitet som kan brukes på flere elementer, for eksempel mange personer, bør også legges over skjemaet[23].

Av/på-knapper (ToggleButton)

Knapper brukes også som av/på-knapper (togler). I slike tilfeller er det viktig å ta med riktig wai-aria merking (aria-pressed). Aria-pressed kan ha tre verdier true, false og mixed.

Knapper i modaler

Det er vanlig å referere til «z-pattern» for utforming av modaler. Det innebærer gjerne å plassere primærknappen nede til høyre. Spørsmålet er om et slikt lesemønster er mer eller mindre uavhengig av design, nære bestemt visuelle virkemidler. I 3 Design Layouts: Gutenberg Diagram, Z-Pattern, And F-Pattern[35] argumenteres det eksempelvis for at leserekkefølge og typiske lesemønstre påvirkes i stor grad av hvordan innhold utformes.

Som nevnt i Generelt om plassering av knapper (side 1) bør primærknapper plasseres til venstre med tanke på bruk av skjermforstørrer. Dette gjelder også for modaler. Jeg tviler likevel på at dette er «ekstremt viktig». Konsekvent plassering er viktigere. To så anerkjente designsystemer som Carbon[27] og Helios[33] anbefaler ulik plassering av primærknappen i modaler. Carbon anbefaler primærknappen til venstre og Helios til høyre.

Om lenker og knapper

«Links go somewhere, buttons do something»[28].

Knapper kan styles som lenker og lenker som knapper. Det kan være lett å tenke at hvilken kontrolltype som brukes har liten praktisk betydning. Det er ikke tilfelle for de som bruker skjermleser, og det å være inkonsekvent med bruk av kontroller kan være forvirrende for alle. Jeg er derfor veldig på linje med [28]: Lenker fører deg et sted, knapper gjør noe. Noen argumenterer helt annerledes[30], men da har de neppe vurdert tilgjengelighet/uu:

While it works very well in some scenarios, it might not work well for you. In that case, try to avoid placing the buttons too close to each other and make sure they look different enough visually. One could be a link, and the other could be a button. What seems to be a small detail might pay off big time and result in lower abandonment and higher conversion. And that’s worth it.

Abryt-lenke og Betal-knapp.

Figur 1 Eksempel fra https://mortentollefsen.no/demo/paypal.html

Med skjermleser navigerer du internt på en side med hurtigtaster: t hopp til neste tabell, b hopp til neste knapp, h hopp til neste overskrift og så videre. Trykker du eksempelvis b for å hoppe til neste knapp vil du ikke komme til lenker. Faktisk er også native bruk av lenker og knapper med tastatur forskjellig[29]: knapper aktiveres med Enter eller Mellomrom, lenker aktuveres kun med Enter.

Suksesskriterier i WCAG

Det er selvsagt de offisielle WCAG-retningslinjene som gjelder. Når jeg har lenket til Aksel-artikler for suksesskriteriene er det fordi disse muligens er enklere å forstå, men også fordi jeg håper litt på tilbakemeldinger for å kunne forbedre forklaringer og testkriterier.

Her har jeg tatt med lovpålagte krav som kan ha noe med knapper å gjøre, men vær klar over at mange vil si at noen av kriteriene er veldig perifere.

1.1.1 Ikke-tekstlig innhold

Tilby et tekstlig alternativ for ikke-tekstlig innhold.

For grafiske knapper innebærer dette at grafikken (og dermed knappen) gis et meningsfylt tekstalternativ.

Hvis det er plass er det absolutt best å ha tekst på knappene. Tekst er vanligvis enklere å forstå, og det gjør det enklere for de som bruker skjermleser å snakke om grensesnittet med de som bruker skjerm.

1.3.1 Informasjon og relasjoner

Bruk HTML semantikk for å formidle visuell presentasjon.

Spesielt med skjermleser, som viser innhold sekvensielt, kan det være vanskelig å vite hvilket innhold en knapp hører til. Tenk deg at du for eksempel har en nettside med medlemmene i et team. For hvert medlem har du en Vis detaljer-knapp. Uten å først sjekke hvordan knappen er plassert på det første medlemmet kan det da være nærmest umulig å skjønne hvilket medlem knappen gjelder for med skjermleser. Løsningen som anbefales er ofte å gi knappene en unik tekst. Hvis knappene heter det samme, eksempelvis dersom det brukes et ikon på knappen med en standard alt-tekst, kan en måtte gjøre det forståelig på være å pakke inn hver person i en semantisk html-tag (li, section, article, …).

1.3.2 Meningsbørende rekkefølge

Innhold skal kunne presenteres sekvensielt på en forståelig måte.

På en måte er dette kriteriet et av de mest relevante i forhold til plassering og rekkefølge på knapper. Likevel tenker jeg at det er sjelden i praksis at rekkefølgen på knapper ikke er forståelig. Om primærknappen kommer først eller sist medfører ikke at rekkefølgen er uforståelig, men i praksis kan det naturligvis bety noe for brukeropplevelsen (eksempelvis hvis du må forbi 20 knapper hver eneste gang du skal velge primærknappen).

1.3.3 Sensoriske egenskaper

Sørg for at brukeren kan forstå instruksjonene på siden, uten å være avhengig av en spesifikk sans eller orientering på siden.

Dette kriteriet handler mer om det du eventuelt sier om knapper enn om knappene i seg selv. Du skal for eksempel ikke bruke instruksjoner av denne typen: «Velg den røde knappen for å slette dokumentet». Henvis gjerne til en spesifikk farge eller plassering, men lag instruksjonen slik at både fargeblinde og helt blinde skjønner hvilken knapp du mener: «Velg den røde Slett-knappen (søplebøtte) for å slette dokumentet.

1.4.1 Bruk av farge

Ikke bruk farger som den eneste måten å kommunisere informasjon på.

Dette kriteriet brytes ikke så ofte, men det kan skje dersom knapper har like ikoner med ulik farge.

1.4.3 Kontrast

Tekst med god kontrast er lettere å lese for alle som bruker synssansen.

WCAG-krav for kontrast gjelder også for knapper.

1.4.4 Endring av tekststørrelse

Tekst kan forstørres til minst 200% uten at informasjon går tapt.

Dette kriteriet omfatter også knapper, dvs. ikke kun brødtekst.

1.4.10 Dynamisk tilpasning – Reflow

Kan man forstørre innholdet til 400% uten å tape informasjon eller funksjonalitet?

Dette kriteriet handler ikke egentlig om knapper, men at du skal kunne nå for eksempel knapper når du zoomer til 400%.

1.4.11 Kontrast for ikke-tekstlig innhold

Alle som benytter synssansen skal kunne oppfatte brukergrensesnittkomponenter og viktig grafikk.

Interaktive komponenter (i alle tilstander) og meningsbørende grafiske elementer skal ha et kontrastforhold på minst 3:1 mot tilstøtende farger?

1.4.13 Pekerfiltomt innhold eller innhold ved tastaturfokus

Gi brukere kontroll over innhold som vises ved hover eller fokus, så det ikke forsvinner før de er klare.

For knapper er dette mest aktuelt i forhold til tooltips, som må imøtekomme følgende kriterier:

Muspekeren kan flyttes over innholdet uten at innholdet forsvinner.
Innholdet forblir synlig inntil brukeren lukker innholdet, flytter fokus vekk fra det utløsende elementet eller informasjonen ikke lenger er relevant.
Innholdet kan avvises uten å måtte flytte fokus eller flytte muspekeren utenfor innholdet

2.1.1 Tastatur

Alt skal kunne gjøres med tastatur.

Dette gjelder også knapper, selvsagt.

2.4.3 Fokusrekkefølge

Navigering med tastatur skal være forståelig.

Dette kriteriet imøtekommes i de aller fleste tilfeller, men jeg har sett eksempler på verktøylinjer og felt (inkludert knapper) som er veldig forvirrende.

2.4.4 Formål med lenke i kontekst (Aksel)

Gode lenketekster gjør det enklere for folk å bestemme om de ønsker å følge lenken.

Dette kriteriet handler spesifikt om lenker. Jeg tenker imidlertid at mye av det samme gjelder for knapper og at det kan nevnes i en anbefaling (ikke knyttet mot 2.4.4). Det å skjønne hva en knapp brukes til i kontekst er ellers dekket av 1.3.1, men for å skjønne akkurat det tror jeg du må ha ganske god kjennskap til wcag.

2.4.7 Synlig fokus

Brukeren må alltid kunne se hvilket element som kommer til å motta tastaturinput.

Gjelder også knapper.

3.2.3 Konsekvent navigering

Et konsekvent oppsett av navigasjonselementer på tvers av sider hjelper brukerne å forutsi hvordan de finner frem på siden.

På profesjonelle nettsider er dette kriteriet vanligvis imøtekommet, men jeg har sett eksempler på skjemaer der det dukker opp en litt annen navigeringsrekkefølge helt til slutt i en flyt. Hvis det dukker opp nye funksjoner: Skriv ut, Send som PDF, Gi tilgang, … Bør slike funksjoner legges før (eller etter, men det liker jeg litt dårligere) Tilbake og Neste (Send).

3.2.4 Konsekvent identifikasjon

Brukere kan lettere gjenkjenne like funksjoner på et nettsted når de har konsekvent navn og utseende.

Mens 3.2.3 handler om rekkefølge handler 3.2.4 om identifisering (utseende, alternativ tekst). På nettsteder der funksjonalitet har blitt utviklet over lang tid og av ulike utviklere har jeg ofte sett eksempelvis alt-tekst som varierer, men der knapper har samme funksjon (og antakelig samme utseende). Dette er ganske forvirrende.

4.1.2 Navn, rolle, verdi

Hjelpemiddelteknologi må kunne identifisere alle brukergrensesnittkomponenter og forstå deres rolle, tilstand og egenskaper.

Egenutviklede knapper må også identifiseres som knapper (role=button), og tilstander må også kodes med wai-aria (for eksempel aria-pressed).

Oppsummering

Vær konsekvent med bruk av lenker og knapper: Lenker fører deg et sted, knapper gjør noe.
Grafiske knapper skal ha en alternativ tekst. Bruk tekst på knappene dersom det ikke er veldig gode grunner til å kun bruke grafikk (spare plass).
Plasser primærknappen sist i en flyt (for eksempel Neste, Send inn, OK). Tab-rekkefølge skal samsvare med leserekkefølge.
Plasser primær-knappen først hvis den ikke inngår i en flyt.
For skjermforstørrere er det enklest å finne knapper dersom de plasseres fra venstre marg.