Kvalitet 2009

Bilder er utilgjengelige for noen brukere, dette på grunn av funksjonsnedsettelser eller begrensninger i mediet som benyttes. Bilder skal derfor ha alternativ tekst slik at informasjonen som ligger i bildene blir tilgjengelig for disse brukerne. Teksten skal være likeverdig med bildets innhold.
Bilder som ikke er relatert til innholdet eller som kun brukes som grafikk på nettstedet, skal ha tom alternativ tekst (alt=””). Dersom man dropper alternativ tekst helt (altså fjerner hele alt=””) risikerer man at en lite beskrivende alternativ tekst genereres automatisk av mediet, for eksempel basert på bildets filplassering eller filnavn.

Referanse; WAI WCAG 2.0 – 1.1.1

Eksempel; Høgskolen i Bergen

Testmetode

IE – WAT – Images – Show Images (se verktøylisten)

Gjenta på 3 sider på nettstedet. Alternativ tekst som ikke er likeverdig med bildets innhold teller på samme måte som bilder uten alternativ tekst.

Svar ja dersom bruk av alternativ tekst er konsekvent gjennomført på alle bilder og tekstene er likeverdig med bildenes innhold.
Svar delvis dersom over halvparten av bildene har tilfredsstillende alternativ tekst.
Svar nei dersom under halvparten av bildene har tilfredsstillende alternativ tekst.

Sjekk at bilder som ikke er relatert til innholdet eller brukes som grafikk har tom alternativ tekst (alt=””).

Det skal være enkelt å forstå hva som er linker på nettstedet og disse skal derfor skille seg ut fra løpende tekst på en tilfredsstillende  og konsekvent måte, for eksempel med understreking eller utheving. Kun fargeforskjell mellom tekst og linker regnes ikke som tilfredsstillende, blant annet med bakgrunn i at personer med nedsatt syn eller begrenset fargesyn vil ha problemer med å oppfatte dette. Med konsekvent menes at lenker i løpende tekst markeres på samme måte på hele nettstedet for å unngå forvirring.

Understreking av tekst som ikke er linker skal ikke forekomme i løpende tekst, da dette kan skape forvirring rundt hva som er linker og ikke på nettstedet.

Referanse; WAI WCAG 2.0 – 1.4.1

Eksempel; Trondheim kommune

Testmetode

Visuell kontroll, kontroller at linker skiller seg tilfredsstillende ut fra løpende tekst. Kontroller også at linker er markert på samme måte (konsekvent) i løpende tekst over hele nettstedet.
Støtteverktøy om nødvendig: IE – WAT – Colour – Greyscale (se verktøylisten).

Eksempel på tilfredsstillende markering er understreking eller utheving av linktekst. Kun fargeforskjell regnes ikke som tilfredsstillende. Dersom understreking brukes til andre formål enn linker i løpende tekst, skal det gis trekk i vurderingen.

Svar ja dersom alle linker er tilfredsstillende og konsekvent markert.
Svar delvis dersom over halvparten av linkene er tilfredsstillende og konsekvent markert.
Svar nei dersom linker ikke er tilfredsstillende og konsekvent markert.

Skalering av tekst er en viktig del av fleksibiliteten på et nettsted og gjør det mulig for brukeren å endre størrelsen på tekstlig innhold etter eget ønske. Målgruppen er brukere med en mildere grad av nedsatt syn (for eksempel middelaldrene/eldre), men som ikke benytter seg av datatekniske hjelpemidler på grunn av dette.

Aller helst skal slik skalering være mulig via eksplisitt funksjonalitet på nettstedet, fordi mange ikke kjenner til funksjonaliteten som ligger i nettleseren. Varierende støtte i nettlesere for skalering av tekst satt i faste enheter øker også behovet for eksplisitt funksjonalitet. Skaleringsfunksjonen skal være lett tilgjengelig og skaleringen skal gjelde på hele nettstedet, også når man går videre til en annen underside.

Skriftstørrelsen skal være satt i relative enheter (eksempelvis em), ikke faste (eksempelvis px).

Eksempel; Regjeringen

Testmetode

Testmetode del 1, eksplisitt funksjonalitet;

Velg en side med mye tekst – visuell kontroll – se etter funksjonalitet på nettstedet som gjør det mulig å skalere tekststørrelsen. Skaler teksten størst mulig, sjekk at skaleringen gjelder all tekst, at innholdet fremdeles er lesbart og kontroller at størrelsen på teksten er minst 20px. Skriftstørrelsen kontrolleres/måles med utvidelsen Firebug (se verktøylisten) i Firefox på denne måten:

Høyreklikk på teksten som skal måles (man trenger ikke å markere teksten) – Velg «Inspect element» – Firebug åpnes nå i Firefox med 2 vinduer – Kontroller at fanen «Style» er valgt i vinduet til høyre – Klikk på den lille pilen like til høyre for fanetittelen «Style» og skru på valget «Show Computed Style» – Kontroller verdien til «font-size», denne skal være minimum 20px. Kontroller også at valgt tekststørrelse lagres slik at man får samme størrelse på resten av nettstedet uten å måtte bruke funksjonaliteten på nytt hver gang man laster siden på nytt.

Skru av Firebug ved å trykke på «Off» oppe til høyre i Firebug-vinduet.

Svar ja, eksplisitt dersom kravene oppfylles og hopp over testmetode del 2, da denne kun brukes der eksplisitt funksjonalitet ikke finnes.

Testmetode del 2, fast/relativ enhet;

Velg en side med mye tekst

IE – Side (evt Vis) – Tekststørrelse – Størst (se verktøylisten), kontroller om teksten skalerer og om dette gjelder all tekst. Svar ja (1 poeng) dersom kravene oppfylles (dersom teksten skalerer er det brukt relative enheter), nei (0 poeng) dersom ett eller flere av kravene over ikke oppfylles (dersom teksten ikke skalerer er det brukt faste enheter).

Informasjon i datatabeller skal være tilgjengelig selv om den presenteres på andre måter enn den mest kjente todimensjonale visningen med rader og kolonner. Spesielt er dette nødvendig for brukere med datatekniske hjelpemidler som leser nettsiden lineært og dermed ikke kan se hva tabellen presenterer eller hvilke celler som hører til hvilke rader og kolonner. Datatabeller skal derfor inneholde rad- og kolonneoverskrifter, overskrift og/eller sammendrag.

I noen enkle tabeller vil overskrift og sammendrag være like og det er derfor tilstrekkelig at kun en av delene defineres uten at dette gir utslag på poenggivningen (indikatoren gir maksimalt 3 poeng).
De ulike kravene kodes med <caption> for tabelloverskrift, <table summary> for tabellsammendrag, samt <th> for rad- og kolonnetitler (<td> brukes ikke til rad- og kolonnetitler).

Denne indikatoren gjelder kun datatabeller. I layouttabeller skal ingen av kravene brukes, mer informasjon om bruk av layouttabeller finnes i indikator 1.9.

Referanse; WAI WCAG 2.0 – 1.3.1

Eksempel; Porsgrunn kommune

Testmetode

Kontroll av datatabell på nettstedet.
IE – WAT – Tables – Show Data Tables (se verktøylisten).
td, th, summary og caption markeres nå i tabellen dersom dette er brukt. Kontroller at th er brukt på kolonne- og radtitler, samt om det er definert caption og/eller summary. Gi poeng basert på vurderingen. Indikatoren gir maksimalt 3 poeng selv om alle krav oppfylles.

Dersom det finnes flere tabeller på nettstedet, ta utgangspunkt i den som oppfyller færrest krav.

Rammer kan i mange tilfeller minske tilgjengeligheten på nettstedet og bør i størst mulig grad unngås. For å sørge for at rammene er tilgjengelige, er det viktig at sentrale elementer er til stede. Title-attributtet skal defineres i samsvar med innholdet (tittelen skal ikke gjenspeile rammens fysiske plassering) slik at hver ramme kan identifiseres basert på navnet. Avsenderinfo gjør det mulig å identifisere innholdets avsender, mens en lenke til helt rammesett gjør det mulig å hente frem alle rammene på nytt.

Ved bruk av iframe er det kun title-attributtet som er relevant her.

Eksempel (nettsted uten rammer); Alta kommune

Testmetode

Kontroll av et rammesett på nettstedet.
Dersom det er iframes som vurderes, er det kun alternativ A (title) som er aktuell. Nettstedet skal uansett ha poeng på alternativ B og C, da disse ikke er aktuelle for iframe.

Testmetode 1, title:

IE – WAT – Frames – Frame name/title (se verktøylisten). Gi poeng dersom title-attributtet er definert og gir informasjon om hva rammen inneholder og ikke hvor den er fysisk plassert.

Testmetode 2, avsenderinfo:

IE – WAT – Frames – Navigate to framed documents (se verktøylisten). Visuell sjekk av rammesiden, se etter informasjon om avsender.

Testmetode 3, link til rammesett:

Hent opp en rammeside på samme måte som i testmetode 2, se etter link til rammesett og klikk på denne for å se om hele rammesettet lastes.

Meny og søk er to av de viktigste funksjonene på et nettsted og skal være tilgjengelig for alle. Enkelte brukere, spesielt de som benytter seg av datatekniske hjelpemidler, vil oppleve problemer med løsninger som er avhengige av ekstra utvidelser (eksempelvis javascript eller Flash) for å fungere. Indikatoren setter derfor krav til at meny og søkefunksjon ikke skal være avhengig av dette for å fungere.

Annen funksjonalitet på nettstedet som er avhengig av javascript og/eller Flash omfattes ikke av denne indikatoren.

Kravet gjelder hele søkefunksjonen, altså både søkefelt og søkeknapp.

Referanse; WAI WCAG 1.0 – 6.3

Eksempel; Alta kommune

Testmetode

Testmetode del 1, Javascript;

Firefox – WDTB – Disable – Disable JavaScript – All JavaScript – Oppdater siden (se verktøylisten).
Svar ja på ett eller begge alternativene, avhengig av hvilke som fungerer som før. Svar nei dersom verken menyer eller søkefunksjon (både søkefelt og søkeknapp) fungerer.

Testmetode del 2, Flash;

Firefox – Flashblock (skru på Flashblock (Javascript må nå være aktivert igjen for at Flashblock skal fungere)) – Oppdater siden (se verktøylisten).
Svar ja på ett eller begge alternativene, avhengig av hvilke som fungerer som før. Svar nei dersom verken menyer eller søkefunksjon (både søkefelt og søkeknapp) fungerer.

Tilstrekkelig kontrast mellom tekst og bakgrunn er viktig for at personer med nedsatt syn skal kunne lese innholdet. Det finnes ulike måter å regne ut kontrast på, algoritmen som benyttes her måler kontrast i lysverdi. Farge spiller ingen nøkkelrolle i algoritmen, slik at kontrastverdien er gyldig også for personer med nedsatt fargesyn.
Dersom man ikke har tilfredsstillende kontrast på nettstedet, er et alternativ å tilby en høykontrastversjon av innholdet.
Logoer, innholdsbilder og lignende har ikke krav til kontrast.

Referanse; WAI WCAG 2.0 – 1.4.3

Eksempel; Høgskolen i Bergen

Testmetode

IE – WAT – Colour – Contrast Analyser (velg luminosity-algoritmen) (se verktøylisten).
Menyer, innhold og andre elementer rettet mot de besøkende skal testes. Logoer og innholdsbilder skal ikke testes.
Velg forgrunns- og bakgrunnsfarge på de ulike elementene, kontroller kontrastverdien og gi poeng basert på det dårligste resultatet.

Når en nettside leses som en sekvens (for eksempel tekst-til-tale-løsninger) har ikke brukeren mulighet til å flytte blikket dit selve hovedinnholdet begynner og er derfor nødt til å lese igjennom statiske elementer (for eksempel hovedmeny og søkefunksjon) før han kommer til innholdet.

Linker som hopper over statiske elementer og fører direkte til relevante innholdselementer internt på siden skal derfor være blant de 5 første linkene på siden. Indikatoren har kun krav om 1 slik link, som skal føre til hovedinnholdet, men flere linker kan legges til dersom disse er relevante. Linknavnet skal være beskrivende og det er ikke noe krav at linkene skal være synlige.

Dersom man ønsker å skjule disse linkene, skal ikke CSS-egenskapene display:none; / visibility:hidden; benyttes, da forsvinner de også i blant annet datatekniske hjelpemidler som har behov for nettopp disse linkene. Posisjonering utenfor det visuelle grensesnittet via CSS er foretrukket dersom disse skal skjules.

Referanse; WAI WCAG 2.0 – 2.4.1

Eksempel; Høgskolen i Bergen

Testmetode

Testmetode del 1, finne linker;

IE – WAT – Doc info – List links (se verktøylisten). Svar «Ja» dersom en av de fem første lenkene er en lenke til hovedinnholdet på siden (noter navnet på linken da dette brukes i del 3).

Testmetode del 2, beskrivende/fungerende;

Sjekk at navnet på linken er beskrivende og at den fungerer tilfredsstillende (klikk og kontroller at man blir flyttet dit det er beskrevet).

Testmetode del 3, kontroll av CSS (kun dersom linkene ikke er synlige);

Firefox – WDTB – CSS – Disable Styles – All Styles (se verktøylisten). Høyreklikk på en av linkene som ble funnet i testmetode del 1 og 2 og velg «Inspect Element» for å starte Firebug. Venstre del vil nå vise HTML-kode med den aktuelle linken er markert, mens høyre del viser teksten «This element has no style rules» (fordi CSS er deaktivert). Trykk nå «Oppdater» i nettleser (dette gjøres for å aktivere CSS igjen). Venstre del som tidligere viste «This element has no style rules» vil nå vise hvilke CSS-egenskaper som gjelder for linken. Svar nei (0 poeng) dersom egenskapene display: none; eller visibility: hidden; er brukt.

Merk at CSS-egenskapene som skjuler linken kan ligge på et omspennende element, eksempelvis en DIV, der hele DIVen skjules. Dette kan sjekkes ved å klikke seg oppover i elementhierarkiet i venstre del av i Firebug, hvorpå CSS-egenskapene vil følge i høyre del.

Eksempel: Se løsningen til http://www.norge.no/, hvor absolutt posisjonering benyttes.

CSS brukes for å skille form og innhold og gjør designet langt mer fleksibelt og funksjonelt blant annet med tanke på visning tilpasset ulike medier. Ved å bruke CSS gir man også brukeren en større mulighet til å overstyre sidens utseende, blant annet farger, kontrast og typografi.
Layouttabeller skal unngås både av semantiske grunner og ikke minst fordi en mister mye av fleksibiliteten og funksjonaliteten som er nødvendig for mange brukergrupper.

Med bakgrunn i at flere brukergrupper viser nettsider uten CSS-instruksjoner, skal en lesbar struktur opprettholdes også når sidene vises uten CSS.

Referanse; WAI WCAG 1.0 – 5.3, samt heftet «Tilgjengelige nettsteder» side 25 kapittel 2.3 og 3.2.

Eksempel; Kongsvinger kommune

Testmetode

Testmetode del 1, CSS og layouttabell;

Firefox – WDTB – CSS – View CSS, kontroller at CSS brukes på nettstedet (se verktøylisten).
Firefox – WDTB – CSS – Disable Styles – All Styles. Kontroller at all formatering resettes (se verktøylisten).
Firefox – WDTB – Outline – Outline Tables – Tables, kontroller om tabeller brukes til layout (se verktøylisten).

Svar ja dersom CSS er tatt i bruk til formatering og layout.
Svar delvis dersom CSS brukes til formatering, men tabeller brukes til layout.
Svar nei dersom tabeller brukes til layout og CSS ikke brukes til formatering.

Testmetode del 2, lesbar struktur;

Firefox – WDTB – CSS – Disable styles – All styles, kontroller at siden beholder lesbar struktur (se verktøylisten).

Eksempler; www.dok.no har en løsning som vil gi 5 poeng, mens http://www.harstad.kommune.no er et eksempel på et nettsted som ikke oppfyller alternativet «Lesbar struktur».

Formålet med denne indikatoren er å gi informasjon om nettstedets hovedspråk, noe som avgjør at tekstlig innhold blir riktig presentert i nettlesere og datatekniske hjelpemidler, blant annet hos tekst-til-tale-løsninger som bruker denne informasjonen til å identifisere hvilket språk som skal benyttes. Dersom nettsiden har innhold på flere språk, er hovedspråket det språket som er mest utbredt.
Nettstedets hovedspråk skal angis i <html> (<html lang=”xx”>).

Aktuelle språkkoder finnes her; http://www.loc.gov/standards/iso639-2/php/English_list.php

Referanse; WAI WCAG 2.0 – 3.1.1 og Specifying Language in XHTML & HTML Content

Eksempel; Regjeringen

Testmetode:

Firefox – Høyreklikk et vilkårlig sted på siden – Vis Kilde – Kontroller at lang=”xx” ligger i <html>, for eksempel på denne måten <html lang=”no”> (se verktøylisten).
Bruk av xml:lang=”xx” alene (<html xml:lang=”no”>) godtas ikke, lang=”xx” må være inkludert.
Språkdeklarering angitt på andre måter enn nevnt over gir ikke poeng.

Aktuelle språkkoder finnes her; http://www.loc.gov/standards/iso639-2/php/English_list.php

W3C sine standarder er grunnlaget for utvikling av tilgjengelige nettsteder og gjør det mulig å presentere nettstedene på ulike medier. Det er også avgjørende at standarder følges for brukere som er avhengige av tilrettelagte løsninger og datatekniske hjelpemidler.

Det tolereres 5 feil i validatoren, uavhengig om det er samme type feil som går igjen flere ganger.

Referanse; WAI WCAG 2.0 – 4.1.1

Eksempel; Trondheim kommune

Testmetode

IE – WAT – Check – HTML Validation Quick Check (bruk valget «All Frames» på sider med rammer) (se verktøylisten).
Test startsiden og en side på nivå 2.
Dersom verktøyet validerer flere sider/rammer, velg resultatet som har samme URL som testsiden.

Svar godkjent dersom validatoren viser 5 eller færre feil.
Svar ikke godkjent dersom validatoren viser 6 eller flere feil.

Bredbånd har fremdeles ikke full dekning i Norge og det er derfor viktig å fokusere på størrelse slik at ikke nettstedet tar lang tid å laste. I tillegg er surfing via mobile enheter i kraftig økning der tunge nettsteder gjør det både tidkrevende og kostbart å surfe. Man bør derfor være observant på filstørrelser på blant annet bilder, HTML og CSS, slik at nettstedet ikke blir større enn det må. Kriteriets testmetode regner med alt som lastes fra nettstedet.

Testmetode

Firefox – Test nettstedets hovedside med YSlow (trykk på «YSlow» nede på statuslinjen i nettleseren og vent mens YSlow starter opp) – Velg «Stats» øverst i YSlow-vinduet (vent mens YSlow måler sidens størrelse).
Kontroller sidens størrelse (Total Size) i kolonnen «Empty Cache» til venstre og gi poeng med på bakgrunn av grenseverdiene i alternativene (se verktøylisten).

Stadig mer informasjon blir lagt ut på nett og det er avgjørende at vi kan stole på at denne informasjonen er riktig. Derfor er det viktig at alle informasjonselementer er påført dato for sist oppdatering. Rene transportsider faller ikke inn under dette kravet.

Eksempel; Asker kommune

Testmetode

Visuell sjekk på et tilfeldig utvalg sider på flere nivå på nettstedet, og man må se på ulike typer informasjonselement (nyheter, tjenestebeskrivelser, saksdokumenter, planer osv.). Rene «transportsider» skal ikke vurderes.
Gi 3 poeng dersom datering er konsekvent gjennomført på nettstedet.
Gi 1 poeng dersom det er datering på over halvparten av innholdselementene og ta med URL til sider uten datering i kommentarfeltet.

Vær oppmerksom på åpenbart feilaktig datostempling, for eksempel ved at hele nettstedet får ny dato når en side oppdateres.

Søkefunksjonen på et nettsted er en viktig navigasjonsstøtte for de fleste brukere. Det har stor betydning at søkefunksjonen er lett tilgjengelig og søkefeltet bør være stort nok til at brukerne kan skrive inn lengre ord eller korte fraser, og fremdeles se det som er skrevet inn (minimum 20 tegn).

Referanse; WAI WCAG 2.0 - 3.2.4

Eksempel; Alta kommune

Testmetode

Testmetode del 1, forekomst

Visuell kontroll, kontroller forekomst av søkefelt og søkeknapp på forsiden.

Testmetode del 2, på alle sider

Visuell kontroll, kontroller et utvalg undersider og sjekk at nettstedet har søkefelt på alle disse.

Testmetode del 3, størrelse

Kontroller at søkefeltet har plass til 20 synlige tegn ved å lime inn «01234567890123456789» (tallrekken består av 20 tegn) og sjekk at hele tallrekken er synlig på en gang.

Link til «Søk» i globalmeny eller lignende som gjentas på alle sider, oppfyller kriteriet «Har søkefelt» (totalt 1 poeng).

En god søkefunksjon er kjennetegnet ved at det er enkelt å finne frem i søkeresultatene, og hvordan søkeresultatet blir presentert er av stor betydning i så måte. På dette kriteriet er det satt fire krav: Beskrivende tittel, brukerstyrt sortering, tematisk gruppering/annen klassifisering, og ikke minst relevante treff.

Eksempel; Samferdselsdepartementet

Testmetode

Foreta søk med relevant søkeord fra en av kjernesidene og vurder treffene. Vurder tittel og mulighet for både sortering (relevans, dato og alfabetisk) og tematisk eller annen gruppering.

Relevante treff innebærer at resultatlisten må inneholde sider med den valgte kjerneinformasjonen, ha generelle dokumenter/sider med definisjoner/beskrivelser først, samt at sider/dokumenter med handlingsrettede/veiledende informasjon inngår høyt oppe på trefflisten. Man må derfor besøke de ulike resultatsidene for å få vurdert dette.

Eksempel;

Regjeringen.no vil på dette punktet oppnå full score;
http://www.regjeringen.no/nb/sok.html?id=86008&epslanguage=NO,NO&quicksearch=barnehage

Hovedmålgruppen for denne indikatoren er fremmedspråklige i Norge som er ute etter viktig informasjon om offentlig tjenestetilbud. Oversettelser av brukerrettet kjerneinformasjon gir derfor mer uttelling enn mer generell informasjon eller turistinformasjon. Virksomhetene er selv de nærmeste til å vurdere sin egen kjernevirksomhet, og tegn på god vurdering av dette gir ekstra uttelling. På bakgrunn av hovedmålgruppen bør inngangen til denne informasjonen ligge lett tilgjengelig på forsiden av nettstedet. Vær oppmerksom på at indikatoren måler språk og ikke målform, og heller ikke legger retningslinjer på hvilke språk som er relevante da dette vil variere og er opp til virksomhet å avgjøre. Automatiserte oversettelser (for eksempel Google Translate) gir ikke poeng her, da det blant annet ikke finnes noe kvalitetssikring av resultatet.

Eksempel; Samferdselsdepartementet

Testmetode

Visuell kontroll, se etter lett tilgjengelig inngang til annen språkversjon. Gi 1 poeng for kontaktinformasjon og 1 poeng for brukerrettet kjerneinformasjon. Sistnevnte skal være utfyllende.
Det foreligger ingen retningslinjer på hvilke språk som godkjennes. Samisk regnes som poenggivende språk.

Eksempel; http://www.trondheim.no/engelsk vil få full uttelling – 2 poeng – blant annet i lys av innholdet under menypunktet «Public Services».

En konsistent meny er det viktigste navigasjonsverktøyet på et nettsted, og denne skal være inngangen til hovedinformasjonen på nettstedet. Brukeren skal alltid ha mulighet til å navigere uten å måtte bruke «Tilbake»-knappen i nettleseren, og er derfor avhengig av at menyen skal være konsistent ned til nivå 3 på nettstedet. Med konsistent menes at menyen skal være gjennomgående lik.

Referanse; WAI WCAC 2.0 - 3.2.3

Eksempel; Finansdepartementet

Testmetode

Visuell kontroll, kontroller at hovedmenyen er konsistent ned til nivå 3 på nettstedet.

Et nettsted kan ha mange undernivåer og en kompleks oppbygging. Det er derfor viktig at brukeren vet hvor i nettstedsstrukturen han befinner seg. Brødsmulesti OG/ELLER markering i meny er begge viktige former for navigasjonsstøtte og de likestilles i denne testen. Brødsmulesti skal være klikkbar, markering i meny skal være tydelig, og begge skal minimum være gjort gjeldende ned til nivå 3 på nettstedet.
NB; Dette kriteriet gir maksimalt gir 2 poeng, selv om man både har brødsmulesti og markering i meny (løsningene sidestilles).

Referanse; WAI WCAG 2.0 – 2.4.8

Eksempel; Finansdepartementet

Testmetode

Visuell sjekk, kontroller om det er mulig å avgjøre hvor på nettstedet man er basert på klikkbar brødsmulesti (eksempelvis brødsmuler/«Her er du») og/eller tydelig markering i meny (eksempelvis utheving/farge).
Markeringen skal minimum være gjort gjeldende ned til nivå 3 på nettstedet.

Innhold på offentlige nettsteder vil ofte være aktuelt å skrive ut. Dette må kunne skje enkelt og gi et tilfredsstillende resultat. Det er for eksempel ikke tilfredsstillende dersom unødvendig mye papir og blekk brukes på menyer, grafikk og bakgrunn, eller at sidene kuttes i margene slik at innhold forsvinner på utskriften. Det beste er om nettstedet har en egen utskriftsvennlig versjon av innholdet, eller at det finnes egne CSS-stilark som automatisk brukes når man skriver ut.

Eksempel; Skien kommune

Testmetode

Opera – kontroller at dette valget er skrudd på; «Fil – Utskriftsalternativer – Skriv ut sidebakgrunn». Dette gjøres fordi alle nettlesere ikke fjerner bakgrunn på utskrift (se verktøylisten).

Se etter lenke eller ikon til utskriftsvennlig versjon eller gå til «Fil – Forhåndsvisning» og kontroller resultatet.

Gi 3 poeng dersom utskriften kun er innholdsrelatert (egen utskriftsvennlig versjon eller via tilrettelegging via CSS).

Gi 1 poeng dersom utskriften inneholder unødvendige elementer fra nettstedet (meny, bakgrunn, etc).

Gi 0 poeng dersom utskriften ikke er tilpasset utskrift.

Vurderingen bør være streng, siden dette ikke er noe nytt krav.

En sideoversikt, for eksempel i form av nettstedskart, gir viktig navigasjonsstøtte for de besøkende. I tillegg gjør en slik oversikt det lettere å se hva nettstedet inneholder og hvordan innholdsstrukturen er organisert. Oversikten bør gi tilgang til innholdet i henhold til menystruktur, indeks bør være en alfabetisk sortert stikkordsliste. Oversikten skal i minste fall dekke innhold ned til nivå 3 og være tilgjengelig og lett å finne fra forsiden.

Det er viktig at en slik innholdsoversikt er oppdatert og ikke inneholder feil.

Referanse; WAI WCAG 2.0 - 2.4.8

Eksempel; Alta kommune

Testmetode

Testmetode del 1, forekomst;

Visuell kontroll, sjekk forekomst av nettstedskart. Link til nettstedskartet skal være godt synlig på forsiden, og teksten på lenken skal være beskrivende slik at det er lett å forstå at det ligger et nettstedskart eller en indeks bak.

Testmetode del 2, dekning;

Visuell kontroll: Sjekk hvorvidt sideoversikten dekker innhold ned til nivå 3.

Bruk av metadata gjør det blant annet enklere for søkemotorer å gi gode treff på søk og har betydning for utviklingen av semantisk web. Derfor er det viktig at «description» og «keywords» brukes aktivt og beskriver hver enkelt underside på en god måte.

Referanse; WAI WCAG 1.0 - 13.2

Eksempel; Samferdselsdepartementet

Testmetode

IE – WAT – Doc info – Metadata information (se verktøylisten). Sjekk forekomst av metadata (description og keywords) på startsiden, samt innholdet i disse. Innholdet skal være beskrivende og relevant i forhold til nettstedets innhold. Gjenta prosessen på minst 3 undersider, og kontroller hvorvidt nettstedet har unike metadata på hver side.
Gi 1 poeng dersom det kun finnes metadata på startsiden eller alle undersider har like metadata.
Gi 2 poeng dersom nettstedet har unike metadata på alle sider.

Nettsteder som kun har unikt beskrivende «description» på hver side belønnes også med 2 poeng.
For sider som er basert på rammer må metadata for innholdsrammen (se på rammens navn eller adresse for å finne innholdsrammen) vurderes.

Tekniske metadata eller metadata som profilerer leverandører gir ikke poeng. «Misbruk» av metadata skal ikke forekomme og kan i verste fall gi poengtrekk.

Nettstedets sidetitler og adresser spiller en viktig rolle på flere områder for de besøkende. En beskrivende sidetittel og adresse gjør det lettere for brukeren å avgjøre hvor på nettstedet han er og hva som kan forventes å finne av innhold på siden. Sidetitlene brukes også av blant annet søkemotorer og nettstedskart, noe som gjør viktigheten enda større, i tillegg til at man legger bedre til rette for bokmerking. Med bakgrunn i blant annet sistnevnte, er det et krav at man skal ha med virksomhetens navn eller domene i tittelen (eksempelvis «Kontakt» vs «Kontakt Hole kommune »). Adressene skal i tillegg til å være beskrivende også være unike for hver side, slik at det er mulig å linke eller bokmerke direkte til en side. Språket som benyttes i adressene skal være det samme som nettstedets hovedspråk.

Referanse; WAI WCAG 2.0 - 2.4.2

Eksempel; Kongsvinger kommune

Testmetode

Testmetode del 1, adresse;

Visuell kontroll på et utvalg sider ned til nivå 3 på nettstedet, kontroller at sidenes adresse (URL) er beskrivende i forhold til innholdet og unik for hver enkelt underside. Kontroller også at språket som benyttes er det samme som nettstedets hovedspråk.
Eksempel på godkjent – http://trondheim.kommune.no/betalingssatser/
Eksempel på ikke godkjent – http://www.norge.no/temaside/tema.asp?id=102

Testmetode del 2, tittel;

Visuell kontroll på et utvalg sider ned til nivå 3 på nettstedet, kontroller at sidenes tittel er beskrivende i forhold til innholdet. Kontroller at virksomhetens navn eller domene er med i sidetittel og at språket som benyttes er det samme som nettstedets generelle hovedspråk.

Språket på nettsidene skal være klart, lett å forstå og enkelt å lese for brukerne. LIX-beregning brukes for å måle tendensen i nettstedets tekster med hensyn til grad av lesbarhet.

Testmetode

http://www.lix.se/index.php?f=0 – Bruk fanen «Klipp», kopier og lim inn egnet tekst fra nettside og kontroller resultatet (se «Textens läsbarhetsindex er …»)
Med egnet tekst menes;

• Kjerneinformasjonsside ment for vanlige brukere
• 150-600 ord
• Overskrifter/mellomoverskrifter skal ikke tas med

Dersom resultatet er nær en av grenseverdiene, gjenta prosessen med en annen egnet tekst og finn gjennomsnittsresultatet.

01.01.09 ble ODF og PDF innført som obligatoriske dokumentformat i staten.

Dette vil gjøre det lettere for de besøkende å få tak i dokumenter fra nettstedet, da man slipper problematikken rundt krav om programvare som i verste fall kan føre til økonomiske utlegg for brukeren.

Indikatoren belønner publisering av dokumenter i HTML-format (at informasjonen ligger som innhold rett på nettstedet i stedet for nedlastbare dokumenter), samt PDF (dokumenter som skal beholde formatering), ODF (dokumenter som er ment til videre redigering) og DOC (som et supplement til ODF i en overgangsperiode). Informasjon både som HTML og nedlastbart dokument er et eksempel på en kombinasjon som gir full score, et annet er korrekt bruk av de nedlastbare formatene PDF og ODF (forklart over).

Redigerbare skjema som PDF med interaktive komponenter (at PDFen kan skrives i) likestilles med ODF.

ODF er en fellesbenevnelse for flere åpne dokumentformater, derav blant annet ODT (tekstdokumenter), ODS (regneark) og ODP (presentasjon).

Testmetode

Visuell sjekk. Kontroller om nettstedet har dokumenter til nedlastning og hvilke dokumentformater nettstedet benytter. Poenggi basert på resultatet, indikatoren gir maksimalt 4 poeng.

Tips; Dokumenter kan finnes via Google ved å bruke følgende søkestreng;
site:norge.no filetype:pdf/odt/doc/etc (bytt ut norge.no med aktuelt nettsted, samt ønsket filtype).

Nettet er en viktig arena for informasjonsflyt mellom forvaltning og bruker. Indikatoren belønner tilrettelegging for en- og toveiskommunikasjon og muligheter for brukervalg. Aktuelle tjenester er nettprat, automatiserte SMS-tjenester og nyhetsstrøm i form av for eksempel RSS eller nyhetsbrev. Det er et krav at tjenestene er lett synlige på nettstedet, fortrinnsvis på forsiden. SMS-tjenester skal være automatiserte og nettsteder som kun oppgir mobilnummer til for eksempel tjenestetorg oppfyller ikke kravet. RSS-strømmer skal kunne oppdages maskinelt og det er derfor et krav at disse implementeres riktig.

Eksempel RSS; Vegvesen.no

Eksempel nettprat; Norge.no

Eksempel SMS; Vegvesen.no

Testmetode

Testmetode del 1, nyhetsstrøm (for eksempel RSS eller nyhetsbrev);

Firefox – Se etter RSS-logo til høyre på adresselinjen i Firefox (testen gjøres på startsiden på nettstedet) (se verktøylisten). RSS-strømmer som ikke kommer opp med ikon i adresselinjen gir ikke poeng (denne er da implementert på en måte som ikke er mulig å oppdage maskinelt), selv om RSS-strøm finnes et annet sted på nettstedet.

Se etter muligheter for å melde seg på nyhetsbrev eller andre nyhetsstrømmer, dette skal være lett synlig.

Testmetode del 2, nettprat og SMS;

Visuell sjekk av nettstedet, tjenestene skal være lett synlige.
SMS-tjenester skal være automatiserte, nettsteder som kun oppgir mobilnummer til for eksempel tjenestetorg oppfyller ikke kravet.

Organisasjonens nettsted er et av de første stedene man leter når man er på jakt etter informasjon om kjerneoppgavene til en organisasjon. Nettstedet skal derfor gi fyldig og oppdatert informasjon om relevante tema og tjenester som er del av organisasjonens kjernevirksomhet. Den viktigste informasjonen og de viktigste tjenestene som organisasjonen tilbyr skal tematiseres, struktureres og aktualiseres på nettstedet slik at brukeren enkelt kan finne frem til den informasjonen han trenger. Indikatoren gir maksimalt 5 poeng, selv om det er 6 krav.

Testmetode

Visuell kontroll, gi en skjønnsmessig vurdering av innholdet på sider med tema-/tjenesteinformasjon. Slike sider skal være lett tilgjengelig og presenteres på en oversiktlig måte med overskrifter, bokser, tydelige funksjonsanvisninger og med interne og eksterne lenker til så vel autentiske (lov)tekster som konkret regelverk og tjenester. Nettsteder som gir brukerne relevant aktualitetsstoff, henvisninger og tilbud om mer-informasjon knyttet til kjernevirksomheten skal belønnes.

Sider med klart avsenderperspektiv som for eksempel «Om oss», skal ikke testes, og en generell henvisning til servicetorg eller lignende oppfyller ikke kravet «Viser hvem i organisasjonen som kan gi mer informasjon».
På kommunale nettsteder er sidene som omhandler barnehagetilbudet i kommunen et eksempel på sider med slik brukerrettet kjerneinformasjon.

Eksempler:

I kommunesektoren er www.asker.kommune.no et eksempel som tilfredsstiller flere av kravene til god informasjon. Hos statlige etater er SFTs temasider et godt eksempel, se blant annet sidene om luftforurensing, http://www.sft.no/tema____3318.aspx.

Sentral kontaktinformasjon skal være lett tilgjengelig uansett hvor på nettstedet man er. Behovet for å ta kontakt utløses ofte av noe som står på sidene og da er det viktig at kontaktinformasjon finnes på samme side. Den viktigste kontaktinformasjonen, det vil si telefonnummer og e-post til virksomheten, bør derfor gjentas på alle sider.

Forsiden eller egen kontaktside skal inneholde telefonnummer, e-post, postadresse og besøksadresse (dersom sistnevnte er forskjellig fra postadressen).

Eksempel; Samferdselsdepartementet

Testmetode

Testmetode del 1, ja

Visuell kontroll, sentral kontaktinfo skal være tilgjengelig på forsiden eller på egen kontaktside som er tilgjengelig fra global meny.
Med sentral kontaktinfo menes sentralbordets telefonnummer, e-post, postadresse og besøksadresse (dersom sistnevnte er forskjellig fra postadressen).

Testmetode del 2, ja, på alle sider

Visuell kontroll, kontroller at telefonnummer og e-post til virksomhetens sentralbord vises på alle sider på nettstedet. Fysisk plassering av kontaktinfoen spiller ikke inn i vurderingen, selv om denne ikke bør gjemmes bort.

Nettsteder er en viktig ressurs for å finne egeninformasjon om organisasjoner. Informasjonen skal være utfyllende og oppdatert, med tanke på beskrivelse av egen organisering, tilhørighet og de viktigste arbeidsområdene.
Informasjonen skal være lett tilgjengelig på nettstedet.

Eksempel; Hole kommune

Testmetode

Testmetode del 1, organisasjonskart;

Visuell sjekk, kontroller om nettstedet har organisasjonskart og om dette er lett å finne. Organisasjonskartet skal være synliggjort på nettstedet, løsninger som krever nedlastning (for eksempel formatene PDF eller DOC) gir ikke poeng.

Testmetode del 2, presentasjoner;

Visuell sjekk, se etter organisasjonsinnganger/klikkbare organisasjonskart med lenker til presentasjon av organisasjonens ulike arbeidsområder eller organisasjonsleddenes oppgaver.
Se i tillegg etter presentasjon av alle ansatte/ledelse. Presentasjonen skal inneholde navn, kontaktinformasjon, arbeidsoppgaver og eventuelt kompetanse på hver enkelt.

For virksomheter der presentasjon av ansatte av forståelige grunner må begrenses (for eksempel politi eller skattevesen), holder det at toppledelsen blir presentert. Løsninger hvor man ikke får oversikt over de ansatte, men kun får de opp ved å søke etter navn gir ikke poeng blant annet fordi dette krever at navnet er kjent på forhånd.

I henhold til offentlighetsloven har man en lovfestet rett til innsyn, og indikatoren belønner derfor organisasjoner som tar i bruk teknologien for å forenkle denne prosessen og som aktivt bruker nettet for å åpne opp organisasjonen. Innsyn i organisasjonens postjournal, saker og møter fremmer demokrati, deltagelse og åpenhet.

Alternativet «Ikke relevant» brukes kun dersom nettstedet ikke representerer en virksomhet, for eksempel www.norge.no som er en portal som eies av Direktoratet for forvaltning og IKT.

Eksempel; Bærum kommune

Testmetode

Testmetode del 1, postjournal;

Visuell sjekk, kontroller forekomst av postjournal (ett poeng) og om dokumenter publiseres i fulltekst eller kan bestilles via eget skjema eller forhåndsutfylt e-post (ett ekstra poeng).
Publisering av dokumenter i fulltekst og bestillingsfunksjonalitet sidestilles i vurderingen.
Løsninger som kun oppgir e-postadresse tilfredsstiller ikke kravet til bestilling.

Testmetode del 2, innsyn;

Visuell sjekk, se etter mulighet for innsyn i saker og møter.
Innsyn i saksdokumenter krever mulighet til å se eller laste ned saksdokumenter, innkallinger eller referat/protokoller fra møter. Digitalt innsyn krever mulighet for å se eller laste ned lyd- eller videooverføringer fra møter.

Alternativet «Ikke relevant» brukes kun dersom nettstedet ikke representerer en virksomhet, for eksempel www.norge.no som er en portal som eies av Direktoratet for forvaltning og IKT.

Indikatoren sjekker hvorvidt offentlige nettsteder tar i bruk elektroniske høringer som verktøy for demokratisk dialog og deltakelse og belønner de som legger til rette for dette. En komplett høringsløsning skal gi tilgang til aktuelle høringsdokumenter, har egne skjema for innsending av uttalelser og gi tilgang til andre uttalelser i saken.

I tillegg til de mer tradisjonelle (og gjerne lovpålagte) høringene de fleste kjenner, belønner også indikatoren nettsteder som arrangerer elektroniske høringer i mindre saker hvor innspill fra berørte/besøkende vil være av interesse. Et eksempel kan være plassering av en kommunal volleyballbane.

Eksempel; Difi – Los

Testmetode

Visuell kontroll, sjekk forekomst av løsning for elektroniske høringer.

Bruk alternativet «enkel høring» dersom virksomheten kun legger ut saksdokumenter og eventuelle høringsuttalelser må sendes inn via e-post.

Bruk alternativet «enkel høring med innsending» dersom virksomheten legger saker ut på høring og har egne skjema til å sende inn høringsuttalelser tilknyttet saken, men mangler tilgang til andre uttalelser i saken. Dette alternativet skal også benyttes dersom nettstedet mangler skjema for elektronisk innsending, men legger ut uttalelser i saken.

Bruk alternativet «komplett høringsløsning» dersom virksomheten legger saker ut på høring, har egne skjema for innsending av uttalelser og gir tilgang til andre uttalelser i saken.

Webteknologien gir store muligheter til å lage nyttige løsninger for de besøkende. Indikatoren sjekker hvorvidt offentlige nettsteder tar i bruk mulighetene som finnes og utnytter disse til sin fordel. Aktuelle løsninger kan være kart, bestillingstjenester eller beregningskalkulatorer. Løsningene skal være lett synlige og ikke være avhengige av innlogging.

Eksempel digital medvirkning; Hole kommune, e-initiativ

Eksempel avansert funksjonalitet; Statens Vegvesen, VisVeg

Testmetode

Testmetode del 1, digital medvirkning;

Visuell kontroll, kontroller forekomst av funksjonalitet som fremmer digital medvirkning. For eksempel kan dette i kommunesammenheng være «elektronisk innbyggerinitiativ», som gjør det enklere for innbyggerne å fremme forslag etter kommunelovens § 39.

Testmetode del 2, funksjonalitet og webteknologi;

Visuell kontroll, kontroller forekomst av avansert funksjonalitet eller tjenester uten innlogging, samt spesielle tjenester utviklet av den enkelte virksomheten som vil være til nytte for brukeren.

Eksempel, digital medvirkning;

Hole kommune har skjema for e-innbyggerinitiativ – http://www.hole.kommune.no/index.php?cat=41243.

Eksempel, funksjonalitet og webteknologi;

«VisVeg» fra Statens Vegvesen – www.visveg.no

Elektroniske skjema gjør prosessen med innsending av skjema lettere og ikke minst raskere, både for brukeren og virksomheten. Indikatoren belønner derfor nettsteder som legger til rette for elektronisk innsending av skjema.
Med hensyn til personvern, skal innsending av elektroniske skjema som inneholder persondata være krypterte. På denne måten er det ikke mulig for uvedkommende å hente ut informasjonen under sending til mottaker.

Maks poengscore på denne indikatoren er 5 poeng, som gis når nettstedet har elektroniske skjema med kryptering.

Eksempel; Alta kommune

Testmetode

Testmetode del 1, relevans;

Avgjør hvorvidt nettstedet har behov for skjema for elektronisk innsending, basert på virksomhetens art. Nettsteder som ikke er relevante skal ha alternativet «ikke relevant» og argumentasjon for beslutningen skal begrunnes. Nettsteder som er relevante vurderes etter testmetode 2 og 3.

Testmetode del 2, elektroniske skjema;

Visuell sjekk av nettstedet. Se etter skjema for elektronisk innsending. Enkle skjema, eksempelvis enkle kontaktskjema, gir ikke uttelling.

Testmetode del 3, kryptering (kun dersom nettstedet har elektroniske skjema som funnet i testmetode del 2);

Firefox, kontroller at URL (sideadressen i adresselinjen) på skjemasiden begynner med httpS://, altså bokstaven S like etter «http».
Et hengelåsikon vises også i statuslinjen i nedre del av nettleseren.

Selvbetjeningsløsninger gir store muligheter for innbyggeren på nett, og det er derfor viktig at nettstedet tilbyr informasjon om viktige aspekter rundt løsningen som er relevante for brukeren. Indikatoren sjekker aspekter rundt hvilke krav som stilles for å kunne autentisere seg (hva kreves for å bruke tjenesten), hvilke tjenester som finnes i selvbetjeningsløsningen og hvordan virksomheten behandler personopplysninger og belønner de nettstedene som gir god informasjon rundt dette. Informasjonen skal være lett synlig og tilgjengelig uten å måtte logge seg inn.

Eksempel; Alta kommune

Testmetode

Testmetode del 1, relevans;

Avgjør hvorvidt nettstedet vil ha behov for innloggingsbasert selvbetjening, basert på virksomhetens art. Nettsteder som ikke er relevante skal ha alternativet «ikke relevant» og argumentasjon for beslutningen skal begrunnes. Nettsteder som er relevante vurderes etter testmetode 2.

Testmetode del 2, informasjon;

Visuell sjekk, kontroller om nettstedet tilbyr innloggingsbasert selvbetjening og hva som finnes av informasjon rundt denne. Løsningen skal ha informasjon om hvilke krav som stilles for å kunne autentisere seg (hva kreves for å bruke tjenesten), hvilke tjenester som finnes i selvbetjeningsløsningen og hvordan virksomheten behandler personopplysninger.
Bruk alternativet «nei» dersom nettstedet mangler selvbetjening med autentisering eller ikke oppfyller noen av kravene til informasjon om selvbetjeningsløsningen.

Eksempel;www.asker.kommune.no