Skjema

Manglende universell utforming i skjema kan føre til at nettstedseier får inn feil data eller at brukerne blir utestengt fra viktige funksjoner. Korrekt kode, utforming og gode ledetekster i skjema er derfor nyttig for alle.

Introduksjon

For å støtte brukerens utfylling av skjema er det nødvendig med

  • god koding
  • god visuell utforming
  • veiledningstekster
  • tydelige feilmeldinger

På nettsted med mange skjema er det bra for brukerne at skjemaene utformes mest mulig likt. Det vil blant annet si konsekvent utseende og plassering på skjemaobjekt og feilmeldinger. Vi har skillt ut feilhåndtering på en egen side, fordi dette også handler om andre situasjoner enn i tilknytning til skjema.

Løsninger for å møte kravene i forskriften

Grunnleggende koding

Du må kode skjemaobjekter slik at de oppfører seg korrekt for alle brukere, uavhengig av utstyr. Den enkleste måten å gjøre dette på er å benytte standardkomponenter som input, select, textarea og button, og la dem oppføre seg slik HTML definerer.

Du kan også benytte andre løsninger, som for eksempel role=”button” fra WAI-ARIA (W3C, engelsk), men vær oppmerksom på at du da kan komme i situasjoner der du må bruke mer kode for å oppnå riktig funksjonalitet. I tillegg må du i større grad teste med et spekter av skjermlesere for å sikre at objektet oppfører seg korrekt, ettersom funksjonalitet som har eksistert lenge i HTML er bedre støttet enn tilsvarende WAI-ARIA.

Eksempelkode for standard HTML-knapp:

<input type="submit" name="send" id="send" value="Send">

Eksempelkode for span-element som skal oppføre seg som en knapp, inkludert stiling for å få utseende som en knapp:

<span role="button" tabindex="0" style="padding:5px 5px 2px 5px; border: 1px solid #adadad; background-color: #ededed; border-radius: 5px;">Send</span>

I tillegg må Javascript lytte etter Enter og Space.

Ledetekster

Alle skjemaobjekt må ha en tilknyttet ledetekst. Dette er viktig for alle brukere, men særlig for brukere med nedsatt motorikk og for sterkt svaksynte brukere med skjermleser.

Det må være en programmeringsmessig kobling mellom ledetekst og skjemafelt
 
 

Den anbefalte metoden er å benytte <label> som er korrekt koblet til skjemaelementet. Det er også formelt riktig å benytte title-attributtet, men problemet er at enkelte skjermlesere ikke fanger opp dette i det hele tatt, samt at ingen skjermlesere fanger det opp på knapper. Andre muligheter fra WAI-ARIA er attributtene aria-label, aria-labeledby og aria-describedby, men ingen av disse har heller per i dag full støtte blant alle skjermlesere.

Korrekt kobling av ledetekst med matching av for- og id-attributt, hvor innholdet i ledetekstens for-attributt er identisk med id-attributtet i skjemaobjektet:

<label for="epost">E-post:</label>
<input id="epost" name="epost" type="email">

En annen måte å koble ledeteksten er ved å la den omfavne skjemaobjektet, altså at label-elementet starter før skjemaobjektet og avsluttes etter:

<label>E-post:
<input id="epost" name="epost" type="email">
</label>

E-post-felt med label
 
 

Gruppering

Dersom du benytter radioknapper, må du gruppere disse både visuelt og strukturelt slik at det er en tydelig kobling mellom hvilken informasjon som etterspørres og svaralternativene. Dette løser du med elementene <fieldset> og <legend>, der <legend> skal være det første elementet i <fieldset>.

Den samme teknikken er ofte nødvendig når du har grupper av avkrysningsbokser eller har flere skjemaobjekter med samme navn på ulike steder i skjemaet, slik tilfellet vil være dersom du har separate felt for leveringsadresse og fakturaadresse.

Kodeeksempel på fieldset og legend:

<fieldset>
<legend>Vil du motta nyhetsbrev?</legend>
<input type="radio" name="radio" id="ja" value="ja">
<label for="ja">Ja</label>
<input type="radio" name="radio" id="nei" value="nei">
<label for="nei">Nei</label>
</fieldset>

nyhetsbrev-skjema med fieldset og legend
 
 

Kompleks funksjonalitet

Det er blitt svært vanlig at script skaper tilleggsfunksjonalitet i skjema. For eksempel gi søkeforslag i søkefunksjon eller i kalender for å velge dato ved fokus på datofelt.

Dersom du benytter script, må du sikre deg at objektenes funksjonalitet blir identifisert korrekt, slik at grensesnittet blir forståelig for brukere som ikke ser grensesnittet. Videre må du kvalitetssikre disse slik at de fungerer godt med forskjellig utstyr. Det du enkelt kan teste selv er bruk av tastatur for navigering og bruk av mobile enheter. I tillegg bør du få utført noe testing med skjermleser av personer som er vant med å bruke slike verktøy.

En vanlig scriptbasert funksjon er søkeforslag. Dersom du benytter dette, må du formidle til brukere som ikke ser grensesnittet at det finnes forslag, og hvordan man navigerer til forslagene, for eksempel slik:    

  • Inkluder tekst i label-elementet som forteller at det vil komme søkeforslag
  • Bruk også attributtet aria-haspopup="true" for å markere med kode at det vil komme søkeforslag, eventuelt også aria-autocomplete.
  • Et visuelt skjult div-element som alltid er til stede utstyres med attributtet aria-live="polite", og etter hvert som brukeren skriver fylles dette med tekst som forteller antall søkeforslag og hvordan navigere i forslagene.
Søkeforslag etter hvert som man skriver. Søkefrasen bør kunne matches hvor som helst i relevante sidetitler. Ofte vil det også være relevante sider som ikke har søkefrasen som del av tittelen, men disse kan eventuelt spares til selve resultatsiden.
 
 

Bruker du kalender for å velge dato, må det likevel være mulig å skrive inn dato. Sørg for at kalenderen kan benyttes med tastatur. Det løser du enklest ved at brukeren kan benytte piltaster i alle retninger, og automatisk skifter til forrige/neste måned.

Brukere med skjermleser må bli fortløpende informert for hver endring om hvilken dato som er valgt for øyeblikket, slik at det blir lett å navigere frem til riktig dato. Den enkleste måten å oppnå dette på er at at fokus blir stående på feltet, med teksten markert, samtidig som datoen oppdateres fortløpende når man benytter piltastene i kalenderen.

Piltaster for å navigere, hopper automatisk til neste måned og år. Visuell markering av valgt dag. Fokus blir stående på feltet, med teksten markert. Teksten oppdateres fortløpende.
 
 

Veiledningstekster

For komplekse skjema eller skjema som krever informasjon brukeren er lite kjent med, kan det være nødvendig å hjelpe brukeren med mer enn bare en ledetekst, gjennom en utdypende veiledning. Den beste måten å gjøre det tydelig for alle brukere at en veiledningstekst finnes, er å gjøre lenken til informasjonen til en del av label til det aktuelle feltet.

Finansielle og juridiske skjema

Skjema som er knyttet til finansielle eller juridiske formål, for eksempel bestilling i nettbutikk, levering av forsikringskrav eller registrering av betaling i nettbank, har særskilte krav til funksjonaliteten. Det samme gjelder dersom skjemaet endrer eller sletter brukerdata. Brukeren må få mulighet til minst én av følgende:

  • Kontrollere at den oppgitte informasjonen er korrekt.
  • Mulighet for å korrigere feil før innsending.
  • Mulighet for å angre eller reversere innsendingen.

Vanlige feil

  • Unngå at knapper er erstattet med lenker som visuelt ser ut som knapper. Dette bryter mot WCAG 1.3.1 om at innhold skal være kodet som det de ser ut som, og gjør at brukere med hjelpemiddel kan få problemer med å få sendt inn skjemaet fordi de ikke finner knappen i sin liste over skjemaobjekt.
  • Når JavaScript er brukt for å endre utseendet til skjemaobjekter, er en vanlig feil at en samtidig endrer oppførselen til skjemaobjektet. Resultatet kan da være at tastaturnavigering ikke lenger virker og/eller skjermleser ikke klarer å identifisere objektene korrekt. Et eksempel på en slik feil er når inaktive HTML-objekter er gjort klikkbare med script.
  • Unngå å lage scriptbaserte funksjoner som bare fungerer med mus.

Se også feilhåndtering.

Anbefalinger utover kravene i forskriften

Hjelp brukeren

Noen vanlige metoder for å hjelpe brukeren med å fylle inn skjemaet er:

  • Gjenbruke kjent informasjon, for eksempel fra brukerens profil eller Postens adressesøk.
  • Begrense hvor mye du spør etter. Det holder vanligvis med ett telefonnummer.
  • Spør i logisk rekkefølge. Ikke spør hva boligen er verdt før du spør om brukeren eier en bolig.
  • Liste mulige valg på en fornuftig måte. Trenger du å vite kommune er det bedre å sortere alfabetisk på navn enn å sortere stigende på kommunenummer.
  • Gi forslag til fullføring av et felt, for eksempel gi forslag ved søk. Dette fungerer både dersom du har et svært stort datasett og et relativt begrenset datasett.
  • La brukeren utvide tidsrammen for å fullføre.
  • Lagre informasjon fortløpende for å unngå tap av data.

Valg av skjemaobjekt

Ut fra hvilken type data du ønsker, bør du vurdere hvilken type skjemaobjekt som passer:

  • Dersom brukeren skal legge inn dato, for eksempel fødselsdato eller avreisedato, bør det være et tekstfelt, gjerne supplert med noen form for datovelger. En serie med nedstrekklister for dato, måned og år er unødvendig krevende for de fleste brukere.
  • Radioknapper benytter du når du vil at brukeren skal velge ett blant få alternativ, for eksempel en mellom ulike betalingsmåter eller Ja/nei-spørsmål.
  • Avkrysningsbokser er det beste når brukeren skal kunne velge flere blant en relativt begrenset antall alternativ.
  • Dersom du har noe mer enn en håndfull alternativ hvor brukeren skal velge ett, er nedtrekksliste det mest fornuftige valget, særlig hvis det er spesifikke tekstvalg.
  • Dersom du har svært mange alternativ hvor brukeren skal velge ett eller flere, bør du benytte en form for forslagsfunksjonalitet, der brukeren både kan velge blant hele utvalget, og avgrense utvalget. I en nettbutikk kan et eksempel kan være å finne en skotype i en bestemt størrelse, der en kan filtrere på skostørrelse og merke.

Koding

Knappen for innsending eller bekreftelse bør alltid være aktiv. Ikke bruk fortløpende validering til å la denne knappen være deaktivert inntil utfyllingen er fullverdig. Enkelte brukere kan ha problemer med å forstå hva som er påkrevd, og blir forvirret av at de ikke får til å sende inn/bekrefte skjemaet.

I HTML5 bør du bruke de nye input-typene når det er aktuelt. Dette vil blant annet forenkle utfylling på mobile enheter ved at du får justert tastaturet til å passe med hva som skal skrives. For eksempel vil enkelte input-typer resultere i rent numerisk tastatur, altså færre taster, som dermed gir større klikkeflater på hver tast.

<input type=“number> gir numerisk tastatur

<input type=“email“> gir bokstavtastatur som inkluderer @

<input type=“date“> gir datovelger som sikrer korrekt format

Sammenligning mellom standard skjermtastatur og numerisk skjermtastatur - sistnevnte har mye større klikkeflater.
 
 

Utforming

Skjemaobjekter bør være tydelig identifiserbare som skjemaobjekter. Hvis ikke kan du risikere at enkelte brukere ikke klarer å fylle ut skjemaet. Løsninger på noen vanlige problemer er:

Viktig ved formgiving av skjemaelementer: Tekstfelt må ha en tydelig ramme.  Radioknapper må være tydelig på hvilket alternativ som er valgt. Nedtrekkslister må ha en pilknapp til høyre. Knapper må være tydelig klikkbare.

I lange skjema kan det være relevant med mellomtitler for å strukturere informasjonen og forenkle utfyllingen. For eksempel kan du ha mellomtitlene ”Om deg” og ”Din adresse” ved brukerregistrering i en nettbutikk eller lignende. Mellomtitler er ikke en erstatning for fieldset og legend, men vil kunne forenkle utfyllingen for mange brukere ved at det blir overkommelige bolker med informasjon om gangen.

Veiledningstekster

Om du har veiledningstekster bør du plasserer disse i direkte tilknytning til objektet teksten handler om. Brukeren bør kunne lese veiledningen og legge inn informasjonen parallelt. Særlig for brukere med konsentrasjons- eller hukommelsesvansker er det krevende å skulle bytte mellom utfylling og veiledning.

Veiledningstekster kan være omfattende, samtidig som ikke alle brukere har behov for dem. Derfor er den beste løsningen vanligvis å bruke utvid-/kollapsfunksjon eller lignende for  veiledningstekster.

Ledetekst og veiledning: Ledeteksten forteller hva som skal skrives inn, mens veiledningen forteller hvor og hvordan brukeren skal fylle inn.

Kompleks funksjonalitet

Script bør benyttes for å forbedre brukeropplevelsen, ikke skape den. For eksempel bør det være mulig å gjennomføre et søk uten script, mens med script får brukeren søkeforslag.

Dersom du benytter kompleks scriptbasert skjemafunksjonalitet som søkeforslag eller datovelger, bør du bygge et bibliotek av kvalitetssikrede komponenter for gjenbruk på alle steder der funksjonaliteten er ønsket, slik at det blir enklere å oppnå konsekvent funksjonalitet.

Publisert: 02. jul 2015, Sist endret: 20. aug 2017

Fant du det du lette etter?

Stjerne(*) er obligatoriske felter som du må fylle ut for å sende skjemaet. 

MERK: Du får ikke svar på denne meldingen. Har du spørsmål du ønsker svar på send oss en e-post til uu@difi.no.

Fant du det du lette etter?
*