Kriteriesett

1.1 - Nettsted og tjenester er enkle å finne gjennom søk

Nettsted og tjenester må være enkle å finne gjennom søk. Ved søk på nettstedets navn, tjenestens navn (eventuelt kortnavn) eller det nettstedet/tjenesten vanligvis kalles, skal brukeren få et relevant treff blant de 5 første treffene på trefflista.

For statlige tjenester gjelder dette uavhengig av om man søker på bokmål eller nynorsk. For kommunale tjenester gjennomføres søket på den målformen kommunen benytter.

For tjenester vil relevante treff enten være direkte til tjenesten, eller til tilknyttede informasjonssider på nettstedet.

Nettstedet skal også ha en søkefunksjon som gjør det mulig å søke internt på nettstedet, og denne skal være lett tilgjengelig, konsekvent plassert og viser minst 20 synlige tegn.

TestpunkterPoeng (60)
Eksternsøk - Søk på nettstedets navn eller den benevnelsen som det er allment kjent under gir relevante treff med beskrivende titler blant de 5 første på trefflista.20
Eksternsøk, tjeneste – Søk på tjenestens navn eller den benevnelsen som den er allment kjent under gir relevante treff med beskrivende titler blant de 5 første på trefflista.20
Internsøk (forekomst) - Nettstedet har en søkefunksjon som er lett tilgjengelig, konsekvent plassert og med et søkefelt som viser minst 20 synlige tegn.5
Internsøk - Søk på relevant innhold, for eksempel navnet eller den benevnelsen som en digital tjeneste er allment kjent under, gir relevante treff blant de 5 første på trefflista.15
Internsøk, delvis - Internt søk på nettstedet gir ikke relevante treff, men søkefunksjonen på nettstedet har hjelpeverktøy som gir en bedre resultatliste.5

Slik tester du

Søk via ekstern søkemotor

Bruk Google og Bing. Søk på nettstedets og tjenestens navn (i to forskjellige omganger, ikke samtidig), eller den benevnelsen som tjenesten eller nettstedet er allment kjent under. Sjekk at søket gir relevante treff blant de 5 første på trefflista. For å oppfylle kravet til tjeneste skal du komme til informasjonssiden til tjenesten på forsiden, eller direkte til tjenesten.

For statlige tjenester skal søket gjøres både på bokmål og nynorsk, dersom det er forskjeller mellom disse. For kommunale tjenester gjennomføres søket på den målformen kommunen benytter.

Søkehistorikken din vil kunne påvirke resultatet i denne testen, så det kan derfor være aktuelt å ta i bruk teknikker for anonymisering. Hvilke søketermer som er brukt i de ulike søkemotorene, skal oppgis i kommentarfeltet i vurderingen.

Søk via intern søkemotor

Sjekk forekomst av intern søkefunksjon på nettstedet. Vurder om det er lett tilgjengelig, om det er konsekvent plassert på alle sider (med unntak av forsiden) og om det er plass til 20 tegn synlig i feltet.

Gjør ulike søk etter relevant innhold (finn relevant innhold på sidene i forkant, og se om dette er mulig å finne gjennom søk). Dersom nettstedet også har digitale tjenester, sjekk om det er mulig å finne disse via søk (med søk på tjenestenavn eller det den er allment kjent som). Sjekk om søket gir relevante treff blant de 5 første på trefflista. Dersom trefflista ikke er optimal, sjekk hvorvidt søkefunksjonen har hjelpeverktøy for sortering eller gruppering etter tema eller emner og at bruk av disse forenkler søkeprosessen og muliggjøre relevante treff. Bruk delvis-alternativet dersom sistnevnte stemmer.

For statlige tjenester skal også internsøket gjøres både på bokmål og nynorsk, dersom det er forskjeller mellom disse. For kommunale tjenester gjennomføres søket på den målformen kommunen benytter.

 

1.2 - Innhold er enkelt å identifisere

Alle sider skal ha beskrivende overskrifter, en unik og beskrivende sidetittel og en beskrivende adresse (URL). Overskriftene skal deklareres i heading-taggen (h) og sidetittelen i title-taggen.

Sidetittelen skal beskrive formålet med tjenesten eller innholdet på siden, og på nettsteder skal virksomhetens navn også være med. Dersom det finnes flere som tilbyr samme type tjeneste (for eksempel søknad om barnehageplass, som er noe alle kommuner tilbyr), skal tjenesteeiers virksomhetsnavn også skal være med i tittelen. Virksomhetsnavnet bør komme til slutt i tittelen, både i tjenesten og på nettstedet.

Språket som blir brukt i den beskrivende adressen (URLen) på informasjonssidene, skal være det samme som hovedspråket på nettstedet (det som er mest brukt).

TestpunkterPoeng (40)
Alle sider har beskrivende og korrekt kodede overskrifter.15
Alle nettstedets sider, samt tjenestens eller tjenesteportalens startside har beskrivende sidetittel (title-tag).10
Alle nettstedets sider har beskrivende adresser (URL) på hovedspråket.15

Slik tester du

Overskrifter

Sjekk at alle sider, både på nettstedet og i tjenesten, har beskrivende og korrekt kodede overskrifter i heading-tagen (h). Rett bruk av overskriftsnivå sjekkes i indikator 4.5, mens mer utfyllende språk, herunder avsnitt og overskrifter, sjekkes i 5.5.

Sidetittel

Sjekk i kildekoden at sidetittelen ligger i title-taggen, og at denne er unik og beskrivende både på informasjonssider på nettstedet og på tjenestens eller tjenesteportalens startside. På nettstedet skal virksomhetens navn være med. I tjenesten skal virksomhetsnavn være med dersom det er flere som tilbyr samme tjeneste (for eksempel søknad om barnehageplass, som er noe alle kommuner tilbyr).

Dersom testen gjelder en tjenesteeier med flere tjenester, skal hver tjeneste ha sitt unike navn.

Beskrivende adresser (URL)

Sjekk om sidene på nettstedet har beskrivende URLer, og at disse er på samme språk som hovedspråket på nettstedet (norsk URL-tekst på sider med innhold på norsk).

 

2.1 - Identitet, formål og oppgaver kommer klart fram

De offentlige nettstedene er en viktig kilde til informasjon om virksomhetenes oppgaver og ansvar. Det skal framgå tydelig hvilken offentlig instans som er ansvarlig for nettstedet og for tilknyttede tjenester.

Ved bruk av sammensatte tjenester, der flere virksomheter er involvert, må brukeren være sikker på hvem som er ansvarlig for hva, for eksempel hvem som har behandlingsansvaret for personopplysninger.

Navnet (eventuell logo) på tjenesten og ansvarlig virksomhet må være synlig på alle sider. ID-portens og Feides tjenesteeiere trenger ikke profileres da felles innloggingsløsninger er en del av en sømløs prosess.

TestpunkterPoeng (35)
Det er lett å identifisere hvem som er ansvarlig for nettstedet.5
Nettstedet har informasjon som presenterer formål og oppgaver knyttet til de viktigste ansvarsområdene.10
Det er lett å identifisere tjenesteeier.20

Slik tester du

Identifisering av ansvarlig virksomhet

Sjekk om det er lett å identifisere hvem som har ansvar for nettstedet og tjenesten gjennom navn og eventuell logo.

Informasjon om ansvarsområder

Sjekk at nettstedet har innhold som beskriver virksomhetens formål og ansvarsområder. Når det gjelder oversikt over tjenesteområdene kommunene har ansvaret for, er det tilstrekkelig at dette kommer fram indirekte gjennom informasjonsarkitekturen. Det skal i tillegg være mulig å forstå hvordan kommunen styres (politisk og administrativt), og hvem som har ansvaret for de viktigste oppgavene.

Eksempel

 

2.2 - Tilpasset plikt- og rettighetsinformasjon er tilgjengelig for brukerne av tjenesten

Brukeren skal lett kunne sette seg inn i sine lov- eller forskriftsbestemte rettigheter og plikter i tilknytning til en tjeneste. Tjenesteeier må derfor formulere og presentere en brukertilpasset plikt- og rettighetsinformasjon for den konkrete tjenesten.

Informasjonen må plasseres der den er mest aktuell for brukerens oppgaveløsning.

Det bør i tillegg henvises (lenkes) videre til mer detaljert informasjon i form av kildedokumenter og formelt regelverk (hjemmel).

Noen rettigheter og plikter er spesifikke for tjenesten, mens andre gjelder for tjenester generelt. Et eksempel på det siste er rettigheter knyttet til personvern, se indikator 3.1 for slike krav.

TestpunkterPoeng (28)
Tilpasset plikt- og rettighetsinformasjon er lett tilgjengelig og blir presentert i tilknytning til brukerens oppgaveløsning .20
Lenker til relevante lover, forskrifter eller annen utdypende informasjon er tilgjengelig fra tjenesten8

Slik tester du

Sjekk at det finnes en tilrettelagt beskrivelse av plikter og rettigheter (tjenestens hjemmel). Sjekk at plikt- og rettighetsinformasjon blir presentert der den er aktuell, f.eks som ledd i brukerens oppgaveløsning.

Sjekk deretter at lenker til utdypende informasjon er tilgjengelig for brukeren, for eksempel i form av lenker til forskrifter og lover. Slike lenker kan enten ligge direkte i tjenesten eller være tilgjengelig via lenke til lenkesamling på nettstedets informasjonssider om tjenesten. Både lenker i tekst og i lenkesamlinger vil kunne tilfredsstille kravet.

 

2.3 - Brukerne av tjenesten finner informasjon om saksgang og krav til dokumentasjon

Brukerne skal enkelt finne informasjon om saksgang og saksbehandling, inkludert forventet saksbehandlingstid.

I de sakene som behandles etter forvaltningslovens bestemmelser skal brukerne informeres om framgangsmåte og frist for å fremme klage.

Det skal også informeres om hvilke opplysninger brukerne forventes å bidra med for å kunne gjennomføre en nettbasert oppgaveløsning. Dette gjelder opplysninger som ikke er vanlig å huske. Brukerne skal også informeres om hvor (i hvilke dokumenter) slike opplysninger kan finnes.

Det skal informeres om hvilke alternativer som finnes til bruk av den digitale tjenesten.

TestpunkterPoeng (35)
Brukerne får informasjon om hvilke opplysninger det er nødvendig å ha tilgjengelig for å kunne bruke tjenesten.10
Brukerne får informasjon om saksgangen.10
Brukerne finner informasjon om framgangsmåten for å fremme klage.10
Brukerne finner informasjon om eventuelle alternative løsninger til den digitale tjenesten.5

Slik tester du

Sjekk at informasjonssidene eller tjenestens startside gir tilstrekkelig informasjon dersom brukerne på forhånd må ha funnet fram bestemte opplysninger for å gjennomføre oppgaveløsningen. Vurderingen skal skjønnsmessig ta hensyn til tjenestens kompleksitet og omfang. Innhold som det er vanlig å huske, som navn, adresse og fødelsdato, er det unødvendig å informere om på forhånd.

Vurder hvorvidt innholdet på informasjonssider, i selve tjenesten eller i kvittering eller svarbrev, gir brukerne tilstrekkelig informasjon om saksgang/saksbehandling, sakbehandlingstid og mulighet for å fremme klage på vedtak.

Sjekk også om det finnes informasjon om eventuelle alternative løsninger til den digitale tjenesten, eller om dette er eneste måte (f.eks papirskjema, oppmøte, etc).

 

2.4 - Brukerne av tjenesten får bekreftelse på innsending av opplysninger

Etter å ha fullført en digital tjeneste skal brukeren få både en umiddelbar bekreftelse på innsendingen og en kvittering. Dette kan være én og samme ting dersom den oppfyller alle krav.

Den umiddelbare bekreftelsen er siden som kommer opp rett etter at brukeren har trykket på send inn eller bestill. Her skal det bekreftes at tjenesten er fullført, og tid og dato skal være oppgitt.

I tillegg skal brukeren få en kvittering som inneholder mer utdypende informasjon enn den umiddelbare bekreftelsen. Dette kan for eksempel være en kvitteringsside, på epost eller gjennom en innloggingsløsning (typisk MinSide eller lignende).

Den umiddelbare bekreftelsen kan også være kvittering, men for å skille kravene for hva man skal få umiddelbart og hva man kan få senere, har vi valgt å bruke to ulike navn her.

Den utfyllende kvitteringen skal inneholde:

  • innsynsrett
  • saksgang
  • fullstendig dokumentasjon på hva som er meddelt gjennom tjenesten
  • informasjon om muligheter for å gjøre endringer
  • kontaktinformasjon
  • eventuelle andre opplysninger som er viktige for brukeren

Dersom den umiddelbare bekreftelsen inneholder alle disse opplysningene (eller informasjon om hvordan man kan få tilgang til dem), vil dette være godt nok til å oppfylle begge kravene.

Vær oppmerksom på at det ikke må sendes taushetsbelagte opplysninger i kvitteringer over ikke-sikre kanaler (f.eks. ikke-kryptert e-post).

TestpunkterPoeng (30)
Ved innsending av opplysninger får brukerne umiddelbart en bekreftelse på skjerm.15
Ikke relevant – Det er ikke nødvendig med umiddelbar bekreftelse på skjerm.15
Brukerne finner meddelte opplysninger etter innsending, samt informasjon om kontakt, innsyn og saksgang.15
Ikke relevant – Det er ikke nødvendig å gi tilgang til meddelte opplysninger og annen informasjon.15

Slik tester du

Fullfør tjenesten ved å trykke på send inn- eller bestill-knappen. Sjekk at disse to kravene er oppfylt (de kan være én og samme side, eller to separate):

Du får umiddelbart opp en side som bekrefter innsendingen. Denne inneholder tid og dato, og en bekreftelse på at tjenesten er fullført.

Du får i tillegg en kvittering som inneholder mer utfyllende informasjon. Dette kan for eksempel være i form av en egen kvitteringsside, på e-post eller gjennom en innloggingsløsning (typisk MinSide eller lignende). Dette skal komme rett etter innsending, for eksempel vil e-post en dag senere ikke være godt nok. Kvitteringen skal ha følgende informasjon:

  • innsynsrett
  • saksgang
  • fullstendig dokumentasjon på hva som er meddelt gjennom tjenesten
  • informasjon om muligheter for å gjøre endringer
  • kontaktinformasjon
  • eventuelle andre opplysninger som er viktige for brukeren

Dersom den umiddelbare bekreftelsen inneholder alle disse opplysningene (eller informasjon om hvordan man kan få tilgang til dem), vil dette være godt nok til å oppfylle begge kravene, det trenger ikke være to separate sider.

Alternativet «ikke relevant» brukes for tjenester hvor umiddelbar respons og kvittering ikke er aktuelt eller ikke gir noen merverdi for brukeren, for eksempel i innsynstjenester.

 

2.5 - Brukerne har mulighet til å gi tilbakemelding

I samsvar med åpenhets- og medvirkningsprinsippene i den statlige kommunikasjonspolitikken skal brukerne enkelt kunne uttrykke sine erfaringer med nettsted og tjenester i form av kommentarer, rangeringer, kritikk og forbedringsforslag.

Tilbakemeldinger kan gis på flere ulike måter som innsendingsskjema, kommentarfelt, kommentarbokser ("fant du det du lette etter?") eller liknende. I tjenesten er det nok å lenke til en side på nettstedet som har slik funksjonalitet (selv om egen funksjonalitet ofte vil være enklere for brukeren), og funksjonaliteten bør være tilgjengelig flere steder enn bare etter innsending for å også få tilbakemelding fra de som ikke fullfører prosessen.

Brukeren skal frivillig kunne velge å være anonym når han eller hun gir tilbakemeldinger.

Virksomheten kan også tilrettelegg for dialog med brukerne via sosiale medier. Det er tilstrekkelig at virksomheten har en generell sosial kanal, f.eks en Facebook-side, Twitter-konto, Flickr-konto eller liknende. Før aktivitet i sosiale media, må virksomheten ha utviklet klare retningslinjer for hva som kan publiseres og det må alltid ta hensyn til personvernet. Se også Difis veiledning om bruk av sosiale medier i offentlig forvaltning.

TestpunkterPoeng (25)
Det er enkelt å gi tilbakemelding.20
Det er mulig å gi tilbakemelding gjennom sosiale medier.5

Slik tester du

Tilbakemelding

Sjekk om det er enkelt å gi tilbakemelding på innholdet både på nettstedet og i tjenesten. Eksempler på tilbakemeldingsfunksjonalitet kan være innsendingsskjema, kommentarfelt, kommentarbokser ("fant du det du lette etter?") eller liknende.

I tjenesten er det ikke krav om egen tilbakemeldingsfunksjonalitet (selv om dette ofte er enklest for brukeren), det er tilfredsstillende å lenke til en side på nettstedet med slik funksjonalitet. Lenken skal være lett tilgjengelig.

Sosiale media

Sjekk om virksomheten sin aktivitet i sosiale media er profilert og lenket til på nettstedet. Det er ikke nødvendig å profilere sosiale media i tjenesten. Innhold i sosiale media bør være mulig å lese uten innlogging, dersom dette er mulig, slik at flest mulig får nytte av det. Vi legger ingen føringer på hvilke sosiale media som bør brukes, dette bør vurderes av virksomheten selv.

 

2.6 - Nettstedet legger til rette for innsyn i postjournal

Offentlighetsloven med tilhørende forskrift lovfester innbyggerens rettighet til innsyn i offentlig virksomhet. Vi belønner derfor virksomheter med nettsteder som tar i bruk webteknologien for å gjøre postjournalene lettere tilgjengelig og enklere å bruke for innbyggeren.

Dokumentbestilling betyr at brukeren via funksjonalitet på nettstedet kan kreve innsyn i dokumentene direkte fra nettstedet eller fra eInnsyn (tidligere Offentlig Elektronisk Postjournal - OEP) dersom virksomheten benytter denne som publiseringsløsning. eInnsyn har også støtte for å vise til fulltekstpubliserte dokument. Bestillingsfunksjonen bør være enkel å bruke. Det skal for eksempel ikke være nødvendig å klippe og lime saksnummer, dokumenttittel eller lignende.

Dokumentbestilling via e-post er ikke poenggivende. Alternativet «ikke relevant» blir kun anvendt dersom nettstedet ikke representerer en virksomhet, eller dersom virksomheten av ulike grunner ikke fører journal. Dersom virksomheter av sikkerhetshensyn ikke kan fulltekstpublisere dokumenter, må dette dokumenteres i vurderingen for å få poengmessig full uttelling.

TestpunkterPoeng (25)
Nettstedet har postjournal i HTML med fulltekstpublisering av alle inngående og utgående dokumenter.20
Nettstedet har postjournal i HTML med dokumentbestilling i HTML-skjema.15
Nettstedet har enkel postjournal i HTML.10
Nettstedet har enkel postjournal i nedlastbare formater (som for eksemplel PDF, DOC eller liknende formater).5
Postjournalen har i tillegg gode søk- og sorteringsmuligheter.5
Ikke relevant - Nettstedet representerer ikke en virksomhet eller er eksplisitt unntatt gjennom forskrift.25

Slik tester du

Kontroller om nettstedet publiserer virksomhetens postjournal og hvor omfattende funksjonalitet som er bygd inn i løsningen. Sjekk hvorvidt fulltekstpublisering og dokumentbestilling inngår. Vi stiller krav om at bestillingsfunksjonen skal være i html-skjema. Bestillingsfunksjon via e-post gir ikke poeng. Postjournalen skal inneholde alle inngående og utgående dokumenter (som ikke er unntatt offentlighet). Postjournal som er publisert i PDF, DOC eller likende formater, skal kun ha 5 poeng.

Ekstrapoeng gis der postjournalen har lett tilgjengelig søk- og/eller sorteringsmuligheter. Gode sorteringsmuligheter innebærer mulighet til å sortere journalen etter minst tre av disse typene:

  • Inngående/utgående post
  • Saksnummer/navn
  • Avsender/mottaker
  • Dokumentdato

Alternativet «Ikke relevant» skal bare brukes dersom nettstedet ikke representerer en virksomhet og derfor ikke har egen postjournal, for eksempel www.norge.no, som er en portal eid av Direktoratet for forvaltning og IKT (Difi). Se ellers de virksomhetene som er listet opp i forskriften til Offentlighetsloven §1 og som er unntatt fra lovens virkeområde.

 

2.7 - Nettstedet legger til rette for innsyn i saker og møter

I samsvar med offentleglova og bestemmelsene om møteoffentlighet i kommuneloven har brukerne en lovfestet rett til innsyn i saker og møter.

Indikatoren gir poeng til organisasjoner som tar i bruk webteknologien for å forenkle denne prosessen, og som aktivt bruker nettet for å åpne opp organisasjonen. Innsyn i hva som skjer i organisasjonen, i form av publisering av saksdokumenter, referater og/eller lyd/videooverføring fra møter, er med på å fremme demokrati, deltakelse og åpenhet.

Hvem gjelder dette for?

Krav om innsyn i saker og møter og digitalt innsyn gjelder der virksomheter er pålagt å tilrettelegge for innsyn og/eller møteoffentlighet gjennom:

  • lover
  • forskrifter
  • egne vedtekter
  • særlige styringsdokument

For innsyn i saker og møter brukes alternativet «Ikke relevant» kun dersom nettstedet ikke representerer en virksomhet eller ikke er pålagt møteoffentlighet, for eksempel der hvor virksomheten er et rent forvaltningsorgan. Et eksempel på det første er Matportalen.no, som er en portal med innhold fra flere ulike virksomheter. Et eksempel på det andre er direktoratene. Det kan også være andre særskilte grunner som gjør at ulike former for innsyn ikke kan praktiseres. Bakgrunnen for dette må i tilfelle forklares og begrunnes.

Dokumenter i denne forbindelse skal som hovedregel publiseres som HTML på nettstedet (altså direkte som tekstinnhold).

TestpunkterPoeng (30)
Innsyn i saksdokument – Nettstedet publiserer innkalling, saksdokument og/eller referat/protokoll fra møter i HTML.15
Innsyn i saksdokument, delvis – Nettstedet publiserer innkalling, saksdokument og/eller referat/protokoll fra møter i nedlastbare formater (som for eksempel PDF, DOC eller lignende formater).5
Ikke relevant med innsyn i saksdokument.15
Digitalt innsyn – Nettstedet publiserer lyd- eller videooverføringer fra møter.15
Ikke relevant med digitalt innsyn.15

Slik tester du

Se etter mulighet til innsyn i saker og møter på nettstedet. Innsyn i saksdokument innebærer muligheten til å se eller laste ned saksdokumenter, innkallinger eller referater/protokoller fra møter. Sjekk at dokumentene publiseres i HTML. Dersom dokumentene publiseres i PDF, DOC eller andre likende formater, gis det kun poeng for delvis - 5 poeng.

Digitalt innsyn krever mulighet til å se eller laste ned lyd- eller video-overføringer fra møter.

Alternativet «Ikke relevant» skal kun benyttes dersom nettstedet ikke representerer en virksomhet, ikke er pålagt møteoffentlighet eller er unntatt offentleglova gjennom forskrift. Det kan også være andre særskilte grunner som gjør at ulike former for innsyn ikke kan praktiseres. Bakgrunnen for dette må i tilfelle forklares og begrunnes.

 

2.8 - Nettstedet legger til rette for elektroniske høringer

Elektroniske høringer er et svært nyttig verktøy for demokratisk dialog og deltakelse, og bidrar til å gjøre formelle høringer mer tilgjengelige for innspill.

Indikatoren sjekker i hvilken grad offentlige nettsteder benytter nettet for å få slike innspill, og belønner de som legger til rette for dette. En fullverdig høringsløsning skal gi tilgang til aktuelle høringsdokument, ha løsning for innsending av innspill og gi tilgang til andres innspill i saken.

TestpunkterPoeng (25)
Komplett høringsløsning – Nettstedet legger saker ut på høring med løsning for innsending av innspill og med tilgang til andre innspill i saka.25
Enkel høring med innsending eller publisering – Nettstedet legger saker ut på høring og har enten løsning for innsending av innspill eller publiserer disse på nettstedet.15
Enkel høring – Nettstedet legger saker ut på høring, men har ingen løsning for elektronisk innsending av innspill og publiserer heller ikke slike innspill på nettstedet.10

Ikke relevant – Type virksomhet gjør at nettstedet ikke kan ha saker på høring.

25

Slik tester du

Sjekk forekomst av løsning for elektroniske høringer på nettstedet og hvor omfattende funksjonalitet som er bygd inn i løsningen.

Bruk alternativet «komplett høringsløsning» dersom virksomheten legger saker ut på høring, har egen løsning for innsending av innspill og publiserer andre innspill i saka.

Bruk alternativet «enkel høring med innsending eller publisering» dersom virksomheten legger saker ut på høring og enten har egen løsning for å sende inn innspill ELLER mangler tilgang til andre innspill i saka på nett.

Bruk alternativet «enkel høring» dersom virksomheten bare legger ut saksdokument, men mangler skjema for innsending av innspill og ikke publiserer innkomne innspill på nett.

Bruk alternativet «ikke relevant» dersom type virksomhet ikke behandler formelle høringssaker. Avgjørelsen skal begrunnes med merknad i kommentarfeltet.

 

3.1 - Hensynet til personvern er ivaretatt

Brukeren skal informeres om nettstedets bruk av informasjonskapsler. Dette inkluderer hvilke informasjonskapsler som brukes, hvilke opplysninger som blir brukt, formålet med bruken, samt hvem som bruker opplysningene. Lenken til slik informasjon må utformes slik at det framgår av lenkenavnet at landingssiden gir informasjon om informasjonskapsler/cookies.

Er informasjonsplikten oppfylt, er det tilstrekkelig at brukeren har akseptert bruken av informasjonskapsler gjennom innstillingen i nettleseren. Dette gjelder også der nettleseren allerede er forhåndsinnstilt for aksept (dvs. at det ikke er nødvendig med «pop-ups» o.l.) Se for øvrig http://www.datatilsynet.no/Teknologi/Internett/cookies/

Alle tjenester skal ivareta hensynene til personvern og sporbarhet, og informere om hvordan personvern ivaretas, hvordan personopplysninger behandles, samt hvilke rettigheter de har til innsyn, retting og sletting.

Personvernerklæringen skal minst inneholde følgende punkter:

  • formålet med innsamling av personopplysninger
  • hvem som er behandlingsansvarlig
  • om det skjer utlevering til tredjeparter
  • framgangsmåte for å få innsyn
  • kontaktinformasjon

Det skal i ettertid være mulig å hente fram kopi av inngitte data og alle lagrede personopplysninger.

TestpunkterPoeng (25)
Brukerne finner informasjon om hvordan informasjonskapsler blir benyttet.10
Tjenesten har personvernerklæring som er tilgjengelig for brukerne både før og etter innlogging, og som fyller de oppgitte innholdskravene.15

Slik tester du

Informasjonskapsler/cookies

Sjekk på nettstedet og tjenestens startside hvorvidt lenkenavnet til informasjon om informasjonskapsler innholder ordene "informasjonskapsler" eller "cookies". Sjekk om landingssidens innhold har tilstrekkelig informasjon om bruk av informasjonskapsler. Dette inkluderer hvilke informasjonskapsler som brukes, hvilke opplysninger som blir brukt, formålet med bruken, samt hvem som bruker opplysningene.

Personvernerklæring

Sjekk om tjenesten har lenke til personvernerklæring. Lenken må være synlig både før og etter innlogging, for eksempel i footer. Erklæringen må inneholder følgende punkter: formål, behandlingsansvarlig, utlevering til tredjeparter, innsyn og kontaktinformasjon.

 

3.2 - Tjenester med sensitiv informasjon er kryptert

All kommunikasjon som innebærer utveksling av sensitive opplysninger eller fødselsnummer mellom innbygger og tjenesteeier, skal være kryptert. Tjenestene bør benytte SSL-sertifikater med utvidet validering.
TestpunkterPoeng (32)
Kommunikasjon av innhold med sensitive personopplysninger eller fødselsnummer er kryptert.8
Tjenesten får karakteren B- eller høyere i Qualys SSL Server Test.16
Tjenesten har SSL-sertifikat med utvidet validering (EV).8
Ikke relevant – kryptering er ikke nødvendig.32

Slik tester du

Kryptering

Sjekk om tjenesten inneholder sensitive opplysninger eller fødselsnummer. Dersom dette ikke er tilfelle, brukes alternativet "ikke relevant".

Dersom dette er tilfelle, sjekk at URLen (sideadressen i adresselinjen) til tjenestesidene begynner med httpS: altså bokstaven S like etter «http». Dersom dette er på plass, er tjenesten kryptert og gis poeng for dette. Tjenester som kun har "http://" (uten S), er ikke kryptert.

Qualys SSL Server Test

Bruk Qualys sitt "SSL Server Test"-verktøy. Kopier URLen til tjenesten (der utfyllingen begynner eller lignende) og lim inn i feltet "Domain name" i testverktøyet. Resultat fra B- og høyere godkjennes og gir poeng.

Utvidet validering

Sjekk hvorvidt tjenesten gir grønn farge i adressefeltet i nettleseren, og sjekk deretter hvorvidt testresultatet under «Authentification» i Qualys SSL Labs (forrige testpunkt) gir ja eller nei på utvidet validering (Extended validation).

 

4.1 - Nettsted og tjeneste er tilgjengelig over både IPv4 og IPv6

IPv4 og IPv6 (forkortelse for Internet Protocol version 4/6) er grunnleggende protokoller for kommunikasjon på internett. Alt utstyr som skal kobles opp mot internett, trenger en protokoll-adresse for å kunne nåes, enten det er en PC, en printer eller et kjøleskap.

Stadig flere enheter har behov for å knytte seg til nettet, og dette krever flere IP-adresser enn det IPv4 kan tilby. Mangelen på IPv4-adresser er reell. Som sentral leverandør av viktige nettsteder og nettjenester kan offentlig sektor spille en viktig rolle i overgangen fra IPv4 til IPv6, og en avventende holdning i det offentlige kan ha flere uheldige virkninger.

Referansekatalogen for anbefalte og obligatoriske IT-standarder i offentlig sektor anbefaler at alle offentlige nettsider og elektroniske tjenester, samt IT-tjenester det offentlige kjøper, bør ha støtte for både IPv4 og IPv6 (dual stack). Dette ble anbefalt av Standardiseringsrådet 14.juni 2011. Difi har også gjennomført en samfunnsøkonomisk analyse der konklusjonen er å gjøre støtte for både IPv4 og IPv6 obligatorisk.

I forbindelse med omleggingen har alle virksomheter et lovpålagt ansvar for å iverksette tiltak mot mulige sikkerhetsutfordringer. I denne sammenheng gjelder det blant annet sikkerhetsutfordringer knyttet til utstyr som støtter begge protokoller idag, og risikoen i arbeidet med overgang til dual stack og støtte for IPv6. 

I de fleste etater vil det være de som er ansvarlige for forvaltning av infrastruktur og domene (drift) som er ansvarlige for å iverksette omleggingen.

TestpunkterPoeng(20)
Nettstedet er tilgjengelig over både IPv4 og IPv6.10
Tjenesten er tilgjengelig over både IPv4 og IPv6.10

Slik tester du

Nasjonal kommunikasjonsmyndighet anbefaler følgende testsider:

 

4.2 - Nettsted og tjeneste er optimalisert for god ytelse og rask nedlasting

Nettsteder og tjenester skal bygges for god ytelse uansett plattform. Brukeren skal slippe å oppleve treg nedlastings- og responstid, og med stadig større utbredelse av teknologi som JavaScript, CSS, AJAX og teknologi på serversiden er ikke størrelse alene det som avgjør nettopp dette.

For å fange opp ytelsen bruker vi en kombinasjon av både størrelsesmåling og karaktersystemet i verktøyet YSlow, som kjører en rekke tester på nettstedet og tjenesten. Sidestørrelsene på nettstedet bør ikke være over 400KB, og både nettsted og tjeneste bør få karakteren A eller B.

TestpunkterPoeng (30)
Nettstedets sidestørrelser er på mindre enn 400 KB10
Nettstedets sidestørrelser er mellom 400 og 500 KB5
Nettstedet får karakteren A eller B i YSlow10
Tjenesten får karakteren A eller B i YSlow.10

Slik tester du

Ved hjelp av verktøyet YSlow (http://yslow.org/) testes forsiden og to undersider på nettstedet for både størrelse (i kb) og ytelse (karakter A eller B gir godkjent). I tjenesten testes startsiden i utfyllingsprosessen for ytelse (karakter A eller B gir godkjent).

Kriterisettet som skal brukes ved ytelsesmålingene, er "YSlow v2" som følger med verktøyet ved installasjon. Poenggivningen baseres på hvilket resultat som oppnås i de to testene. Sidestørrelser under 400kb gir full uttelling, men størrelser mellom 400-500kb gir delvis uttelling. Karakterkravet til både nettsted og tjeneste er A eller B.

 

4.3 - Nettsted og tjeneste er tilpasset mobile enheter

Den økende bruken av smarttelefoner og nettbrett tilsier at offentlige digitale tjenester og nettsteder bør tilrettelegges for bruk på mobile enheter.

Målet er at nettsteder og tjenester skal kunne benyttes på mobile visningsenheter med forskjellige skjermstørrelser. Det kan være ved hjelp av responsivt design (medietilpasset stilark, CSS) , eller en egen mobilversjon. Løsningen skal kunne brukes på de visningsenhetene og plattformene som er aktuelle for målgruppen og oppgaven. Det er derfor viktig at nødvendig funksjonalitet og informasjon er tilgjengelig også i mobiltilpassede versjoner, og at all funksjonalitet kan brukes på berøringsskjermer.

TestpunkterPoeng (45)
Mobilløsningen gir et godt helhetsinntrykk.35
Delvis - Mobilløsningen er tilpasset, men oppleves ikke som optimal.15
Nettstedets navigasjon og søk er lett å identifisere i alle skjermstørrelser.5
Alt innhold på nettstedet er mulig å nå fra mobil visning.5

Slik tester du

Helhetsinntrykk

Dette er en subjektiv helhetsvurdering av hvordan nettsted og tjeneste fungerer på forskjellige mobile enheter. Både nettsted og tjeneste er testet på smarttelefon og nettbrett, og hvilke enheter som har blitt brukt, vil bli oppgitt sammen med resultatet. Hva som blir lagt vekt på, vil variere noe, men følgende punkter vil ofte inngå vurderingen:

  • Både nettsted og tjenester gir et godt helhetsinntrykk. For nettsteder som blir vurdert sammen med en tjeneste, er det en forutsetning for å få poeng at begge deler er mobiltilpasset.
  • Nettstedet prioriterer det viktigste innholdet.
  • Oppgaveløsingen er enkel, inkludert at det er enkelt å fylle inn data.
  • Funksjonalitet som innlogging og innsending fungerer.
  • Innholdet i tjenesten er tilpasset visningen, inkludert at visningen tilpasser seg forskjellige enheter.
  • Viktige berøringselementer i tjenesten, f.eks. menyknapper og neste- eller forrige-knapp, er enkle å bruke (dvs. at de ikke er for små og at det er litt luft mellom dem).
  • Tekststørrelsen i tjenesten er tilstrekkelig stor.

Delvis-alternativet vil brukes i de tilfellene der både nettsted og tjeneste er mobiltilpasset, men ikke oppleves som optimale. Alternativet skal ikke brukes i tilfeller der for eksempel nettstedet er mobiltilpasset, men tjenesten ikke er det.

Navigasjon og søk

Navigasjonen bør være lett å identifisere i alle skjermstørrelser. På mindre skjermer bør horisontale menyer ofte unngås. Søkefunksjonen bør ligge utenfor menyen.

Alt innhold er mulig å nå

Nettstedet får poeng dersom alt innhold fra desktop-versjonen av nettstedet også er tilgjengelig fra mobile enheter. Eksempler på innhold en kan sjekke om er tilgjengelig begge steder, er alle menypunkter, og offentlig elektronisk postjournal (der det er relevant). Dersom en begrenset mobilversjon har lenke til det fullstendige nettstedet, vil dette også godkjennes – selv om det fullstendige nettstedet ikke er mobiltilpasset.

 

4.4 - Funksjonaliteten virker og innholdet er oppdatert

Alt innhold skal være oppdatert og all funksjonalitet skal virke, også på ulike operativsystemer og plattformer.

Det vil si at lenker og knapper virker uten feil, og at all informasjon er relevant og datert. Frister o.l. skal være oppdatert og tydelig markert, og dersom fristen er passert bør dette komme klart fram.

TestpunkterPoeng (20)
All funksjonalitet virker uten feil.10
Alt innhold på informasjonssidene er relevant og datert.10

Slik tester du

Sjekk relevante sider både på nettsted og i tjenesten og undersøk hvorvidt funksjonalitet, altså lenker, knapper og lignende, virker uten feil og i henhold til formål.

Sjekk relevante informasjonsider på nettstedet og vurder hvorvidt viktig informasjon, for eksempel innsendingsfrister, er oppdatert. Alle slike informasjonssider skal være datert.

 

4.5 - Alt innhold er korrekt kodet

Alt innhold må kodes korrekt og leveres i en form som sikrer at det kan presenteres i ulike brukeragenter uten at informasjon og struktur går tapt. Nettsted og tjenester skal utformes slik at de følger vedtatte standarder.

Dette innebærer at valideringskravet følger den standarden som er deklarert. Er HTML 5 deklarert, må nettsidene altså validere i henhold til HTML 5. Tjenesten må også fungere sammen med kompenserende teknologi og i ulike brukeragenter.

Hovedspråket skal deklareres i HTML-taggen, se veiledning for deklarering av språk.

TestpunkterPoeng (55)
CSS brukes for å skille mellom form og innhold.5
Semantisk HTML brukes for sikre samsvar mellom innhold og koding.20
Delvis - Semantisk HTML-koding er tatt i bruk, men ikke på en tilstrekkelig systematisk måte.10
Hovedspråket er deklarert i HTML-taggen.5
HTML-koden på 90 prosent av undersøkte sider på nettstedet validerer uten syntaksfeil.15
HTML-koden på 80 prosent av undersøkte sider på nettstedet har 10 eller færre syntaksfeil.7
HTML-koden på alle undersøkte sider i tjenesten validerer uten syntaksfeil.10

Slik tester du

Både nettsted og tjeneste testes for bruk av CSS, semantisk HTML, deklarering av språk og for validering av HTML-kode (syntaks). Bruk W3C Markup Validation Service for HTML-validering og sjekk den semantiske kodingen med støtte i verktøy som Structure-funksjonen i Web Accessibility Toolbar eller Outline-funksjonen i Web Devloper Toolbar.

Bruk av CSS for å skille form og innhold

Sjekk at CSS brukes for å skille form og innhold, og om tabeller brukes til layout. Gjør følgende tester på både nettsted og tjeneste:

  1. Skru av CSS med QuickJava i Firefox. Kontroller at all formatering blir tilbakestilt.
  2. Skru på tabellmarkering med Web Developer Toolbar (Outline – Outline Tables) eller Web Accessibility Toolbar (Tables - Table borders). Eventuelle tabeller vil nå være innrammet. Kontroller og vurder bruken av tabeller. Dersom tabeller aktivt er benyttet til layoutformål skal det ikke gis poeng for bruk av CSS.

Semantisk koding i tjenester

Testutvalget av skjemaelementer er avhengig av hvilke elementer som den aktuelle tjenesten har tatt i bruk. I og med at skjemaelementene i HTML brukes til å identifisere alt fra et enkelt input-felt, for eksempel et søkefelt, til kompliserte tjenester med flere og omfattende grupper med input-felt, gjør vi en skjønnsmessig vurdering av hvilke konkrete krav som skal gjøres gjeldende for den aktuelle løsningen. Generelt vil krav om bruk av «label» gjelde for de fleste input-felt, mens kravet om «fieldset» og «legend» gjelder for mer kompliserte nettskjema med grupper av input-felt med flere enn tre elementer. 

Følgende krav er eksempler på hvilke elementer som vil bli testet for hva, dersom de inngår i tjenesten:

  • Skjema: HTML-elementene “label”, “fieldset”  og “legend” er benyttet. Label-elementet brukes sammen med «for»-attributtet og ved bruk sammen med skjema (form)-elementet skal disse kobles korrekt sammen ved at attributtet «for» har samme verdi som skjema-elementets id-attributt. Dersom «legend» er tatt i bruk skal tekstinnholdet være beskrivende.
  • Knapper (buttons): Funksjonelle knapper er kodet med korrekte attributter og verdi. Dette kan for eksempel se slik ut: <input type=”submit” value=”Send inn”>.
  • Tekstelementer: Overskrifter er kodet riktig (h-tagg). Overskriftene skal, i tillegg til å være beskrivende, også ha rett bruk av overskriftsnivå for å strukturere teksten. I tillegg blir lister og brødtekst også testet for korrekt semantisk kode. Gjelder også informasjonssider tilknyttet tjenesten.

Semantisk koding på nettsteder

I likhet med testing av semantikk i digitale tjenester, vil vi også på nettsteder kunne teste de elementene som er mye brukt. I hovedsak vil vi teste overskrifter, brødtekst og lister.

Firefox – WDTB – Outline – Outline Custom Elements (skru også på «Show Elements Name When Outlining» i samme meny). Legg til disse 3 linjene (med eller uten teksten i parentes, det spiller ingen rolle, de bare forklarer hva de gjelder) i dialogboksen som kommer opp, og trykk OK):

  • Element 1: P,(tekstavsnitt)
  • Element 2: H1,H2,H3,H4,H5,H6,(overskrifter)
  • Element 3: OL,DL,UL,LI,DD,DT,(lister)

Test startsiden og tre sider på nivå 2. Kontroller at tekstavsnitt, overskrifter (se også at overskriftsnivåene er rett) og lister blir rammet inn. Alternativt kan Structure-funksjonen i Web Accessibility Toolbar benyttes som testverktøy.

Alternativet for "delvis" når det gjelder semantisk korrekt koding omhandler testsituasjoner der vi ser at semantisk koding er tatt i bruk, men at slik koding ikke i tilstrekkelig grad er systematisk gjennomført på alle testede elementer.

Språkdeklarering

IE – WAT – Doc Info – Show Lang Attributes. Kontroller at lang=”xx” ligg i HTML-taggen, for eksempel på denne måten <html lang=”no”>. Det er også godkjent at xml:lang=”xx” ligger i tillegg til lang=”xx”, men xml:lang="" alene er ikke godt nok.

Det er hovedspråket, altså det som er mest brukt på hver side, som skal deklareres. Sjekk både nettstedet og tjenesten.

HTML-validering

Vi sjekker omtrent 100 tilfeldige sider per nettsted mot W3C sin validator. Det finnes ulike verktøy på markedet som kan validere flere sider i en operasjon, eller du kan bruke W3C sin HTML-validator (en side om gangen).

Gi 15 poeng dersom minst 90 % av de undersøkte sidene validerer. Gi 7 poeng dersom minst 80 % av de undersøkte sidene har 10 eller færre feil.

I tjenesten kan du bruke W3C sin HTML-validator dersom tjenesten er tilgjengelig for alle. Dersom det finnes tilgangsbegrensninger (f.eks om tjenesten har innlogging), bør du bruke "Validate local HTML" i "Web developer toolbar" eller kopiere kildekoden og bruke W3C sin "Validate by direct input". Alle sider i tjenesten skal validere for å få poeng.

 

4.6 - Brukerne av tjenesten får varsel om tidsbegrensninger

Brukeren skal gis nok tid til å både forstå innholdet og utføre oppgavene sine.

Alle tidsbegrensninger skal informeres om/varsles på en tydelig og forståelig måte, og det skal være mulig å enten:

  • Skru den helt av
  • Justere den (velge hvor lang den skal være)
  • Forlenge den (varsles før utløp og enkelt kunne forlenge den)

For tjenester som bruker forlengings-alternativet er det viktig å merke seg at brukeren aktivt skal varsles når fristen nærmer seg, og at det skal være enkelt å forlenge den, for eksempel med å vise en dialogboks med informasjon og en egen forlengingsknapp. Vi anbefaler ikke løsninger som endrer kontekst, altså der brukeren må gå til en annen side og så tilbake igjen. Det vil heller ikke være tilfredsstillende å informere om tidsbegrensningen og forlengingsmuligheter i forkant av utfyllingen (vi skiller mellom «å informere» og «å varsle»). 

Det gis unntak for kravet i disse tilfellene:

  • Unntak i sanntid: Tidsbegrensningen er en nødvendig del av en hendelse i sanntid (for eksempel en auksjon), og det finnes ikke noe alternativ til tidsbegrensningen.
  • Nødvendig unntak: Tidsbegrensningen er nødvendig, og en forlengelse vil gjøre handlingen ugyldig.
  • 20-timers unntak: Tidsbegrensningen varer lenger enn 20 timer.

En mer detaljert forklaring av kravene og unntakene finnes i WCAG 2.2.1.

TestpunkterPoeng (10)
Brukerne får varsel om og mulighet til å forlenge eller skru av tidsbegrensninger.10
Ikke relevant - Tjenesten har ikke tidsbegrensninger10

Slik tester du

Sjekk om tjenesten har tidsbegrensninger, og om en av følgende mulighetene finnes:

  • Skru den helt av
  • Justere den (velge hvor lang den skal være)
  • Forlenge den (varsles før utløp og enkelt kunne forlenge den)

Sjekk at det gis et aktivt varsel og at det er enkelt å forlenge fristen.

 

5.1 - Det er enkelt å orientere seg

Det skal være enkelt for brukeren å orientere seg, både på nettstedet og i tjenesten.

Et nettsted kan ha en kompleks oppbygging med flere undernivåer, og det er derfor viktig at brukeren vet hvor han er i strukturen og hvordan denne er bygd opp. Brødsmulesti og/eller menymarkering gir begge god orienteringsstøtte og er likestilte poengmessig. Det er altså tilfredsstillende med bare én av disse. Brødsmulestien skal være klikkbar slik at det er mulig å navigere i strukturen, mens menymarkering skal være tydelig (mer enn endring av bare for- eller bakgrunnsfarge alene). Begge skal minimum dekke ned til nivå 3 i nettstedets struktur.

Det skal være enkelt å navigere seg fram til tjenester og annet relevant innhold på nettstedet. Det vil si at det er en inngang til den aktuelle tjenesten fra alle relevante informasjonssider.

I tjenesten er det viktig at brukeren får oversikt over prosessen og hvor langt han er kommet i oppgaveløsningen. Tjenesten skal derfor ha en enkel oversikt over stegene i utfyllingsprosessen og aller helst bør det være mulig å navigere mellom stegene i denne. Alle stegene i prosessen skal være synlig fra begynnelsen, men det gis unntak for tjenester som har sporvalg eller lignende der stegene varierer. Å kunne navigere fremover i stegene i tjenester med sporvalg vil heller ikke være aktuelt. Tjenesten skal også ha fremdriftsinformasjon for å vise hvor langt brukeren har kommet og hvor mye som gjenstår.

Stegoversikt og fremdriftsinformasjon skal være godt synlig og tilgjengelig i alle steg, samt være forklarende og konsistent utformet. Stegoversikt og fremdriftsinformasjon kan gjerne være ett og samme element så lenge utformingen er forståelig og ivaretar kravene til begge. Fremdriftsinformasjon kan vises på ulike måter, for eksempel ved å fortelle hvilket steg du er på (Steg 2 av 5), at det er tydelig markert hvor i stegoversikten du er eller prosentvis fullføring (60% fullført). Dersom tjenesten bruker en tallskala for å vise fremdriften (eks «Steg 2 av 5»), skal siste steg før innsending/bestilling være det høyeste tallet (altså «Steg 5 av 5», og ikke «Steg 4 av 5» der kvittering etter innsending blir «Steg 5 av 5»).

TestpunkterPoeng (55)
Nettstedet har menymarkering og/eller klikkbar brødsmulesti.10
Nettstedet har enkel intern navigasjon til tjenesten eller annet relevant innhold.20
Delvis – Nettstedets interne navigasjon oppleves ikke som optimal.5
Tjenesten har en enkel oversikt over stegene i utfyllingsprosessen.15
Brukerne kan navigere i tjenestens stegoversikt.5
Tjenesten har framdriftsinformasjon.5
Ikke relevant – Stegoversikt og framdriftsinformasjon er ikke nødvendig siden tjenesten er uten flere steg.25

Slik tester du

Brødsmulesti og/eller menymarkering

Sjekk om nettstedet har tydelig menymarkering og/eller klikkbar brødsmulesti som gjør det mulig å avgjøre hvor man er i strukturen, og at dette er tilgjengelig ned til minimum nivå 3. Det er nok å bare ha én av disse to løsningene. Menymarkeringen skal være tydelig og det er ikke tilfredsstillende å bare endre for- eller bakgrunnsfarge alene. Sjekk at funksjonaliteten fungerer fra ulike innganger, blant annet via meny og søk.

Intern navigasjon

Sjekk nettstedets menyer, snarveier og eventuell annen navigasjonsstøtte og vurder hvor enkelt det er å navigere seg fram til en utvalgt tjeneste eller annet relevant innhold. Sider med informasjon som er relatert til en aktuell tjeneste, skal ha inngang til tjenesten fra denne siden.

Stegoversikt og fremdriftsinformasjon

Sjekk om tjenesteen har en enkel oversikt over stegene i utfyllingsprosessen og om det er mulig å bruke denne til navigasjon mellom stegene. Alle steg i prosessen skal være synlig fra begynnelsen, men mindre det er sporvalg eller lignende løsninger. Kravet til navigasjon fremover i en tjeneste som har sporvalg eller lignende kan også fravikes.
Sjekk også om det finnes fremdriftsinformasjon som forteller hvor langt du er kommet i prosessen.

Både stegoversikt og fremdriftsinformasjon skal være godt synlig og tilgjengelig i alle steg, samt være forklarende og konsistent utformet. I enkelte tilfeller kan stegoversikt og fremdriftsinformasjon være ett og samme element. Fremdriftsinformasjon kan vises på ulike måter, for eksempel ved å fortelle hvilket steg du er på (Steg 2 av 5), at det er tydelig markert hvor du er i stegoversikten eller prosentvis fullføring (60% fullført). Dersom tjenesten bruker en tallskala for å vise fremdriften (eks «Steg 2 av 5»), skal siste steg før innsending/bestilling være det høyeste tallet (altså «Steg 5 av 5», og ikke «Steg 4 av 5» der kvittering etter innsending blir «Steg 5 av 5»).

5.2 - Nettsted og tjeneste er logisk og ryddig

Nettstedet og tjenesten skal være både logisk og ryddig.

Grafiske og funksjonelle elementer skal brukes på en gjennomført måte, altså at de uttrykkes likt overalt. Det skal være lett å skille mellom ulike tekstelementer som overskrift, mellomoverskrift, spørsmålstekst, feilmeldinger og andre elementer. Tekstelementer skal ikke være utformet slik at de fremstår som noe annet enn de er, for eksempel vil røde informasjonstekster kunne tolkes som feilmeldinger og understrekede ord kunne tolkes som lenker.

For at en tjeneste skal være enkel å bruke, må spørsmålene som skal besvares og handlingene som skal utføres, komme i en logisk rekkefølge for brukeren. Ut fra hvilke opplysninger som trengs (opplysninger som etaten eller andre etater ikke allerede har), er det noen opplysninger det f.eks av utsilingshensyn er naturlig å spørre etter først. Tjenesten skal i tillegg fremstå som ryddig og strukturert og uten elementer som kan forstyrre gjennomføringen. Brukeren skal loses gjennom tjenesten steg for steg, én ting om gangen.

Relaterte elementer skal være plassert nær hverandre og adskilt fra andre elementer, slik at det oppstår en naturlig sammenheng mellom dem og det blir enklere å forstå hva som hører sammen. Grafikk og symboler for handling, som knapper og lenker, er logisk plassert og brukes konsekvent. Elementer eller funksjonalitet skal ikke komme oppå hverandre.

TestpunkterPoeng (51)
Det er lett å skille mellom ulike tekstelementer som overskrifter, mellomoverskrifter, spørsmålstekst, feilmeldinger og andre elementer, både i tjenesten og på nettstedet.5
Nettstedet og tjenesten framstår som ryddig.10
Tjenestens grafiske og funksjonelle elementer er brukt på en gjennomført og logisk måte.8
Elementer som hører sammen i tjenesten er plassert nær hverandre og adskilt fra andre.10
Spørsmål og utfyllingsfelt i tjenesten er plassert logisk i tema og framdrift.10
Nettstedets grafiske og funksjonelle elementer er brukt på en gjennomført og logisk måte.8

Slik tester du

Sjekk at både nettsted og tjeneste fremstår som ryddig og strukturert uten forstyrrende elementer og at luft, grafikk eller typografi blir brukt for å skape et oversiktlig grensesnitt. Sjekk at det er enkelt å skille mellom ulike tekstelementer, og at disse er konvensjonelt utformet. Eksempler på sistnevnte kan være understrekede ord som ikke er lenker, eller rød tekst som er ren informasjon, ikke feilmeldinger – slik det kan tolkes som.

Sjekk at både nettstedets og tjenestens grafiske og funksjonelle elementer er benyttet på en gjennomført og logisk måte, altså at de er uttrykt likt gjennom hele nettstedet og hele tjenesten. Det aksepteres at både nettsted og tjenesten har sin egenart. Sjekk også at elementer eller funksjonalitet i tjenesten ikke er plassert oppå hverandre.

Gå gjennom hele tjenesten og sjekk at relaterte elementer, som f.eks spørsmålstekst, utfyllingsfelt, hjelpetekst og feilmeldinger, er plassert nær hverandre og adskilt fra andre slik at det er enkelt å forstå konteksten. Sjekk at spørsmål og utfyllingsfelter i tjenesten er plassert i en logisk rekkefølge med tanke på tema og framdrift. Knapper eller lenker til neste steg i prosessen bør være nederst til høyre.

5.3 - Tjenestens enkeltelementer er konvensjonelt utformet

Konvensjoner sikrer at vi får en relativt lik utforming av elementer på tvers, uavhengig av hvor brukeren er eller hvem som står bak.

Dette gjør at brukeren kjenner igjen funksjonalitet både med tanke på utseende, plassering, hvordan det skal brukes og ikke minst hvordan det skal oppføre seg. Dersom tjenesten følger konvensjonene ved utforming av de ulike enkeltelementene vil dette være med på å forenkle arbeidet og øke brukskvaliteten, samtidig som behovet for skriftlige forklaringer reduseres.

Vi ser i utgangspunktet på alle elementer som inngår i tjenesten, men vi har i tillegg valgt å spesifisere enkelte elementer som er mye brukt i tjenester for å sikre at konvensjonene på disse områdene blir fulgt. Konvensjonene er beskrevet i testpunktlisten.

TestpunkterPoeng (48)
Spørsmålstekster står før eller over utfyllingsfeltet.8
Benevninger, format og fortegn er plassert ved feltet.8
Feltets størrelse er tilpasset antall tegn som skal fylles inn.8
Avkryssingsbokser og radioknapper står foran tilhørende tekst.8
Nedtrekkslister har et nøytralt valg (evt «Ikke relevant»).8
Andre funksjonelle elementer som inngår i tjenesten er konsekvent og konvensjonelt utformet.8

For å unngå at brukeren gjør ubevisste valg, skal nedtrekkslister ha et nøytralt valg som er utfylt som standard. Dette kravet kan fravikes dersom det er hensiktsmessig og gir en bedre løsning.

Slik tester du

Gå gjennom den aktuelle digitale tjenesten. Sjekk samtlige testpunkter i listen over, og gjør en vurdering for hvert enkelt.

Ved sjekk av feltstørrelse skal det gjøres en vurdering av i hvor stor grad eventuelle avvik påvirker brukskvaliteten.

Kravet til nøytralt valg i nedtrekkslister kan fravikes dersom dette er hensiktsmessig og gir brukeren en bedre løsning enn ved at det finnes et nøytralt valg. Eventuelle avvik skal begrunnes, og i slike tilfeller skal det likevel gis poeng for «Nedtrekkslister har et nøytralt valg».

 

5.4 - Det viktigste er fremhevet

Det skal være enkelt å forstå hva som er viktig. Den viktigste informasjonen og funksjonaliteten skal være fremhevet, og den skal skille seg ut fra annet innhold. Dermed vil det bli enklere for brukeren å forstå innholdet og få med seg det som er relevant i den situasjonen han er i.

Effektive virkemidler for å fremheve det viktigste kan blant annet være fargevalg/kontrast, fysisk plassering, størrelse og bruk av luft.

Tjenester som innebærer innsending av opplysninger (for eksempel søknadsskjema), skal ha en tydelig innsendings- eller bestillingsknapp som fullfører prosessen (aller helst «Send» eller «Bestill», men også andre tydelige handlingsknapper kan godkjennes).

TestpunkterPoeng (35)
Den viktigste informasjonen og funksjonaliteten skiller seg ut fra annet innhold og er enkel å forstå.25
Delvis – Den viktigste informasjonen og funksjonaliteten skiller seg i noen tilfeller ut fra annet innhold, men dette er ikke konsekvent gjennomført.10
I tjenesten utløses innsending av opplysninger ved bruk av en tydelig innsendings- eller bestillingsknapp.10

Slik tester du

Det viktigste skiller seg ut

Sjekk både nettsted og tjeneste. Vurder hvorvidt viktig informasjon og funksjonalitet er tilstrekkelig fremhevet og skiller seg tilfredsstillende ut fra annet, mindre relevant innhold. Fremhevingen skal gjøre det enkelt å forstå innholdet og hva som er relevant i det aktuelle tilfellet. Virkemidler for fremheving kan være fargevalg/kontrast, fysisk plassering, størrelse eller bruk av luft. I de tilfellene der fremheving er benyttet, men ikke er helt konskvent gjennomført, kan de gis poeng for delvis.

Tydelig innsendings-/bestillingsknapp

Sjekk at tjenester der det sendes inn opplysninger, har en tydelig innsendings- eller bestillingsknapp, aller helst «Send» eller «Bestill», men også andre tydelige handlingsknapper godkjennes.

Sjekk også at det ikke finnes knapper som kan mistolkes for å være innsendings- eller bestillingsknapp, dette kan også forekomme. Det skal være klart og tydelig hva som avslutter tjenesten.

 

5.5 - Innholdet er uttrykt i et godt språk

Innholdet skal presenteres på en måte som er i tråd med prinsippene for klarspråk. Det vil si at alle tekster skal være skrevet i et klart, brukerrettet og korrekt språk.

Ifølge Språkrådet er et dokument skrevet i klarspråk dersom mottakerne

  1. finner det de trenger
  2. forstår det de finner
  3. kan bruke det til det de skal gjøre

Vi vil belønne tekst som benytter ord og uttrykk brukeren kjenner, og som forklarer fagord og vanskelige ord. I digitale tjenester belønner vi også tekst med aktive, brukerorienterte setninger, der det går tydelig fram hvem som skal gjøre hva. Vi ser også etter om teksten er strukturert på en måte som hjelper brukeren med å forstå innholdet. Det er da viktig å dele teksten inn i passelige avsnitt, med relevante overskrifter som gir mening for brukeren. Kravet til godt språk gjelder i utgangspunktet for all tekst på nettsteder og tjenester, men vi vil legge spesiell vekt på følgende tekster:

  • Plikt-, rettighets- og formålsinformasjon
  • Personvernerklæring og informasjon om bruk av informasjonskapsler
  • Brukerveiledning
  • Spørsmålstekst
  • Hjelpetekster
  • Kvittering
  • Nettstedets framside
TestpunkterPoeng (45)
Ordbruken er konsekvent og gjenkjennelig for brukerne, og teksten er korrekt skrevet.15
Setningskonstruksjonen er brukerrettet og poengtert.15
Teksten er strukturert etter det som er viktigst for brukeren, delt opp i avsnitt og med relevante overskrifter.15

Slik tester du

Finn fram til de aktuelle tekstene på nettstedet og i tjenesten, og gjør en vurdering av ordbruk, setningsoppbygning og tekststruktur. For hver tekst, gå gjennom følgende punkter:

  • Er ordbruken gjenkjennelig for brukerne, eller er det mange vanskelige ord og faguttrykk? Er ukjente, vanskelige ord eventuelt forklart i teksten eller med en pop-up?
  • Er ordbruken konsekvent eller brukes flere ord for å beskrive det samme?
  • Er det mange skrivefeil? Vi mener det viktigste er at teksten er klar og brukerrettet, og vil godta noen skrivefeil, tegnsettingsfeil eller lignende, så lenge dette ikke går ut over forståelsen av teksten.
  • Er setningene aktive og rettet mot brukeren, eller er det mange setninger med passivkonstruksjon?
  • Er teksten i tjenestene utformet for å ligne på en dialog med brukeren, eller er det mange passive og nøytrale formuleringer?
  • Er setningene korte og poengterte, eller er de lange og kompliserte?
  • Er informasjonsteksten strukturert etter det som er viktigst for brukeren, eller er den ustrukturert og vanskelig å få oversikt over?
  • Er teksten brutt opp i avsnitt, eller er det lange tekster uten avsnitt?
  • Er teksten brutt opp med relevante overskrifter som gir mening for brukerne, eller er det lange tekster uten overskrifter og underoverskrifter?

For nettsteder som har tjenester, vil det være tilstrekkelig å teste språket i de punktene som er spesifisert i innledningen. For nettsteder som ikke har tjenester, må vi lage et utvalg på fem undersider hvor vi tester språket.

Referanse

 

5.6 - Innholdet presenteres på flere språk og målformer

Mange innbyggere i Norge har et annet morsmål enn norsk. For å gjøre det enkelt for alle å bruke et nettsted eller en digital tjeneste, er det viktig å kunne tilby informasjon og tjenester på flere språk.

Basert på kunnskap om målgruppen, er det opp til virksomhetene å avgjøre på hvilke språk informasjon tilbys. Ifølge statens kommunikasjonspolitikk skal virksomhetene vurdere om det er tilstrekkelig å oversette informasjonen til engelsk, eller om det i tillegg er behov for oversettelse til andre fremmedspråk. I tillegg sier kommuneloven at kommuner og fylkeskommuner skal drive aktiv informasjon om sin virksomhet, og at forholdene skal legges best mulig til rette for offentlig innsyn i den kommunale og fylkeskommunale forvaltning.

Det samme gjelder for tjenester. De overordnede IT-arkitekturprinsipper for offentlig sektor legger til grunn at tjenester bør være tilgjengelig på målgruppens språk. Prinsippene gjelder for statlige organ, men er også anbefalt for kommunal sektor. Skjema skal ifølge målloven også være tilgjengelige på både bokmål og nynorsk, og vi legger til grunn at dette også gjelder digitale tjenester. Dette kravet i målloven gjelder ikke kommunal sektor.

TestpunkterPoeng (40)
Tjenesten finnes på et annet språk17
Brukerne av tjenesten finner informasjon om tjenesten og alternativer til den digitale løsningen på et annet språk.5
Nettstedet har informasjon om organisasjonens brukerrettede kjernevirksomhet på et annet språk.7
Nettstedet har enkel kontaktinformasjon på et annet språk.3
Tjenesten finnes på begge målformer.8
Ikke relevant – Virksomheten har ikke krav på seg om å ha tjenesten på begge målformer.8

Sånn tester du

Alternative språk

Sjekk om tjenesten finnes på minst ett annet språk enn norsk. Der det finnes både informasjonstekst og tjeneste på annet språk, skal brukerens språkvalg følge med i overgangen mellom nettsted og tjeneste.

Sjekk også nettstedet om informasjon finnes på minst ett språk i tillegg til norsk. Se om følgende er tilgjengelig:

  • Informasjon om den aktuelle tjenesten og alternativer til den digitale løsningen skal være på nettstedet.
  • Informasjon om organisasjonens brukerrettede kjernevirksomhet skal være på nettstedet. Med brukerrettet kjernevirksomhet mener vi virksomhetens formål og viktigste ansvarsområder, samt hvilke tjenester den tilbyr (se også indikator 2.1).
  • Enkel kontaktinformasjon skal være på nettstedet. Med enkel kontaktinformasjon mener vi telefonnummer, e-postadresse, post- og besøksadresse, samt kontakttider (se også indikator 6.2).

Automatiske oversettinger som Google Translate er ikke godkjent, da kvaliteten vil være varierende.

Målform

Sjekk til slutt om tjenesten er tilgjengelig på både bokmål og nynorsk. Dette kravet gjelder ifølge målloven bare statlige organ, men dette er ikke til hinder for at også kommunale virksomheter også bør oppfylle dette kravet. For kommuner, og eventuelt andre tjenesteeiere som har unntak fra denne regelen, kan ikke-relevant-alternativet benyttes.

 

5.7 - Teknologien brukes for å forenkle oppgaveløsingen

Én av fordelene ved digitalisering er at teknologien kan forenkle oppgaveløsningen og gi tjenester som er skreddersydd brukerens situasjon.

Intensjonen bak dette kriteriet er å belønne digitale tjenester som har smarte løsninger som gjør det enklere for brukerne å løse oppgavene sine.  «Do the hard work to make it simple», som det heter i de britiske design-prinsippene.

Ett eksempel kan være komplekse tjenester som forenkles gjennom sporvalg, slik at utfyllingen er tilpasset brukeren, og han eller hun blir skjermet fra irrelevante felter. Et annet eksempel er tjenester som tar seg av utregninger for brukerne. Disse skal da vises slik at brukeren kan kontrollere utregningene.

TestpunkterPoeng (45)
Teknologien brukes smart for å forenkle oppgaveløsningen.45
Delvis – Smart teknologi brukes for å forenkle deler av oppgaveløsingen.30
Ikke relevant – Oppgaveløsingen er ukomplisert og kan ikke forenkles gjennom smart teknologi.45

Slik tester du

Noe av utfordringen med dette kriteriet er at det er vanskelig å definere en smart teknologisk løsning på forhånd. Vi gjør en vurdering av om teknologien er tatt i bruk for å forenkle oppgaveløsningen. Noen løsninger som vi aktivt vil se etter, er for eksempel:

  • Tjenesten bruker sjekkmekanismer for å sile ut ikke-relevante brukere.
  • Tjenesten bruker sporvalg for å tilpasse spørsmålene underveis basert på tidligere svar.
  • Tjenesten gjør utregninger for brukerne, og viser utregningene slik at de kan kontrolleres av brukeren.
  • Tjenesten tilbyr smarte inputmetoder, som å velge dato fra kalender.
  • Tjenesten sjekker automatisk input, for eksempel ved å validere innholdet, og eventuelt automatisk rette formatfeil eller foreslå alternativer.
  • Tjenesten henter inn data fra andre registre og bruker dette for å forenkle oppgaveløsingen for brukeren (ut over forhåndsutfylte felt).
  • Internsøk på nettsted: det gis fortløpende forslag til søkefraser eller søketreff.

Noen digitale tjenester er relativt enkle, og det er dermed ikke nødvendig eller mulig å bruke teknologiske løsninger for å forenkle oppgaveløsingen ytterligere. I disse tilfellene bruker vi svaralternativet «ikke relevant». Selv om denne indikatoren primært gjelder for digitale tjenester, vil også smarte teknologiske løsninger på nettsteder belønnes.

Eksempel

Søknad om lån i Statens lånekasse er et eksempel der det er bygd inn sjekkmekanismer tidlig i inputprosessen slik at brukeren raskt får vite om han eller hun tilfredsstiller kvalifikasjonskravene for å ta tjenesten i bruk. Også Skatteetatens pendlerveiviser legger opp til en slik forenkling av oppgaveløsningen. Kompleksiteten i disse løsningene skjules ved hjelp av smart programmering.

Se utdanning.no for fortløpende forslag til søketreff i internsøk.

Referanse

 

5.8 - Tjenesten har forhåndsutfylte felter

Opplysninger som allerede er samlet inn av en offentlig virksomhet, bør gjenbrukes. Slike opplysninger kan brukes til tjenester med forhåndsutfylte felt for å få til reell forenkling for brukerne.

For eksempel kan kommuner og andre virksomheter i forvaltningen bruke ID-porten til innloggingstjenester med forhåndsutfylling av personnummer, telefonnummer, e-postadresse fra ID-portens kontaktregister. Kommunene bør også kunne hente navn, adresse og martikkelopplysninger fra egne registre.

Det skal være tydelig hvor slike data kommer fra, og eventuelt hva brukeren kan gjøre for å endre dem.

Ifølge ELMER 3.0, punkt 3.5, skal forhåndsutfylt informasjon som brukeren ikke kan endre, vises som tekst uten feltinnramming, mens informasjon som brukerne kan redigere, skal presenteres i vanlige utfyllingsfelt.

Dersom virksomheten ikke kan forventes å ha opplysninger som forenkler tjenesten, eller informasjonen som kan gjenbrukes har liten relevans for tjenesten, vil innlogging ikke gi noen merverdi for brukeren. Dette er årsaken til at vi har med et «ikke relevant»-alternativ.

TestpunkterPoeng (25)
Relevante opplysninger som allerede er kjent for virksomheten, blir automatisk utfylt i tjenesten.20
Forhåndsutfylt informasjon blir presentert på korrekt måte.5
Ikke relevant – Bruk av forhåndsutfylte opplysninger har liten eller ingen forenklings- eller effektiviseringsverdi for brukeren.25

Slik tester du

Sjekk i tjenesten at virksomheten ikke spør etter opplysninger som burde være kjent, og at opplysninger som er forhåndsutfylt, er korrekt presentert. Informasjon som ikke kan redigeres, skal vises som tekst uten feltinnramming, mens informasjon som kan redigeres, skal presenteres i vanlige utfyllingsfelt.

Dersom tjenesteeier ikke har forhåndsutfylte felter, men burde ha det, skal han ha 0 poeng på hele indikatoren. Dersom tjenesteeier ikke kan forventes å ha opplysninger som forenkler tjenesten, eller informasjonen som kan gjenbrukes har liten relevans for tjenesten, skal alternativet "Ikke relevant" brukes.

 

5.9 - Brukeren mister ikke registrerte opplysninger

Løsningen skal bidra til å forhindre at brukeren mister registrerte data. Dette kan gjøres ved å automatisk lagre det brukeren fyller inn, og gi varsel dersom han gjør noe som fører til uønsket tap av data.

Det bør også være mulig å bruke tilbakeknappen i nettleseren for å gå tilbake forrige side/steg uten at man mister data eller avbryter utfyllingsprosessen. Mange brukere bruker denne funksjonen aktivt, og det bør derfor også være støtte for det i tjenester.

TestpunkterPoeng (25)
Brukerne får advarsel ved handlinger som kan føre til tap av data.15
Data går ikke tapt dersom man bruker tilbakeknappen i nettleseren.10

Slik tester du

Her tester du bare tjenesten, ikke nettstedet.

Advarsel ved tap av data

Fyll ut noen tilfeldige felter, og naviger deg deretter til et annet steg/side i tjenesten før du går tilbake til dit du startet utfyllingen (ved å bruke navigasjonen i tjenesten, ikke tilbakeknappen i nettleser - den bruker vi senere i testen). Sjekk at de utfylte opplysningene ble lagret, eventuelt at det kommer et varsel dersom det forsvinner. Sjekk at det samme skjer dersom du prøver å avbryte tjenesten.

Det skal være mulig å avbryte tjenesten uten å lagre dersom man ønsker det, men det må da altså varsles dersom dette medfører tap av data. Slikt varsel er ikke nødvendig dersom det kommer tydelig frem av funksjonen i seg selv at informasjon vil gå tapt, for eksempel en knapp merket "Tøm alle felter" og denne er plassert slik at det ikke er mulig å trykke på ved en feiltagelse.

Tilbakeknapp i nettleser

Fyll ut noen tilfeldige felter, og bruk deretter tilbakeknappen i nettleser til å gå tilbake til forrige side/steg. Gå så tilbake til der du startet utfyllingen, og sjekk at de utfylte opplysningene ble lagret. Dersom hele prosessen avbrytes når tilbakeknappen brukes, regnes også dette som feil. Dersom den tradisjonelle tilbakeknappen ikke er tilgjengelig (for eksempel at tjenesten åpnes i et nytt vindu uten knapper, adressefelt, etc), kan du sjekke dette ved å bruke alternative innganger som "Backspace" (viskeknappen) på tastaturet, eller høyreklikke på siden og velge "Tilbake" derfra.

 

5.10 - All funksjonalitet er enkel å oppdage og å bruke

Det skal være enkelt å både oppdage og enkelt å bruke funksjonaliteten som er tilgjengelig, som for eksempel lenker og knapper.

Funksjonaliteten skal være godt synlig, den skal være konvensjonelt utformet slik at den er enkel å forstå, og klikkflatene skal være store nok til at de kan brukes både på berøringsskjermer og av personer med nedsatt motorisk funksjonevne.

Tekstlenker skal skille seg ut fra annen (løpende) tekst på andre måter enn kun ved bruk av farge, for eksempel med understreking. Dette hjelper blant annet fargeblinde, men kan også være en fordel ved krevende lysforhold.

TestpunkterPoeng (25)
Tekstlenker og funksjonelle ikoner og knapper er konvensjonelt utformet og enkle å klikke på.25

Slik tester du

Sjekk både nettsted og tjeneste. Se om det både er enkelt å oppdage og enkelt å bruke funksjonaliteten som er tilgjengelig ved å sjekke om all funksjonalitet:

  • er godt synlig
  • er konvensjonelt utformet – og det er enkelt å forstå bruken
  • har store nok klikkflater

Sjekk også at tekstlenker skiller seg fra annen (løpende) tekst og mer avansert funksjonalitet som opplasting av filer (f.eks. dra-og-slipp eller velge fil fra liste). Dette bør være godt forklart og enkelt for brukeren. Det bør eventuelt også være enkelt å forstå hvordan man kan legge til flere vedlegg.

Dersom tekst framstår som lenker uten å være det, for eksempel dersom det brukes understreking av viktige ord, skal dette gis trekk på 5.2, på testpunktet "Det er lett å skille mellom ulike tekstelementer ...".

 

5.11 - All funksjonalitet kan betjenes med tastatur

Brukerne skal ha tilgang til all funksjonalitet som lenker, skjemafelt, hjelpetekster og innsendingsknapp med tastatur, og ikke havne i tastaturfeller som gjør at de blir stående fast.

Fokus skal markeres slik at det er mulig å se hvor på siden de er, og rekkefølgen på elementene skal være logisk.

TestpunkterPoeng (20)
Bruk av tab-tasten gir tilgang til alle relevante lenker og kontroller.10
Fokus er tydelig visuelt markert.5
Ved bruk av tab-tasten markeres fokus i en logisk rekkefølge.5

Slik tester du

Bruk tab-tasten for å navigere rundt på nettstedet og tjenesten med tastaturet. Sjekk at du får tilgang til all relevant funksjonalitet, og at det ikke er noen tastaturfeller som gjør det umulig å komme videre i løsningen. Sjekk også at fokus markeres tydelig og i logisk rekkefølge.

Rekkefølgevurderingen omfatter også om visuelt skjulte objekter får fokus. Vi godkjenner at fokus markeres med nettleserens default-innstilling, men tester likevel om dette forsvinner eller svekkes på grunn av designvalg av bakgrunnsfarger eller lignende.

 

5.12 - Nettsted og tjeneste har god kontrast

For å sikre god lesbarhet må all meningsbærende tekst og grafikk ha tilstrekkelig kontrast mot bakgrunnen.

Dette er viktig for alle brukere, særlig under krevende lysforhold. De som trenger dette mest, er svaksynte, dyslektikere og fargeblinde.

Kontrast måles ut fra lysstyrke, der maksimal kontrast er 21:1 for svart mot hvit. Det spiller ingen rolle for kontrastmåling hva som er forgrunnsfarge og hva som er bakgrunn, men brukeropplevelsen vil selvfølgelig være ulik.

Kravene til kontrast er:

  • Normal tekst (opp til 18pt): 4,5:1
  • Stor tekst (minst 18 pt): 3:1
TestpunkterPoeng (20)
Kontrastverdiene er minst 4,5:1 på normal tekst (opp til 18pt) og minst 3:1 for stor tekst (minst 18pt).20
Delvis – Hovedløsningen tilfredsstiller ikke kravene, men det er en egen høykontrastversjon som tilfredsstiller kontrastkravene.5

Slik tester du

Det finnes ulike måter å regne ut kontrast på. Algoritmen som blir brukt her, måler kontrast i lysverdi. Farge spiller ingen nøkkelrolle i algoritmen, slik at kontrastverdien er gyldig også for personer med nedsatt fargesyn.

Menyer, tekstinnhold og annet innhold rettet mot brukeren skal testes, både på nettstedet og i tjenesten. Logoer, innholdsbilder eller andre elementer som kun er ment som pynt, har ikke bestemte krav til kontrast og skal derfor ikke testes.

Bruk Contrast Analyser-verktøyet i WAT-verktøylinjen i Internet Explorer (se oversikt over verktøy).

Velg forgrunns- og bakgrunnsfarge på de ulike elementene med kontrastverktøyet (velg luminosity-algoritmen), kontroller kontrastverdien og gi poeng basert på det svakeste resultatet.

For nettsteder med egen høykontrastversjon, skal en først vurdere hovedløsningen. Dersom hovedløsningen ikke tilfredsstiller kravet om kontrastverdier høyere enn 4,5:1 og 3:1, skal en kontrollere at lenken til høykontrastversjonen er lett synlig og har tilfredsstillende kontrast, og at høykontrastversjonen tilfredsstiller kravet om kontrastverdier høyere enn 4,5:1 og 3:1. Dersom høykontrastversjonen tilfredsstiller kravene, brukes alternativet «Delvis».

 

6.1 - Brukerne får hjelp til å unngå og rette opp feil

Brukerne skal oppleve utfyllingen av informasjon i en digital tjeneste som så enkel som mulig.

Dette betyr at tjenesten må ha gode hjelpetekster ved felter som krever ekstra forklaring. Ved feil i besvarelser skal feilen oppdages automatisk og varsles tydelig og så raskt som mulig, men ikke før feltet forlates. Den aktuelle feilen skal varsles med markering i eller ved feltet, og feilmeldingen skal inneholde forslag til hvordan feilen kan løses.

Feilmeldingen må presenteres på en slik måte at brukeren kan rette opp feilene mens meldingen er synlig, og skal være tydelig med god kontrast mot bakgrunn. Brukeren skal også ha adgang til å gå videre uten å rette feilen med en gang, der dette er mulig.

TestpunkterPoeng (38)
Alle relevante felter har hjelpetekster (språk og innhold sjekkes i 5.5).5
Ved feil i besvarelser får brukerne feilmelding så raskt som mulig, men ikke før feltet forlates.5
Den aktuelle feilen varsles med markering i eller nær feltet.5
Feilmeldingen inneholder forslag til hvordan feilen kan løses, og er synlig mens feilen rettes.10
Ved manglende utfylling av felt får brukerne varsel om dette.5
Der det er mulig, skal brukerne ha adgang til å gå videre uten å rette feilen.3
Tjenester som er lange eller med flere trinn, har en liste over feil som gjenstår på slutten, med lenker til aktuelle felt.5
Ikke relevant med liste over feil – tjenesten har ikke flere trinn.5

Slik tester du

Her trenger du bare å sjekke selve tjenesten, ikke noe på nettstedet. Vurder følgende punkter:

Undersøk om alle relevante felt har hjelpetekster (felter som krever ekstra forklaring). Legg merke til at vi i dette kriteriet tester tilstedeværelsen for hjelpetekster, mens vi i kriterium 5.5 ser på det språklige innholdet i hjelpetekstene. Her ser vi derfor blant annet på plassering i forhold til utfyllingsfelt (tydelig inngang) og hvordan hjelpetekstene er utformet.

Gjør bevisste feilutfyllinger i ulike felter. Vurder om feilen varsles på en tilfredsstillende måte. Feilmeldingen skal komme uoppfordret så raskt som mulig (f.eks ikke først når man går videre til neste steg), men ikke før feltet forlates. Sjekk om feilmarkeringen/-meldingen er plassert i eller nær feltet med feilen slik at det er enkelt å forstå relasjonen til feltet, og om den har god nok kontrast.

Sjekk at feilmeldingen inneholder forslag til hvordan feilen kan løses, og at denne er synlig mens feilen rettes (det er for eksempel ikke godkjent at feilmeldingen bare vises i en dialogboks som må lukkes før feilen kan rettes opp).

La ett eller flere obligatoriske felt stå tomme og sjekk om løsningen varsler om dette.

Sjekk om det er mulig å gå videre (både til neste utfyllingsfelt og til neste side/steg) uten å rette opp feil eller med tomme felt, altså at det er fri utfyllingsrekkefølge i tjenesten.

Sjekk at lengre tjenester og tjenester med flere trinn har en liste over feil på slutten. La noen felter stå tomme eller ha bevisste feilutfyllinger og gå til slutten av tjenesten. Sjekk også at det finnes lenke til de aktuelle feltene fra hver feilmelding. Korte tjenester uten flere trinn kan bruke alternativet "ikke relevant".

 

6.2 - Brukerstøtte er lett tilgjengelig

Brukere som trenger hjelp må tilbys dette. Behovet for hjelp eller kontakt blir ofte utløst av noe som står på sidene og kontaktinformasjon skal være lett tilgjengelig uansett hvor på nettstedet eller tjenesten du befinner deg.

Den viktigste kontaktinformasjonen, telefonnummer og e-postadresse (eventuelt kontaktskjema), skal derfor være godt synlig og konsekvent plassert på alle sider. I tjenesten er det tilfredsstillende at dette ligger bak en tydelig hjelp-/kontaktfunksjon.

I tillegg skal startsiden eller en egen kontaktside på nettstedet ha utvidet kontaktinformasjon, som minst skal inneholde:

  • Telefonnummer
  • E-postadresse (eventuelt kontaktskjema eller chat)
  • Organisasjonsnummer
  • Kontakttider
  • Postadresse
  • Besøksadresse (dersom denne ikke er samme som postadressen)

Tjenesten skal også tilby mulighet til å kommunisere direkte med brukerstøtte for å få personlig veiledning til gjennomføringen, for eksempel via telefon, chat eller lignende.

TestpunkterPoeng (25)
Utfyllende kontaktinformasjon er lett tilgjengelig direkte på startsiden eller på egen kontaktside på nettstedet.5
Den viktigste kontaktinformasjonen er synlig og konsekvent plassert på alle sider.5
Utvidet brukerstøtte med personlig veiledning er lett tilgjengelig ved gjennomføring av en digital tjeneste.15

Sånn tester du

Kontaktinformasjon

Sjekk at den viktigste kontaktinformasjonen, telefonnummer og epostadresse (evt kontaktskjema) er synlig på alle sider på nettstedet og i tjenesten. Den valgte fysiske plasseringen av kontaktinformasjonen har ingen betydning så lenge den er godt synlig og konsekvent plassert på alle sider. Den trenger ikke være plassert på samme sted både på nettstedet og i tjenesten, men den skal være plassert på samme sted på alle nettstedets sider og på samme sted på tjenestens sider. I tjenesten er det tilfredsstillende om den viktigste kontaktinformasjonen ligger bak en tydelig hjelp-/kontaktfunksjon.

Sjekk om utfyllende kontaktinformasjon (se kravliste i bakgrunnsteksten) er tilgjengelig på nettstedets startside eller på en egen kontaktside.

Utvidet brukerstøtte

Sjekk om det er mulig å kommunisere direkte med brukerstøtte for å få personlig veiledning til gjennomføringen, for eksempel via telefon, chat eller lignende. Der det er begrensede åpningstider, både for telefon og chat, skal dette opplyses om.

Eksempel

Statens vegvesen: Søk om førerkort. Her ligger kontaktinformasjonen i megafooter på alle sider/trinn i tjenesten.