Opprette tilgjengelige Android Apps Assistive Technologies

Når du designer en Android-app, vil du ha så mange som mulig å laste ned og bruke den appen, men dette kan bare skje hvis appen din er tilgjengelig for alle-inkludert folk som får tilgang til deres Android-enheter via hjelpefunksjoner, eller som opplever mobilapper uten elementer som farge eller lyd.

I mitt siste innlegg om å skape tilgjengelige Android-apper, viste jeg deg hvordan du gir den beste opplevelsen til alle som bruker appen din, ved å optimalisere programmet ditt for tilgjengelighetsfunksjonene som er bakt inn i hver Android-enhet. Jeg vil også dekke tilgjengeligheten beste praksis, og hvordan egentlig sett appens tilgjengelighet til testen, før du sender den ut i verden. 

Når du har fullført denne artikkelen, vet du hvordan du lager programmer som integreres med skjermlesere, retningsbestemte kontroller og Bytt enheter, samt andre nyttige Android-tilgjengelighetsfunksjoner som for eksempel lukkede bildetekster.

Støttende hjelpemidler

En assistentteknologi eller tilgjengelighetsfunksjon er et program eller en maskinvare som gjør enhetene mer tilgjengelige. Android har en rekke tilgjengelighetsfunksjoner innebygd, og det er mange apper og til og med eksterne enheter som folk kan laste ned eller kjøpe for å gjøre deres Android-enheter bedre tilpasset deres behov. 

På samme måte som du optimaliserer Android-appene dine for å fungere godt med berøringsskjermen og forskjellige skjermkonfigurasjoner, bør du optimalisere appen din for disse tilgjengelighetstjenestene.

Optimalisering for hjelpeteknologi er en av de viktigste trinnene i å skape en tilgjengelig app, så i denne delen skal jeg dekke alle de store tilgjengelighetstjenestene og vise hvordan du optimaliserer appen din for å gi bedre opplevelse for hver av disse tjenestene. 

Støtte skjermlesere

Brukere med visjonsrelaterte problemer kan interagere med sine Android-enheter ved hjelp av en skjermleser, som er en talesyntese som leser tekst høyt når brukeren beveger seg rundt skjermen. 

Nylige utgivelser av Android kommer vanligvis med Googles tekst-til-tale (TTS) -motor forhåndsinstallert. For å sjekke om TTS er installert på enheten din:

• Åpne enheten din innstillinger app.
• Navigere til Tilgjengelighet> Tekst-til-tale-utgang. 
  
• Undersøk Foretrukket motor verdi-dette bør settes til Google tekst-til-tale-motor.
  

TTS-motoren driver forskjellige skjermlesere, inkludert Googles TalkBack, som er skjermleseren jeg skal bruke:

• Last ned Google TalkBack fra Google Play-butikken.
• Navigere til Innstillinger> Tilgjengelighet.
• Å velge Snakke tilbake.
• Skyv glidebryteren til På stilling. 
  

Hvis du eier en Samsung-enhet, kan du ha forhåndsinstallert Voice Assistant-skjermleseren. Voice Assistant er en port av Google TalkBack som har mange av de samme funksjonene, slik at du vanligvis ikke trenger å installere TalkBack hvis du allerede har tilgang til Voice Assistant. 

Navigere i skjermlesere

De fleste skjermlesere støtter to navigasjonsmetoder: 

• Lineær navigasjon. Leverer lydmeldinger når brukeren beveger seg rundt brukergrensesnittet på en lineær måte, enten ved å sveipe til venstre eller høyre eller ved å bruke en retningskontroll (som er en annen tilgjengelighets service vi vil se på kort tid).
• Utforsk ved berøring. Skjermleseren kunngjør hvert brukerelement som brukeren berører den.
  

Det er viktig å teste applikasjonen din ved hjelp av både lineær navigering og Utforsk ved berøring metoder.

Vær oppmerksom på at noen kan bruke TalkBack ved siden av BrailleBack-programmet og en ekstern, oppfriskbar punktskrift. Braille-støtte er ikke noe du kan teste fullstendig uten å kjøpe en braille-skjerm, men hvis du er interessert i å lære mer om disse enhetene, så er det nok av braille-skjermvideoer på YouTube.

Du kan også bruke BrailleBack-appen til å forhåndsvise hvordan appens tekst vil gjengi på punktvisning. Når BrailleBack er installert, naviger til Innstillinger> Tilgjengelighet> BrailleBack> Innstillinger> Utvikleralternativer> Vis Braille-utgang på skjermen. Naviger tilbake til hoved BrailleBack-skjermen, skyv glidebryteren inn i På posisjon, og BrailleBack vil da legge til et overlegg som viser brailleceller for hvilken skjerm du ser for øyeblikket.

Nå som du har konfigurert skjermleseren din (og eventuelt BrailleBack), kan vi se på hvordan du kan optimalisere appen din for denne tilgjengelighets tjenesten. 

Legge til innholdsbeskrivelser

Tekstetiketter legger til rot på skjermen, så det er mulig, bør du unngå å legge til eksakte etiketter på brukergrensesnittet ditt. 

Kommunisere en knappes hensikt ved hjelp av et søppelkanneikon i stedet for a Slett Etikett kan være god design, men det gjør presentere et problem for skjermlesere, da det ikke er noe for den skjermleseren å lese! 

Du bør gi en innholdsbeskrivelse for alle kontroller som ikke har synlig tekst, for eksempel ImageButtons og avmerkingsboksene, og for visuelle medier som bilder. 

Disse innholdsetikettene vises ikke på skjermen, men tilgjengelighets-tjenester som skjermlesere og punktskrift vil kunngjøre etiketten når det tilhørende brukergrensesnittet blir satt i fokus. 

Du legger til en innholdsbeskrivelse til et statisk element ved hjelp av android: content:

 
 Ikke kast ord som beskriver komponentens fysiske utseende. Brukeren trenger å vite hva som skal skje når de samhandler med en kontroll, ikke nødvendigvis hvordan den kontrollerer utseende.
 
 Ikke ta med instruksjoner om hvordan du skal samhandle med en kontroll. Det er mange forskjellige måter å kommunisere med en enhet ved siden av berøringsskjermen. Det er derfor potensielt villedende for brukeren å "trykke på denne lenken for å redigere innstillingene dine", ikke bare legge til unødvendige ord i innholdsbeskrivelsen.. 
 
 Ikke legg til innholdsbeskrivelser til alt. Skjermlesere kan ofte ignorere UI-elementer som eksisterer bare for å gjøre skjermen ser finere ut, så du trenger vanligvis ikke å gi en innholdsbeskrivelse for appens dekorative elementer. Du kan også eksplisitt instruere en Utsikt Ikke å svare på en tilgjengelighetsservice ved å markere den som android: content = “@ null” eller android: isImportantForAccessibility = “no” (Android 4.1 og høyere).
 
Brukere må kunne identifisere elementer fra innholdsbeskrivelsen alene, så hver innholdsbeskrivelse må være unik. Ikke glem å oppdatere beskrivelsene for gjenbrukte layouter, for eksempel Listevisning og RecyclerView.
Når du er fornøyd med innholdsbeskrivelsene dine, bør du sette dem på prøve ved å forsøke å navigere appen din bare ved hjelp av talte tilbakemeldinger, og deretter foreta nødvendige justeringer. 
Ikke tørk ut skjermlesere
Enkelte skjermlesere lar deg justere en applyd uavhengig av andre lyder på enheten, og noen støtter enda "lyd ducking", som automatisk reduserer enhetens annen lyd når skjermleseren snakker. Du bør imidlertid ikke anta at brukerens valgte skjermleser støtter noen av disse funksjonene, eller at de er aktivert. 
Hvis appen din har musikk eller lydeffekter som potensielt kan drukne en skjermleser, bør du gi brukerne en måte å deaktivere disse lydene på. Alternativt kan appen deaktivere all unødvendig lyd automatisk når den oppdager at en skjermleser er aktivert. 
Ikke stole på visuelle signaler 
Det kan være vanlig å formatere koblinger som blå, understreket tekst, men folk som opplever brukergrensesnittet ditt som en serie av skjermlesere, kan være uvitende om disse visuelle signalene.  
For å sikre at alle brukere er klar over appens hyperkoblinger, enten:
 
Setning ankerteksten din slik at det er klart at dette teksten inneholder en hyperkobling.
 
Legg til en innholdsbeskrivelse.
 
Trekk ut hyperkoblingen til en ny kontekst. Hvis du for eksempel flytter lenken til en knapp eller et menyelement, vil brukeren allerede vite at de skal interagere med denne kontrollen. 
 
Vurder å bytte tidsbestemte kontroller
Noen kontroller kan forsvinne automatisk etter at en tidsperiode er gått. For eksempel har videoavspillingskontroller en tendens til å falme ut når du er noen sekunder i en video. 
Siden skjermlesere kun kunngjør en kontroll når den får fokus, er det en sjanse for at en tidsbestemt kontroll kan forsvinne før brukeren har en sjanse til å fokusere på den. Hvis appen din inneholder noen tidsbestemte kontroller, bør du vurdere å gjøre dem permanente kontroller når programmet ditt oppdager at en skjermleser er aktivert, eller i det minste forlenge tiden denne kontrollen forblir på skjermbildet. 
Ikke stol på farger
Med mindre du inkluderer dem i innholdsbeskrivelsene dine, vil skjermlesere ikke kommunisere fargekoder til brukerne dine, så du bør aldri bruke farge som eneste middel til å kommunisere viktig informasjon. Denne regelen bidrar også til at appen din er tilgjengelig for personer som er fargeblind, eller som har problemer som skiller mellom bestemte farger. 
Hvis du bruker farge for å markere viktig tekst, må du understreke denne teksten ved hjelp av andre metoder, for eksempel ved å gi en innholdsbeskrivelse, lydeffekter eller haptisk (berøringsbasert) tilbakemelding når denne teksten blir tatt i fokus. Du bør også gi flere visuelle tegn for personer som er fargeblind, for eksempel å variere skriftstørrelsen eller bruke kursiv eller understreke effekter.
Bytt tilgang og retningskontroller
Brukere med begrenset syn eller manuelle fingerferdighetsproblemer kan betjene enheten ved hjelp av retningskontroller eller byttilgang, i stedet for berøringsskjermen. 
1. Teste appens brytertilgang 
Bytt tilgang gir deg mulighet til å kommunisere med Android-enheten din ved hjelp av en "bryter" som sender et tastetrykkssignal til enheten, som ligner på å trykke på en OK eller Å velge knapp.
I denne delen skal vi skape separate "Next", "Previous" og "Select" -brytere, men det er også mulig å opprette en "Select" -bryter og ha bytte tilgangssyklus gjennom skjermens interaktive elementer i en kontinuerlig sløyfe. Jeg foretrekker å teste appen din ved hjelp av denne automatisk skannemetoden, og deretter navigere til Innstillinger> Tilgjengelighet> Bytt tilgang> Innstillinger> Automatisk skanning.
Android støtter følgende brytere:
 
Enhetens maskinvareknapper, for eksempel Hjem eller Volum opp / volum ned. Dette er vanligvis hvordan du skal teste appens bryterstøtte, da det ikke krever at du kjøper en dedikert bryterenhet.
 
En ekstern enhet, for eksempel et tastatur som er koblet til Android-enheten via USB eller Bluetooth. 
 
En fysisk handling. Du kan bruke enhetens frontkamera til å tilordne "bryter" -funksjonen til en fysisk handling, for eksempel å blinke øynene eller åpne munnen din. 
 
Slik aktiverer du Switch Access:
 
Navigere til Innstillinger> Tilgjengelighet> Bytt tilgang.
 
Å velge innstillinger i øvre høyre hjørne. 
 
Velg neste, Tidligere og Å velge elementer i sin tur, trykk på maskinvare-tasten du vil tilordne til denne handlingen, og trykk deretter på Lagre.
 
Naviger tilbake til hovedmenyen Bytt tilgang skjermen, og skyv glidebryteren inn i På stilling. 
 
Du kan deaktivere Bytt tilgang på et hvilket som helst tidspunkt ved å navigere til Innstillinger> Tilgjengelighet> Bytt tilgang og skyver glidebryteren inn i Av stilling.
2. Teste Appens Retningsstyringsstøtte 
Retningsbestemte kontroller lar brukeren navigere på enheten på en lineær måte, ved bruk av Opp ned venstre høyre handlinger, på samme måte som du bruker fjernkontrollen til å navigere i TV-guiden.
Android støtter følgende retningskontroller:
 
enhetens maskinvare nøkler.
 
eksterne enheter som er koblet til via USB eller Bluetooth, for eksempel en styreflate, tastatur eller retningsbestemmelse (D-pad)
 
programvare som emulerer en retningsbestemt kontroll, for eksempel TalkBack-bevegelser
 
Utforming for retningskontroller og byttilgang
Når brukeren samhandler med appen din ved hjelp av Switch Access eller en retningskontroll, må du sørge for at: 
 
De kan nå og samhandle med alle appens interaktive komponenter.
 
Fokus beveger seg fra en UI-kontroll til den neste på en logisk måte. For eksempel, hvis brukeren trykker på Ikke sant knappen på retningskontrollen, så bør fokus flyttes til UI-elementet de forventer. 
 
Hvis du bruker Android standard Visninger, så bør kontrollene dine være fokusable som standard, men du bør alltid sett dette på prøve. 
For å kontrollere at alle dine interaktive komponenter er fokusable via Switch Access, bruk bryterne til å navigere fra toppen av skjermen til bunnen, slik at hver kontrollgevinst fokuserer på et tidspunkt. 
Den enkleste måten å teste appens retningsstyringsstøtte på er å etterligne en retningsplate på en Android Virtual Device (AVD).
Ulempen er at dette krever redigering av AVDs config.ini innstillinger. Merk at følgende instruksjoner er skrevet for macOS, så hvis du utvikler på Windows eller Linux, kan trinnene være litt forskjellige. 
 
Åpne et "Finder" vindu og velg Gå> Gå til mappe ...  fra verktøylinjen.
 
I den etterfølgende popupen, skriv inn ~ / .Android / avd og klikk deretter Gå.
 
Åpne mappen som tilsvarer den AVD du vil bruke.
 
Kontroller-klikk på config.ini fil og velg Åpne med> Annet ...  
 
Velg et tekstredigeringsprogram; Jeg velger TextEdit.
 
I den påfølgende tekstfilen finner du hw.dPad = ingen linje og endre den til hw.dPad = yes. Lagre denne filen. 
 
Start programmet på AVD du nettopp har redigert.
 
Velg Mer knappen (der markøren er plassert i følgende skjermbilde). 
 
 
Å velge Retningspute fra venstre meny.
 
Du kan nå navigere søknaden din ved hjelp av en emulert retningsplate.
 

 Android Standard UI-kontroller er standard som standard, men hvis du sliter med å fokusere på en bestemt kontroll, må du kanskje markere det som fokusabelt, ved å bruke enten android: fokuserbar = "true" eller View.setFocusable ().
Du bør også kontrollere at fokusordren beveger seg fra ett brukergrensesnitt til det neste på en logisk måte, ved å navigere rundt alle appens kontroller, i alle retninger. (Ikke glem å teste omvendt!) 
Android bestemmer hver skjerms fokusordre automatisk basert på en algoritme, men noen ganger kan du kanskje forbedre denne sekvensen ved å endre fokusordre manuelt. 
Du kan angi visningen som skal få fokus når brukeren beveger seg i en bestemt retning, ved hjelp av følgende XML-attributter: android: nextFocusUp, android: nextFocusDown, android: nextFocusRight, og android: nextFocusLeft.
For eksempel, tenk at du har følgende layout: 
 http://schemas.android.com/apk/res/android "xmlns: app =" http://schemas.android.com/apk/res-auto "xmlns: tools =" http://schemas.android. com / verktøy "android: layout_width =" match_parent "android: layout_height =" match_parent "verktøy: context =" com.jessicathornsby.accessibility.MainActivity ">    

Som standard, når Knapp kontroll er i fokus:
 
Pressing Ned vil bringe avmerkingsbokser i fokus.
 
Pressing Ikke sant vil bringe EditText i fokus. 
 
Du kan bytte denne bestillingen ved å bruke android: neste egenskaper. I følgende kode:
 
Pressing Ned bringer EditText i fokus.
 
Pressing Ikke sant bringer avmerkingsbokser i fokus. 
 
Alternativt kan du endre fokusordren ved kjøring med setNextFocusDownId, setNextFocusForwardId, setNextFocusLeftId, setNextFocusRightId, og setNextFocusUpId.
Forenkle layoutene dine
Enkelere oppsett er enklere for alle å navigere, men dette gjelder spesielt for alle som samhandler med appen din ved å bruke Switch Access eller en retningskontroll. 
Når du tester appens navigasjon, ser du etter muligheter til å fjerne elementer fra brukergrensesnittet ditt. Spesielt bør du vurdere å fjerne nesting fra layoutene dine, som nestede oppsett gjør søknaden betydelig vanskeligere å navigere. 
Ikke forsøm Appens berøringsskjermstøtte
Noen brukere med manuelle fingerferdighetsproblemer kan foretrekke å samhandle med enhetene sine ved hjelp av berøringsskjermen. 
For å hjelpe deg med å støtte disse brukerne, bør alle appens interaktive elementer være 48 x 48 dp eller større, med minst 8 dp mellom alle berørbare elementer. Du vil kanskje også eksperimentere med å øke størrelsen på et berøringsmål uten å øke størrelsen på det relaterte Utsikt, bruker Android TouchDelegate API.
Lukkede bildetekster 
Du bør gi teksting for alle appens talte lyd.
Slik aktiverer du lukkede bildetekster på enheten:
 
Navigere til Innstillinger> Tilgjengelighet> Undertekster.
 
Skyv glidebryteren inn i På stilling. 
 
På Android 4.4 og høyere legger du til en ekstern tekstkildefil i WebVTT-format ved hjelp av addSubtitleSource (), for eksempel:
myVideoView.addSubtitleSource (getResources (). openRawResource (R.raw.subs_english_vtt), MediaFormat.createSubtitleFormar ("text / vtt", Locale.ENGLISH.getLanguage ()));
Undertekster er en systemavhengig innstilling, slik at noen som stoler på bildetekster, sannsynligvis vil starte programmet med bildetekster som allerede er aktivert. Men hvis en bruker ikke har bildetekster aktivert, så er det avgjørende at du gjør det klart at appen din støtter lukkede bildetekster og gir en måte å aktivere bildetekster på. Ofte kan du oppnå begge disse tingene ved å ha en Bildetekster tekster~~POS=HEADCOMP knappen fremtredende i brukergrensesnittet ditt - for eksempel, legger du til en Bildetekster tekster~~POS=HEADCOMP knappen til appens videoavspillingskontroller. 
Siden bildetekster er en systemavhengig innstilling, trenger appen din bare å videresende brukeren til den aktuelle delen av enhetens innstillinger applikasjon (Innstillinger> Tilgjengelighet> Undertekster). For eksempel: 
offentlig boolean onOptionsItemSelected (MenuItem item) if (item.getItemId () == R.id.menu_captions) startActivityForIntent (new Intent (Settings.ACTION_CAPTIONING_SETTINGS)); 
Android vil endre bildetekstens formatering i henhold til brukerens systemovergripende tekstinnstillinger, plassert i Innstillinger> Tilgjengelighet> Undertekster. For å sikre at bildeteksten din fortsatt er leselig, uavhengig av brukerens innstillinger, må du teste bildetekster på Android-komplett utvalg av formateringsalternativer.
Skriftstørrelse
Brukere som sliter med å lese på skjermtekst, kan øke skriftstørrelsen som brukes på enheten.
Du må sørge for at appen din fortsatt fungerer over en rekke tekststørrelser. For å teste dette, kan du prøve å endre tekststørrelsen hele enheten.
 
Start enheten din innstillinger app.
 
Navigere til Innstillinger> Tilgang> Skriftstørrelse. 
 
Skyv glidebryteren mot det store EN for å øke skriftstørrelsen, og mot den lille EN for å redusere skriftstørrelsen. 
 
Forutsatt at du definerte teksten i skalerbare piksler (sp), bør appen din oppdatere automatisk basert på brukerens skriftstørrelsesinnstillinger.
Hvis du har designet et fleksibelt layout, så bør appen din ideelt sett imøtekomme en rekke tekststørrelser, men du bør alltid test hvordan appen din håndterer hele spekteret av Skriftstørrelse innstillinger, og foreta nødvendige justeringer. Tekst som øker eller avtar basert på brukerens preferanser, kommer ikke til å forbedre brukeropplevelsen hvis noen innstillinger gjør appen ubrukelig! 
Konklusjon
I dette innlegget lærte du hvordan du optimaliserer appen din for noen av Androids mest brukte hjelpeteknologi og tilgjengelighetsfunksjoner. 
Hvis du er interessert i å lære mer om tilgjengelighet, har Google publisert en prøveapp som inneholder kode for mange av de teknikkene som diskuteres i denne artikkelen. Du vil også finne mye informasjon om mobil tilgjengelighet generelt, over på Web Accessibility Initiative nettsiden.
I mellomtiden kan du sjekke ut noen av våre andre innlegg om Android app-utvikling!



		
			
	   
	




Kode