Rapport over problem knyttet til universell utforming NDLA 2022-12-13
Om denne rapporten
Tjenestens navn
NDLA
Analysens omfang og avgrensninger
Utvalgte sider som kunden har sendt oss. Ligger i et dokument.
Ansvarlig for tjenesten
Useit Consulting Norway AS
Kontaktopplysninger
elsa@useitconsulting.no
hanna@useitconsulting.no
Protokollen er opprettet av
Elsa Kristensen (Useit)
Verktøy og nettlesere som er benyttet
Nettleser:
- Chrome
- Firefox
- Safari
Skjermleser:
- NVDA
- VoiceOver (Mac & iOS)
- TalkBack (Lenovo tablet)
Verktøy:
- Aceit
- Color Contrast Analyzer
- Axe Dev Tools
Oppsummering av resultatet
Grensesnittet fungerer generelt bra i mange måter, men det viser seg å ha problemer som påvirker flere brukergrupper. Dere har vært flinke til å kode overskrifter som overskrifter, og passet på å ha god fargekontrastforhold mellom tekst og bakgrunn. Alle lydklipp/podkast har en tekstversjon, noe som er bra for hørselshemmede brukere.
Det er flere øvelser på siden som er brukervennlig, også for skjermlesere. Men det er også en del forbedringspotensialer for å gjøre dette enda bedre. De mest berørte brukerne er synshemmede brukere som er avhengige av skjermlesere, brukere som er avhengige av tastaturet for navigering, hørselshemmede brukere og kognitivt svekkende brukere.
En skjermleser er et hjelpemiddel som konverterer alt som finnes på skjermen i form av tale eller punktskrift. Synshemmede brukere er avhengig av hva skjermleseren leser. Hvis ting ikke er korrekt kodet for å være tilgjengelig og tolket riktig for skjermleser, utgjør det en barriere for denne brukergruppen.
Det er enkelte øvelser som skjermleserbrukere ikke får tilgang til, der man blant annet bruker sensoriske informasjon som ber brukere å "se seg rundt" som blir vanskelig å utføre for skjermleserbrukere.Det er også enkelte tilfeller hvor skjermleserrekkefølgen ikke er logisk, overskrifter som ikke følger et hierarkisk rekkefølge og bilder som ikke har alternativ tekst.
Tastaturbrukere bruker ofte tabulatortasten for å navigere mellom interaktive elementer som lenker og knapper. Tastaturrekkefølgen er heller ikke logisk på enkelte steder, og fokusmarkeringen kan ha dårlig fargekontrastforhold på enkelte steder.
Det er flere videoer som har ikke undertekster, noe som hørselshemmede brukere er avhengig av. Alle deres videoer mangler en synstolkning, som skal gi en sammenlignbar beskrivelse av hva som skjer i videoen
For brukere med kognitiv svikt kan det være vanskelig å forstå feilmeldinger hvis det er kun beskrevet med farge og ikon, og ikke med tekst.
Hvert punkt i rapporten er satt med ulike kriterier, fra kritisk til lav. Disse avhenger av omfanget av problemene, hvor mye det påvirker brukerne og hvor ofte det oppstår.
Sortering
Innhold
Prioritet: Kritisk
Dette er problemer som har svært stor påvirkning på brukernes evner til å benytte grensesnittet. En del brukere blir sannsynligvis helt utestengt.
Tidsmaskin-spillet er umulig å bruke med skjermleser
ID:
Ally-3658
Prioritet:
Kritisk
Status:
Åpen
Beskrivelse og løsningsforslag:
Tidsmaskin-spillet er ikke mulig å fullføre med en skjermleser da enkelte elementer er umulig å håndtere. Nedenfor lister vi de største utfordringene en skjermlserbruker får:
- Klikkbare objekter som knapper er dårlig beskrevet. "Spill"-knappen på starten sier kun "knapp". Synshemmede brukere får ikke informasjon om at det er en spill-knapp som de kan trykke på.
- Skjermleserrekkefølgen er ikke logisk når man navigerer til første side etter introen. Skjermleserbrukere får først fokus på "Lukk"-knappen og ikke selve innholdet. Her må brukeren navigerere bakover for å nå innholdet. Dette skaper mye forvirring for skjermleserbrukere som forventer at nytt innhold blir opplest, men så kommer dem ikke videre etter "Lukk"-knappen og må navigere seg bakover.
- Brukeren må kunne se på skjermen for å delta i spillet (Sensory characterstics). Synshemmede brukere kan ikke "lete rundt" i et rom slik som seende brukere gjør.
- Man kan heller ikke klikke på objekter i spillet med tastaturet. Dette fører til at skjermleserbrukere ikke får tilgang til knappene. Det er ingen knappetekst, selv om det er knappeobjekter.
Løsningsforslag
- Det er svært vanskelig for en synshemmede brukere å "se seg rundt i rommet" og lete etter objekter. Brukeren må få muligheten til å pilnavigere seg rundt rommet for å rotere kameraet slik at man kan "se" hele rommet. Deretter må skjermleserbrukere få en forklaring av objektene som har fokus.
- Alle klikkbare objekter må være tilgjengelig med tastaur. Det kreves også beskrivende knappetekster som refererer til objekter i tekst opp/ned.
- Det er også mulig å bruke lyd for lydinstruksjoner som et alternativ - det er mange måter man kan bruke det på.
Sider vi henviser til
Flere øvelser er ikke tilgjengelig for skjermleserbrukere
ID:
Ally-3682
Prioritet:
Kritisk
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er en øvelse som lar brukere bygge atomer. Denne tredjepartsløsningen er ikke tilgjengelig for en synshemmede brukere som bruker skjermlesere. Når en skjermelser navigerer til denne øvelsen, vil skjermleseren kun få opplest en URL og at det er tom gruppe.
Skjermleserbrukere blir dermed ekskludert fra å delta i innholdet.
Denne øvelsen er heller ikke tilgjengelig for skjermlserbrukere. Øvelsen er kodet med canvas, som er et element som er vanskelig å samhandle med skjermleser.
Løsningsforslag
- I koden til denne rammen er det flere elementer som er kodet med aria-hidden="true". Dette attributtet gjør at innhold blir skjult for skjermleserbrukere, og dette er nok en av grunnene til hvorofr skjermleserbrukere ikke får tilgang til noe innhold til denne øvelsen.
Sider vi henviser til
Flere øvelser bør forbedres for tastaturbrukere
ID:
Ally-3683
Prioritet:
Kritisk
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere øvelser som er vanskelig å håndtere med tastatur, og flere av disse problemene nevnes også i andre punkter i protokollen.
I Ally-3658 er det en tidsmaskin-øvelse som er vanskelig å håndtere med skjermleser, noe som gjør det også vanskelig å håndtere med tastatur. Det første problemet som dukker opp er at det faktisk ikke er mulig å trykke "start" i øvelsen. Dette hindrer tastaturbrukere fra å delta i øvelsen.
I koden er knappen kodet med en tabindex="-1", noe som hindrer tastaturbrukere å navigere til knappen.
Øvelsen innebærer også at man skal navigere rundt et rom, men dette får ikke tastaturbrukere tilgang til.
I Ally-3671 er det en tredjepartsløsning som ikke er mulig å nå med tastatur:
I Ally-3682 nevnes det også en "Bygge atom"-øvelse og "Smittebrydd i Kongsland"-øvelse som ikke er tilgjengelige for skjermlesere. Denne er heller ikke tilgjengelig for tastaturbrukere, så her får heller ikke tastaturbrukere ta del av innholdet.
Løsningsforslag
- Sørg for å fjerne tabindex="-1" på "start"-knappen.
- For at tastaturbrukere skal få tilgang til å navigere seg rundt i rommet, bør piltastene være en mulighet å navigere på.
Sider vi henviser til
https://ndla.no/subject:1:f18b0daa-6507-4025-8998-b8a11c8ccc70/topic:7:ff48ed85-dbc5-4b98-a3b2-4212fd341c1a/topic:1:07a16836-8498-478e-a718-ece26ea52c3f/resource:1:186332
https://ndla.no/nb/subject:1:f18b0daa-6507-4025-8998-b8a11c8ccc70/topic:11:46a52646-8e07-472f-9e2d-564a93ce8757/topic:11:5885269c-ce1d-4d9e-b6d5-93e894252959/resource:1:61329
Forhåndsinnspilte videoer må ha synstolkning
ID:
Ally-3717
Prioritet:
Kritisk
Status:
Åpen
Beskrivelse og løsningsforslag:
Alle deres videoer mangler synstolkning, noe som er viktig for synshemmede brukere som bruker skjermlesere. Dette fører til at enkelte brukere blir ekskludert hvis de ønsker å forstå formålet med videoen.
I videoen nedenfor er det essensielt å ha en synstolkning. Videoen har ikke lyd, så her får ikke skjermleserbrukere beskjed om hva som blir tegnet i videoen. Her bør skjermleserbrukere også få beskjed om hva slags kinesisk tegn som blir tegnet.
Løsningsforslag
- Tenk over: Informasjon i teksten på bilde skal leses opp.. (navn, informajsonsskilter...)
-
Vi anbefaler å følge retningslinjene på dette i forhånd, noe som gjør det lettere å oppfylle dette kriteriet. På "veileder for universelt utformet video" kan dere lese mer om hva synstolkning innebærer:
https://www.universell.no/fagomraader/universell-utforming/veileder-for-universelt-utformet-video/synstolking/
Sider vi henviser til
Alle videoer
Prioritet: Høy
Dette er problem som har en stor påvirkning på brukernes evner til å forstå grensesnittet.
Enkelte overskrifter glemmer å hoppe over overskriftsnivåen
ID:
Ally-3622
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er enkelte overskrifter som har glemt å hoppe over overskriftsstrukturen. For synshemmede brukere som bruker skjermlesere, er det viktig at overskrifter følger en hierarkisk struktur. Dette er for å hjelpe at brukerne med forstå sammenhengen mellom den overordnene overskrift og underoverksriftene.
Følgende eksempel kommer fra siden "Råvarer og produksjon". Her er det flere h1-overskrifter, og h2-overskrifter som hopper direkte til en h1-overskrift.
Det er også viktig å merke seg at det er ikke et avvik å ha flere h1-overskrifter, men vi anbefaler å kun ha én. Denne h1-overskriften skal representere tittelen på siden.
Det samme problemet skjer på "Oppsummering"-siden.
Dette skjer også på en rekke andre sider.
Løsningsforslag
- Sørg for at overskriftene følger en hierarkisk struktur fra h1-h6. Pass på også å ha kun h1-overskrift.
Sider vi henviser til
Forhåndsinnspilte videoer må ha undertekster
ID:
Ally-3626
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Overordnet mangler de fleste videoer undertekster, noe som er spesielt viktig for brukere som er døve eller tunghørte. Her får ikke disse brukerne muligheten til å høre hva som skjer i videoene, og uten undertekster har ikke disse brukerne tilgang til informasjonen i videoen.
Det utgjør også et problem for brukere som kan havne i en situasjon der de ønsker å få med innholdet i videoene, men har ikke muligheten til å slå på lyden.
Videoen nedenfor kan også åpnes i YouTube, og da vil en undertekst vises. Men her det viktig at man også får muligheten til å få en undertekst vises når man er på siden deres.
Mangelen på undertekster rammer med andre ord en ganske stor brukergruppe, hvorav noen blir helt eksludert fra å få tilgang til informasjon.
Men det er enkelte videoer som har undertekster, se eksempel nedenfor:
Så dette avhenger veldig hvilken videospiller man implementerer på siden.
Løsningsforslag
- Sørg for at alle videoene med lydtekst har undertekster.
Sider vi henviser til
Video uten undertekst
Video med undertekst
Unngå hjelpetekster på engelsk
ID:
Ally-3628
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er veldig bra at dere har hjelpetekster, men når hjelpetekstene er på et annet språk enn norsk er det vanskelig å lese den engelske teksten med en norsk skjermleser.
Dette skjer ofte tredjepartsløsningen h5p.
Eksemplet ovenfor viser når en skjermleser når en knapp, og hjelpetekst på engelsk vil bli lest opp.
Nedenfor er et eksempel hvor det er lagt til en hjelpetekst som er forvirrende for skjermlerbrukere. Hjelpeteksten forteller på engelsk at man kan bruke piltastene for å komme til neste i sliden, men dette er ikke en lysbildefremvisning.
Nedenfor viser vi et annet eksempel hvor det er hjelpetekster på engelsk:
I Ally-3546 er det flere øvelser som har engelske hjelpetekster.
Løsningsforslag
- Når resten av inneholdet på siden er på norsk så bør hjelpeteksten også være på norsk.
Sider vi henviser til
Muskelapp er vanskelig å håndtere med tastatur
ID:
Ally-3642
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Som nevnt i Ally-3634 er muskelappen også vanskelig å håndtere med tastatur. Brukere med begrensede motoriske ferdigheter bruker ofte tastaturet til å navigere på sider. Tastaturbrukere bruker ofte tabulatortasten for å navigere mellom interaktive elementer som knapper og lenker. Muskelappen lar brukere trykke på bestemte deler av kroppen med musen, men dette er ikke mulig med tastatur.
Det er ikke kun brukere med nedsatt motorikk som bruker tastatur for å navigere gjennom en side, enkelte brukere foretrekker å bruke tastaturet uten å ha en salgs funksjonshemmig.
Men som allerede nevnt i All-3634 finnes det alternativ å velge muskelgrupper ut i fra en rullegardinmeny:
Selv om skjermleserbrukere ikke får tilgang til å trykke på bildet har dem allikevel muligheten til å velge mellom enkelte kroppsdeler ut i fra en nedtrekksmeny. Så her finnes det en alernativ for tastaturbrukere.
Løsningforslag
- For øyeblikket er øvelsen der man kan velge enkelte kroppsdeler kodet som et bilde med <svg>, <g> og <path>-elementer. Dette er elementer som tastaturbrukere ikke kan samhandle med. Hvis muskelgruppene hadde vært kodet som <button> så hadde brukerne fått tilgang til å navigere til elementene med tabulatortasten.
Sider vi henviser til
Unngå bilder av tekst
ID:
Ally-3669
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere bilder som har tekst i bildet, noe som påvirker flere brukergrupper. For skjermleserbrukere er det ikke alltid bildebeskrivelsen er tilstrekkelig nok.
Nedenfor er et bilde hvor alternativ teksten er "Smittekjeden på gul bakgrunn. Illustrasjon":
Alternativ teksten samsvarer ikke men innholdet i bildet.
Det er også andre brukere som blir påvirket, blant annet brukere med dyskleksi. Enkelte dysletikere er avhengige av å øke avstanden mellom tegn for å øke lesbarheten. Dette verktøyet vil ikke fungere hvis det er tekst i bildet. Andre brukere er avhengige av tekstforstørrelse, og dette verktøyet fungerer heller ikke med tekst i bilder. Når man forstørrer teksten i bildet kan man risikere at teksten i bildet blir uskaprt og vanskelig å lese.
Nedenfor er også et annet eksempel:
Det finnes derimot andre bilder som har en bra alternativ tekst, eksemplet nedenfor har alternativteksten "Maslows behovspyramide med fem nivåer. Nederst fysiologiske behov, som sult, tørste, søvn, deretter trygghetsbehov, så sosiale behov, videre behov for anerkjennelse og øverst behov for selvrealisering. Illustrasjon.". Dette beskriver godt informasjonen til bildet.
Løsningsforslag
- Vi anbefaler at man koder bildene med HTML og CSS, slik at enkelte brukergrupper enkelt kan forstå innholdet til bildene.
Sider vi henviser til
Andre sider med tekst i bilder:
Flere øvelser er vanskelig å gjennomføre med skjermleser
ID:
Ally-3678
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er en annen øvelse som krever at brukeren må se seg rundt, noe som er et problem for synshemmede bukere som bruker skjermleser. Problemene som nevnes her, treffer mye i det som allerede er nevnt i Ally-3685.
Nedenfor listes det problemer som forårsaker problemer for skjermleserbrukere:
- Når skjermleserbrukere kommer til øvelsen, bør de informeres om hvordan øvelsen skal gjennomføres. Her bør det være en hjelpetekst som hjelper brukeren med å forstå at øvelsen består av ulike deler som lar deg navigere i synagogen og at man får mer detaljert informasjon om enkelte objekter i synagogen.
- Det er mulig å navigere til alle objektene i synagogen med piltastene, rundt med piltastene, noe som er veldig bra! Men her må knapebeskrivelsene være mer beskrivende for brukerne. Enkelte knapper viderefører brukeren til et nytt sted i synagogen, mens andre knapper tar brukeren til et modalt vindu med mer informasjon. Dette bør tydeliggjøres for brukerne. Nedenfor er et eksempel på dette hvor en knapp har fått knappebeskrivelsen "Davidstjernen", men når man trykker på knappen vil et modalt vindu åpnes.
Samme type problem skjer også siden "Tester som utføres på boreveskæn".
"Bilverkstedet 360" har de samme problemerne, hvor skjermleserbrukere må se seg rundt på et bilverksted. Det er imidlertid enkelte områder hvor det ikke er ingen klikkbare objekter, så skjermleserbrukere får ikke muligheten til å "se seg rundt" som visuelle brukere.
Følgende eksempel viser et bilde av en slamvekt med spesifikke knapper som man trykke på for å få mer informasjon om spesifikke deler av slamvekten.
Når en synshemmet bruker som bruker en skjermleser når dette bilde, blir ikke brukeren varslet om at bildet inneholder knapper som man kan samhandle med.
Knappebeskrivelsene er ikke tilstrekkelig nok for skjermleserbrukere, her forteller den kun navnet på hvert objekt.
Denne øvelsen fra "Åtteregelen" gir beskjed til brukere at de kan trykke på "gardin"-knappen for å se hvilken trend verdiene følger. Skjermleserbrukere når denne knappen og forteller at det er en glidebryter. Brukerne får imidlertid ikke den samme opplevelsen som visuelle brukere.
Løsningsforslag
- Hjelpeteksten for hvordan man utfører øvelsen bør tydeliggjøres enda mer fra start. Dette kan gjøres ved å legge til en sr-only.
- Sørg for at knappebeskrivelsene er enda mer tilstrekkelig, dette gjøres i aria-label.
Sider vi henviser til
Tastaturrekkefølgen er ikke logisk
ID:
Ally-3704
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Øvelsen "Bilverkstedet 360" har knapper som ikke er ordnet i en logisk fokusrekkefølge. Etter at brukeren har trykket på "spill"-knappen og kommer til den første siden, må brukeren navigere seg bakover for å nå knappen. Dette skaper en feil fokusrekkefølge for tastaturrekkefølge.
Det er flere øvelser i "Oppsummeringsoppgaver" som ikke er logisk. Når tastaturbrukere navigerer til denne øvelsen, vil det siste kortet få fokus først. Dette betyr at det kan være vanskelig å se at noen av kortenene har fokus.
Hvis man setter fokus på det første kortet vil det være enklere å se at man har fått fokus. Det er også en mer logisk fokusrekkefølge å starte med det første kortet.
Denne øvelsen som også kommer fra samme side har heller ingen logisk fokusrekkefølge. Nedenfor er et lite eksempel på hvordan fokusrekkefølgen er. Det mest logiske ville vært om "fruktose" hadde fokus først, og deretter følgt en fokus fra venstre til høyre.
I Ally-3568 nevnes det enkelte steder hvor skjermleserrekkefølgen ikke er logisk, og enkelte av problemene påvirker også fokusrekkefølgen.
Løsningsforslag
- Sørg for at fokusrekkefølgen samsvarer med den rekkefølgen som visuelle brukere leser. Dette går som vanligivs fra venstre til høyre.
Sider vi henviser til
Bildebeskrivelser blir ikke lest opp av skjermlesere
ID:
Ally-3536
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Alternativ tekst er lagt til flere bilder, noe som er bra! Men bildebeskrivelsen leses ikke opp hvis bildet er kodet sammen med en lenke som åpner et nytt vindu. Når bildet åpnes i et nytt vindu, har bildet ingen alternativ tekst. Dette betyr at skjermleserbrukere ikke forstår hva innholdet i bildet er.
Det er viktig for skjermleserbrukere å gi en beskrivelse av bildet som tilsvarer det en visuell bruker ville sett bildet.
Følgende eksempel fra "Vårt verdensbilde" åpnes i nytt vindu uten en alternativ tekst.
Det er også bilder som ligger inne i en tidslinje som ikke har tilstrekkelig nok bildebeskrivelse:
Løsningsforslag
- Sørg for at alternativteksten for bilde blir lest opp før den blir lest opp som en lenke. Hvis bildet åpnes i et nytt vindu, er det også viktig at bildet har en alt-tag som inneholder bildebeskrivelsen.
Sider vi henviser til
Skjermleserbrukere får ikke tilgang til informasjon i mouseover
ID:
Ally-3539
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Flere artikkelsider har knapper som gir ut mer informasjon når man holder musepekeren over knappen. Denne informasjonen blir ikke lest opp av en skjermleser, noe som betyr at synshemmede brukere ikke vil kunne få tilgang til denne informarsjonen.
Alle knappene nedenfor viser informasjon når man holder musepekeren over knappen.
Nedenfor er kodeutsnittet til informasjonsboksen. Den er for øyeblikket kodet med en aria-hidden="true" som betyr at skjermlesere ikke vil lese opp informasjonen. Hvis man fjerner dette attributtet, vil informasjonen bli lest opp når skjermleserbrukere kommer til knappen.
Løsningsforslag
- Sørg for å fjerne aria-hidden for å få informasjonen lest opp av skjermleser.
- Nedenfor lenker vi til et sted hvordan man kan lage tilgjengelige "tooltip".
https://accessibilityinsights.io/info-examples/web/aria-tooltip-name/
Sider vi henviser til
Dra og slipp øvelser er være vanskelig å gjennomføre med skjermleser
ID:
Ally-3546
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Dra og slipp-elementer har blitt brukt og her får skjermleserbrukere store problemer. For øyeblikket er det umulig for synshemmede brukere som er avhengige av skjermlesere å navigere i denne øvelsen:
Det har blitt gitt instruksjoner for skjermleserbrukere for hvordan man gjennomfører denne øvelsen, men her er instruksjonene på engelsk. Dette skaper forvirringer når skjermleseren er på norsk og skal lese en engelsk tekst med norsk stemme. Alle inndatafeltene har også en engelsk beskrivelse, som bør endres til norsk.
Instruksjonene samsvarer heller ikke med utførelsen av øvelsen, her for skjermleserbrukere vanskeligheter å dra og slippe elementene. Hjelpeteksten forteller at man kan aktivere et element ved tykke "mellemrom"-tasten, noe som fungerer. Men når elementet har fokus får man instruksjoner om hvordan man drar elementene med piltastene, dette fungerer ikke.
Siden "Hva tror du om miljøgifter" har også en dra-og-slipp-øvelse, men her får brukere også en rullegardinmeny for å flytte på elementer. Dette er et bra alternativ for skjermleserbrukere som ikke har mulighet å "dra og slippe".
Det finnes er en type dra og slipp øvelse som bør forbedres for skjermleserbrukere. Det som er bra er at skjermleserbrukere kan gjennomføre øvelsen, men her må man tydeliggjøre hvordan øvelsen skal gjøres for skjermleserbrukere.
- For det første er skjermleserrekkefølgen ulogisk. Når man kommer inn i rammen leses først "habitat"-området, deretter alle artene. Dette bør gjøres motsatt. Artene blir heller ikke presentert i noen logisk rekkefølge. Les mer om løsningsforslaget i Ally-3568.
- En hjelpetekst for skjermleserbrukere kan for eksemepl være "Velg mellom arter for å plassere dem i rett habitat". Dette hjelper brukerne med å forstå hvordan de kan gjennomføre øvelsen.
- Alle artene blir opplest, noe som er bra. Imidlertid er hjelpeteksten på engelsk, så hver art blir lest opp som "Grabbable item 2 av 6, Ekorn".
- Når man velger en art blir man automatisk flyttet til habitat-område, noe som er bra. Men her er hvert område kalt som "Dropzone 1", "Dropzone 2", osv. Her må hjelpeteksten forbedres. Først må vi forklare for skjermleserbrukere hvordan habitaten ser ut, og deretter bør hvert habitat være bedre forklart. For eksemepel "Droppsone 1, fjell i natur".
Samme type øvelse fra "Oppsummeringsoppgaver" har samme problem som nevnt ovenfor:
Denne øvelsen fra "Repitisjon: IMI-kategorier" er veldig lik som øvelsene ovenfor. Øvelsen kan utføres med skjermleser, men hjelpeteksten er også på engelsk. Skjermleserrekkefølgen er heller ikke logisk. Etter å ha valgt en kategori i sidepanelen og plassert den i en bestemt religion, må skjermleserbrukere navigere bakover for å komme tilbake til listen over kategorilisten.
Denne øvelsen fra "Oppsummeringsoppgaver" kan være vanskelig for skjermleserbrukere, hvis de ofte må flytte mellom ord i sidefeltet og setningene. For eksempel, hvis brukeren har valgt ordet "fettsyrer", vil det ta dem til setningene med felter, når man har valgt et felt, bør fokuset gå direkte til sidepanelet med ordene.
Et alterantiv for å gjøre den mer tilgjengelig for skjermleserbrukere er å vise en rullegardingmeny med alle ordalternativene når en skjermleserbruker kommer til inntastingsfeltet, slik at de enkelt kan finne ut hvilket ord som hører til hvilken setning. (Se eksempel som på andre bildet)
Nedenfor vises også en tankekartøvelse hvor man kan dra og slippe hovedemner og underemner på et tankekart. Skjermleserbrukere kan få vanskeligheter med å forstå sammenhengen mellom ulike ordene man kan velge, og hvor i tankekartet de kan plasseres. For øyeblikket er alle de tomme feltene lest opp som "dropzone", så her er det vanskelig for skjermleserbrukere å forstå hvor i tankekartet de skal plassere et ord.
Løsningsforslag
- Det er veldig bra at det finnes hjelpetekster! Men sørg for at de er på norsk og ikke engelsk, eksempel nedenfor:
- Etter at man har aktivert en knapp er det ikke mulig å dra dette elementet. Et alternativ for å kunne dra elementer, kan være at man tabtaster igjen på den aktiverte knappen for å flytte elementet til ønsket plass/emne. Deretter trykker man på enter/mellemrom igjen for å slippe elementet til ønsket plass/emne.
- Løsningsforslag til tankekart: Som allerede nevnt, bør tankekartet være mer tilgjengelig for skjermleserbrukere. Skjermleserbrukere får beskjed om at de har valgt et ord, og når de beveger seg mellom de forskjellige inndatafeltene blir de lest kun som "Dropzone 1 av 8". Hvis en bruker har valgt ordet "mineraler" og ønsker å plassere det mellom "vitaminer" og "vann", bør skjermleserbrukere få beskjed om dette, samtidig at disse underemne mangler et hovedemne som står tomt. Skjermleserbrukere bør også informeres på forhånd om at dette er et tankekart der man skal plassere næringsstoffer som under- eller hovedemner.
Sider vi henviser til
Skjermleserrekkefølgen er ikke logisk
ID:
Ally-3568
Prioritet:
Høy
Status:
Åpen
Beskrivelse og løsningsforslag:
Når man har valgt et steg i læringsstien så vises det informasjon på siden, denne informasjonen blir ikke lest opp direkte etter man har valgt et steg. Dette kan være forvirrende for synshemmede brukere som bruker skjermleser som forventer at innholdet i valgt sted skal bli opplest. Her må skjermleserbrukere navigere gjennom hele læringsstien før dem kommer til innholdet.
Et annet sted hvor skjermleserrekkefølgen ikke er logisk er på tidslinken. Nedenfor er en en tidslinje med tidsperioder. Når man klikker på "Nazistene til makten i Tyskland" vil ikke fokuset gå direkte til selvet innholdet. I dette tilfellet vil navigereringen fortsatt skje i tidslinjen så her bli "Kriseforliket" opplest først, deretter hele tidslinjen. Hvis skjermleserbrukere skal lese innholdet, må man navigere seg bakover.
I denne øvelsen skal man bla gjennom ulike lysbilder. Når man trykker på neste lysbilde, vil ikke navigeringen foregå i selve innholdet. Her må skjermleserbrukere navigere bakover for å komme til innholdet.
Øvelsen "Smitteutbrudd i Konglsand" har innhold som ikke er plassert i en logisk leserekkefølge for skjermleserbrukere. Bildet nedenfor illustrerer at meldingen blir opplest først sammen med svar til ordføreren, deretter innholdsteksten, og til slutt forklaring på at må huske å sende meldingen.
Skjermleserrekkefølgen samsvarer ikke med den visuelle rekkefølgen. Det mest logiske hadde vært å få innholdsteksten opplest først, deretter meldingen med svar, og til slutt påminnelsen å huske å sende melding.
Fra samme side er det en annen lysbildefremvisning. Når man trykker på neste side flytter ikke fokuset direkte til innholdet på den nye sliden. Her må skjermleserbrukere navigere bakover for å nå innholdet.
Øvelsen "Radioaktivitet" har flere klikkbare objekter som ikke har en logisk leserekkefølge. Her blir blant annet ikke informasjonsknappen opplest først, noe som er veldig viktig for skjermleserbrukere å forstå hvordan denne øvelsen skal utføres.
I Ally-3546 nevnes det flere øvelser som har en dårlig leserekkefølge for skjermleserbrukere.
Løsningsforslag
- Det er viktig at skjermleserrekkefølgen er logisk. Dette gjøres ved å plassere innholdet i en logisk rekkefølge i HTML-koden.
- For å flytte fokus kan man også bruker JavaScript.
Sider vi henviser til
Knapper har ikke et tilgjengelig navn for skjermleserbrukere - Løst
ID:
Ally-3542
Prioritet:
Høy
Status:
Løst
Beskrivelse og løsningsforslag:
Flere knapper er kodet sammen med ikoner som ikke har noen beskrivelse for skjermleserbrukere. Dette betyr at flere knapper blir lest opp som "knapp" for synshemmede brukere. Skjermleserbrukere vil dermed ikke forstå funksjonen til knappene.
Nedenfor viser vi enkelte knapper som ikke har en beksrivelse fra artikkelsidene:
Løsningsforslag
- Sørg for å gi en tilgjengelig beskrivelse av knappene for skjermleserbrukere. Dette kan gjøres ved hjelp av aria-label. Eller ved å bruke en sr-only og koble det med aria-describedby.
Sider vi henviser til
Alle sider
Prioritet: Medium
Dette er problem som påvirker en del brukeres evner til å forstå og benytte grensesnittet.
Unngå knappetekster på et annet språk enn norsk
ID:
Ally-3615
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere knapper som er godt beskrevet for synshemmede brukere som bruker en skjermleser, men det imidlertid enkelte steder hvor beskrivelsen for knappene er på engelsk. Dette kan være forvirrende når en norsk skjermleser som har talespråket sitt på norsk skal begynne å lese engelsk knapper. I og med resten av innholdet også er på norsk, vil det også oppstå forvirringer når engelske knapper blir plutselig lest opp.
Nedenfor er et annet eksempel hvor en knapp får en engelsk beskrivelse.
Løsningsforslag
- Istedet for at hjelpeteksten er på engelsk, sørg for at den er på norsk.
Sider vi henviser til
Overskrifter som ser ut som overskrifter må kodes som overskrifter
ID:
Ally-3616
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Totalt sett har dere vært flinke til å kode overskrifter som overskrifter, men det er enkelte steder hvor dette mangler. For synshemmede brukere som bruker skjermlesere, er det viktig at overskrifter er korrekt kodet som overskrifter. Skjermleserbrukere bruker ofte overskrifter for å navigere seg rundt på en nettside.
Eksemplet nedenfor kommer fra siden "Familie - egenvurdering av grammatikkforståelse". Her er tittelen kodet som en h1-tag, noe som er riktig. "Dokumentasjonsverktøy" er ikke kodet som en overskrift, men bør siden den representerer innholdet som kommer under. I dette tilfellet bør den kodes som h2-tag.
Disse overskriftene fra "Rapportgenerator for naturfag og biologi" er kodet som <div>, og behøver å kodes som h-tag.
Løsningsforslag
- Sørg for å kode overskrifter som h-tag. Det er viktig å følge et hierarksik rekkefølge fra h1-h6.
Sider vi henviser til
Statusmelding bør forbedres
ID:
Ally-3618
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Å ha statusmeldinger er veldig nyttig når man gjør dynamiske endringer på en side. Men det er enkelte steder hvor teksten i statusmeldingen bør forbedres for brukere av skjermleser.
Eksemplet nedenfor kommer fra siden "Øv to og to saman!", når man trykker på neste side vil statusmeldingen "Avløysaord for an-be-het-else ord 1" bli lest opp automatisk for hver gang man går til neste side.
For å gjøre det enklere for skjermleserbrukere, kan det faktiske ordet på kortet leses først i stedet som en statusmelding. I dette tilfellet blir det "likhet". Det er veldig bra at "Kort 8 av 15" blir opplest automatisk.
På flere sider som for eksempel "Smitteutbrudd i Kongsberg" har man muligheten til å avmerke "Tilleggstoff". Da vil flere fagstoff vises nedenfor. Skjermleserbrukere får beskjed om at "Tilleggstoff" er markert, men de får ikke beskjed om hvor disse ekstra fagstoffene blir plassert. Dette bør formidles automatisk for disse brukerne.
Løsningsforslag
- Sørg for at statusmeldingen blir endret slik at det ikke blir en unødvendig opplesning for skjermleserbrukere.
Sider vi henviser til
Enkelte inndatafelter er vankselig å forstå med skjermleser
ID:
Ally-3619
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er enkelte øvelser som krever at man skriver inn ord i inntastingsfeltet. Hjelpeordet for det man skal skrive inn er plassert på slutten av setningen. Dette betyr at skjermleserbrukere ikke blir fortalt hvilke ord de skal skrive når fokus er på inndatafeltet.
Når en skjermleser får fokus på inndatafeltet vil hjelpeteksten "Blank input 1 of 12" vises.
Det samme problemet ser vi fra siden "Eigedomsord":
Løsningforslag
- For at skjermleserbrukere skal få beskjed om hvilke ord de skal fylle ut i inndatafeltet kan et alternativ å bytte ut teksten i hjelpeteksten til hjelpeordet samt en beskrivelse, for eksempel:
"Sett inn avløysaord, innflytelse".
Sider vi henviser til
Interaksjon i videoer er vanskelig å oppfatte med skjermleser
ID:
Ally-3624
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Underveis i enkelte videoer vil en knapp/knapper vises som brukere kan samandle med. Når videoen spilles av for en svaksynt bruker med skjermleser, blir brukeren ikke umiddelbart varslet om at det er knapper å samhandle med. Visuelle brukeren vil se at det er knapper som vises automatisk, for skjermleserbrukere får dem ikke umiddelbart beskjed om at det er knapper de kan samhandle med.
Skjermleserbrukere får muligheten til å navigere seg til knappen og samhandle med den, noe som er bra.
Knappebeskrivelsen er heller ikke tilstrekkelig nok, der skjermleserbrukere får kun knappebeskrivelsen "interaksjon".
Løsningsforslag
- Skjermleserbrukere bør varsles umiddelbart om når en knapp vises, slik at dem forstår at det er en knapp de kan samhandle med. For å få beskjeden opplest automatisk kan man bruke aria-live og sr-only.
- Knappebeskrivelsen bør også forbedres, et eksempel på en bra knappetekst kan være "Les mer om blansjeres før koking".
Sider vi henviser til
Unngå å bruke aria-hidden på interaktive elementer
ID:
Ally-3629
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Aria-hidden skal kun brukes for innhold som ikke skal vises for skjermleserbrukere. Dette attributtet forårsaker forvirringer når det brukes på interaktive elementer som skjermleserbrukere må samhandle med.
I følgende eksempel blir brukeren bedt om å klikke på plusstegnet. Dette plusstegnet er for øyeblikket kodet med aria-hidden, så skjermleserbrukere får ikke tilgang til knappen.
Dette medfører at skjermleserbrukere vil få vanskeligheter med å forstå at det ikke finnes et plusstegn og vil tro at det ikke er mulig å utføre øvelsen.
Løsningsforslag
- Ikonet er for øyeblikket kodet sammen med en knapp, men siden ikonet ikke blir lest opp er det vanskelig for skjermleserbrukere å forstå at det er et plusstegn de kan trykke på. Derfor bør aria-hidden fjernes.
Sider vi henviser til
Fargekontrastforhold mellom fokusmarkering og bakgrunn er ikke tilstrekkelig
ID:
Ally-3631
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Vi se flere knapper som får en dårlig fokusmarkering, der fargekontrastforholdet mellom fokusmarkeringen og bakgrunnen ikke er tilstrekkelig. Her må kontrasten være på minst 3,0:1 for å være godkjent. For brukere som er svaksynte og ikke klarer å skille mellom kontraster er det viktig at denne fokusmarkeringen har en tilstrekkelig kontrast.
Eksemplet nedenfor kommer fra siden "Hva tror du om miljøgifter", hvor det kommer en blå fokusmarkering på en blå knapp.
Tidslinjen får også dårlig fokusmarkering, der hele boksen får en annen farge så selvet ikonet/teksten blir nesten usynlig.
Muskelappen har også enkelte knapper som får en dårlig fargekontrast på fokusmarkeringen:
Her vises en tynn blå strek rundt det som er markert, og for enkelte brukere er det ikke tilstrekkelig.
Løsningsforslag
- Sørg for å endre på fokusmarkeringen slik at den oppfyller lovkravet (3,0:1).
Sider vi henviser til
Bakgrunnen går an å nå med modale vinduer
ID:
Ally-3633
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
De fleste modale vinduer er korrekt kodet der man ikke har mulighet å navigere i bakgrunnen, men det er ett sted hvor bakgrunnen mangler å bli låst.
På siden "Tasks: Timeline of African American Timeline" er det en øvelse der man skal matche bilder. Når man har matchet riktig så vil et modalt vindu åpnes, men her er det fortsatt mulighet å navigere i bakgrunnen.
For synshemmede brukere som bruker skjermleser er det viktig at bakgrunnen er låst slik at det ikke blir forvirringer.
Løsningsforslag
- For å låse bakgrunnen må man legge til en aria-hidden="true" i bakgrunnen.
Sider vi henviser til
Muskelapp er vanskelig å håndtere med skjermleser
ID:
Ally-3634
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Muskelappen lar brukere få mer informasjon ved å trykke på bestemte deler av kroppen. Skjermlesebrukere får ikke tilgang til denne funksjonen. Når brukeren navigerer til denne øvelsen vil øvelsen kun leses som "bilde". Tastaturbrukere er heller ikke i stand til å navigere til bestemte muskelgrupper.
Selv om skjermleserbrukere ikke får tilgang til å trykke på bildet har dem allikevel muligheten til å velge mellom enkelte kroppsdeler ut i fra en nedtrekksmeny.
Løsningforslag
- Siden det allerede finnes en alternativ for skjermleserbrukere å velge mellom kroppsdeler kan man gjøre selve "kroppen" skjult for skjermleserbrukere. Dette kan gjøres med aria-hidden="true".
- Hvis man ønsker at skjermleserbrukere skal navigere i kroppen kan man kode øvelsen med HTML-kode, og gjøre alle klikkbare objekter klikkbar med tastatur.
Sider vi henviser til
Matche bilder-øvelsen bør forbedres for skjermleserbrukere
ID:
Ally-3640
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Øvelsen "Match the picture" er tilgjengelig for skjermleserbrukere, men øvelsen må forbedres ytterligere for disse brukerne. Det finnes allerede noen statusmeldinger for å hjelpe skjermleserbrukere å gjennomføre øvelsen, men det er enkelte steder hvor mer informasjon er nødvendig.
Nedenfor lister vi til ting som bør forbedres:
- Skjermleserbrukere trenger tydeligere informasjon om hvordan øvelsene fungerer. Dette bør kommuniseres når brukeren er inne i rammen.
- Skjermleserbrukere bør informeres om totalt kort i øvelsen.
- Man bør også hjelpe brukeren til å navigere fritt i rutenettet.
- Kort som allerede er snudd bør ikke være tilgjengelig for brukerne.
- Kort som ikke er snudd er kallt "unturned", ellers er det en bildetekst. Denne informasjonen bør tydeliggjøres.
- Brukerne får ikke informasjon om kortene ikke stemmer overens, de får kun beskjed om det er match, som vist nedenfor:
Løsningsforslag
- Som vi tydelig ser er det enkelte ting som bør forbedres slik at skjermleserbrukere enkelt kan gjennomføre denne øvelsen. For å gi en statusmelding som kun blir lest opp for skjermleserbrukere kan man bruke sr-only og koble det med aria-live="polite".
Sider vi henviser til
Enkelte knappebeskrivelser må forbedres for skjermlesere
ID:
Ally-3662
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
I flere fagartikler er det en knapp for hver overskrift. Denne knappen forteller skjermleserbrukere at man kan kopiere lenken til overskriften. Problemet her er at overskriften i knappebeskrivelsen ikke samsvarer den faktiske overskriften.
I kodeutsnittet kan vi se i hjelpeteksten (aria-label) at overskriften i knappeteksten ikke samsvarer med den faktiske overskriften som er "kjærlighetsdramaet i Norden".
Dette problemet ser vi på alle knappene som skal kopiere overskriftslenken.
Som nevnt i Ally-3628 er det flere hjelpetekster som er på engelsk. Det samme gjelder for enkelte knappetekster, hvor norsk innhold har fått engelsk knappebeskrivelse for skjermleserbrukere. Dette skjer ofte i tredjepartsløsningen H5P.
Nedenfor er andre eksempler på knapper med engelsk beskrivelse, fra siden "Hydrogenbindinger":
Denne knappen fra øvelsen "Smitteutbrudd i Kongsland" har fått knappebeskrivelsen "Go to slide Neste slide" for skjermleserbrukere, noe som ikke samsvarer med det knappen faktisk gjør.
Løsningsforslag
- Sørg for at overskriften i knappebeskrivelsen tilsvarer den faktiske overskriften.
Sider vi henviser til
Alle fagartikler
Flere knapper er ikke korrekt kodet som knapper
ID:
Ally-3671
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er enkelte klikkbare objekter som knapper som ikke er korrekt kodet som knapper. Det er fortsatt mulig å håndtere disse klikkbare objektene, men skjermleserbrukere får ikke beskjed at det er knapp.
Nedenfor får denne minimerte knappen ikke beskjed om at det er knapp. Den forteller tilstanden til knappen (minimert), men knappen bør fortsatt formidle at det er knapp som kan trykkes på.
Denne knappen fra "Feltarbeid"-siden er heller ikke kodet som en knapp.
"Rapportmalen"-siden har en tredjepartsløsning som inneholder knapper som ikke er korrekt kodet som knapper. Foreløpig er de kodet med <li>-elementer, så her blir ikke skjermleserbrukere varslet om at det finnes klikkbare knapper.
Øvelsen "Radioaktivitet" har en rekke klikkbare objekter som kun er kodet som <div> eller bilder (img). Det har blitt gitt hjelpetekster for skjermleserbrukere om at det er knapper, men de mangler allkelvel å være programmert kodet som <button>.
Løsningsforslag
- Sørg for å kode knappene som <button>.
Sider vi henviser til
Diagram er vanskelig å oppfatte med skjermleser
ID:
Ally-3688
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
"Hydrogenbindinger" har et diagram som er vanskelig for skjermleserbrukere å forstå. Når synshemmede brukere når dette diagrammet, får de kun beskjed om at det er en illustrasjon. Brukerne blir også bedt om å trykke på en "gardin", men denne knappen er også vanskelig å forstå med skjermleser.
Løsningsforslag
- Det er viktig for skjemleserbrukere å få beskrevet hva dette diagrammet går ut på. Et alternativ kan være å legge til en tekstalternativ for diagrammet som beskriver hva den går ut på, slik at skjermleserbrukere får den samme beskrivelsen som visuelle brukere som kan se diagrammet.
Sider vi henviser til
Enkelte bilder behøver bedre alternativ tekst
ID:
Ally-3694
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Utover på siden er det svært mange bilder som har god alternativ tekst, noe som er bra! Det er imidlertid enkelte bilder som behøver bedre alteratniv tekst for at synshemmede brukere som bruker skjermleser enkelt skal forstå hva som skjer i bildet, og få samme opplevelse av bildet som seende brukere.
Det er ofte illustrasjoner med tekst i bilder som ikke har bra nok alternativ tekst, dette nevnes i Ally-3669.
Enkelte diagrammer er satt som bilder,noe som gjør det vanskelig for synshemmede brukere å forstå innholdet i diagrammet. Med VoiceOver vil den lese opp dette diagrammet som "Graf, ørret, bilde". Dette stemmer ikke overens med det diagrammet viser.
Denne lysbildefremvisningen har flere bilder som behøver bedre alternativ tekst. Alternativ teksten til dette bildet her er "Tilstand ved vannet i 1998", noe som ikke tilsvarer det seende brukere faktisk ser.
Løsningsforslag
- Det er viktig at alternativ teksten samsvarer med det visuelle brukere ser. Når det gjelder diagram kan det være vanskelig å gi en alternativ tekst, men da bør det være en tekst ved siden av diagrammet som oppsummerer hva diagrammet viser.
Sider vi henviser til
Feilmeldingene er ikke knyttet til svaralaternativene
ID:
Ally-3699
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere feilmeldinger på siden deres. Feilmeldingene som vises er ikke strukturert koblet sammen med svaralternativene.
Eksemplet kommer fra siden "I hvilken habitat hører artene hjemme". Hvis man svarer feil og trykker på "Svar", så vil ikke skjermleserbrukere få umiddelbart beskjed om at de har valgt feil.
Eksemplet nedenfor er fra siden "Øv to og to saman!". Når man svarer feil vil en feilmelding bli opplest for skjermleser, noe som er bra. Her er hjelpeteksten imidlertid på englesk, noe som ikke er helt korrekt. Les mer i Ally-3628.
Men fra samme side ser vi disse feilmeldingene som ikke blir opplest automatisk for skjermlesere.
Nedenfor er fra "Repitisjon: IMI-kategorier"-siden. Her er det feilmeldinger som ikke blir presenert automatisk for skjermleserbrukere.
Løsningsforslag
- Objektet som har en feil må også gjengi programmatisk at den har en feil. Feilmeldinger kan kobles ved å bruke aria-describedby på elementet og koble det sammen med ID på elementet som feilmeldingen er nestet i.
- For at feilmeldingen kun skal vises for skjermleserbrukere kan man legge til en sr-only.
Sider vi henviser til
Riktig feilmelding:
Mouseoverfunksjon er ikke mulig å nå med skjermleser i Radioaktivitet
ID:
Ally-3714
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
I Radioaktivitet kan man holde musepekeren over enkelte knapper, og her vil mer informasjon utvides. Skjermleserbrukere får ikke tilgang til denne informasjonen når knappen har fokus.
Dette gjelder ikke kun denne knappen, det er også flere knapper i øvelsen som har en mouseover.
Løsningsforslag
- Først og fremst er ikke disse knappene kodet som knapper (les mer i Ally-3671).
- Nedenfor lenker vi til et sted hvordan man kan lage tilgjengelige "tooltip".
https://accessibilityinsights.io/info-examples/web/aria-tooltip-name/
Sider vi henviser til
Matematiske uttrykk må tydeliggjøres for skjermlesere
ID:
Ally-3715
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere matematiske uttrykk på siden deres som er vanskelig å oppfatte med skjermleser. Det er ikke alltid skjermleser oppfatter hva de ulike matematiske uttrykene er.
Nedenfor er et annet eksempel fra "Parallellkoblinger", med skjermleser er det vanskelig å forstå dette matematiske uttryket.
Løsningsforslag
- Sørg for å sette en sr-only der man skriver hvordan de matematiske uttrykene sier. Slik at skjermleserbrukere også skal forstå hva de ulike uttrykene betyr.
Sider vi henviser til
Videoer behøver en tekstforklaring på hva innholdet i videoen er
ID:
Ally-3720
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere videoer som behøver en tekstforklaring på hva innholdet i videoer er. Dette er noe som er viktig for flere brukere, men spesielt for synshemmede brukere som bruker skjermlesere og brukere med kognitive vanskeligheter. Dette gjør det enklere for dem å forstå hensikten med videoen.
Eksemplet nedenfor fra "Teiknskriving" har kun et kinesisk tegn ovenfor videoen. Dette gjør det vanskelig for brukere å forstå hva innholdet til videoen er.
Eksemplet nedenfor fra "Kreativ bildebehandling" beskriver godt innholdet til videoen.
Løsningsforslag
- Sørg for at det finnes en forklaring for videoene, slik som vist i eksemplet ovenfor.
Sider vi henviser til
Uklare feilmeldinger i øvelsene
ID:
Ally-3730
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Øvelsene har ulike feilmeldinger. I "Øv to og to sammen" vises feilmeldingene som rødt kryss og for enkelte brukere kan det være forvirrende. Spesielt for de med kognitive vanskeligheter.
Ved å tillegg markere feilmeldingen med en teskbeskrivelse vil det sørge for at alle brukere forstå hva som har gått galt.
Siden "Oppsummering" markerer feilmeldingene med -1 i tillegg. Men en tekstbeskrivelse hadde vært mer tilstrekkelig.
Løsningsforslag
- Sørg for å gi en tekstlig forklaring på hva som gikk galt eller riktig. Som nevnt tidligere kan noen brukere synes det er vanskelig å forstå fargene og symbolene som indikerer hva som er riktig og galt. Derfor ønsker vi at dere presiserer dette ved å markere svaralterntivene som "riktig" eller "galt".
Sider vi henviser til
Skjemaeelementer trenger å grupperes i koden
ID:
Ally-3731
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Skjemaelementer som alternativknapper og radioknapper behøver å grupperes i koden. Ved å gruppere de programmatisk hjelper skjermleserbrukere med å forstå forholdet mellom radioknapper/inndatafelter og teksten ved siden av dem.
Nedenfor er noen eksempler på skjemaelementer som bør grupperes i koden, fra "Oppsummering"-siden.
Løsningsforlsag
- Grupper hele området med fieldset, og sørg for at alle skjemaelementene har sitt egent legen-element i fieldsettet.
- For radioknapper kan man neste role="radiogroup" rundt alle alternativknappene.
Sider vi henviser til
Enkelte øvelser krever at brukere skal se seg rundt
ID:
Ally-3742
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
For brukere som er synshemmet er det vanskelig å forstå beskrivelser som forteller dem å "se seg rundt". I Ally-3658 nevnes det en øvelse hvor brukere må se seg rundt i et rom.
Man har også bruk andre sensoriske beskrivelser som "oppe til høyre" og "nede til venstre", og det er godkjent.
I Ally-3678 er det også flere øvelser som nevnes hvor det er sensoriske beskrivelser.
Løsningsforslag
- Det er svært vanskelig for en synshemmede brukere å "se seg rundt i rommet" og lete etter objekter. Brukeren må få muligheten til å pilnavigere seg rundt rommet for å rotere kameraet slik at man kan "se" hele rommet. Deretter må skjermleserbrukere få en forklaring av objektene som har fokus.
https://ndla.no/subject:cc109c51-a083-413b-b497-7f80a0569a92/topic:6d046e59-6f9d-4947-b13b-8a337a12a0ee/topic:3480efc2-81b3-4fa2-aaf7-a331500c5298/resource:69b783b7-797f-41e4-b76f-e757fba99aad
Skjermstørrelsen tilpasser seg ikke layout
ID:
Ally-3744
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere av elementene på siden som justeres når skjermstørrelsen endres, men her er det visse elementer som kan by på utfordringer for brukere med små skjermer. Her vises ofte teksten over bilder, noe som resulterer i dårlig fargekontrastforhold mellom tekst og bakgrunn. Det er også flere knapper som er umulig å nå.
Nedenfor er skjermstørrelsen endret til 462px x 320px. Her er det vanskelig å trykke på enkelte knapper.
Løsningsforslag
- Sørg for at plattformen er responsivt og fungerer på tvers av flere skjermstrørrelser. Dette gjøres ved hjelp av MediaQueries i CSS.
Sider vi henviser til
Landemerket nav mangler
ID:
Ally-3745
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Før øyeblikket mangler <nav>-elementet. <nav> brukes for å definere en blokk med navigasjonslenker som menyer.
Brukere som er svaksynte og bruker skjermleser bruker ofte hurtigkommandoer for å navigere mellom landemerker, og her er dem avhengig at <nav> er der.
Nedenfor vises det hvordan navigasjonsmenyen er, og hvordan den er kodet som i koden.
Løsningsforslag
- Sørg for å ha <nav>.
Knapper som utvider informasjon bør kodes med aria-expanded
ID:
Ally-3552
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere knapper som mangler en aria-expanded. Dette attributtet forteller skjermleserbrukere om knapper kan utvides og minimeres.
Nedenfor er et eksempel fra "Podkastoppgave: Genteknologi –muligheter og trusler" hvor knappen "Tekstversjon" utvides.
Etter å ha utvidet informasjonen er det viktig at informasjonen leses opp etter man har aktivert knappen.
Det er også en knapp på siden "Familie - egenvurdering av gramatikkforståelse":
"Velg språk" og "Innhold"-knappene i navigasjonsmenyen behøver en aria-haspopup="true". Dette er fordi det er en dialogrute som komme fram når man aktiverer knappene.
Det er også enkelte faktabokser som utvider mer innhold som bør ha en aria-expanded.
Løsningforslag
- Sørg for å ha en aria-expanded="true" når knappen er utvidet, eller "false" når den er minimert. Dette gjør det lettere for skjermleserbrukere å forstå når et nytt område vises under knappen.
- Det er viktig at informasjonen blir lest opp direkte etter man har aktivert knappen. Dette gjøres ved å endre på rekkefølgen i HTML eller ved å sette fokus via JavaScript.
- Sørg for at "Velg språk" og "Innhold"-knappene har en aria-haspopup=true.
Sider vi henviser til
Dynamiske statusmeldinger gjengis ikke for hjelpemidler
ID:
Ally-3555
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere statusmeldinger som vises dynamisk på siden. Dette er statusmeldinger som også bør gjengis automatisk for skjermleserbrukere.
I eksemplet nedenfor endres antall gjenstående nøkkelord når man legger til et nøkkelord. Dette bør gjengis for skjermleserbrukere.
Siden "Øv to og to saman!" har også statusmeldinger som vises dynamisk på siden når har fått et resultat. Når man sjekker resultatet, vil antall riktige svar og en statusmelding vises, dette bør gjengis automatisk for skjermlesere. Brukere får også beskjed om de valgte ordene er riktig eller feil, dette bør også formidles for skjermleserbrukere.
Denne oppgaven forteller skjermleserbrukere hvordan de ligger an i quizen, mnen når de velger en påstand, forteller det dem ikke umiddelbart og den valgte påstanden er riktig eller feil. Dette bør formidles automatisk.
Denne lysbildefremvisningen fra "Feltarbeid"-siden forteller ikke umiddelbart til kjermleserbrukere umuddelbart om hva som inneholder i lysbildefremvisningen. Når brukeren navigere til neste side, bør alternativ teksten til bildet og statusmeldingen nedenfor bildet bli opplest.
Løsningsforslag
- Legg til aria-live="polite" rundt div-elementet med statusmeldingen slik at statusmeldingen leses automatisk etter at nøkkelordet er lagt til.
Sider vi henviser til
Ikoner med statusmeldinger bør forbedres for skjermleserbrukere
ID:
Ally-3561
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Når man fullfører en side i læringssti, vil et "sjekk av"-ikon vises som indikerer at man har fullført siden. Skjermleserbrukere får ikke opplest ikonet eller en indikasjon at siden er fullført. Som et resultat får skjermleserbrukere ikke den samme opplevelsen som visuelle brukere.
Løsningsforslag
- For øyeblikket har ikonene en aria-hidden="true". Dette betyr skjermlesere ikke vil lese ikonene. Dette attributtet må fjernes for at ikonene skal leses opp. Legg til en aria-label="Oppgave er fullført" når en oppgaveside er fullført for eksempel.
Sider vi henviser til
Innhold som er på et annet språk må markeres i koden
ID:
Ally-3570
Prioritet:
Medium
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere tekster som er på et annet språk enn norsk. For brukere som er svaksynte kan det oppstå forvirringer når en norsk skjermleser leser opp tekster på engelsk for eksempel.
Nedenfor er et eksempel fra en engelsk tekst.
Løsningsforslag
- For at skjermleseren skal skifte "språk", må det markeres i koden. Hvis det er en engelsk tekst må man markere teksten med lang="en", lang="en-US" eller lang="en-UK" for engelsk.
Sider vi henviser til
Main-elementet mangler - Løst
ID:
Ally-3746
Prioritet:
Medium
Status:
Løst
Beskrivelse og løsningsforslag:
For øyeblikket er ikke hovedinnholdet plassert i <main>-element. Skjermleserbrukere bruker ofte hurtigkommandoer mellom landemerker, og her er dem avhengig at <main> er der.
Nedenfor markeres det hvor hovedinnholdet er, som altså er under navigasjonsmenyen.
Løsningsforslag
- Sørg for å legge hovedinnholdet i <main>.
Prioritet: Lav
Dette er problem som bør korrigeres for å minimere risikoen for problemer hos brukerne.
En tabell er ikke kodet som tabell
ID:
Ally-3614
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
På siden "Familie – egenvurdering av grammatikkforståelse" har man mulighet til å skrive ne egne mål hvor resultatet vil bli presentert i en slags tabell. Denne tabellen er ikke kodet som en tabell, men den bør for at skjermleserbrukere skal forstå sammenhengen.
For øyebliket blir "Mål Vurdering" opplest først, deretter listen under mål og listen under vurdering. Derfor vil man ikke forstå sammenhengen mellom målene og vurderingene.
Løsningsforslag
- Sørg for å kode kolonneoverskriftene som <th scope>, og radene som <td scope>. Det er også viktig at alle tabellen har en overskriftt som er kodet som en h-tag eller caption. Nedenfor viser vi et eksempel hvordan en tabell kodes:
<table> <caption>Måloppnåelse</caption> <tr> <th scope="col">Mål</th> <th scope="col">Vurdering</th> </tr> <tr> <th scope="row">Bli bedre på lekser</th> <td>..vurderingsknappene..</td> </tr> <tr> <th scope="row">Bli bedre å rekke opp hånde</th> <td>vurderingsknappene</td> </tr> <tr> <th scope="row">Bli bedre å følge med</th> <td>vurderingsknappene</td> </tr> </table>
Sider vi henviser til
Dekorative bilder bør skjules for skjermleserbrukere
ID:
Ally-3632
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er enkelte ikoner som er dekrorative som ikke er nødvendig å få opplest for skjermleserbrukere. Dekorative bilder er bilder som er meningsløse, og å skjule dem for skjermleserbrukere unngår unødvendig opplesning for brukerne.
Følgende eksempel kommer fra "Hva tror du om miljøgifter?", hvor tommel opp og tommel ned ikonene blir lest opp som "thumb".
Løsningsforslag
- For å skjule dekorative bilder kan man enten legge til en tom alt-tag (alt="") eller aria-hidden="true".
Sider vi henviser til
Muskelappen har knapper som må kodes som faner
ID:
Ally-3659
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Muskelappen har knapper som bør kodes som faner (engelsk: tab) for å gjøre det enklere for skjermleser- og tastaturbrukere å navigere mellom disse knappene. Tastaturbrukere for muligheten til å pilnavigere mellom fanene, og skjermleserbrukere for opplest at dette er faner og antall faner som er i fanelisten.
Løsningsforslag
- Nest alle knappene i fanelisten i en role="tablist", for å hjelpe skjermleserbrukere å forstå at elementet fungerer som en beholder for ett sett med faner.
- Kod hvert enkelt knapp i fanelisten som role="tab".
- Bruk aria-selected som indikerer at fanen er aktivert når den er på true, og false når den ikke er aktivert.
- Informasjonen som er under hver fane må være kodet som div role="tabpanel", som indikerer at elementet fungerer som en beholder for innhold i fanepanelet. Deretter har en aria-labelledby, som referer til tab elementet som styrer panelet. Husk å oppgi et navn som er tilgjengelig for fanepanelet.
- Ha også en aria-controls som referer til elementet med role="tabpanel", det vil si området som vises.
- Nedenfor lenker vi til en side man kan ta inspirasjon fra:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role
Sider vi henviser til
Enkelte knapper har dårlig fargekontrastforhold
ID:
Ally-3685
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
"Åtteregelen"-siden han en ovelse hvor brukere får beskjed om å studere en figur og finne ut hvilken trend verdiene følger. Her kan man dra opp "gardina" og se hva systemer er.
"Hardina"-knappen har for tiden et dårlig fargekontrastforhold på 1,1:1. Dette betyr at flere brukere vil få vanskeligheter med å se at det er en "gardin"-knapp de kan trykke på for å dra.
Disse knappene som indikerer antall sider i en lysbildefremvisning får en fargekontrastforhold på 1,6:1.
Løsningsforslag
- Sørg for at fargekontrastforholdet mellom knappen og bakgrunnen er på minst 3,0:1.
Sider vi henviser til
Enkelte knapper får ikke tydelig fokusmarkering
ID:
Ally-3686
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Tastaturbrukere bruker ofte tabulatortasten for å navigere mellom interaktive elementer som knapper og lenker. Hvis interakive objekter ikke har en tydelig fokusmarkering, er det vanskelig for disse brukerne å se hvor de er på siden. Derfor er disse brukerne avhengige av å ha fokusmarkeringer på alle interkative objekter og et fargekontrastforholdet på minst 4,5:1 mellom fokusmarkeringen og bakgrunnen.
Eksemplet nedenfor kommer fra "Åtteregelen" der brukere får beskjed om å trykke på "gardin"-knappen. Denne knappen får ikke en visuell fokusmarkering.
Løsningsforslag
- Sørg for at de tfinnes en tydelig fokusmarkering, og at fargekontrastforholdet mellom fokusmarkerkingen og bakgrunnen er på minst 4,5:1.
Sider vi henviser til
Diagram har dårlig fargekontrast på søyler
ID:
Ally-3687
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Siden "Hydrogenbindinger" har diagrammer som har får dårlig fargekontrastforhold mellom søylene og bakgrunnen. For enkelte brukere vil det være vanskelig å skille mellom fargene, men vi ser at dere har tydelig skrevet hvilket stoff som tilhører hvilken søyle.
Nedenfor får den blå søylen fargekontratsforhold på 1,4:1, den rosa på 1,7:1 og gul på 1,1:1.
Løsningsforslag
- Sørg for at fargekontrastforholdet er på minst 3,0:1.
Sider vi henviser til
Unngå å bruke aria-label på div-elementer
ID:
Ally-3750
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
For øyeblikket brukes aria-label på div-elementer. Div-elementer er et element uten semantikk, som ikke fungerer ikke bra med WAI-ARIA attributtet aria-label. Aria-label fungerer bare på utvalgte semantiske elementer som knapper og lenker for eksempl. Når det brukes på et div-element, kan det forarsåke at det ikke fungerer i tvers av alle nettlesere og hjelpeteknologier som skjermlesere.
Nedenfor er et kodeutstnitt fra "Vårt verdensbilde" hvor aria-label har blitt lagt til et div-element:
Løsningforslag
- Nedenfor lenker vi til hvilket elementer som kan ha aria-label:
https://www.tpgi.com/short-note-on-aria-label-aria-labelledby-and-aria-describedby/
Sider vi henviser til
Ingen funksjon for å lese undertekster
ID:
Ally-3752
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Muligheten til å få undertekster opplest i videoene deres er veldig nyttig for døvblinde brukere. Det er for øyeblikket ingen alternativ på videospillere på siden.
I og med dette påvirker en liten gruppe brukere, prioriterer vi dette problemet lavt i denne analysen.
Les mer om lydtekst her:
https://info.nrk.no/tilgjengelighet/?/hvordan-finner-en-lydtekst#lydtekst
Løsningsforslag
- Sørg for at videospillerne har funksjonen til å kunne lese undertekster. Noen gode eksempler på videospillere som har denne funksjonen er "AblePlayer".
EN 301 549:
7.1.5
Aceit:
U207
Glidebryter bør forbedres for skjermleserbrukere
ID:
Ally-3554
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Hvis man justerer glidebryteren i denne tidslinjen, vil skjermleserbrukere få beskjed om et tall som ikke gjenspeiler antall minutter man er inne i podcasten.
Hvis man for eksempel setter glidebryteren til tidpsunktet 4:59, vil skjermleserbrukere få opplest "21", noe som kan skape forvirringer.
Siden "Feltarbeid" har også en glidebryter. På bildet nedenfor kan man visuelt se at lysbildefremvisningen viser året 2010, men når glidebryteren navigerer til dette årstallet vil skjermleserbrukere få opplest året 2008. Dette problemet oppstår gjennom denne lysbildefremvisningen.
Løsningforslag
- Sørg for at glidebryteren er koblet til den valgte tiden. Glidebryteren behøver også en hjelptekst (aria-label) som forteller for eksempel "Tidspunkt valgt er 4:59 minutter".
Sider vi henviser til
Tabeller er ikke kodet riktig med kolonne- og/eller radoverskrifter
ID:
Ally-3572
Prioritet:
Lav
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er flere tabeller som mangler attributtet scope. Attributtet scope er det som forteller til skjermlesere hvis overskriften er en kolonneoverskrift eller radoverskrift.
Denne tabellen fra "Å skrive en fagartikkel" mangler også disse attributtene:
Løsningforslag
-
For at dette skal være riktig, må de kodes som et th element og med attributet scope som enter peker på rad (="row") eller kolonne (="col").
Sider vi henviser til
Prioritet: Anbefaling
Dette er anbefalinger for ytterligere å forbedre universell utforming og brukeropplevelse i grensesnittet.
Knapper behøver en synlig label (etikett)
ID:
Ally-3751
Prioritet:
Anbefaling
Status:
Åpen
Beskrivelse og løsningsforslag:
Det er en rekke knapper med ikoner som ikke har en synlig label (etikett på norsk). Det kan være vanskelig for brukere med kognitive vansker å forstå hva disse knappene fører til. Det samme gjelder brukere som er nye på siden.
I eksemplet nedenfor viser vi en knapp med ikon med en synlig label:
Punktet er satt som anbefaling fordi dette er ikke et avvik, men noe vi anbefaler får å øke brukervennligheten.
Løsningsforslag
- Sørg for at alle knapper som er kodet med ikoner har en synlig label som vist i eksempelet ovenfor.
Sider vi henviser til
https://ndla.no/en/subject:cc109c51-a083-413b-b497-7f80a0569a92/topic:6d046e59-6f9d-4947-b13b-8a337a12a0ee/topic:3480efc2-81b3-4fa2-aaf7-a331500c5298/resource:69b783b7-797f-41e4-b76f-e757fba99aad
https://ndla.no/nb/subject:1:83ce68bc-19c9-4f2b-8dba-caf401428f21/topic:1:222a5d54-6f39-45bd-afc7-a234be9a7d15/topic:1:b222361d-5af6-447d-952f-86208af712e7/resource:7e0a4b8b-a952-4d08-894d-dea29002a630
https://ndla.no/nb/subject:1:fb6ad516-0108-4059-acc3-3c5f13f49368/topic:1:860e0dc0-7691-4b90-ba3b-8a00c39c9448/topic:1:6422199b-cd4c-4728-8560-e357482c14d2/resource:d131b97f-4925-4da1-8cfa-99d4bed4b6b4
Hopp over læringssti bør finnes
ID:
Ally-3567
Prioritet:
Anbefaling
Status:
Åpen
Beskrivelse og løsningsforslag:
Dette er ikke et avvik fra WCAG, men kun en anbefaling vi ønsker å komme med.
For å unngå å gå igjennom hver læringssti etter man har valgt en side bør en "Hopp over læringssti" finnes. Dette gjør at skjermleserbrukere ikke behøver å navigere gjennom denne læringsstien som fører til at brukeropplevelsen blir bedre.
Sider vi henviser til
Om sorteringen
Problembeskrivelsene er sortert i henhold til kravene i WCAG og EN 301 549. Kun retningslinjer der det finnes problembeskrivelser vises.
Først er krav fra WCAG (nivå A og AA) listet opp, de er også en del av EN-standarden og finnes i kapittel 9, 10 og 11. Krav 1.3.1 i WCAG finnes dermed som 9.1.3.1 , 10.1.3.1 og 11.1.3.1 i EN 301 549.
Etter at kravene i WCAG følger krav i EN 301 549 som ikke er en del av WCAG, inkluderer dette for eksempel noen krav i kapittel 5 og 11. Kun krav der det er problembeskrivelser vises.
I dag er det kun WCAG som er påkrevd for nettgrensesnitt i Norge. Imidlertid gjelder alle kravene, bortsett fra kravet om teksting av live video, i Sverige og EU.
1.1.1 Non-text Content
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.2.1 Audio-only and Video-only (Prerecorded)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.2.2 Captions (Prerecorded)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.2.3 Audio Description or Media Alternative (Prerecorded)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.2.4 Captions (Live)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.2.5 Audio Description (Prerecorded)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.3.1 Info and Relationships
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.3.2 Meaningful Sequence
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.3.3 Sensory Characteristics
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.3.4 Orientation
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.3.5 Identify Input Purpose
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.1 Use of Color
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.2 Audio Control
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.3 Contrast (Minimum)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.4 Resize text
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.5 Images of Text
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
1.4.10 Reflow
EN 301 549
Vi har ikke sett noen problemer her.
1.4.11 Non-text Contrast
EN 301 549
Vi har ikke sett noen problemer her.
1.4.12 Text Spacing
EN 301 549
Vi har ikke sett noen problemer her.
1.4.13 Content on Hover or Focus
EN 301 549
Vi har ikke sett noen problemer her.
2.1.1 Keyboard
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.1.2 No Keyboard Trap
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.1.4 Character Key Shortcuts
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.2.1 Timing Adjustable
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.2.2 Pause, Stop, Hide
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.3.1 Three Flashes or Below Threshold
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.1 Bypass Blocks
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.2 Page Titled
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.3 Focus Order
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.4 Link Purpose (In Context)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.5 Multiple Ways
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.6 Headings and Labels
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.7 Focus Visible
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.4.11 Focus Not Obscured (Minimum) (WCAG 2.2)
EN 301 549
Vi har ikke sett noen problemer her.
2.5.1 Pointer Gestures
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.5.2 Pointer Cancellation
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.5.3 Label in Name
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.5.4 Motion Actuation
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.5.7 Dragging Movements (WCAG 2.2)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
2.5.8 Target Size (Minimum) (WCAG 2.2)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.1.1 Language of Page
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.1.2 Language of Parts
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.2.1 On Focus
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.2.2 On Input
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.2.3 Consistent Navigation
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.2.4 Consistent Identification
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.2.6 Consistent Help (WCAG 2.2)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.1 Error Identification
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.2 Labels or Instructions
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.3 Error Suggestion
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.4 Error Prevention (Legal, Financial, Data)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.7 Redundant Entry (WCAG 2.2)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
3.3.8 Accessible Authentication (Minimum) (WCAG 2.2)
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
4.1.1 Parsing
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
4.1.2 Name, Role, Value
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
4.1.3 Status Messages
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
5.2 Activation of accessibility features
EN 301 549
Vi har ikke sett noen problemer her.
5.3 Biometrics
EN 301 549
Vi har ikke sett noen problemer her.
5.4 Preservation of accessibility information during conversion
EN 301 549
Vi har ikke sett noen problemer her.
6.1 Audio bandwidth for speech
EN 301 549
Vi har ikke sett noen problemer her.
6.5.2 Resolution
EN 301 549
Vi har ikke sett noen problemer her.
6.5.3 Frame rate
EN 301 549
Vi har ikke sett noen problemer her.
6.2.1 RTT provision
EN 301 549
Vi har ikke sett noen problemer her.
6.2.2 Display of RTT
EN 301 549
Vi har ikke sett noen problemer her.
6.2.4 RTT responsiveness
EN 301 549
Vi har ikke sett noen problemer her.
7.1.5 Spoken subtitles
EN 301 549
Vi har ikke sett noen problemer her.
11.6.2 No disruption of accessibility features (apps only)
EN 301 549
Vi har ikke sett noen problemer her.
11.7 User preferences
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
11.8.2 Accessible content creation
EN 301 549
Vi har ikke sett noen problemer her.
11.8.3 Preservation of accessibility information in transformations
EN 301 549
Vi har ikke sett noen problemer her.
11.8.4 Repair assistance
EN 301 549
Vi har ikke sett noen problemer her.
12.1.1 Accessibility and compatibility features (Product documentation)
EN 301 549
Vi har ikke sett noen problemer her.
12.1.2 Accessible documentation (Product documentation)
EN 301 549
Vi har ikke sett noen problemer her.
12.2.2 Information on accessibility and compatibility features (Support services)
EN 301 549
Vi har ikke sett noen problemer her.
12.2.3 Effective communication (Support services)
EN 301 549
Vi har ikke sett noen problemer her.
12.2.4 Accessible documentation (Support services)
EN 301 549
Vi har ikke sett noen problemer her.
Knyttet til standardene, men ikke til en bestemt retningslinje
WCAG & EN 301 549
Vi har ikke sett noen problemer her.
Utover WCAG 2.1 (AA), WCAG 2.2 (AA) og EN 301 549
Vi har ikke sett noen problemer her.
Om sorteringen
Problembeskrivelsene er sortert etter brukergrupper som er berørt av problemet. Gruppene er hentet fra kapittel 4 i EN 301 549. Nedenfor vises kun grupper der det er problembeskrivelser som påvirker gruppen. Nederst er problembeskrivelser som ikke er knyttet til noen gruppe. Husk at problemer kan påvirke flere enn brukergruppene som er knyttet til problemet. Husk også at ikke alle brukere som opplever vanskeligheter nødvendigvis identifiserer seg med en bestemt gruppe nedenfor.
Problemer for brukere som ikke kan se
Vi har ikke sett noen problemer her.
Problemer for brukere med begrenset syn
Vi har ikke sett noen problemer her.
Problemer for brukere uten fargesyn
Vi har ikke sett noen problemer her.
Problemer for brukere uten hørsel
Vi har ikke sett noen problemer her.
Problemer for brukere med nedsatt hørsel
Vi har ikke sett noen problemer her.
Problemer for brukere uten taleevne
Vi har ikke sett noen problemer her.
Problemer for brukere med nedsatt bevegelsesevne eller styrke
Vi har ikke sett noen problemer her.
Problemer for brukere med begrenset rekkevidde
Vi har ikke sett noen problemer her.
Problemer som rammer de som er sensitive for lysfølsomhet
Vi har ikke sett noen problemer her.
Problemer for brukere med nedsatt kognisjon
Vi har ikke sett noen problemer her.
Problemer som påvirker personvernet
Vi har ikke sett noen problemer her.
Ikke knyttet til noen spesifikk brukersituasjon
Vi har ikke sett noen problemer her.
-