For at brukerne skal forstå hvordan nettsiden eller appen skal betjenes, er det blant annet viktig å tilby gode instruksjoner. Dette er spesielt viktig for mobile enheter, hvor liten berøringsskjerm som ofte brukes i ulike lys- og værforhold, gjør det vanskeligere å holde oversikt, og lettere å gjøre feil.

Tema:

    Introduksjon

    På mobile enheter er det ekstra viktig å tilby meningsfulle ledetekster og instruksjoner, og å la brukerne kontrollere og rette opp inndata eller angre innsending av skjema med finansielle eller juridiske formål. Mange brukere har også god nytte av at det viktigste innholdet ligger lett tilgjengelig, og at navigasjonselementer presenteres i samme rekkefølge på tvers av ulike sider i appen og har konsekvent utforming som gjør det tydelig at elementene er klikkbare.

    Her har vi trukket frem noen ting som er spesielt viktige å passe på når det kommer til universell utforming av apper slik at alle kan forstå innholdet, og hvordan de skal betjenes uten å gjøre feil ved utfylling og innsending av informasjon i skjema.

    Løsninger som møter kravene i forskriften

    Hjelp brukerne å forhindre feil i finansielle og juridiske skjema

    Skjema med finansielle eller juridiske formål, for eksempel kjøp i nettbutikk, signering av avtaler eller betaling i mobilbank, har strengere krav til funksjonaliteten. Det samme gjelder dersom skjemaet endrer eller sletter brukerdata.

    I slike skjema skal brukerne ha mulighet til å enten kontrollere at oppgitt informasjon er korrekt, mulighet til å rette opp feil før innsending, eller mulighet til å angre eller reversere innsendingen eller slettingen. Hensikten med dette er å forhindre tap av store datamengder, som å slette en hel fil, eller unngå å sende inn eller lagre utfylling av et helt skjema. Dette er ekstra viktig i apper, da liten skjerm, berøringsskjerm og ulike lys- og værforhold kan øke risikoen for at brukerne gjør feil ved utfyllingen.

    Personer som bruker hjelpemidler, som for eksempel skjermleser (evt. personer med nedsatt kognisjon, motorikk eller syn) drar ekstra nytte av å kunne kontrollere, rette eller reversere inndata, da risikoen for å gjøre feil øker ytterligere ved bruk av hjelpemidler. Det kan også nevnes at disse brukerne i stor grad bruker mobile enheter på grunn av de innebygde tilgjengelighetsfunksjonene i enhetene, som igjen gjør det ekstra viktig å passe på dette ved utvikling av apper.

    Reversere innsending

    Brukeren må få beskjed om at innsending eller sletting av data kan reverseres eller angres. Dette kan for eksempel være knyttet til en mekanisme, som en knapp, med ledetekst «Avbestill», «Kanseller», «Ring oss for å avbestille», «Angre sletting», «Gjenopprett» eller lignende. Brukeren må også få informasjon om hvilket tidsrom innsendingen eller slettingen må reverseres eller angres, for eksempel innen 24 timer, og de må få informasjon om hvordan de kan reversere eller angre innsendingen eller slettingen.

    Det er ikke konkrete krav til hvordan innsendingen eller slettingen må angres eller reverseres, dette er opp til virksomheten. Det kan for eksempel gjøres ved hjelp av en enkel mekanisme på nettsiden, via en henvendelse på e-post eller over telefon.

    Kontrollere og korrigere informasjon

    I tilfeller der nettsiden kontrollerer om det finnes, og avdekker inndatafeil, får brukeren beskjed om dette, og mulighet til å rette opp feilene før innsending.

    Bekrefte og korrigere før innsending

    Før innsending skal brukeren ha mulighet til å bekrefte at informasjonen som er gitt i skjemaet er korrekt. Dette kan gjøres på flere måter:

    • I et skjema som kun går over én enkeltside, kan brukeren navigere mellom spørsmålene/ inndatafeltene, og se over og eventuelt redigere før de sender inn.
    • I et skjema som går over flere sider kan brukeren enten
      • bla fritt mellom sidene i skjemaet, slik at de kan se over og eventuelt redigere svarene på spørsmålene/ i inndatafeltene før de sender inn, eller
      • få en samlet oppsummering av all informasjon de har gitt i skjemaet slik at de kan se over, og tilgang til en mekanisme så de kan endre svarene før de sender inn.

    I alle tilfellene, har skjemaet en obligatorisk mekanisme for å bekrefte informasjonen før innsending, og denne mekanismen er separat fra mekanismen for å sende inn skjemaet.

    Eksempel

    En mobilbank tilbyr flere steg for å gjennomføre en betaling mellom to kontoer:

    1. Velg hvilken konto det skal betales fra
    2. Skriv inn kontonummer til konto det skal betales til
    3. Oppgi beløp
    4. Velg betalingsdato

    Når alle feltene er fylt ut, får brukeren en oppsummering av informasjonen de har fylt inn, og kan enten velge å gjennomføre eller avbryte betalingen.

    Ledetekster eller instruksjoner

    Alle skjemaelement skal ha en tilknyttet ledetekst eller instruksjon slik at brukeren forstår hvordan skjemaet skal fylles ut. Dette gjelder også informasjon om at et skjemaelement er obligatorisk.

    Skjemaelementet skal også være koblet til ledeteksten i koden slik at skjermlesere leser opp riktig ledetekst til brukeren.

    Skjemaelement skal ha en synlig identifikasjon i form av ledetekst, instruksjon eller ikon/symbol/bilde. Identifikasjonen skal være visuelt plassert i eller rett ved skjemaelementet, og alltid være synlig når skjemaelementet er i fokus.

    Bruk meningsfulle etiketter

    Gi tydelige og beskrivende etiketter til skjemaelementer som tekstfelt, avkryssingsbokser og knapper. Etikettene skal formidle formålet eller forventet inndata for hvert element.

    Gi tilgjengelige hint og instruksjoner

    Inkluder ekstra hint eller instruksjoner for å hjelpe brukere med å fylle ut skjemaet.

    Hjelp brukeren å rette feil i skjema

    Vis tydelige feilmeldinger nær de relevante feltene slik at brukerne får midler og informasjon for å rette feil i inndata. Sørg også for at de er tilgjengelige for alle brukere slik at de kan korrigere feil.

    Vurder skjemalayout og mellomrom

    Tillat tilstrekkelig avstand mellom skjemaelementene for å unngå utilsiktede handlinger og for å forbedre lesbarheten. Unngå rotete layouter som kan forvirre eller overvelde brukerne.

    Test opp mot lovkravene

    For å vite om en løsning oppfyller lovkravene, er det viktig med kunnskap om kravene og at du tester innholdet.

    For hvert krav, kalt suksesskriterium, finner du informasjon om formålet, brukerbehov, tilsynets tolking og krav til samsvar. For forståelse av informasjon og betjening av brukergrensesnitt på mobile enheter gjelder:

    Anbefalinger utover kravene i forskriften

    Plasser viktige elementer lett tilgjengelig, og uten behov for å sveipe

    Den lille skjermstørrelsen på mange mobile enheter begrenser mengden innhold som kan vises samtidig uten å måtte scrolle. For å bedre brukeropplevelsen ved at brukerne kommer raskt til innholdet, bør du komprimere navigering og annen funksjonalitet i toppen av appsiden, minimere antall dekorative objekter (som bilder), og sørge for at det vises konkret innhold fra starten av appsiden.

    Å plassere viktig informasjon slik at den er synlig uten behov for å scrolle, kan øke brukeropplevelsen for alle brukere, men er spesielt viktig for brukere med nedsatt syn og brukere med kognitive utfordringer. Konkret kan en slik plassering av informasjon hjelpe:

    • Brukere av skjermforstørrelser som kan finne viktig informasjon uten å måtte scrolle for å flytte det forstørrede området.
    • Brukere med kognitive utfordringer som nedsatt korttidsminne/korttidshukommelse, ved at de kan finne innhold uten å utføre en interaksjon.
    • Brukere med kognitive utfordringer og nedsatt syn, når elementene blir plassert på et konsistent sted.

    Vær også nøye med gruppering og plassering av objekter. Mange mobile plattformer har skjermleser for blinde som leser opp det brukeren peker på. Brukeren holder da fingeren på skjermen, og gjør dobbel berøring for å aktivere et objekt. De fleste mobilbrukere starter oppe til venstre og beveger seg primært nedover langs venstre kant. Dermed er det ugunstig med høyrejustering av objekter, spesielt hvis de dekker liten del av skjermbredden.

    Tilby instruksjoner for spesiallagde gester for berøringsskjerm

    Å tilby tilpassede gester for å operere en berøringsskjerm kan gjøre det mulig for utviklere å skape effektive nye grensesnitt. Imidlertid kan tilpassede gester være utfordrende å oppdage, utføre og huske for mange brukere.

    Derfor bør det gis instruksjoner, for eksempel i form av overlapp, verktøytips, opplæringsprogrammer også videre, for å forklare hvilke gester som kan brukes for å styre et gitt grensesnitt, og om det finnes alternativer. For at instruksjonene skal være effektive, bør de være lette å oppdage og tilgjengelige. Instruksjonene bør også være tilgjengelige når som helst når brukeren trenger dem, ikke bare ved første bruk, selv om de ved første bruk med fordel kan fremheves ekstra.

    Konsekvent navigering

    Navigasjonskomponenter i appen bør presenteres i samme rekkefølge på tvers av ulike sider i appen. Forutsigbarhet er viktig for mange brukere, og endringer i grensesnittet innenfor appen vil være forstyrrende for alle. Det betyr at hovednavigering og andre navigasjonmekanismer som gjentas på flere sider, for eksempel logo, søkefelt, meny og «Hopp til hovedinnhold»-funksjon, bør presenteres med samme oppsett på ulike sider i appen, og fungere på samme måte. Dette gjelder også når det brukes responsivt design, hvor komponentene ordnes basert på enhetsstørrelse og skjermretning.

    Det er ikke et krav at oppsettet skal være likt mellom ulike skjermstørrelser eller skjermretninger, men det vil være et pluss for brukerne om det følger samme oppsett. For eksempel kan en app ha noen komponenter som er skjult eller vises i en annen rekkefølge når appen vises i forskjellige skjermstørrelser eller visningsretninger, men de komponentene som vises, forblir konsekvente innenfor hver skjermstørrelse og -retning.

    Eksempel

    En app har en logo, en tittel, et søkeskjema og en navigasjonslinje øverst på hver side, som vises i samme relative rekkefølge på hver side der de gjentas. På én side mangler søkeskjemaet, men de andre elementene er fortsatt i samme rekkefølge. Når appen vises på en liten skjerm i portrettmodus, er navigasjonslinjen sammenfoldet til et enkelt ikon, men oppføringene i nedtrekksmenyen som vises når ikonet aktiveres, er fortsatt i samme relative rekkefølge.

    Konsekvent identifikasjon

    Komponenter med tilsvarende funksjon som brukes på flere ulike sider i en app, bør ha lik visuell utforming og identifiseres i koden på en konsistent måte. Dette kan for eksempel gjøres ved at søkefelt, «hjem»-knapp, «last ned»-funksjon, «neste/forrige side»-knapper, ikoner og menyer som går igjen på flere sider i en app ser visuelt like ut, og har konsistent ledetekst eller tekstalternativ i koden. Det er ikke nødvendig at identifikasjonen er identisk, men konsistent.

    Eksempel på konsistent referanse til andre sider

    En app hvor søkeresultater vises over flere sider, og hver side i resultatvisningen har en lenke til den første siden, forrige siden, og neste siden, osv. er ledeteksten til knappene «Side 1», «Side 2», «Side 3» osv. Selv om ledetekstene ikke er identiske, er de konsistente.

    Eksempel på søkefelt

    Et søkefelt som brukes på flere sider i appen ser visuelt likt ut, og er kodet med den samme ledeteksten på alle sidene hvor søkefeltet brukes. Så lenge funksjonen til søkefeltet er den samme på tvers av sidene, bør man ikke bruke ledeteksten «Søk» på en side, og «Finn» på en annen.

    Gjør det tydelig at elementer er klikkbare

    Elementer som utløser endringer, bør kunne skilles tydelig fra ikke-klikkbare elementer som innhold, statusinformasjon osv. Det bør gis en tydelig indikasjon på at elementer i appen som lenker og knapper er klikkbare. Dette gjelder spesielt på berøringsskjermer der klikkbare elementer vanligvis oppdages visuelt (berøring og musbruk). Interaktive elementer må også være mulige å oppdage for brukere som er avhengige av et programmatisk bestemt tilgjengelig navn, slik som skjermleserbrukere.

    Seende brukere som samhandler med innhold ved hjelp av berøring eller visuelle markører (for eksempel mus, styreplate, joysticker) bør kunne tydelig identifisere klikkbare elementer som lenker eller knapper. Eksisterende konvensjoner for godt design av brukergrensesnitt har som mål å bruke visuelle indikatorer på at elementer er klikkbare. Etter prinsippet om redundante koder bør det være mer enn ett visuelt kjennetegn på at elementer er klikkbare. Å følge disse konvensjonene er til fordel for alle brukere, men spesielt for brukere med synshemninger.

    Visuelle kjennetegn som kan skille et klikkbart element fra andre inkluderer form, farge, stil, posisjonering, tekstetikett for en handling og konvensjonell ikonografi.

    Eksempler på kjennetegnende egenskaper:

    Form: Knappform (avrundede hjørner, skyggelegging), avkryssingsboks, rektangel for utvalg med pil som peker nedover.

    Visuelle ikoner: spørsmålstegn for mer informasjon, hjem-ikon, hamburgerikon for meny, diskett for lagre, tilbakepil.

    Fargeavvik: form med annen bakgrunnsfarge for å skille elementet fra sidebakgrunnen, annen tekstfarge.

    Stil: Understreket tekst og farge for lenker.

    Plassering: Vanlig plassering av elementer som tilbakeknapp i nedre venstre hjørne (iOS), og menyelementer innenfor venstrejustert nedtrekksliste for navigasjon.

    Språkendringer på siden

    Har du skrevet deler av innholdet i appen på et avvikende språk bør dette komme frem av koden. Dette kan for eksempel være et sitat som er skrevet på et annet språk, eller at sideinnholdet er på et språk og menyene på et annet. For native apper er dette en anbefaling, men for nettapper og nettsteder er det lovkrav.

    Begreper som er blitt en del av språket, som egennavn og lignende, trenger ikke å merkes opp. For eksempel finnes ordet «date» i norske ordbøker, og norske skjermlesere kan uttale ordet korrekt. Det betyr at en norsk tekst kan inneholde ordet «date» uten at du må spesifisere at dette er et engelsk ord.

    Det kanskje vanligste tilfellet av språkendringer er når appen har en avdeling på et annet språk, for eksempel egne engelske sider. Da er ofte menyene og footeren fortsatt på norsk. I dette tilfellet kan du enten bestemme deg for at hovedspråket skal være engelsk, for så å merke opp de norske områdene med norske språkkoder, eller at hovedspråket skal være norsk og at det engelske innholdet merkes opp med engelsk språkkode. Det viktigste er at du husker å definere både hovedspråk og språkendringer.

    OBS: Husk at dette kravet også gjelder for ledetekster som er programmatisk angitt.

    Språkkoder

    Språkkoden kan støtte alle typer opplesing, både hjelpemiddel for personer med lesevansker, skjermlesere for sterkt svaksynte og innebygde opplesingsfunksjoner. For å angi språk benytter du språkkodene som er definert i standarden ISO 639-1.

    Noen eksempler på slike språkkoder er:

    • no – norsk
    • nb – norsk bokmål
    • nn – nynorsk
    • se – samisk (nordsamisk)
    • en – engelsk
    • sv – svensk
    • da – dansk
    • de – tysk
    • fr – fransk

    Det norske språket har altså tre språkkoder: «no», «nb» og «nn». «no» er vanligst å bruke for å definere at siden er på norsk, men du kan også velge «nb» eller «nn», avhengig av om siden er skrevet på nynorsk eller bokmål.

    Liste over samtlige godkjente språkkoder (ekstern side, engelsk). Merk at det er koder med to bokstaver som gjelder.

    Kodeeksempel for Andriod (Kotlin)

    På Android, kan du bruke «LocaleSpan» for å merke deler av innhold på et spesifikt språk. Flere «LocaleSpan» kan samles/embeddes i en «SpanableString» for å merke innhold på flere ulike språk.

    val locale = Locale.forLanguageTag("no-NB")
    val localeSpan = LocaleSpan(locale)

    val string = SpannableString("Appt")
    string.setSpan(localeSpan, 0, string.length, Spanned.SPAN_INCLUSIVE_INCLUSIVE)

    element.setText(string)

    Kodeeksempel for iOS (Swift)

    På iOS kan «accessibilitySpeechLanguage», nøkkelen for «NSAttributedString» brukes for å merke deler av innhold på et spesifikt språk. Flere «NSAttributedString» kan samles/embeddes i en «NSMutableAttributedString» for å merke innhold på flere ulike språk.

    I tillegg kan «accessibilityLanguage»-attributtet til «UIAccessibility”-protokollen brukes til å angi et enkelt språk for et element. Mange objekter implementerer denne protokollen, som «UIApplication» og «UIView».

    element.attributedText = NSAttributedString(
    string: "Appt",
    attributes: [.accessibilitySpeechLanguage: "no_NB"]
    )

    application.accessibilityLanguage = "no_Nb"
    view.accessibilityLanguage = "no_NB"

    Hjelp brukerne å forhindre alle feil i skjema

    Vi anbefaler å hjelpe brukerne til å forhindre feil i alle typer skjema, også de som ikke medfører juridiske forpliktelser, krever økonomiske transaksjoner, endrer eller sletter brukerstyrte data i datalagringssystemer eller som sender svar på tester utført av brukeren. Dette gjøres ved å gi brukeren mulighet til å kontrollere at oppgitt informasjon er korrekt, mulighet til å rette opp feil før innsending, eller mulighet til å angre eller reversere innsendingen.

    Hjelp brukerne å forstå innholdet

    Gjør det lettere for brukerne av appen eller nettløsningen din å forstå innholdet du legger ut ved å tilby tilleggsinformasjon.

    Uvanlige ord

    For ord og uttrykk som brukes på en uvanlig eller begrenset måte, bør du tilby ordforklaring via en mekanisme (for eksempel knapp). Dette omfatter blant annet idiomer og sjargong.

    For eksempel det norske uttrykket «hoppe etter Wirkola» som kan forklares som en risiko for å skuffe publikum gjennom å prestere dårligere enn den foregående. Dette er et idiom som kan brukes uavhengig av hoppsporten, men er knyttet opp mot skihopperen Bjørn Wirkolas gode prestasjoner.

    Forkortelser

    Dersom teksten din inneholder forkortelser, spesielt der den forkortede formen av et ord ikke er blitt en del av språket, bør du tilby den fullstendige formen eller betydningen av forkortelsen via en mekanisme (for eksempel knapp).

    Leseferdighet

    Dersom en tekst i appen eller på nettsiden din krever leseferdigheter på et nivå som er høyere enn det som forventes etter norsk ungdomsskole, bør du tilby ekstra innhold som gjør det lettere å forstå teksten. Det kan for eksempel være en lydversjon, en illustrasjon eller en oppsummering av det viktigste. Det er viktig at denne tilleggsinformasjonen ikke krever leseferdigheter på et høyere nivå enn det som forventes etter norsk ungdomsskole.

    Uttale

    For ord som kan ha ulik betydning avhengig av hvordan ordet uttales i ulike kontekster, men denne konteksten ikke er tydelig i teksten, bør du tilby informasjon om hvordan ordet uttales. Dette kan for eksempel gjøres ved å ha en mekanisme hvor brukeren kan få opp den fonetiske beskrivelsen av ordet, eller en lydfil av hvordan ordet uttales.

    Kontekstendringer

    Det anbefales å gi brukerne full kontroll over kontekstendringer i appen eller på nettsiden ved at disse enten kun skjer som følge av en handling fra brukeren, eller at brukeren har mulighet til å skru av slike endringer ved hjelp av en mekanisme. Med kontekstendring menes for eksempel at innhold åpnes i et nytt vindu, at fokus flyttes til en annen komponent eller at innhold oppdateres av seg selv.