Tilgjengelighetserklæring for vegvesen.no

  • vegvesen.no
  • STATENS VEGVESEN, organisasjonsnummer 971 032 081
Erklæringen er oppdatert

I hvilken grad er nettstedet i samsvar med kravene til universell utforming?

Nettstedet er delvis i samsvar med kravene til universell utforming av ikt.

Det er brudd på 35 av 48 krav i regelverket.

Hva betyr bruddene for brukerne?

Bruddene som er registrert i denne erklæringen får spesielt konsekvenser for brukere som har følgende forutsetninger:

  • Bruk uten syn
  • Bruk med avgrenset syn
  • Bruk uten fargesyn
  • Bruk uten hørsel
  • Bruk med nedsatt hørsel
  • Bruk med nedsatt bevegelsesevne eller styrke
  • Bruk med begrenset rekkevidde
  • Begrensning av anfall på grunn av lysfølsomhet
  • Bruk med nedsatt kognisjon

Meld gjerne fra om brudd på kravene

Vi ønsker tilbakemelding fra brukerne.

  • Har du oppdaget feil og mangler knyttet til universell utforming av nettstedet?
  • Trenger du alternativ til innhold som ikke er universelt utformet?
  • Har du innspill til forbedringer av nettstedet?

Du kontakter oss via:

Klage

Diskrimineringsnemnda behandler klager om brudd på regelverket. Du finner informasjon om hvordan du klager på nettstedet til Diskrimineringsnemnda. Du kan også klage på manglende eller sent svar på tilbakemeldinger du har sendt til oss.


Status for innhold som ikke er universelt utformet

Vi har innhold på nettstedet som ikke er universelt utformet. Vi redegjør for hvilket innhold det gjelder, årsaken til at vi ikke følger kravene til universell utforming av ikt og hva det betyr for brukeren. Det er presentert i samme rekkefølge som kravene i WCAG 2.1-standarden.
STATENS VEGVESEN kategoriserer innholdet som ikke er universelt utformet på vegvesen.no slik:

Prinsipp 1. Mulig å oppfatte

Informasjon skal være presentert på en måte brukeren kan oppfatte. Det vil si at informasjon ikke bare skal kunne oppfattes med én enkelt sans. For å se grafikk trenger du for eksempel en skjerm og synssansen. Derfor skal bilder ha en alternativ tekst, i følge WCAG. Tekst kan også bli presentert på mange ulike måter, blant annet som punktskrift, syntetisk tale, på skjerm, tolkes som tegnspråk eller som symbol. WCAG krever derfor at tekst blir brukt som alternativ til lyd, film og bilder.

Innhold som bryter kravet

Vegvesen trafikk web: Vegvesen trafikk har et kart som viser hvilke objekter (f.eks. Trafikkmeldinger, ladestasjoner, trafikkflyt, m.m.) som finnes i et område, dette er ikke beskrevet tekstlig og er derfor utilgjengelig for de som ikke kan se kartutsnittet.

VegSak: Felter for inndata har ikke et nyttig navn som forteller brukeren hva de skal skrive inn i feltet. Dette gjelder for alle inndata-felt i løsningen. Det finnes også ikoner som inneholder hjelpetekster som ikke har et tilgjengelig navn som forteller brukeren hva ikonet er.

Førerkorttjenester - Select-elementene for utløpsdato og år har tilgjengelige navn på engelsk (Month og Year). Det er ikke ulovlig å bruke flere språk på samme side men da må innhold som skiller seg fra det generelle språket på siden markeres med riktig språk kode gjennom lang-attributtet. Dette er også delvis relatert til Statens vegvesen logoen (som er av utrolig lav oppløsning) hvor alt-teksten (1) ikke er beskrivende for bildet og (2) er på et annet språk enn det generelle språket på betalingssiden.

Innhold som bryter kravet

Din side – bytt bruker: Landemerker som brukes mer enn en gang har ikke unike navn. Dette fører til unødvendig mange elementer å navigere på siden for skjermleserbrukere.

Din side – navigasjon nivå 2: Landemerker som brukes mer enn en gang har ikke unike navn. Dette fører til unødvendig mange elementer å navigere på siden.

Din side – oversikt: Landemerker som brukes mer enn en gang har ikke unike navn. Dette fører til unødvendig mange elementer å navigere på siden. Gjelder nav til brødsmulestien.

Din side – søk om innsyn i personopplysninger: Ledetekst er ikke koblet sammen med radioknapper med <fieldset> og <legend>. Dette gjør det vanskelig for skjermleserbrukere å vite hva som hører til i en radioknappgruppe. Feilmeldinger skal programmatisk knyttes til skjemafelt med bruk av aria-describedby. Dette er ikke gjort i dagens løsning. Resultatet er at skjermleserbrukere ved tabnavigasjon ikke får feilmeldingen annonsert.

Din side – toppmeny: Menyen er ikke definert med et eget landemerke, og er kun del av "main" landemerket. Her burde menyen være en del av banner landemerket "header" og en egen "nav" for hele navigasjonsområdet burde defineres.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Vi har noen regelbrudd på bl.a Kjøretøysiden. Konsekvensene kan være at det er vanskelig å lese innholdet. Feilene går på hvordan noen elementer er kodet. Vi jobber med å fornye utseendet på våre løsninger.

Vadis - Vi har feilmeldinger i skjema som ikke er koblet til respektiveskjemafelter. Dette kan gjøre det vanskelig for enkelte brukere åidentifisere feilmeldinger.

Din side – Kjøretøykontroll: Det meste av dette er løst, men vi tar en liten sjekk på gjenstående. 

Vegvesen trafikk web: Vegvesen trafikk har noen tilfeller av hopp i overskriftshierarkiet, altså at vi hopper rett til H2, eller fra H2 til H4.

VegSak: Overskrifter og annen tekst er ikke kodet riktig. Grupper av skjemafelter er ikke samlet programmatisk. Seksjoner er ikke tatt i bruk.

Parkreg: Mangel på beskrivelse av hva klikkbare elementer gjør. 

Parkreg HC: "Fieldset skal brukes for å gruppere relaterte deler av skjema, disse er ofte visuelt relaterte. Som serienummer-feltene. Her er serienummer en overskrift men ikke <fieldset>. Resultatet er at skjermleserbrukere som tabnavigerer til området ikke får beskjed om at det er serienummer de nå jobber med, de hører bare «Kommunenummer». Kommunenummer er ikke koblet til skjemafeltet det beskriver. Benytt attributtet for i label elementet for Kommunenummer for å koble ledeteksten til skjemafeltet, selv om det er disabled. Det benyttes tab-elementer for privatpersoner og instutisjon. Disse er ikke definert riktig. Role tab er benyttet, men parent elementet tablist er ikke benyttet, selv om det er påkrevd. Elementene pressenteres også i en liste som inneholder andre child-elementer enn listelementer. Dette bryter med HTML standarden da ingenting annet en listelementer er tillat som direkte child-elementer av <ul>/<ol>. Feilmeldinger skal programmatisk knyttes til skjemafelt og annonseres med aria-live attributtet for skjermleserbrukere. For feilmeldinger er aria-live=’assertive’ varianten å foretrekke. Husk at aria-live kun annonserer endringer i seg selv. Derfor må aria-live regionen (der feilmeldinger skal komme) laste samtidig som siden laster. Så kan den populeres med feilmeldinger når de kommer. Feilmeldingene på HC annonseres ikke med aria-live og er ikke knyttet til skjemafelt med aria-describedby. Tabellen på Se parkeringstillatelser i din kommune har klikkbare tabellerader som kan brukes for å sortere tabellen. Men dette er ikke tydelig hverken for skjermleserbrukere eller oss som seende brukere. Som seende brukere skulle vi gjerne sett et ikon på sorterbare tabellrader også når de ikke er sorterte for å indikere at de kan klikkes på. Men dette er ikke et krav. Skjermleserbrukere skal få beskjed om at tabellen er sorterbar via aria-sorted. Info om gyldige parkeringstillatelser - det som ser ut som overskrifter i de to boksene er ikke kodet som overskrifter. ".           

Førerkorttjenester - «Finner du ikke klassen du ser etter?» fungerer som og ser ut som en overskrift, selv om den ikke er definert som dette. Dette kan være noe subjektivt så dere må selv ta stilling til dette. 

Ferjesøk: Samme feil på 1.3.1, 2.4.3  og 4.1.2 : På datovelgeren på reisetider er det flere feil som kan føre til vanskeligheter med å tabnavigere seg på siden. Flere elementer er kodet med feil semantikk og radiogruppen har ingen ledetekst som gjør det forståelig for brukeren hva det er. Radiogruppen kan få fokus selv om dette ikke er et interaktivt element. Brukere av tastatur og skjermlesere vil derfor kunne oppleve utfordringer med å navigere riktig i datovelgeren.

Sms-varsling: Pause varslinger er en utvidbar knapp. Utvidbare knapper skal markeres med aria-expanded. Dette kan forvirre skjermlesere som betegner den som åpnet eller lukket. Flere av sidene mangler et <main> landemerke. Generelt bør alt innhold på en nettside være en del av et landemerke. Informasjonsboksen om "Alle endringer lagres automatisk" burde informeres om før brukeren gjør noen endringer, og burde dermed flyttes tidligere i rekkefølgen av elementer.

Transportørregister: Rapporten som blir generert gir en oversikten over transportører som det søkes etter i et tabellformat på skjermen. I noen av kolonnene er det mulighet for å ekspandere detaljer for en gitt transportør, og da vises det flere rader under dette tabellinnnslaget.

Nybilvelger: Det er definert h4-overskrifter for det som skulle vært ledetekster for skjemafelter. Dette bryter med logisk overskriftsrekkefølge samt at disse h4-overskriftene burde vært definert som label-elementer.

Arbeidsvarsling: I løsningen finnes det en del eksempler på at ting ikke er kodet likt som de ser ut som. Vi har f.eks. en knapp for å «fjerne arbeidssted», men som ikke er kodet som en knapp. Dette gjør det vanskelig for skjermlesere å oppfatte hva det er.

Søk om innsyn i personopplysninger: Ledetekst er ikke koblet sammen med radioknapper med <fieldset> og <legend>. Dette gjør det vanskelig for skjermleserbrukere å vite hva som hører til i en radioknappgruppe. Feilmeldinger skal programmatisk knyttes til skjemafelt med bruk av «aria-describedby». Dette er ikke gjort i dagens løsning. Resultatet er at skjermleserbrukere ved tabnavigasjon ikke får feilmeldingen annonsert.

Innhold som bryter kravet

Din side – toppmeny: Når nytt innhold dynamisk presenteres på en nettside er viktig at dette innholdet blir presentert et sted som er logisk for brukeren. Dette betyr at innholdet bør plasseres slik at brukeren er klar over hvor innholdet er kommet og at innholdet enkelt kan nås. "Tjenester"-knappen som utvider et område genererer elementer på slutten av menyen, ikke rett etter knappen som utvider området. Dette fører til at det er vanskelig å navigere seg til elementene som ekspanderes ved hjelp av "Tjenester"-knappen. Dette gjelder både på større og mindre skjermer.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Fokus flyttes ikke til toppen av ny side når man trykker neste eller tilbake. Visuelt flyttes det synlige området til toppen av siden, tabber man derimot vil man se at første element man får fokus på er første element i footer (da det var her fokus «sist var»). Fokus må settes på toppen av siden, mer spesifikt på trinnindikatoren i det nye området. Dette gjelder på mindre skjermer: Rekkefølgen av tastaturnavigasjon og visuell rekkefølge er ulik. Neste er visuelt over avbryt, men avbryt er knappen brukeren først får fokus på ved tab-navigering. Slik skal det ikke være.

VegSak: Tekst er ikke kodet som tekst.

Innhold som bryter kravet

VegSak: Hvis brukeren gir inndata som ikke er gyldig, peker feilhåndteringsteksten ikke mot feltet som krever korrigering, men ber brukeren peke musepekeren mot feltet for å få utfyllende informasjon.

Nybilvelger: Ikke tatt spesielt hensyn til fargebruk i hht. kravene.

Innhold som bryter kravet

VegSak: Løsningen støtter ikke begge visningretninger.

Innhold som bryter kravet

VegSak: Ingen inndatafelt støtter formål med feltet programmatisk.

Parkreg HC: Samtlige skjemafelter er definert som input type text. Dette er ikke riktig. Flere av skjemafeltene burde vært definert med input type number, som orgnummer og kortnummer. Dette er et gjennomgående problem på tvers av løsningen. 

Førerkorttjenester - Inputfelter trenger korrekt formål designert i koden for typen input som «text», «date» eller «number» osv. Dette gjør at for eksempel inputfelter som kun krever tall vil gjøre det umulig for bruker å taste inn bokstaver, men også at mobilbrukere får riktig tastatur opp for utfylling av skjemafeltet. Dette hever brukervennligheten som en ekstra bonus for å følge uu-kravene. Til eksempel har postnummer skjemafeltet definert typen text selv om det eneste som skal godkjennes som en postadresse er input av typen number.

SMS-varsling: Feks mobilnummer og andre gjentakende felter man kan skrive inn tekst burde ha autocomplete attributtet slik at nettleser kan automatisk fylle det inn.

Nybilvelger: Ledetekst for inndatafelter er ikke knyttet til feltene. 

Parkeringsregisteret - HC-registeret: Skjemafeltene er definert som input-type text, men noen av feltene skulle f.eks. vært definert med input-type number, som organisasjonsnummer og kortnummer. 

Arbeidsvarsling: Felter som spør om e-postadresse er kodet slik at de autoutfylles med fysisk adresse. Felter som ber om mobilnummer, mangler autoutfylling av mobilnummer. Dette gjør at feil eller ingen forslag foreslås, og er særlig negativt for brukere med kognitive utfordringer.

Innhold som bryter kravet

Arbeidsvarsling: På oversiktsbildet «mine tillatelser» er noen APV-er markert med svart strek til høyre i raden, andre med oransje og noen i grå. Det samme gjelder tillatelser. I tillegg har vi også to lenker som kun er markert i blå farge. En person som ikke ser farge vil ikke kunne oppfatte denne informasjonen. 

Din side – meldinger: Lenker, knapper og andre interaktive elementer bruker kun en oransje farge for fokusmarkering og denne har ikke god nok kontrast. Dette gjør det vanskelig å se hvor en har fokus for tastaturbrukere eller ved swiping på touchskjerm.

Din side – søk om innsyn i personopplysninger: Når du har sendt inn ønske om innsyn blir du presentert med en lenke som kun med bruk av farge viser at den er en lenke. Lenken mangler understrek.

VegSak: Tilbakemeldinger på ugyldig inndata fra bruker markeres kun med fargen rødt.

Parkreg HC: "I grafene brukes kun farge for å skille mellom de forskjellige punktene i grafen. Ser du ikke forskjell på disse fargene er det vanskelig å finne ut hva som er hva. Samtidig innfrir ikke disse to fargene kontrastkrav mot hverandre på 3.1. Mål kontrast mellom fargene er 2.5:1. I linjediagrammet brukes en stiplet linje for å vise hvilken linje som er for hele Norge. Men i indikatoren under som sier hva som er Trondheim og hva som er hele Norge brukes bare hele farger, ser du ikke forskjell på disse er du like langt."

Førerkorttjenester - Det gjengis lenker til de ulike stegene i prosessen øverst på siden Forny førerkort. Her burde lenker som peker på steget man er på være markert aria-current=page eller tilsvarende slik at skjermleserbrukere får informasjonen som gjengis visuelt (sort sirkel fremfor grå for å indikere aktivt steg). Som gjengitt i skjermdumpen under får ikke skjermleserbrukere med seg informasjonen som er gitt visuelt (lenkene annonseres bare slik de er, de inkluderer ikke konteksten av at sirklene er farget og at dette indikerer gjellende steg i prosessen). Vi benytter også anledningen til å anbefale å definere en overskrift under trinngjengivelsen med lenker som repeterer navnet på steget man befinner seg på. Dette vil gjøre det tydeligere hvilket steg man er på utover trinn-indikasjonen øverst (anbefaling), men vil også gjøre at overskriftshierkaiet i tjenesten må gås gjennom på nytt.

Søk om innsyn i personopplysninger: Når du har sendt inn ønske om innsyn, blir du presentert med en lenke som kun med bruk av farge viser at den er en lenke. Lenken mangler understrek.

Innhold som bryter kravet

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Det er for dårlig (tilfredstiller ikke krav) på fokusmarkering enkelte steder. For eksempel rundt knapp for søk på kjøretøyoversikten.

VegSak: Kontrasten mellom bakgrunn og tekst er i noen tilfeller lavere enn 4,5:1.

Parkreg HC: Alt tekstlig innhold av "normal" størrelse skal innfri kontrastkrav på 4.5:1. Mål kontrast på rødfargen i feilmeldinger på tvers av løsningen er målt til 4.26:1. Gjør altså rødfargen noe mørkere, eller gjør bakgrunnen lysere for å innfri kontrastkravene.

Førerkorttjenester - Feilmeldingene i skjemaet for førerkortfornyelse har ikke høy nok kontrast til å møte minstekravene og trenger utbedring. Dette gjelder også på første trinn i bestill nytt førerkort prosessen. Minstekravet for tekst sin kontrast mot bakgrunnen er 4.5:1 (normal størrelse). Målt kontrast er på 3.9:1.

SMS-varsling: Elementer som ikke innfrir krav om kontrast: Ledeteksten "mobilnummer" ved henting av engangskode. Blå knapper mot grå bakgrunnsfarge. Hvit tekst i knapper mot blå bakgrunnsfarge. Lenker i tekst: blå tekst mot hvit bakgrunn. Hvitt skrivefelt mot grå bakgrunn. Knappene for kategorier(nord, sør, øst...): blått mot hvit bakgrunn. Log ut knapp og informasjonsboks om at "endringer lagres automatisk". Ja/Nei knapp ved abonnering. Dette fører til at brukere kan ha vanskelig for å skille mellom elementer og tekst som er nødvendig for bruk av tjenesten. 

Nybilvelger: Lenken «Hjelp» er presentert med veldig lav kontrast, og det mangler tydeligere markering av at dette er en lenke.

Innhold som bryter kravet

VegSak: Enkelte felter er ikke store nok til å vise hele innholdet og enkelte labels skjules bak inndatafelt  når tekststørrelse økes til 200%.

Nybilvelger: Resultatsiden mister innhold ved forstørrelse på mer enn 150 %.

Innhold som bryter kravet

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: På noen av våre tjenester ser vi at noe innhold blir borte når man zoomer 400%,

Vegvesen trafikk web: Vegvesen trafikk har ved 400% zoom noen knapper som overlapper hverandre og kartet, som gjør kartet lite tilgjengelig. Man må også scrolle horisontalt for å se deler av  innholdet.

Førerkorttjenester - Suksesskriteriet «1.4.10 Reflow» krever at innhold eller funksjonalitet skal være tilgjengelig selv ned til grenseverdier for skjermstørrelser på 256x320px. På ditt førerkort siden havner informasjon om gyldighet bak ikoner som indikerer førerkorttype. Innhold som tekstinnhold skal ikke bli delvis utilgjengelige når man er på mindre skjermer. Påse at disse ikonene ikke havner over informasjonen om førerkorts gyldighet ved mindre skjermer.

Nybilvelger: Resultatsiden mister innhold ved forstørrelse på mer enn 150 %.

Innhold som bryter kravet

Arbeidsvarsling: Løsningen har to typer hovedknapper, en blå og en grå. Den grå knappen har svært lav kontrast mot bakgrunnen, og vil være vanskelig å se for en bruker med nedsatt synsevne. 

Din side – meldinger: Lenker, knapper og andre interaktive elementer bruker kun en oransje farge for fokusmarkering og denne har ikke god nok kontrast. Dette gjør det vanskelig å se hvor en har fokus for tastaturbrukere eller ved swiping på touchskjerm.

Din side – søk om innsyn i personopplysninger: Fokusindikatoren på denne tjenesten benytter en gul farge mot en lys grå bakgrunn. Dette bryter minimum kontrastkrav og det vil derfor være vanskelig å se hvor tastaturfokus er.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Knappen Avbryt i skjemaløsningen må få introdusert en ramme eller bakgrunnsfarge som har tilstrekkelig kontrast til bakgrunnen den blir presentert på. Det er svært vanskelig å identifisere det klikkbare området når det ikke er en tilstrekkelig kontrast/ramme rundt elementets klikkbare flate. Dette blir utbedret når vi får nytt utseende på våre tjenester.

VegSak: Knapper og andre interaktive elementer har lavere kontrast enn det som kreves.

Parkreg HC: Fokusmarkering skal være en visuell tydelig markering av hvilket element som har fokus. Denne fokusmarkeringen er i dag markert med svv-oransje farge. Denne fargen innfrir ikke kontrastkrav for ikke tekstlig innhold (minst 3:1). Fokusmarkeringsfargen må altså gjøres mørkere. Det beste ville vært å implementere fokusmarkeringen fra komponentkassen/designsystemet.              Klikkbare flater (gjerne knapper) uten et ikon som indikerer at de er klikkbare skal ha en kontrast på minst 3:1. To knapper kommer frem når du har sendt inn en søknad på parkeringstillatelse, disse mangler en ramme med høy nok kontrast. Bytt gjerne til knappene fra komponentkassen for å løse dette. I grafene brukes kun farge for å skille mellom de forskjellige punktene i grafen. Ser du ikke forskjell på disse fargene er det vanskelig å finne ut hva som er hva. Samtidig innfrir ikke disse to fargene kontrastkrav mot hverandre på 3.1. Mål kontrast mellom fargene er 2.5:1. I linjediagrammet brukes en stiplet linje for å vise hvilken linje som er for hele Norge. Men i indikatoren under som sier hva som er Trondheim og hva som er hele Norge brukes bare hele farger, ser du ikke forskjell på disse er du like langt. 

Førerkorttjenester - Det er for lav kontrast på fokusmarkeringen i tjenesten. SVV-oransje farge benyttes alene for fokusmarkering av interaktive elementer. For å illustrere problemet med temafargen svv-oransje følger det under en skjermdump av alle de ulike kontrastforholdene til checkboksen på første trinn i prosessen. Verken den blå fargen fra checkboksen, den grå bakgrunnen eller den røde fargen når checkboksen har fremprovosert en feil har tilstrekkelig kontrast mot fokusmarkeringsfargen (svv-oransje). Problemet repeterer seg på samtlige elementer i denne tjenesten.

Ferjesøk: Fokusmarkeringer er definert, men med en farge som har for lav kontrast til kravet. Derfor kan brukere ha vanskeligheter med å se fokusmarkeringene på siden.

SMS-varsling: Elementer som ikke innfrir krav om kontrast: Hvitt skrivefelt mot grå bakgrunn. Knappene for kategorier(nord, sør, øst...), blått mot hvit bakgrunn. Log ut knapp og informasjonsboks om at endringer lagres. Ja/Nei knapp ved abonnering. Dette fører til at brukere kan ha vanskelig for å skille mellom elementer som er nødvendig for bruk av tjenesten.

Nybilvelger: Lenkene under steg 2 og «Bilmerke-søk personbil» er markert med et oransje og hvitt ikon. Denne fargekombinasjonen bryter med minstekravet for kontrast for ikke-tekstlig innhold. Utydelig markering av interaktivt område til select.

Søk om innsyn i personopplysninger: Fokusindikatoren i tjenesten benytter en gul farge mot en lys grå bakgrunn. Dette bryter minimum kontrastkrav og det vil derfor være vanskelig å se hvor tastaturfokus er.

Innhold som bryter kravet

VegSak: Noe innehold blir skjult bak annet innhold når linjeavstand økes.

Innhold som bryter kravet

VegSak: Hjelpetekster som dukker opp når man har mmusepekeren over informasjonsikonet på den første siden i søknaden lukkes når man flytter musepekeren vekk fra ikonet.

Prinsipp 2. Mulig å betjene

Web er interaktivt. Det er viktig at brukerne for eksempel kan navigere, velge knapper og sette haker i avkryssingsfelt, med det utstyret og den hjelpemiddelteknologien de bruker. Dette betyr for eksempel at det ikke bare skal være mulig å bruke mus. Alt innhold og all funksjonalitet skal også kunne brukes bare med tastaturet.

Innhold som bryter kravet

Vegvesen trafikk web: Vegvesen trafikk har noe innhold som bare er tilgjengelig ved å trykke i kartet med musepeker. Det er derfor ikke mulig å nå som tastaturbruker. Eksempler på innhold er rasteplasser, døgnhvileplasser, høydebegrensninger, noen webkamera, m.m.

VegSak: Enkelte felter er ikke tilgjengelige gjennom tastatur.

SMS-varsling: Dagens løsning gjør at tastaturbrukere ikke når noen av lenkene/knappene da lenkene ikke har definert det påkrevde attributtet href (for at lenken skal være tab-fokuserbar). Dette gjør at brukere med skjermleser ikke får tabbet til lenkene.

Arbeidsvarsling: Når du skal søke om hvilket tidsrom du ønsker å jobbe i, gjøres dette i en nedtrekksmeny. Den er ikke tilgjengelig via tastatur. Det er også slik at når du skal velge arbeidssted, må det gjøres i kart, og du kan ikke velge lokasjon kun med tastatur. Dette er problematisk for brukere som ikke kan benytte mus.

Innhold som bryter kravet

VegSak: Som en konsekvens av at enkelte felter ikke er tilgjengelige gjennom tastatur, kan man ikke gå videre i løsningen fordi det utilgjengelige feltet ikke er krysset av.

SMS-varsling: På siden til Fjelloverganger(https://www.vegvesen.no/trafikkinformasjon/reiseinformasjon/fjelloverga…) har en knapp til abonnementsiden for sms. Denne knappen bør informere om at brukeren sendes til en ekstern side. Den eksterne siden burde også ha en tilbakelenke til forrige side.

Arbeidsvarsling: Når du skal velge dato, f.eks. hvilken dato du ønsker å arbeide, benytter løsningen en datovelger. Det er mulig å navigere inn i denne med tastatur, men du kommer ikke ut. Dette blir dermed en tastaturfelle, noe som er problematisk for brukere som ikke kan benytte mus.

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Hopp til hovedinnhold-lenken går til sekundærmenyen for Din side istedenfor det faktiske hovedinnholdet. 

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Hopp til hovedinnholdlenken går til sekundærmenyen for Dinside istedenfor det faktiske hovedinnhold.

VegSak: Det er ikke mulig å hoppe over blokker av innhold med snarveilenker. Blokker av innhold er heller ikke programmatisk delt inn i seksjoner.

Arbeidsvarsling: Funksjonen for å kunne hoppe rett til hovedinnhold er ikke tatt i bruk.

Søk om innsyn i personopplysninger: Hopp til hovedinnhold-lenken går til sekundærmenyen for Din side istedenfor det faktiske hovedinnholdet.  

Innhold som bryter kravet

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Det mangler unike titler i fanen når du går inn på et konkret kjøretøy fra Kjøretøyoversikten. 

Førerkorttjenester - Oversiktssiden for de ulike selvbetjningsløsningene som finnes under førerkort har bare titelen «oversikt | Statens vegvesen». Dette er ikke en beskrivende nok titel for hva som presenteres på siden. Nøkkelordet førerkort må inkluderes i titel definisjonen.

SMS-varsling: Innloggede sider har ikke en beskrivende tittel.

Innhold som bryter kravet

Din side – bytt bruker: På skrivebord blir fokus satt på toppen av siden når en går på en av lenkene, men på mobile enheter settes fokus til cirka der på siden en bruker var når de aktiverte en lenke. Dette fører til at fokus ikke settes til første element på siden og at bruker selv må skjønne at hen må navigere bakover for å komme til første element.

Din side – navigasjon nivå 2: På skrivebord blir fokus satt på toppen av siden når en går på en av lenkene, men på mobile enheter settes fokus til cirka der på siden en bruker var nå de aktiverte en lenke. Dette fører til at fokus ikke settes til første element på siden og at bruker selv må skjønne at hen må navigere bakover for å komme til første element på siden.

Din side – oversikt: På skrivebord blir fokus satt på toppen av siden når en går på en av lenkene, men på mobile enheter settes fokus til cirka der på siden en bruker var nå de aktiverte en lenke. Dette fører til at fokus ikke settes til første element på siden og at bruker selv må skjønne at hen må navigere bakover for å komme til første element på siden.

VegSak: Enkelte inndatafelt hoppes over når man går gjennom siden med tabulator.

Ferjesøk: Samme feil på 1.3.1, 2.4.3  og 4.1.2 : På datovelgeren på reisetider er det flere feil som kan føre til vanskeligheter med å tabnavigere seg på siden. Flere elementer er kodet med feil semantikk og radiogruppen har ingen ledetekst som gjør det forståelig for brukeren hva det er. Radiogruppen kan få fokus selv om dette ikke er et interaktivt element. Brukere av tastatur og skjermlesere vil derfor kunne oppleve utfordringer med å navigere riktig i datovelgeren.

Innhold som bryter kravet

VegSak: Det finnes flere lenker i løsningen hvor det ikke kommer klart fram hva formålet med lenken er og hva lenken åpner.

Nybilvelger: Les mer-lenker er brukt. Brukeren får derfor ingen informasjon om formålet med disse lenkene.

Innhold som bryter kravet

VegSak: Det er ikke mulig å søke eller navigere nettsiden på andre måter enn å fylle ut inndatafeltene på den aktuelle siden og å trykke "neste".

Arbeidsvarsling: Kartet som skal brukes til å markere arbeidsområde kan ikke navigeres til uten bruk av mus. Dette er problematisk for brukere som kun benytter tastatur.

Innhold som bryter kravet

Din side – meldinger: Lenker, knapper og andre interaktive elementer bruker kun en oransje farge for fokusmarkering og denne har ikke god nok kontrast. Dette gjør det vanskelig å se hvor en har fokus for tastaturbrukere eller ved swiping på touchskjerm.

Din side – toppmeny: Samme visuelle indikasjon gis for fokusmakering som gis for utvidede knapper og lenker som leder til samme side som en befinner seg på. Det er derfor vanskelig å skille elementer som har fokus fra andre elementer. Fokus som settes på allerede aktive eller utvidede elementer får ikke fokusmarkering. Fokusmarkeringen på elementer med understrek er vanskelig å identifisere.

Parkreg HC: Fokusmarkering skal være en visuell tydelig markering av hvilket element som har fokus. Denne fokusmarkeringen er i dag markert med svv-oransje farge. Denne fargen innfrir ikke kontrastkrav for ikke tekstlig innhold (minst 3:1). Fokusmarkeringsfargen må altså gjøres mørkere. Det beste ville vært å implementere fokusmarkeringen fra komponentkassen/designsystemet.

Førerkorttjenester - Det er for lav kontrast på fokusmarkeringen i tjenesten. SVV-oransje farge benyttes alene for fokusmarkering av interaktive elementer. For å illustrere problemet med temafargen svv-oransje følger det under en skjermdump av alle de ulike kontrastforholdene til checkboksen på første trinn i prosessen. Verken den blå fargen fra checkboksen, den grå bakgrunnen eller den røde fargen når checkboksen har fremprovosert en feil har tilstrekkelig kontrast mot fokusmarkeringsfargen (svv-oransje).

Ferjesøk: Fokusmarkeringer er definert, men med en farge som har for lav kontrast til kravet. Derfor kan brukere ha vanskeligheter med å se fokusmarkeringene på siden.

SMS-varsling: Flere elementer på de innloggede sidene mangler tilstrekkelig fokusmarkering. Blå knapper for eksempel har ikke tilstrekkelig kontrast ved fokus. Dette gjør det vanskelig å visuelt registrere hvilket element som er i fokus.

Fjelloverganger: På forsiden som viser en oversikt over alle fjelloverganger er det en knapp med dropdown for filtreringsmuligheter som ikke har synlig fokus ved tab. Dette kan føre til at brukene som kun bruker tastatur vil kunne oppleve utfordringer med å nå disse filtreringsmulighetene. Tastaturbrukere bes benytte søkefeltet lenger oppe på siden, fremfor tab-navigering.

Nybilvelger: Den gule linjen som brukes rundt enkelte knapper har tilstrekkelig kontrast.

Arbeidsvarsling: Fokusfargen som er valgt i løsningen, er ikke lett synlig. Den er særlig vanskelig å se på kartet for å markere arbeidsområde. Oransjefargen som brukes har en lav kontrast mot f.eks. grå bakgrunn, som er mye brukt i løsningen. Dette er særlig problematisk for de med nedsatt synsevne.

Innhold som bryter kravet

Nybilvelger: Har en slider-funksjon hvor bruker må klikke og dra, alternativt skrive inn verdier manuelt.

Innhold som bryter kravet

VegSak: Ingen tekster på nettsiden har tilgjengelige navn.

Nybilvelger: Ledetekst for inndatafelter er ikke knyttet til feltet.

Prinsipp 3. Forståelig

Målet med nettsteder er at brukerne skal forstå hvordan sidene skal brukes og informasjonen de får. Det handler om at nettstedet er forutsigbart, har et enkelt språk og god hjelpefunksjonalitet. Rett koding er viktig for at nettstedet skal fungere med hjelpemiddelteknologi, for eksempel vil rett språk på siden sørge for at teksten blir lest opp på rett måte for brukere med talesyntese.

Innhold som bryter kravet

VegSak: Språk er ikke programmatisk angitt.

SMS-varsling: Det er definert lang attributtet for abonner løsningen. Dessverre er dette attributtet definert til "en", altså engelsk. Det betyr at hjelpemiddelbrukere vil få annonsert norsk innhold med engelsk uttale.

Innhold som bryter kravet

Vegvesen trafikk web: Når brukeren har valgt engelsk språk, så er de delene av innholdet som fortsatt er på norsk ikke merket med lang-attributtet.

Førerkorttjenester - Select-elementene for utløpsdato og år har tilgjengelige navn på engelsk (Month og Year). Det er ikke ulovlig å bruke flere språk på samme side men da må innhold som skiller seg fra det generelle språket på siden markeres med riktig språk kode gjennom lang-attributtet.

Innhold som bryter kravet

VegSak: Når brukeren endrer på "Antall tilhengere" på side 1, endres konteksten på siden ved at flere felter per angitte tilhenger legges til på siden.

Parkreg HC: Viktig informasjon som trengs for å fylle ut felter som datoformat bør stå i ledetekst (<label>) fremfor som placeholder. Placeholder-elementet blir borte med en gang du begynner å skrive, og det er ikke alltid å lett å huske hvilket format man skulle bruke. Samtidig er det ikke ledetekster for skjemafeltene, pilen er ikke tilstrekkelig for å beskrive hva skjemafelt 2 i skjermdumpen under står for.

Innhold som bryter kravet

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Vi har noen få steder i tjenestene våre hvor knappene "neste" og "avbryt" ikke alltid er på samme sted. Vi jobber med å endre utseendet på våre løsninger. Dette vil da bli utbedret og rettet. Konsekvensen før retting er at bruker kan bli forvirret over hvor han/hun finner riktig knapp.

Innhold som bryter kravet

Din side – toppmeny: Aria-label er definert for lenken til Din side. Verdien i attributtet er annerledes enn det visuelle navnet til lenken. Visuelt heter lenken Din side, mens gjennom aria-label heter den "Din oversikt".

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Vi jobber med å endre utseendet på våre tjenester. I en periode hvor noen av nettsidene våre er i gammelt design, og noen er over i nye, bryter dette med krav. Et eksempel er at Bestill prøveskilt er i gammelt design, men Bestill skilt er i nytt.

VegSak: Felt som er omdekket av kravet har konsekvent identifikasjon, men ikke tilgjengelig navn.

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Feilmeldinger er ofte lette å oppfatte for seende brukere, for skjermleserbrukere kan det være vanskeligere. Seende brukere får fokus satt til toppen av siden hvor det er en oppsummerende melding som sier at noe er feil, hva som er feil må brukere finne ut selv.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Vi har i dag noen få steder i tjenesten "legge til medeier" manglende forklarende feilmelding. Den blir ikke dynamisk opplest for de med skjermlesere.

Vadis - Skjemaløsningen har enkelte utfordringer relatert til feilmeldinger ogidentifikasjon av feilmeldinger. Feilmeldinger er til tider ikke beskrivendeav hvilket skjemafelt de er relatert til, det er ingen programmatiskidentifikasjon av godkjent/ikke godkjent validering og feilmeldingene ertil tider ikke til hjelp for brukeren.

VegSak: Brukeren får beskjed om feil, men får ikke beskjed om hva som er feil før de hviler musepekeren over feltet som er markert med rødt.

Søk om innsyn i personopplysninger: Feilmeldinger er ofte lette å oppfatte for seende brukere, for skjermleserbrukere kan det være vanskeligere. Seende brukere får fokus satt til toppen av siden hvor det er en oppsummerende melding som sier at noe er feil, hva som er feil må brukere finne ut selv.

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Alle obligatoriske skjemafelt må markeres som obligatoriske, selv om alle er obligatoriske. Hvis * brukes for å markere obligatoriske felter skal det forklares hva * faktisk betyr. Skjermleserbrukere skal også få beskjed om noe er påkrevd.  Bruk aria-required og * kan skjules for skjermleserbrukere. Aria-required gir den samme informasjonen. I skjemafelt skal aria-required brukes rett på skjemafeltet, i sjekkboks og radioboksgrupper holder det at aria-required brukes på den første sjekkboksen; men det kan også brukes på alle.

Vegvesen trafikk web: Ruteplanleggeren har ikke markert obligatoriske felter verken med atrributtet required eller visuelt. Alle felter er obligatoriske og man vil få feilmelding dersom feltet ikke er fylt ut slik at man får fylt det ut og dermed planlagt en rute. Ved valg av kartinnhold er det obligatorisk å velge en type ladestasjon, dette er heller ikke markert visuelt, men man får tydelig feilmelding.

VegSak: Det kommer ikke tydelig fram om et inndatafelt er obligatorisk eller ikke.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Vi mangler beskrivelse av noen valg brukeren må ta. For eksempel under Velg kjøretøy i Prøveskilt. Dette kan forvirre brukeren. Vi trenger en bedre forklaring på hvilke valg en bruker skal ta.

Parkreg HC: Det er ingen indikasjon om hvilke skjemafelter som er påkrevd i skjemaer. Bruk * eller (påkrevd)/(obligatorisk) i ledeteksten til obligatoriske skjemafelter. Brukes * må * forklares hva betyr i starten av skjemaet. Definer også required i skjemafelter som er obligatoriske. Dette er det god håndtering for i komponentkassen. Hvis alle skjemafelter er obligatoriske kan dette informeres om i starten av skjema fremfor å markere alle som påkrevde. 

Førerkorttjenester - Det brukes to * tegn på ledeteksten for helseopplysninger. Den ene kommer fra legend, den andre ligger som et eget element med aria-hidden definert. Dette betyr i praksis at skjermleserbrukere får høre «stjerne» uten at det er forklart hva dette betyr (da informasjonen fra toppen av siden om hva * betyr også er gjemt gjennom aria-hidden). Dette i kombinasjon med at det ikke er noen semantisk markering av at checkboksen er påkrevd gjør at kriteriet 3.3.2 om markering av påkrevde skjemafelter brytes. Slik utformingen i dag er vil ikke skjermleserbrukere bli informert om at skjemafeltet er påkrevd.

SMS-varsling: Det mangler ledetekst for dato- og tidsfeltet for pausing av varsler. Dette gjør at brukere med skjermleser ikke kan vite hva feltet er til.

Nybilvelger: Søkefeltet for å filtrere i resultater i tabellen har ingen synlig ledetekst og en engelsk placeholdertekst («Search»).

Arbeidsvarsling: Obligatoriske felter markeres verken programmatisk eller visuelt i løsningen. Tilnærmet alle felter er obligatoriske, men det er likevel påkrevd å markere dette programmatisk og visuelt. Når du ikke markerer dette, kan det føre til utfordringer fordi brukere kan bli forvirret om hva de må fylle ut og hva som er valgfritt.

Søk om innsyn i personopplysninger: Alle obligatoriske skjemafelt må markeres som obligatoriske, og skjermleserbrukere skal også få beskjed om noe er påkrevd. Dette mangler i denne tjenesten.

Vegvesen trafikk: Ruteplanleggeren har ikke markert obligatoriske felter verken med attributtet required eller visuelt. Alle felter er obligatoriske og du vil få feilmelding dersom feltet ikke er fylt ut. Ved valg av kartinnhold er det obligatorisk å velge en type ladestasjon, dette er heller ikke markert visuelt, men du får tydelig feilmelding.

Innhold som bryter kravet

VegSak: Det benyttes kun farge for å identifisere inndatafelt med feil.

Transportørregister: Hvis man bruker søkefeltene feil, får man ikke generert en rapport. Men man får heller ingen forslag til hvordan feil bruk av søkefeltet kan løses.

Innhold som bryter kravet

VegSak: Det finnes ingen mekanisme som gir brukeren mulighet til å bekrefte dataen de har gitt før søknaden sendes.

Prinsipp 4. Robust

Rett koding av nettstedet er viktig, og dette er som regel ivaretatt med bruk av standardelement i HTML. Valider at koden på nettstedet er rett. Dette er spesielt viktig dersom du bruker ny teknologi eller lager egne element (custom widgets).

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Det finnes en ugyldig liste på en sjekkboksgruppe. Sjekkboksgruppa ser kanskje ut som en liste men grupper av sjekkbokser er grupper av sjekkbokser, ikke lister. Fjern <ul>-elementet da det brukes på en måte som bryter HTML-standarden og ikke gir noe ekstra verdi til skjemaet. Oppsumeringen av "Din henvendelse" fungerer visuelt som en beskrivende liste (<dl>) men er bare kodet som en samling av <div>-elementer. Dette gjør det vanskelig for skjermleserbrukere å forstå hvilken overskrift som hører sammen med inntastet data.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Brukere som bruker opplesningsverktøy kan bli forvirret der vi har kodet feil, slik at brukeren ikke får lest opp i riktig rekkefølge.

Parkreg HC: Det benyttes tab-elementer for privatpersoner og instutisjon. Disse er ikke definert riktig. Role tab er benyttet, men parent elementet tablist er ikke benyttet, selv om det er påkrevd. Elementene pressenteres også i en liste som inneholder andre child-elementer enn listelementer. Dette bryter med HTML standarden da ingenting annet en listelementer er tillat som direkte child-elementer av <ul>/<ol>.

Ferjesøk: På oversikten over avganger har alle elementer på siden samme ID. Dette vil derfor gjøre det vanskelig for skjermleserbrukere å skille på elementene.

SMS-varsling: Det er identifisert duplikate ID’verdier på ikonet for Vinter stengt, samt elementer med id "subscription-list". Duplikate id'er kan resultere i at skjermlesere har problemer med å knytte elementer til hverandre eller interagere korrekt med dem. Det er også identifisert <label> innad i <button> element på "Filter" knappen.

Nybilvelger: ID-verdien «userSelectionList_31» på resultatsiden er duplisert to steder.

Arbeidsvarsling: I løsningen finnes det en rekke eksempler på kodefeil. Dette er typisk ulovlig nøsting og tagger. Disse rangerer fra store feil (hovedinnhold som er skjult for skjermleser) til mindre feil som inputfelt som mangler label (beskrivelse). Dette fører til utfordringer for de som bruker skjermleser.

men bare har fått rollen button.

Søk om innsyn i personopplysninger: Det finnes en ugyldig liste på en sjekkboksgruppe. Sjekkboksgruppa ser kanskje ut som en liste men grupper av sjekkbokser er grupper av sjekkbokser, ikke lister. Oppsumeringen av «Din henvendelse» fungerer visuelt som en beskrivende liste (<dl>), men er bare kodet som en samling av <div>-elementer. Dette gjør det vanskelig for skjermleserbrukere å forstå hvilken overskrift som hører sammen med inntastet data.

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Sjekkboksene har det som visuelt fungerer som ledetekst i fet skrift og en utvidet beskrivelse i vanlig tykkelse skrift under. Programmatisk er alt i samme label. Med VoiceOver for Mac annonseres bare ledeteksten og informasjon om at det er det finnes et element til. Beskrivelsen blir ikke lest opp. Med NVDA annonseres alt på en gang, dette er irriterende fordi vi må høre alt innholdet før vi får vite at elementet er en sjekkboks og om den er sjekket av.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Knappen Velg for å velge en bil blir gjort om til å hete Valgt etter den er interagert med. Dette er et problem da Valgt knappen ikke lenger har en funksjonalitet. Ingen skjer når man trykker på valgt.

VegSak: Inndatafelt har ikke tilgjengelige navn eller roller.

Parkreg: Klikkbare knapper er kodet som lenker pr. 1.2.2023

Parkreg HC: Kommunenummer er ikke koblet til skjemafeltet det beskriver. Benytt attributtet for i label elementet for Kommunenummer for å koble ledeteksten til skjemafeltet, selv om det er disabled. Knappen for å ekspandere mer info-innhold mangler aria-expanded. Skjermleserbrukere får ingen beskjed om at noe har skjedd når de ekspanderer. Legg til aria-expanded på knappen for å indikere ekspansjonsstatus. 

Førerkorttjenester - Knappene for å utvide de ulike trafikkskolene heter bare «Ekspander knapp» og er markert med aria expanded. Disse knappene burde få unike navn som sier noe om hva de ekspanderer. Dette kan gjøres på en spenstig måte med å benytte aria-labelledby og peke på de nye og forbedrede ID’ene til første celle i hver rad, som funnet over beskriver. Da vil knappene hete det samme som trafikkskolen og de vil fremdeles være gi indikasjon om ekspanderstatus.

Ferjesøk: Samme feil på 1.3.1, 2.4.3  og 4.1.2 : På datovelgeren på reisetider er det flere feil som kan føre til vanskeligheter med å tabnavigere seg på siden. Flere elementer er kodet med feil semantikk og radiogruppen har ingen ledetekst som gjør det forståelig for brukeren hva det er. Radiogruppen kan få fokus selv om dette ikke er et interaktivt element. Brukere av tastatur og skjermlesere vil derfor kunne oppleve utfordringer med å navigere riktig i datovelgeren.

SMS-varsling: Pause varslinger er en utvidbar knapp. Utvidbare knapper skal markeres med aria-expanded. Dette kan forvirre skjermlesere som betegner den som åpnet eller lukket. Midt, Nord, Øst, Sør og Vest er markert som lenker. Dette er feil da elementene fungerer som utvidbare knapper. Ja/Nei knappene for påmelding annonserer ikke for skjermleser hvilket valg som er aktivt, da ledeteksten er satt til aria-hidden, dette gjør at skjermlesere ikke har noen mulighet til å vite hvilket valg som er aktivt. I denne contexten er det heller ingen måte å vite hvilken strekning som er aktiv, her burde det brukes feks aria-describedby for å knytte checkboksen til strekningsnavnet.

Innhold som bryter kravet

Din side – søk om innsyn i personopplysninger: Skjermleserbrukere beholder fokuset sitt der de var og får ingen beskjed om at noe har gått galt i skjemaet.

Din side - salgsmelding, registrering ny og samme eier, bestille vognkort, bestille skilt, prøveskilt, kjøretøyoversikt, førstegangsregistrering, vektårsavgift, tap av skilt, legg til/fjern medeier, personlig skilt, avregistrering: Enkelte steder, for eksempel i forbindelse med Godkjenn salgsmelding eller når brukeren søker opp et kjøretøy, kommer det opp en spinner, men vi forteller ikke brukeren at siden lastes. Vi annonserer ikke godt nok feilmeldinger eller lastebeskjeder.

VegSak: Statusbeskjeder er ikke kodet på en programmatisk riktig måte.

Fjelloverganger: Nettsiden har søkefunksjonalitet, men et tilhørende tekstfelt som beskriver antall treff i listen det søkes i. Denne listen filtreres og oppdaterer seg ved endring av input i søkefeltet. Antall treff i listen blir dynamisk annonsert for skjermleserbrukere, men blir kun lest opp som et tall uten beskrivelse. Konsekvensen er at skjermleserbrukere vil kunne ha vanskeligheter med å forstå hvor mange fjelloverganger de må navigere seg gjennom for å finne det de leter etter.


Test og vurdering av nettstedet

Vi har testet og vurdert nettstedet internt, i kombinasjon med ekstern hjelp.

Om erklæringen

  • Tilgjengelighetserklæring for dette nettstedet ble opprettet første gang .