Where to get started with accessible design as an android developer

Submitted by lordjeff on

This page is a collection of notes, information, suggestions and other information collected by various developers on common questions, issues and information that an android developer may need to know. ACCESSIBILITY FOR DEVELOPERS - ANDROID WEBPAGES Here is a list of URLs for android developers .. The top level link is the first link below .. and the 3 after that are sub-sections. The second link below has some more detailed information. http://developer.android.com/guide/topics/ui/accessibility/index.html Accessibility http://developer.android.com/guide/topics/ui/accessibility/apps.html Making Applications Accessible http://developer.android.com/guide/topics/ui/accessibility/checklist.html Accessibility Developer Checklist http://developer.android.com/guide/topics/ui/accessibility/services.html Building Accessibility Services TalkBack: https://support.google.com/accessibility/android/answer/6007100 AccessibilityNodeInfo: http://developer.android.com/reference/android/view/accessibility/Access... WebVTT: http://dev.w3.org/html5/webvtt/ Adding Captions on YouTube: https://support.google.com/youtube/answer/2734796?hl=en

Android Accessibility, The Missing manual
http://www.last-child.com/android-a11y-missing-manual/

New Tools In Android L

https://www.novoda.com/blog/designing-android-apps-with-vision-impaired-...
http://www.deque.com/blog/accessible-text-input-android/

 

Discovered these additions to help developers improve accessibility:

 

LABELLING BUTTONS SO THEY GET SPOKEN BY TALKBACK

 

Developers should label all buttons and TextViews that they want spoken with a line like: android:contentDescription="Record" They can also use the method setContentDescription() to dynamically set the contentDescription label for a button etc. - from within their java code. MAKING A BUTTON OR TEXTVIEW NOT BE SPOKEN BY TALKBACK Many stackoverflow posts will suggest using null - as in: Quote: android:contentDescription="@null" but that is equivalent to NOT having a contentDescription line - i.e. the default behavior - and TextView will still be spoken by TalkBack. If developer wants a TextView to not be spoken by TalkBack - they can use a contentDescription with a blank space as the string: android:contentDescription=" "

 

MAKING TEXTVIEWS ALSO ACCESSIBLE VIA KEYBOARD OR DPAD MOVEMENT

 

By default only Buttons will be traversable if a user is using a keyboard - so developers should test on the emulator in their development environment and use the on-screen DPAD or keyboard to move between buttons. As a user uses the keyboard to move between buttons - if developer wants that focus should be able to move to a TextView and thus be spoken etc. - then they should remember to include this line in the TextView: Quote: android:focusable="true" MOUSE MOVEMENT OR

 

SWIPING DOES NOT WORK AS EXPECTED WITH TALKBACK EXPLORE-BY-TOUCH

As you touch your finger on screen and start to move it - the touch events are not delivered to your app - but are consumed by TalkBack - and only after your finger has travelled some distance will the first touch events start to be delivered to your app. This coincides with the sound you hear when you tap and then swipe your finger on screen - i.e. the distinctive cluck-cluck sound which signifies that TalkBack has been engaged and will now speak buttons as you move across them with your finger. This makes it difficult to make conventional finger-drawing type apps - since TalkBack is interfering with the flow of touch events. So the developer needs to be creative about how they are going to be able to accomplish what the user needs to do - or the developer needs to wait for Android issues to be resolved.

 

VOLUME BUTTON EVENTS ARE NOT DELIVERED TO APPS - IN NEWEST TALKBACK

This issue is documented on this webpage: https://code.google.com/p/eyes-free/issues/detail?id=309 Issue 309: [Talkback] Volume Up/Down OnKeyDown does not fire Where one TalkBack engineer concedes that it is related to some change in newer Android versions which is now making Volume Button press events be consumed by TalkBack or at least not delivered to the app: Quote from TalkBack team member: Volume keys are currently filtered by TalkBack on 4.3+ for better handling of volume stream switching. Will consider an alternative approach or a user preference in a future release. GENERATING ADDITIONAL SPOKEN INSTRUCTIONS FOR TALKBACK USERS Developers can make their apps speak some extra stuff for TalkBack users - by either using the Text to Speech API on Android - or if they want to keep things simple - by just issuing a Toast message on screen. Which when TalkBack is on - will also be spoken by TalkBack. So you can use Toast messages - preferably with LENGTH_SHORT so they don't remain on screen for very long like this: Quote: Toast.makeText(context, "Click button on bottom-left", Toast.LENGTH_SHORT).show(); PROGRAMMATICALLY JUDGING IF USER HAS TALKBACK ENABLED OR NOT Sometimes developer may want to issue an extra message - like the Toast messages mentioned above - but only to TalkBack users. Since the message may be redundant or extra information for sighted users who may feel it is a needless re-statement of what they already have guessed. In such cases the developer can call a method which tells them if TalkBack is on or off. Android provides a method for doing that - but that is available only for later Android versions. If the developer wants a method that seems to work from Android 2.2 and above up to newer versions of Android - they can use the method outlined in the following thread : https://groups.google.com/forum/#!topic/eyes-free/9pajGQLp4X0 Subject: Programmatically checking for Accessibility - if TalkBack is on

Category: 

Audience: