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 regelverket og hva det betyr for brukeren. Det er presentert i samme rekkefølge som kravene i WCAG 2.1-standarden.

Innovit kategoriserer innholdet som ikke er universelt utformet på eApply 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.

1.1 Tekstalternativer

Beskrivelse av retningslinje: Gi tekstalternativer til alt ikke-tekstlig innhold, slik at det kan konverteres til formater som brukerne har behov for, for eksempel stor skrift, blindeskrift, tale, symboler eller enklere språk.

1.1.1 Ikke-tekstlig innhold

Enkelte input-felt er ikke koblet til ledeteksten. Dette fører til at brukere med enkelte IKT-hjelpemidler ikke vil få lest opp hva input-feltet handler om.

1.3 Mulig å tilpasse

Beskrivelse av retningslinje: Lag innhold som kan presenteres på forskjellige måter uten at informasjon eller struktur går tapt.

1.3.1 Informasjon og relasjoner

Enkelte input-felt er ikke koblet til ledeteksten og et bilde ligger i en <h2>-tag. Dette kan føre til forvirring hos brukere med IKT-hjelpemidler.

1.3.5 Identifiser formål med inndata

Input-felter i skjema mangler autocomplete attrbuttet. Dette påvirker brukere med nedsatt kognisjon og motorikk.

1.4 Mulig å skille fra hverandre

Beskrivelse av retningslinje: Gjør det enklere for brukerne å se og høre innhold, blant annet ved å skille forgrunnen fra bakgrunnen.

1.4.1 Bruk av farge

I enkelte skjema er ikke feilmelding plassert sammen med input-feltet dermed er det kun farge som viser hvor feilen er. Dette gjør det vanskeligere for personer med nedsatt synsevne å vite hvor feilen ligger og hvilken feilmelding som hører til hva.

1.4.3 Kontrast (minimum)

Enkelte steder i løsningen oppfylles ikke minimumskravet om kontrast. Dette gjleder særlig steder hvor brukeren ikke har data og en statusmelding vises. Dette er et viktig kriteruim for alle brukere, men spesielt for de med nedsatt synsevne.

1.4.4 Endring av tekststørrelse

Noen steder i løsningen vil tekst overlappe og/eller gå utenfor konteineren sin ved tekststørrelse på 200%. Dette gjør det vanskelig for brukere med nedsatt synsevne å bruke løsningen når de trenger forstørret tekst.

1.4.10 Dynamisk tilpasning (Reflow)

Løsningen har flere steder som bryter med dette kriteriummet. Løsningen tilpasser seg ikke tilstrekkelig ved zoom på 400%. Brukere mister både informsjon og navigasjonselementer. Dette gjør at brukere med enheter av lavere oppløsning og brukere som trenger å forstørre innholdet, mister funksjonalitet og informasjon.

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.

2.1 Tilgjengelig med tastatur

Beskrivelse av retningslinje: Gjør all funksjonaliteten tilgjengelig med tastatur.

2.1.1 Tastatur

Enkelte sentrale elementer kan ikke nås ved bruk av tastatur; slik som navigasjonselementer og knapper som er tilknyttet obligatoriske elementer i skjema. Dette gjelder både standard tastatur og tastatur med bruk av skjermleser. Brukere avhengig av disse navigasjonsmetodene kan ikke bruke løsningen.

2.1.2 Ingen tastaturfelle

Inputfelter som krever at inputet er av en gyldig verdi tillatter ikke brukeren å tabbe seg bort fra feltet. Dette sammen med at hverken ledetekst eller feilmelding er korrekt kodet til inputfeltet gjør at brukere med skjermleser ikke vet hva som skal skrives inn eller hvordan de retter opp feilen for å komme seg videre i skjemaet. I enkelte tekstfelter er det ikke mulig å tabbe seg bort fra feltet (i svar på en melding f.eks). Tastaturfeller gjør at viktig funksjonalitet ikke er tilgjengelig for enkelte brukere.

2.4 Navigerbar

Beskrivelse av retningslinje: Gjør det mulig for brukerne å navigere, finne innhold og vite hvor de befinner seg.

2.4.1 Hoppe over blokker

Mye av innholdet i løsningen er gruppert riktig, men gjentatte elementer slik som navigasjonslandmerker mangler en måte å skille de fra hverandre. Det er heller ikke noe landmerke for hovedinnhold, slik at brukere med skjermleser må tabbe minst 8 ganger for å komme seg til hovedinnholdet, selv med navigasjonslandmerker. En bruker med tastatur uten skjermleser må også gjennom minst 8 tab-steg Dermed, stilles det krav til en mekanisme som hopper til hovedinnholdet som også må tilfredstille egne krav beskrevet av uutilsynet. Dette påvirker alle brukere avhengig av tastatur og gjør løsningen tungvint å bruke.

2.4.2 Sidetitler

Sidetittelen er den samme uavhengig av hvor man er i løsningen. Dette gjør det vanskelig for brukere å se hvor de er i lønsingen, særlig ved bytting av fane. For brukere med skjermelsere vil samme sidetittel bli lest opp unsett hvor de er og det blir vanskelig å vite hvor i løsningen man befinner seg.

2.4.3 Fokusrekkefølge

Tastaturrekkefølge i headeren er ulik leserekkefølge, men kan fremdeles betjenes. Derimot, er presentasjon av saker i lister (tabeller) ikke konsekvent med leserekkefølge og gjør i denne settingen det vanskelig for brukere med skjermleser å betjene innholdet. Tabellnavigasjon blir presentert før innholdet og med ingen statusbeskjeder vet ikke brukeren om det ligger noe innhold i tabellen. I tillegg må de tabbe seg gjennom alle resultatene og deretter tilbake igjen for å komme til navigasjonselementene. Dette gjør løsningen særlig tungvint for brukere avhengig av skjermleser.

2.4.4 Formål med lenke (i kontekst)

Det er flere elementer i løsningen som er kodet som en link, selv om funksjonaliteten er kodet som en knapp. Dette gjør at løsningen ikke oppfyller kriteriummet ettersom brukere med skjermlesere vil få elementet lest opp som en link og dermed mangle konteksten rundt linken (linkteksten er ikke tilstrekkelig i alle tilfeller).

2.4.6 Overskrifter og ledetekster

Flere input-felter i skjema er ikke kodet korrekt til den tilhørende ledeteksten, det er brukt en overskrifts-tag for et bilde og søkefelt er ikke korrekt kodet til ledetekst. Brukere med IKT-hjelpemidler vil ha vansker med å bruke løsningen korrekt.

2.4.7 Synlig fokus

Enkelte elementer får ikke synlig fokus ved tastaturnavigasjon. Dette gjør det vanskelig for brukere å vite hor de er på siden og kan forårsake at brukere aktiverer uønsket funskjonalitet.

2.5 Inndatametoder

Beskrivelse av retningslinje: Gjør det enklere for brukerne å betjene funksjonalitet med andre inputmetoder enn bare tastatur.

2.5.3 Ledetekst i navn

Ved opplasting av bilder stemmer ikke ledeteksten i knappen med det tilgjengelige navnet. Brukere avhengige av taleinput vil ikke vite hvordan de kan aktivere knappen.

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.

3.1 Leselig

Beskrivelse av retningslinje: Det må være mulig å forstå informasjon og betjening av brukergrensesnitt.

3.1.2 Språk på deler av innhold

Språk på deler av innhold mangler "lang"-attributtet. I tillegg, dersom man endrer språk til engelsk, vil fremdeles deler av innhold være på norsk selv om "lang"-attributtet for siden er satt til engelsk. Enkelte brukere vil miste tilgang til informasjon og brukere med skjermlesere vil ikke kunne tilpasse opplesningsspråket til innholdet.

3.2 Forutsigbar

Beskrivelse av retningslinje: Sørg for at websider presenteres og fungerer på forutsigbare måter.

3.2.4 Konsekvent identifikasjon

i menyen er ikke bokmål og engelsk kodet som button men istede som link, selv om de ser ut som de andre elementene. Med link tenker man at man går til en ny side e.l. * Komponenten for å slette en rad oppfører seg ikke alltid likt. Noen ganger åpnes en dialogboks om brukern ønsker å slette raden, mens i et annet skjema får man ikke opp dialogboksen.

3.3 Inndatahjelp

Beskrivelse av retningslinje: Hjelp brukere med å unngå feil og å rette opp feil.

3.3.1 Identifikasjon av feil

I enkelte skjema står ikke feilmedlginen sammen med inputfeltet hvor feilen ligger og det kommer ikke frem av selve teksten hvor feilen ligger. Dette gjør det vanskeligere for brukere å identifisere og rette opp feil.

3.3.2 Ledetekster eller instruksjoner

Det er opplyst om skjemaelementa er obligatoriske, merking med symboler blir ikke forklart før nederst på siden. Dette gjør at brukere kan gå glipp av informasjonen.

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).

4.1 Kompatibel

Beskrivelse av retningslinje: Sørg for best mulig kompatibilitet med aktuelle og fremtidige brukeragenter, inkludert kompenserende teknologi.

4.1.1 Parsing (oppdeling)

Det finnes duplikate IDer i løsningen.

4.1.2 Navn, rolle, verdi

Under meldinger brukes det en klikkbar div som skjuler/viser meldingen , vedlegg og svar. Div-en mangler rolle og/ eller WAI-ARIA-rolle og kan dessuten ikke nås med tastatur. Brukere avhengig av tastatur vil ikke kunne bruke denne funksjonliteten og de med skjermleser vil ikke vite hensikt/funksjonalitet.

4.1.3 Statusbeskjeder

Det finnes statusbeskjeder som ikke er kodet med rolle eller andre egenskaper. Dette gjør at brukere med f.eks skjermleser ikke vet hva feilen er eller hvordan de retter den uten at beskjedene får fokus.