Generelle spørsmål

En barriere er en hindring som gjør det vanskelig eller umulig for enkelte mennesker å få adgang. For eksempel kan trapp hindre en rullestolbruker fra å komme inn I en bygning..
Dårlig utformede nettsteder kan også inneholde barrierer. For ekesmpel kan navigasjon på nettstedet kreve bruk av mus Mennseker med motoriske vansker eller mobiltelefonbrukere kan da oppleve en hindrng som I verste fall kan gjøre nettstedet ubrukelig for dem.
Et tilgjengelig nettsted har ingen barrierer og vil fungere for alle brukere, også de med spesielle behov, som de med netsatt syn, dyslektiere, fargeblinde, eller som sagt mobiltelefonbrukere. If your web site is barrier free, more people can use your web site. Uten barrierer vil ditt nettsted kunne brukes av flere.
For mer informasjon see også (engelsk) WAI Resources on Introducing Web Accessibility

Forsøk å fjerne de barrierer som sjekken fant. Noen barrierer kan kreve endringer ut over de rent tekniske justeringene, så som kursing av redaktører for å produsere mer tilgjengelig innhold, mens andre tiltak kan kreve endringer I publiseringsverktøyet. Dette kan for eksempel gjelde en overgang fra tabeller brukt til å strukturere en side, til stilark for samme struktur.
 

Du kan også få nærmere råd fra en tilgjengelighetskonsulent Og sist men ikke minst , lytte til bruker av nettstedet ditt, og legg til rette for dem slik at de enkelt kan rapportere barrierer eller andre problemer de oppdager.
Generelt kan sies at jo lavere UWEM-Score du får på nettstedet jo mer tilgjengelig er nettstedet ditt. Se også vår ansvarsfraskrivelse for nærmere opplysninger om bruk av resultatene.
For mer informasjon om forbedring av tilgjengeilghet se også oversikten fra WAI (engelsk) "Improving the Accessibility of Your Web Site".
 

Hver nettside testes med 21 HTML-tester og to CSS-tester.

W3C tilbyr flere retningslinjer og teknikker for hvordan man kan lage tilgjengelig nettinnhold. (denne informasjonen finnes bare på engelsk).

For informasjon på norsk, har Deltasenteret gitt ut tre veiledere for hvordan man kan lage tilgjengelige nettsteder. Den første omhandler oversikt og innholdsproduksjon den andre design og koding. (Publisert i 2006), Den tredje gjelder Anskaffelse og kvalitetskriterier utformede nettsteder.
 

Fargene gjenspeiler UWEM-score. Rødt signaliserer dårligste poengsum, mens grønt står for beste poengsum. UWEM-score er beregnet som forholdet mellom antallet tester som identifisert barrierer og antallet tester som er gjennomført.
 

UWEM står for "Unified Web Evaluation Methodology" og er en europeisk metodikk for å måle i hvilken grad innhold på nett er tilgjengelig for mennesker med nedsatt funksjonsevne. Metoden bygger på retningslinjene fra W3C (WCAG1.0/W3C), og ble utviklet av 24 organisasjoner i et samarbeid. Se også
http://www.wabcluster.org.

WCAG står for Web Content Accessibility Guidelines, og er retningslinjer som skal forklare hvordan tilgjengelig innhold på nett kan utformes. WCAG utvikles av World Wide Web Consortium (W3C). Den første versionen av WCAG (WCAG 1.0) ble publisert I 1999, og WCAG 2.0 ble publisert I Desember 2008. eGovMon og eAccessbility Cecker er basert på UWEM tester som er definert ut fra WCAG 1.0. For mer om WCAG se også WCAG overview.
Checkeren bruker UWEM-tester, som er basert på WCAG 1.0.

For mer informasjon om WCAG, se WCAG overview (finnes kun på engelsk).

De fleste nettsteder som er utformet I hendold til WCAG 1.0 vil ikke kreve store endringer for å tilfredstille WCAG 2.0. De grunnleggende retningslinjene er uendret, så forskjellene ligger hovedsaklig i at WCAG 2.0 er mer generell for å kunne brukes på flere teknologier ut over HTML, og at kravene i WCAG 2.0 er mer spesifike slik at de enklere kan testes..

Les også på http://www.w3.org/WAI/WCAG20/from10/diff.php for mer informasjon om forskjellene mellom WCAG 1.0 og 2.0. Informasjonen finnes bare på engelsk.

Selv om sjekk av tilgjengliehget til et nettsted blir gjennomført ut fra samme retningslinjer er det rom for ulike måter å gjennomføre det i praksis. WCAG 2.0 med sine mer spesifikke krav danner et bedre grunnlag enn WCAG 1.0 for å utforme tester, men for å gjennomføre repeterbare sjekker av nettsteder må ytterligere krav spesifiseres. Det gjelder blandt annet hvordan nettsider skal velges fra et nettsted, og hvordan en score beregnes.
 

Dette avhenger av når den nye versjonen av UWEM vil bli ferdigstilt. Ta gjerne kontakt med oss for en oppdatert status på denne utviklingen.

Send oss en e-post på maintainer@egovmon.no med en beskrivelse av problemet, den nøyaktige nettadressen (URL) som ble testet, samt hvilken nettleser du brukte da du testet nettsiden.

Checkeren inkluderer korrekt oppbygget HTML (W3C HTML validator) i tillegg til andre tilgjengelighetstester. Checker fokuserer på tilgjengelighet, mens validatoren fokuserer på korrekt oppbygget HTML. Korrekt oppbygget er ikke i seg selv nok for tilgjengelighet, men korrekt oppbygget HTML er også en del av tilgjengelighetstestene.

Checkeren tester på samme måte som W3C sin validator for stilark.

Skrifttyper uten serif er som regel lettere å lese enn med serif.
Eksempler:
Dette er skrifttype med serif (Times New Roman)
Dette er en skrifttype uten serif (Arial)
Se også:
http://www.w3.org/TR/css3-fonts/
http://www.surl.org/usabilitynews/81/PersonalityofFonts.asp
http://psychology.wichita.edu/surl/usabilitynews/52/UK_font.htm
og
http://courses.iicm.tugraz.at/hci/hci.pdf
se kap 11.2 Factors Influencing the Legibility of Text (pp 140)

Linjen som feilmeldingen refererer til ser slik ut
<a href=''><a href="http://samarbeidforarbeid.regjeringen.no/">Samarbeid for arbeid</a></a>
Grunnen til feilmeldingen er at en <a> er nøstet. Den lange listen med “missing one of” skyldes at validatoren ikke vet hva den som har laget siden egentlig har ment og at flere muligheter er tillatt.
Andre ting enn tekst kan plasseres mellom taggene. HTML-definisjonen bestemmer hvilke elementer som er tillatt i hvilken posisjon.

Robots.txt benyttes av søkemotorer (eks. Google) for å ekskludere deler av et nettsted fra automatisk gjennomsøkning (indeksering). Normalt plassers baner til kataloger med innhold som ikke bør indekseres, f.eks programmer i robots.txt, men det er også mulig å legge inn baner til kataloger og dokumenter. Merk at Robots.txt ikke gir noen beskyttelse mot indeksering, og ikke kan brukes som en sikkerhetsmekanisme.
Det er viktig å huske at robots.txt fungerer som en anbefaling for crawlere. De som implementerer crawlere velger om den skal følge robots.txt eller ikke. I dag er det etablert at de «snille» crawlerene respekterer robots.txt (slik som Google, Yahoo). Derimot vil de «slemme» crawlerene (malware) kunne bruke robots.txt for å finne ut hvor sensitiv informasjon kan befinne seg.
Se også:
http://www.robotstxt.org/faq/nosecurity.html
http://www.seomoz.org/ugc/how-to-use-robotstxt-and-redirects-the-wrong-way
http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1974/1849
 

Ja, det er avgjort bedre å legge stiler i en separat fil enn å legge det inn i HTML dokumentet. På denne måten blir utseende skilt fra innhold, og utseendet (stilene) kan dermed enkelt gjenbrukes på andre sider på nettstedet.
 

Foreløpig er ikke LIX en del av vår checker, men kan bli vurdert i fremtidige versjoner. LIX er imidlertid ikke formelt en del av WCAG.

Checkeren bruker W3C validatoren for å finne valideringsfeil på dokumentet. Dermed skal feilene som oppdages av W3C validatoren også rapporteres av Checkeren. Hvis dette ikke er tilfelle, er det trolig en feil med Checkeren som vi gjerne vil få en melding om.