Tilgjengelighetserklæring for Oppgjør med Helfo

I diagrammet vil skjermleseren kun fortelle "bilde", noe som ikke gir en betydning for skjermleserbrukere. Diagrammet er kodet som en canvas, og det er heller ikke mulig å gå inn i diagrammet og få søylene lest. 
Synshemmede får ikke tilgang til informasjon i diagrammet.

• Her bør skjermleserbrukere få en tilgjengelig beskrivelse på dette diagrammet, slik at de får likeverdig informasjon som seende brukere. 
• Det som ligger i Canvas er ikke en naturlig del av DOM strukturen i koden. For ikke kompleks innhold, er det ikke noen utfordringer å bruke Canvas. Her kan man da bruke role="img" og gi tekstbeskrivelse ved hjelp av aria-label.
  Ved kompleks innhold må man skape et backup innhold. Når det er interaktivitet er det utfordrende å få tilgjengelig og det er noe som sjeldent anbefales. I slike tilfeller er det bedre å bruke SVG, da det er enklere å lage interaktivitet med Javascript. 
  Les mer om dette på https://pauljadam.com/demos/canvas.html 
• Et annet alternativ er å legge til en tabell sammen med diagrammet, som skjermleserbrukere kan få opplest, noe som mangler per nå.  

Det er eksempler på at
- overskrifter ikke er korrekt kodet som overskrifter.
- enkelte overskrifter ligger på samme nivå programmatisk, men som visuelt tyder på en hierarkisk rekkefølge.
- tabeller er i hovedsak kodet riktig med th og td elementer (noen mangler th element), men mangler riktig attribut for å spesifisere hvilken retning overskriften har. 
- avkrysningsbokser er i enkelte tilfeller kodet inne i tabeller
- tabelloverskrifter som beskriver innholdet i tabellen mangler (må komme rett over tabellen).   
- flere skjemaobjekter er gruppert sammen, men er ikke programmatisk gruppert i koden.

Gjør det vanskeligere for skjermleserbrukere å navigere seg på sidene, siden de ikke får brukt hurtigkommandoer til å navigere til forskjellige overskrifter.

Det er videre flere feilmeldinger som ikke er knyttet til inputfeltet, noe som fører til at skjermleserbrukere ikke får umiddelbart informasjon om dette. 

- Forsikre at overskriftet er kodet programmatisk med h-tag, og sørge for at overskrifter havner i riktige nivåer. 

- alle kolonnoverskrifter må kodes med th-elementet. I tillegg må det ha attributet scope som enter peker på rad (="row") eller kolonne (="col").

- En tabell som visuelt ikke ser ut som en tabell, bør ikke kodes som en tabell. 

- Ha tabelloverskrift direkte over tabellene. Her må overskriftene være kodet i en h-tag, eller <caption>

- Sørg for å ha WAI-ARIA attributtet aria-describedby på inputfeltet og koble det sammen med id på elementet hvor feilmeldingen ligger.

- Grupper hele området med fieldset, og sørg for at alle skjemaobjektene har sitt eget legend-element i fieldsettet. 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fieldset

- En rød ramme dukker opp dersom man kopierer en ny regning med tomme elementer i de obligatoriske feltene. Feilmeldingen formidles av en rød ramme, noe som både gjør det vanskelig å forstå for svaksynte brukere, men også for de med kognitive vansker.  

- Det benyttes lenker som kun skiller seg ut med farger, noe som gjør det vanskelige for svaksynte brukere å skille mellom lenketekst og vanlig brødtekst.

- Sørg for at feilmeldingen blir beskrevet i tekst. Dette kan for eksempel være en tekst ved siden av som forteller at det er obligatoriske felt som må fylles ut. 

- For å skille denne lenken fra vanlig brødtekst kan man blant annet legge en understrek under lenken, eller et ikon.

Enkelte knapper har har ikke tilstrekkelig kontrast mellom fokusmarkering og nærliggende farger på interaktive objekt. For brukere som er svaksynte er det viktig at fokusmarkeringen har en tilstrekkelig kontrast. 

Øke kontrasten til å være på minst 3,0:1. 

Det er flere knapper som ikke har tilstrekkelig kontrast mellom fokusmarkering og nærliggende farger på interaktive objekt.

For brukere som er svaksynte er det viktig at fokusmarkeringen har en tilstrekkelig kontrast. 

Justere slik at det blir tilstrekkelig kontrast

Det er enkelte informasjonsknapper som utvider informasjon når mus eller tastatur får fokus på den.

Med skjermleser vil den ikke lese opp innholdet i boksen, noe som gjør at de ikke får tilgang til samme informasjon. 

• For ikke komplekst innhold kan Canvas gjøres enkelt tilgjengelig. For kompleks innhold med interaktivitet, er Canvas sjeldent anbefalt. Dette på grunn av at det er ekstremt utfordrende å få det til å fungere bra. Her anbefales det heller å bruke SVG, som på en enklere måte kan legge til interaktivitet tilegjengelig med Javascript. 
• For å kode "tooltip" riktig, følg våres anbefalinger i U210 og Ally-2560. 

Det benyttes mange skjemaobjekter. I innmatningsfeltene dukker en feilmelding opp dersom man skriver noe feil. For brukere som har kognitive vansker, kan det være vanskelig å forstå hva dem har gjort feil der feilmeldingene ikke er godt noen beskrevet. 

Sørg for å hjelpe brukeren med å spesifisere hva som har gått galt. I dette tilfellet kan et et alternativ er å skrive ut formatet som trengs for at informasjonen som fylles ut skal være gyldig. 

WAI-ARIA attributtet aria-label er brukt på et span-element (her datofeltene). Dette fører det til at den blir lest opp som gruppert, noe som kan skape forvirringer for skjermleserbrukere.

- Dersom dere skal bruke WAI-ARIA attributt til å gruppere elementer, forsikre at dere bruker riktige roller. Ved radioknapper, bør det være role="radiogroup", fulgt av role="radio" og aria-checked="true"/"false". Ved avkryssningsbokser, bør det helst være role="group" , fulgt av role="checkbox" og aria-checked="true"/"false". 

- Sørg for å fjerne aria-label på span-elementet for å unngå problemer med hjelpeteknologier.

- I tilfeller hvor det finnes en løsning i HTML-kode, bør denne alltid brukes i første omgang i steden for å bruke WAI-ARIA. 

I "Manuell registrering" er søkefunksjonen til "Diagnoser" og "Takster" vanskelig å forstå hvordan fungerer for skjermleserbrukere, og hvordan de legger til et søkeforslag.

• søkeforslagslisten ikke blir formidlet for skjermlesere. 
• det er vanskelig for skjermleserbrukere å forstå at de må gå inn i et nytt område for å klikke på "Legg til"-knappen. Det er også mulig å tabbe seg inn i området etter man har klikket på et søkeforslag, men dette er ikke noe skjermleserbrukere får beskjed om.

Enkelte tabeller i "Oppgjør med Helfo" trenger forbedringer.

- kolonneoverskriften "Lastet opp" blir lest opptil tre ganger. 
- Når man navigerer til radene under en kolonneoverskrift, leses også aria-label teksten
- kolonneoverskriften er beskrevet som "Filter by", noe snarere er en ledetekst knyttet til Alle praksiser. 
- kolonnen "Alle statuser" ikke samsvarer med radene under
 

I "Registrer praksis" er det lagt til en  aria-label="Velg ukeday-key" for alle ukedagene, noe som gjør det forvirrende for skjermleserbrukere å forstå hva "key" er for noe og vanskelig å si om man har vaglt "alle", "mandag", "tirsdag" og så videre.

Informasjonsknapper:
Benytter informasjonsknapper som utvides for å vise mer informasjon. 
- Disse blir per i dag lest opp som kun "bilde" av skjermleser. Dette er fordi de er kodet med en role="img".
- informasjonsknappen er koblet sammen med overskrifter. 
 

Knapper:
- to knapper i "Oppgjør med Helfo" som bør indikere for skjermleserbrukere om de er valgt eller ikke. 
- flere knapper som bør kodes som faner (role="tablist") i Oppgjør med Helfo
- enkelte knapper trenger bedre beskrivelser for skjermleserbrukere

- Søkefunksjonen i Manuell registrering er en veldig komplisert funksjon, fremfor alt for skjermleserbrukere. Her må man sikre at fokuset havner i riktig område etter at brukeren valgt et av søkeforslagene i listen. Utfordringen her blir imidlertid hvordan brukeren enkelt skal komme tilbake til neste søkeforslag listen. For søkefunksjon knyttet til takster, anbefaler vi å gi en beskrivelse på hvordan søkefunksjonen kan håndteres med tastatur og skjermleser. For søkefunksjonen knyttet til diagnoser, kan brukeren velge diagnose ved å trykke på Enter tasten i listen. For å sikre at skjermleserbrukere får beskrivelse av fortkortelsen, kan man for eksempel kopple beskrivelsen ved hjelp av aria-describedby på elementet i listen og id på elementet som beskrivelsen ligger i.  

Oppgjør med Helfo:

- Vi ser at det kan være vanskelig for skjermleserbrukere å forstå sammenhengen når "Filter by" blir kolonneoverskriftene for radene over praksis. Derfor kan man lage en kolonneoverskrift som sier "Praksis" som kun er tilgjengelig for skjermleserbrukere. Dette kan gjøres ved å bruke sr-only.
- Skjul ledetekstene (Filter by, Last ned...) fra skjermleser ved å bruke aria-hidden="true". For å sikre at de blir opplest i tilknytning til dropdown-listene, koble de sammen med aria-labelledby og id på elementet som ledeteksten ligger i. 
- Fjern aria-label, og bruk heller WAI-ARIA attributtet aria-sort="ascending". Ved å bruke Jacascript, kan man endre verdiet dersom brukeren ønsker å sortere synkende eller stigende.
- Sørg også får å kode disse kolonnene som <button>

De fleste har skjermleseren sin på norsk, og derfor blir det forvirrende når en norsk stemme skal lese opp engelske ord. Derfor bør teksten være på det språket som stemmer overens med det hovedsakelige språket på siden. 

Informasjonsknapper:

• Sørg for å ha en role="tooltip" istedenfor role="img", nedenfor lenker vi til en side man kan inspirasjon fra.
  https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/t…
• Tooltipen bør ikke være inne i overskrifter, dette for at skjermleserbrukere ikke skal få mye unødvendig opplesning. 

Knapper:
- Sørg for å kode disse som aria-pressed="true" når den er markert, eller "false" når den ikke er markert.
- Bruk en div role="tablist" på det som nester rundt knappene, dette for å indikere brukerne at elementet fungerer som en beholder for et sett med faner.
- Kod knappene som en <button role=tab>. Dette indikerer at elementet fungerer som en tabulatorkontroll.
- Bruk en aria-selected på knappene. Dette indikerer at fanen er aktivert når det 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.

"Manuell registrering":
- sidevisningene endres når man går til neste/forrige side, og dette bør leses automatisk for skjermlesere når man går til en annen side, slik at skjermleserbrukere automatisk får likeverdig informasjonen som seende brukere. 
- statusmelding som dukker opp etter man har registrert en regning bør leses automatisk for skjermleserbrukere, slik at de får beskjed om at regningen har blitt registrert. 
- Dersom man sletter en regning, gis ikke en tilbakemelding, dette er noe vi anbefaler å få både for seende brukere og ikke-seende brukere.
- Når man trykker på pluss- og minus-knapper vil antallet i inputfeltet endre seg. Denne informasjonen blir ikke gjengitt for skjermlesere.

Ettersom statusmeldingene dukker opp dynamisk, kan man bruke WAI-ARIA attributtet aria-live="polite" sammen med aria-atomic="true" på div-elementet. Et annet alternativ er å flytte fokus manuelt til teksten som sier statusmeldingen. 
https://www.digitala11y.com/aria-atomic-properties