Tilgjengelighetserklæring for Senja Avfall digitalt adgangsbevis app (Android)

Kriterium:
Hvis ikke-tekstlig innhold er en kontroll eller tar imot brukerinndata, må det ha et navn som beskriver formålet.

Begrunnelse:
Kriteriet er ikke oppfylt enkelte steder ved bruk av talehjelpemidler (VoiceOver/TalkBack). Eksempler inkluderer:

- Knappen for profilikonet mitt leses opp som «Bilde, person». Den bør i stedet leses opp som «knapp, min profil». Det samme gjelder ikonet for å legge til eiendom («+») i topplinjen.
- Indikatorene for gjenværende og tildelt kvote annonseres som en prosentvis fylling av statuslinjen, uten kontekst eller gyldig enhet.

Neste steg:
Sørg for at ikke-tekstlige knapper og indikatorer beskriver formålet sitt ved bruk av VoiceOver.

Kriterium:
Informasjon, struktur og relasjoner som formidles gjennom presentasjonen, kan bestemmes programmatisk eller er tilgjengelig i tekst.

Begrunnelse:
Kriteriet er ikke oppfylt flere steder i applikasjonen ved bruk av talehjelpemidler (VoiceOver/TalkBack). Eksempler inkluderer:

- Oppsett av tømmekalender: kommuneikoner annonseres som bilder; kommune- og adresserader er ikke klikkbare eller gruppert med «Velg»-knappen.
- Varsler om tømming: av/på-bryter annonseres uten kontekst og er ikke gruppert med etiketten sin; varslingstidspunktet tolkes som et tall i stedet for et klokkeslett.
- Neste tømmedato og fraksjoner er ikke gruppert i ett samlet, logisk element.
- Åpningstider: radene bør grupperes i logiske elementer; klokkeslett bør leses opp som tid, ikke bare som tall.
- Skjema: skjematyper bør merkes som knapper; radioknapper og knappen for bildeleser i skjemaet bør merkes semantisk.
- Rader i eiendomsvelgeren er ikke merket som klikkbare.
- Skjermbildet for alle transaksjoner: radelementer er ikke gruppert; datoer leses opp som tall på iOS.
- Statusmerket for delingskode annonseres som en inaktiv knapp.
- Å bruke Rotor-verktøyet for å navigere gjennom appens innhold via overskrifter fungerer ikke fordi seksjonene ikke er semantisk spesifisert.
- Listeelementer angir ikke sin indeks og rolle (4.1.2). De er heller ikke gruppert sammen som en seksjon.
- På siden for redigering av profilinformasjon leser ikke VoiceOver opp etikettene til tekstfeltene etter at et felt er trykket på.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Legg til manglende overskriftssemantikk.
3. Grupper listeelementer med felles semantikk som annonserer formål og antall.
4. Slå sammen semantikken til tekstfelt med etikettene deres, slik at feltkonteksten alltid er tilgjengelig for brukeren.
5. Test mot kriteriet.
 a) Bruk rotor-/overskriftsnavigasjon for å bekrefte at overskrifter blir funnet.
 b) Sjekk at lister annonserer «liste, X elementer».
 c) Sjekk at skjemaetiketter annonseres sammen med feltene.
 d) Bekreft at gruppert innhold annonserer gruppenavnet.

Delvis oppfylt

Kriterium:
Når rekkefølgen innholdet presenteres i påvirker betydningen, kan en korrekt leserekkefølge bestemmes programmatisk.

Begrunnelse:
Leserekkefølgen opprettholdes i de aller fleste deler av appen, men det finnes mindre mangler, for eksempel:
- på kontaktskjermen leses begge titlene opp først – telefonnummer, e-post – og først deretter verdiene deres.

Neste steg:
1. Rett opp leserekkefølgen på «Kontakt oss»-skjermen.
2. Test rekkefølgen på nytt etter andre rettinger (f.eks. semantiske rettinger og gruppering, som beskrevet over).

Kriterium:
Innholdet begrenser ikke visning og betjening til én bestemt skjermorientering, som stående eller liggende format, med mindre en bestemt orientering er essensiell.

Begrunnelse:
Appen har låst stående format. Dette kan ikke endres, og kriteriet er derfor ikke oppfylt.

1. Vi anbefaler at appen ikke tilpasses dette kravet. Liggende format på telefonen ville krevd en redesign av grensesnittet. Man kan formelt vise til kriteriet om uforholdsmessig stor byrde her.

Delvis oppfylt

Kriterium:
Formålet med hvert inndatafelt som samler inn informasjon om brukeren, kan bestemmes programmatisk når:
   - Inndatafeltet tjener et formål identifisert i seksjonen om inndataformål for brukergrensesnittkomponenter;
   - Innholdet er implementert med teknologier som støtter identifisering av forventet betydning for skjemadata.

Begrunnelse:
Appen støtter identifisering av inndataformål ved å vise ulike tastaturoppsett for ulike tekstfelt. For eksempel inneholder tastaturet som åpnes når man trykker på e-postfeltet, @-tegnet nær mellomromstasten. Tastaturet som åpnes når man trykker på telefonfeltet, viser kun tall og enkelte tilleggstegn.

Appen støtter ikke autoutfylling for kontaktdata. Brukere må skrive inn navn, e-postadresse og telefonnummer manuelt, noe som kan være vanskeligere for enkelte brukere.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Bruk AutofillGroup i deler av applikasjonen som ber om gjentakende data fra brukeren.

Kriterium:
Bortsett fra teksting og bilder av tekst, kan tekst skaleres opp til 200 prosent uten hjelpemiddelteknologi, uten tap av innhold eller funksjonalitet.

Begrunnelse:
Appen støtter for øyeblikket tekstskalering på maksimalt 120 prosent, noe som er langt under de påkrevde 200 prosentene.

Vi har også identifisert områder der grensesnittet kunne vært forbedret for å bedre støtte større skrift på de minste skjermene, for eksempel:
- teksten på flisene på hjemmeskjermen og knappene i bunnlinjen kan brytes, slik at flisene får ujevn høyde
- linjene med skjemanavn får kanskje ikke plass
- instruksjonene under QR-koden kan bli beskåret utenfor skjermen
- kontakt-e-posten kan brytes og bli beskåret
- skriftstørrelsen for beboerens e-post kan være for liten

Neste steg:
1. Rett opp de identifiserte problemene.
2. Analyser funksjonaliteten til applikasjonen etter at teksten er skalert til to hundre prosent. Sjekk hvilke komponenter som vises korrekt, hvilke som krever mindre endringer, og hvilke som bør redesignes.
3. Basert på analysen, avgjør om skaleringsgrensen bør økes ytterligere, eller om det trengs andre justeringer av grensesnittet.

Delvis oppfylt

Kriterium:
Innhold kan presenteres uten tap av informasjon eller funksjonalitet, og uten behov for todimensjonal rulling for:

   Vertikalt rullende innhold ved en bredde tilsvarende 320 CSS-piksler;
   Horisontalt rullende innhold ved en høyde tilsvarende 256 CSS-piksler.

Unntatt deler av innholdet som krever et todimensjonalt oppsett for bruk eller mening.

Begrunnelse:

Appen fungerer fint på en enhet med 320 px bredde. Brukervennligheten på en enhet med en høyde på 256 piksler er derimot sterkt begrenset. Topplinjen og bunnnavigasjonen skaleres ikke riktig og dekker nesten hele skjermen.

Neste steg:
1. Vi anbefaler at appen ikke tilpasses dette kravet. Mobilenheter med skjermer på 256 pikslers høyde finnes praktisk talt ikke. Å tilpasse grensesnittet til en så ekstrem situasjon ville krevd en redesign av grensesnittet. Man kan formelt vise til kriteriet om uforholdsmessig stor byrde her.

Kriterium:
All funksjonalitet i innholdet kan betjenes gjennom et tastaturgrensesnitt uten krav om spesifikk timing for enkelttastetrykk, unntatt der den underliggende funksjonen krever inndata som avhenger av banen til brukerens bevegelse og ikke bare endepunktene.

Begrunnelse:
Tastaturnavigasjon i appen er begrenset. Eksempler inkluderer:
  - Det er mulig å velge og navigere med fanene i bunnnavigasjonen, men elementene utheves ikke.
  - Navigasjon mellom tekstfelt på siden for redigering av profilinformasjon er mulig med tab-tasten. Pilnavigasjon fokuserer kun på tekstfeltet for telefonnummer.
  - Sider med kun HTML/tekst kan ikke rulles med tastaturet.

«Tastatur»-kriteriet bør imidlertid også tolkes som «sveip til neste element»-funksjonen i skjermlesere som VoiceOver og TalkBack. I denne sammenhengen er det enkelte problemer:
- Under innlogging kan ikke brukeren navigere til personvernerklæringen og godta-knappen med hjelpemiddelteknologi med mindre man trykker på en innholdstekst og deretter sveiper den. Et lignende problem oppstår på skjermbildet for åpningstider.
- På iOS kreves 2 sveip for å navigere gjennom hjemkortene.
- På prissiden uthever skjermlesere også tomme linjer.
 

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Bruk Semantics og Focus- eller FocusNode-klassene til å rette opp feilene som er funnet.
 

Kriterium:
Formålet med hver lenke kan bestemmes ut fra lenketeksten alene, eller fra lenketeksten sammen med den programmatisk bestemte lenkekonteksten, unntatt der formålet med lenken ville vært tvetydig for brukere generelt.

Begrunnelse:
Det er enkelte steder i applikasjonen hvor kriteriet ikke er oppfylt ved bruk av talehjelpemidler (VoiceOver). Eksempler inkluderer:

- Knappen for personvernerklæringen indikerer ikke at handlingen vil åpne en ekstern nettleser.
- «Kontakt oss»-knappene indikerer ikke at de vil videresende til telefon- eller e-post-appen.
- Knappene i bunnnavigasjonen beskriver ikke formålet sitt (1.1.1, 4.1.2).

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Ved bruk av VoiceOver, sørg for at alle navigasjonsknapper, spesielt de som navigerer til skjermbilder utenfor applikasjonen, beskriver formålet sitt. Eksempel: «knapp, personvernerklæring, åpnes i nettleser»

Delvis oppfylt

Kriterium:
Ethvert tastaturbetjent brukergrensesnitt har en driftsmodus der tastaturets fokusindikator er synlig.

Begrunnelse:
Det er enkelte steder i applikasjonen hvor kriteriet ikke er oppfylt. Eksempler inkluderer:
  -  Tilbakepilen i navigasjonslinjen har ingen fokusindikator.
  -  Elementene i bunnnavigasjonen har ingen fokusindikator.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Endre bruken av Material-, InkWell- og Container-komponenter for å sikre synlig utheving.

Kriterium:
For brukergrensesnittkomponenter med etiketter som inkluderer tekst eller bilder av tekst, inneholder navnet teksten som presenteres visuelt.

Begrunnelse:
Kriteriet er ikke oppfylt flere steder i applikasjonen ved bruk av stemmestyring (Voice Control). Eksempler inkluderer:
  -  Tilbake- og profilknappene er merket henholdsvis «knapp» og «bilde», og kan derfor ikke brukes pålitelig med stemmestyring.
  -  For å åpne eiendomsvelgeren må brukeren si navnet på den valgte eiendommen i stedet for den riktige kommandoen, «Bytt eiendom».
  -  Tekstfeltene for redigering av profil har ikke navn som kan brukes til å utløse en talekommando.
  -  Resten av kommandoene er på norsk, et språk som ikke støttes av stemmestyring.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Bruk semantikk til å merke knapper i henhold til formålet deres.
3. Sørg for at alle komponenter kan velges ved hjelp av stemmestyring.

Kriterium:
Hvis en inndatafeil oppdages automatisk, blir elementet som inneholder feilen identifisert, og feilen beskrives for brukeren i tekst.

Begrunnelse:

Ved bruk av VoiceOver leser ikke appen opp varslene (toasts) som dukker opp. Dette påvirker feilutsatte prosesser, som redigering av profilinformasjon eller utfylling av skjemaer.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Bruk Semantics-komponenten til å tvinge VoiceOver til å lese opp varselets rolle og tittel når det dukker opp.

Kriterium:
For alle brukergrensesnittkomponenter (inkludert, men ikke begrenset til: skjemaelementer, lenker og komponenter generert av skript), kan navn og rolle bestemmes programmatisk; tilstander, egenskaper og verdier som kan angis av brukeren, kan settes programmatisk; og varsling om endringer i disse elementene er tilgjengelig for brukeragenter, inkludert hjelpemiddelteknologi.

Begrunnelse:
Kriteriet er ikke oppfylt flere steder i applikasjonen ved bruk av talehjelpemidler (VoiceOver/TalkBack). Se eksemplene fra punkt 1.3.1.

Neste steg:
1. Identifiser alle deler av appen som bryter med kriteriet.
2. Bruk Semantics-komponenten til å merke navn og rolle for alle knappene i henhold til formålet deres.