Tilgjengelighetserklæring for enova.no

Vi har en del bilder uten alternativ tekst på nettsiden. For brukere med skjermleser vil en alternativ tekst og beskrivende tekst formidle innhold i bildet også til dem.

Det kommer ikke tydelig nok frem hvilke videoer som er mediealternativ eller hovedinnhold. Stort sett er ikke undertekst tilgjengelig i våre videoer og vi har heller ingen tekstlig alternativ plassert ved video der lyd og bilde formidles, med noen unntak. Ved å legge til et tekstlig alternativ kan for eksempel døve få med seg informasjonen som formidles i video. Det er i tillegg fint for alle dersom man ønsker å se en video, men ikke har mulighet å ha på lyd i rommet man er i. 

Det er en del forekomster på nettsiden vår der overskriftsnivåer hoppes over, ofte til h4. Både semantisk og visuelt er det viktig med en logisk struktur med overskriftsnivåer for å navigere til innhold både for syn og skjermleser i logisk rekkefølge. Det finnes flere tabeller, spesielt innlogget for bedrift, som mangler tittel (caption). Det samme gjelder landemerker som gjentas flere ganger på en side. Det er viktig å navngi elementene for å fortelle hva de inneholder, for eksempel hva en tabell viser.

Det er en del rekkefølge som ikke blir meningsfull som en konsekvens av at overskriftsnivåer en del steder ikke er kodet slik det ser ut. Et eksempel på forsiden der "Aktuelle saker" er tittel for artikler under. "Aktuelle saker" er h4 mens lenker under er h3. Lenkene vil da bli lest opp før h4 om sluttbruker navigerer seg gjennom siden med overskriftsnivåer og skjermleser. Med css skrudd av vises den heller ikke som en overskrift til lenkene under. Det er også eksempel på tabell uten meningsfylt rekkefølge tabelloverskrifter vises i bold, men semantisk er alt td på samme nivå.

Vi har få forekomster med brudd på dette kravet. I skjema innlogget for bedrift blir det beskrevet at "alle detaljer til høyre må beskrives så riktig som mulig." Kun de som kan se elementene og er på "riktig" skjermbredde" vil kunne tolke hvor "høyre" er i denne sammenhengen. Det er viktig å tilby informasjon som alle kan tolke og forstå uavhengig av sensoriske egenskaper.

Stort sett oprettholder vi kravet for visningsretning med få unntak. For eksempel viser ikke chatfunksjonalitet startknapp ved landscape på mobil.

Vi har mange tilfeller der inndataformål ikke er identifisert. I felter som fornavn, etternavn, rolle i foretak, e-post, telefonnummer mangler attributtet autocomplete med riktig verdi. Det mangler i tillegg formtag og submitbutton som slike felt krever. De har heller verken navn eller id attributt som er nødvendig for at det skal fungere. Felter som har markert inndataformål hjelper sluttbruker å fylle ut slike gjentagende felter enklere med ulike hjelpeverktøy. 

Vi har noen få tilfeller der vi kun bruker farge for å formidle informasjon. For å vise at felt ikke er fylt ut vises ingen feilmelding, kun bruk av farge for å vise feil i skjema for innlogget privatperson. Vi har og noen lenker som ikke er utformet forskjellig fra vanlig tekst, for eksempel for eksempel "Hovedside | ny søknad" i header for innlogget bedrift eller lenker i cookiestabell. Å formidle informasjon kun ved bruk av farge vil gjøre det  vanskelig for fargeblinde å får med seg riktig informasjon eller hva som er interegerbart. Ved å heller ikke bruke farge får de som ikke er fargeblinde samme opplevelse som de som ikke kan se farger.

I løsningen vår har vi en god del brudd på konrastkrav, men stort sett i innlogget løsning. Der det brukt lysegrå tekst på hvit bakgrunn eller omvendt til titler,spesielt i øverste område, header, og informasjon om påbegynt skjema. Noen knapper i skjema er ikke interegerbare, disabled, og viser feks lysegråbakgrunn med hvit tekst. Når noen knapper i skjema er i fokus blir konrasten og veldig lav. Det er også andre tilfeller der bakgrunn på knapp og hvit tekst har dårlig kontrast. Ellers er det dårlig konrast for feilmeldinger i skjema for privatperson og skjema for å få "oppdateringer av enova". I innlogget løsning er det og brukt lyseblå bakgrunn med hvit tekst. Det er viktig å lage en løsning som er robust der kontrast tåler dagslys/solys. God konrast er spesielt viktig for svaksynte. 

Det er stort sett mulig å endre størrelse på tekst uten tap av innhold på nettsiden vår. Det er derimot noen tilfeller der informasjon forsvinner ved endring av tekststørrelse. Chatmodul mister inputfelter ved zoom opp mot 200%. Det meste på siden er responsivt med noen unntak som ikke er brudd på 1.4.4, men 1.4.10. For noen er det viktig å kunne endre tekststørrelse, enten om man har blitt eldre eller andre årsaker. Med mulighet å tilpasse størrelse etter sitt behov får også denne brukergruppen med seg informasjon som er på nettsiden. Derfor er det viktig at informasjon eller funksjonalitet ikke forsvinner ved endring av tekststørrelse. 

Vi har noen få tilfeller der bilde av tekst vises uten tekstalternativ eller tekstlig beskrivelse. For eksempel vises steg for en prosess der tekst er i form av bilde uten alternativ tekst. Den visuelle beskrivelsen i bildet viser steg for hvordan søke støtte. Det er og en del ren tekst i noen slidere. I noen av tilfellene kunne vi vurdert å ha brukt html da det er enklere å opprettholde behov for flere brukergrupper, zoom av tekst, skjermleser etc, og om ikke alternativ tekst. Det vil vi vurdere til nytt innhold. 

Stort sett oppfører nettsiden vår seg responsiv og innhold legger seg under hverandre ved zoom eller mindre skjerm. Det finnes noen unntak som chat-modul. Ved zoom opp mot 400% forsvinner innhold. Et annet eksempel er tekst i header for innlogget bedriftsprofil. Ellers er en del vertikal scrolling for skjema på innlogget bedriftside. Det er viktig for alle med god responsivitet slik at man kan bruke den enheten man ønsker, men spesielt viktig for personer med nedsatt syn som har behov å zoome. 

Det er ikke veldig mange forekomster på nettsiden vår der ikke-tekstelig innhold har dårlig kontrast, men det forekommer noen steder. I skjema for innlogget privatperson vises linjer og sirkler med tall hvor i prosessen man er der kontrast er dårlig. Noen radioknapper har dårligkonrast der sirkel er hvit på en oransje bakgrunn. Det er heller ikke like tydelig for alle at disabled elementer ikke er interaktive, feks de med nedsatt syn eller kognitive utfordringer. Kombinasjon av dårlig kontrast og at elementet ikke er klikkbart kan bli forvirrende for enkelte. Inputelementer, for eksempel et tekstfelt, kan generelt kan fremheves noe mer enn i dag. Det er brukt symbolet " * ", for å formidle hvilke felter i skjema som er obligatorisk å fylle ut der konrasten ikke god nok i skjema for å få oppdateringer av Enova. Å vise kontrast for ikke-tekstelig innhold er viktig da det er med på å formidle informasjon eller funksjon. 

Innlogget på bedriftside vises ikke deler av tekst i header f.eks "hovedside -nytt foretak" ved bruk av tekstavstand. Heller ikke åpningstider for betjening.

Denne funksjonaliteten forekommer ikke ofte på siden vår, men det er noen unntak. Inne på bedrift - søknadskjema, der man kan opprette nytt bygg, er det en tooltip som ikke kan fjernes med escape eller ta musepeker over. Det er mye informasjon om felter som er påkrevd. Ikoner viser også informasjon i form av tooltip med samme funksjonalitet. På forsiden dukker det opp tooltip ved mouseover. Den er mulig å "avise" ved å klikke esc, det dekkes heller ikke over annet innhold. Det er ikke mulig å bruke med mouseover, da forsvinner elementet. Det er viktig å kunne fjerne innhold som dukker opp automatisk ved mouseover eller fokus da det kan være i veien for annet innhold man ønsker å lese eller nå. Pekerfølsomt innhold kan være forstyrrende for å utføre det man skal på en nettside, de er heller ikke veldig enkelt for en med nedsatt håndfunksjon å kontrollere. Det kan være frustrerende om man har behov å zoome fordi man har nedsatt syn og innhold dukker opp og dekker store deler av innhold på siden. Det kan og være vanskelig å håndtere for de med nedsatt kognisjonsevne. 

Vi har en del elementer på siden som ikke er interegerbare med tastatur. Det er mange knapper for å vise og skjule innhold som ikke fungerer med tastatur fordi de ikke kodet med riktig html-element. Flere eksempler på dette er knapp for å avslutte samtale i chatlog. De fleste tabeller er ikke interegerbare for å viser mer informasjon eller velge med tastatur. I innlogget skjema for å velge bolig er boligen visuelt en lenke, men kodet som en div og ikke interegerbar med tastatur. Innlogget for bedrift er ikke lenker i modal "ny søknad" navigerbare med tastatur. Modul for å få ut data på faktorer som påvirker utslipp er ikke interegerbar med tastatur. Det er og noen tilfeller det elementer iskjema ikke funger helt heldig med tastatur eller er interegerbar, for eksempel avhukningsfelter. Det er viktig å lage en nettside som kan brukes med tastatur for de som ikke kan bruke vanlig mus, men andre hjelpemidler. Noen eksempler er vanlig tastatur, tastatur kontrollert med munnpinne, stemmekontroll. 

Vi har få tilfeller av tastaturfeller, men det fremkommer allikevel i chat-dialog. Det er ikke mulig å lukke hat med kryssikon med tastatur. 

Det er mulig å hoppe til hovedinnhold når man ikke er innlogget med tastatur. På innlogget side er det ikke mulig. Man kan hoppe til <main> området dersom landemerket eksisterer. Derimot er det ikke alle brukere som vet om dette. Ved tab burde man tilby en knapp som vises der man kan hoppe direkte for hovedinnholdet, brukes med tastaturnavigasjon og for de med skjermlesere. Enkelte steder forsvinner innholdet når man hopper til hovedinnhold. En hyppig tastaturnbruker er det kjekt å kunne hoppe over gjentagende innhold på toppen av en nettside. 

Vi har stort sett gode sidetitler som er kodet riktig, men det er et forbedringspotensialet. Det finnes noen sidetitler med manglende relevant beskrivelse av emne eller formål med siden, heller ikke når den blir lest ut av kontekst. Et eksempel er oversiktsiden for privatpersoner. Sidetittel sier ingenting om at man er inne på en oversiktside for privatpersoner. Dette er viktig dersom man for eksempel har mange faner oppe samtidig og for søk. 

Det er stort sett en logisk struktur på rekkefølge på nettsiden med noen unntak. Etter man har åpnet hovedmeny med tastatur og skal tabbe videre til elementene i menyen går fokus videre til andre elementer i header. Andre eksempler elementer i modal som ikke blir navigert til når den åpnes. Innlogget for bedrift er tabrekkefølge for å kontakte enova omvendt av hvordan de vises i header. Om fokusrekkefølge er veldig forskjellig fra leserekkefølge, ikke er meningsfull, kan det være forvirrende for de fleste, spesielt for de med nedsatt kognisjon, nedsatt motorikk eller bruk av skjermleser.

Det er mange gode beskrivende tekster med formål til lenke. Selv om det er markert flere steder tydelig når man laster ned en PDF er det noen tilfeller lenker ikke formidler dette. Et eksempel er lenken "vilkår for statsstøtte", fremstår som en vanlig lenke, men laster ned en PDF når man forventer å bli ledet til en ny side. Det samme gjelder lenker som åpner en ekstern side i ny fane. Det er mange lenker med tekst "les mer". Det er ikke et brudd på kravet da det fungerer i kontekst av informasjon, men er å anbefale å gi lenketekst en god beskrivelse av lenkeformål. Dette vil være spesielt behjelpelig for de som for eksempel bruker skjermleser og talestyre.

Det meste på nettsiden vår har synlig fokus, men det finnes en del unntak. Innlogget er hjelp-lenke ikke i fokus når navigeres til. Knapp for start registrering som innlogget privatperson er ikke i fokus ved tab. I skjema vises avhukningsfelter, både disabled og enabled uten fokus ved bruk at tab. I skjema er det meste ikke fokuserbart med tastatur, heller ikke i modal for å laste opp fil.  Ved bruk av tab i hovedmeny navigeres det gjennom visuelt skjulte lenker. Det blir vanskelig å vite for eksempel hvilken lenke eller knapp man har navigert til dersom det ikke vises visuelt hva som er i fokus.

Det er mange tilfeller ledetekst ikke vil fungere slik det bør på nettsiden med stemmekontroll. Grunnen til dette er stort sett fordi ledetekst til skjemaelementer ikke er koblet sammen, eller aria-label som overstyrer visuell tekst. For eksempel er lenke "privat" i hovedmeny overstyrt med aria-label "vis linker for privat". Om en bruker aria-label for å overstyre burde ordet som vises visuelt være først i rekkefølgen. Noen skjemaelementer har en visuell ledetekst/label, men som ikke er koblet til inputfelt i kodet. Dette er viktig spesielt for de som bruker talekontroll. 

Vi følger ikke ISO-standard med to tegn for språkkode. Det er heller ingen språkkode for innlogget løsning. Vi har riktig språkkode for innlogget privatperson, men ikke for innlogget bedriftsperson. Riktig språkkode for siden er viktig for de som bruker skjermleser slik at innhold uttales på riktig språk eller dialekt.

Vi har veldig lite innhold som er på andre språk en norsk. Unntak er lenken "about enova". Artikkelsiden til lenken er på norsk domene, men innhold på engelsk og mangler lang=en" attr.  Riktig språkkode for siden er viktig for de som bruker skjermleser slik at innhold uttales på riktig språk eller dialekt.

Stort sett har vi konsekvent rekkefølge for navigering på nettsiden vår for gjentagende innhold. Nedtreksmeny for å se hvem som er innlogget vises under header for innlogget privatperson og over for bedriftsperson. I skjema er det noen ulikheter for å navigere til forrige og neste sted. I bedriftsløsning er det mulig å navigere tilbake både øverst og nederst for skjema, mens for skjema for privatperson er ikke dette mulig. Om konsekvent navigering ikke støttes blir det forvirrende for de fleste, men spesielt for blinde, svaksynte og de med nedsatt kognisjon. 

Det forekommer en del tilfeller der like elementer opptrer eller ser forskjellig ut. Logo i header er plassert identisk og utformet likt, men har ulik destinasjon ut i fra hvor på nettsiden man er. Noen lenker som laser ned PDF vises ulikt noen steder. For eksempel i liste for søknadsdokumenter er det fremvist at lenker er nedlastbare PDF, mens andre steder blir ikke det formidlet. I innlogget løsning for privat og bedrift er oversiktside, skjema og fremgangsmåte for å opprette nytt skjema realtivt ulikt. Konsekvent identifikasjon er behjelpelig for alle, men spesielt for de som har nedsatt kognisjon, blinde, døvblinde og svaksynte. 

I skjema for innlogget privatperson og skjema for "oppdateringer fra Enova" er det en del feil som kastes automatisk uten tilstrekkelig beskrivelse av feil. I skjemafelt for privatperson blir det kun kastet feil i form av farge. Det er viktig for de fleste å få en klar indikasjon at en feil har oppstått og hva feilen er, men spesielt for døvblinde, blinde, fargeblinde og de med nedsatt kognisjonsevne.

Vi har stort sett ledetekst og instruksjoner til skjemaelementer, med noen unntak. I alle skjema er det brukt symbol (*) for å markere hvilke felter som er obligatoriske uten å forklare hva symbolet betyr på starten av siden. Noen grupper med avhukningsfelter eller radioknapper mangler en label, instruksjon for hva man skal huker av eller velger. Det blir enklere for de fleste å forstå hva man skal fylle ut dersom det er en beskrivende ledetekst eller instruksjon.

Det er stort sett ingen forslag til feil i noen av våre skjema verken om de kastes automatisk eller ikke. Det er behjelpelig for alle å se forslag ved feil, spesielt for de med nedsatt kognitiv evne, nedsatt motorikk, blinde, døvblinde og fargeblinde.

Det er noen tilfeller der nøsting av elementer ikke er i riktig rekkefølge eller ugyldig. For eksempel har innholdområdet der "råd, inspirasjon og tips" vises har vi en footer i en footer. Noen steder har knapper ugyldig tag som <div> eller <p> eller label med <div> tag. Utover det er det stort sett mangel på riktig nøsting av elementer for skjemaelementer der <form>, <fieldset> slik at de fleste verktøy fungere optimalt for å sende inn skjema. Det er noen få tilfeller av dupplikat av id. I de få tilfellene er de stort sett tomme eller ikke brukt til noe. Ved syntaksfeil eller nøsting kan gjøre det umulig for de som bruker hjelpeverktøy eller vanlig tastatur 

Det er mange tilfeller på nettsiden vår der navn, rolle eller verdi ikke opprettholdes. For eksempel er det mange knapper som ikke er kodet som knapper eller det gis indikasjon om at de er en knapp. De fleste radioknapper skjemagrupper som avhukningsfelter og radioknapper mangler en tilhørende ledetekst i kode. I Iframes eller andre elementer det fremkommer flere av som <article> og <section> er det ingen ledetekst som beskriver innholdet. Dette gjør det vanskelig å benytte hjelpemidler som for eksempel stemmekontroll eller skjermleser.

Vi har stort sett ikke støtte for statusbeskjeder for skjermleser der innhold oppdateres dynamisk. De fleste skjemaer støtter ikke at feilmeldinger leses opp, heller ikke søkefelt der innhold oppdateres mens du skriver forteller om noe skjer.