android-Making Applications Accessible

Applications built for Android are more accessible to users with visual, physical or age-related limitations when those users activate accessibility services and features on a device. These services make your application more accessible even if you do not make any accessibility changes to your code. However, there are steps you should take to optimize the accessibility of your application and ensure a pleasant experience for all your users.

> If you use only the standard components for your application, the steps are:

1. Add descriptive text to user interface controls in your application using the android:contentDescription attribute. Pay particular attention to ImageButton, ImageView and CheckBox.
2. Make sure that all user interface elements that can accept input (touches or typing) can be reached with a directional controller, such as a trackball, D-pad (physical or virtual) or navigationgestures .
3. Make sure that audio prompts are always accompanied by another visual prompt or notification, to assist users who are deaf or hard of hearing.
4. Test your application using only accessibility navigation services and features. Turn on TalkBack and Explore by Touch, and then try using your application using only directional controls. For more information on testing for accessibility, see the Accessibility Testing Checklist.

You can make these controls more accessible with the android:contentDescription XML layout attribute. The text in this attribute does not appear on screen, but if the user enables accessibility services that provide audible prompts, then when the user navigates to that control, the text is spoken.

For this reason, set the android:contentDescription attribute for every ImageButton, ImageView,CheckBox in your application's user interface, and add descriptions to any other input controls that might require additional information for users who are not able to see it.

 Note: For EditText fields, provide an android:hint attribute instead of a content description, to help users understand what content is expected when the text field is empty. When the field is filled, TalkBack reads the entered content to the user, instead of the hint text.

> Android provides several APIs that let you control whether a user interface control is focusable and even request that a control be given focus:

• setFocusable()
• isFocusable()
• requestFocus()

<LinearLayout android:orientation="horizontal"
        ... >
    <EditText android:id="@+id/edit"
        android:nextFocusDown=”@+id/text”
        ... />
    <TextView android:id="@+id/text"
        android:focusable=”true”
        android:text="Hello, I am a focusable TextView"
        android:nextFocusUp=”@id/edit”
        ... />
</LinearLayout>

Note:  You can modify the focus order of user interface components at runtime, using methods such as setNextFocusDownId()  and  setNextFocusRightId() .
>  These are the main tasks for ensuring the accessibility of your view:

• Handle directional controller clicks
• Implement accessibility API methods
• Send AccessibilityEvent objects specific to your custom view
• Populate AccessibilityEvent and AccessibilityNodeInfo for your view

> Accessibility events are messages about users interaction with visual interface components in your application. These messages are handled by Accessibility Services, which use the information in these events to produce supplemental feedback and prompts. In Android 4.0 (API Level 14) and higher, the methods for generating accessibility events have been expanded to provide more detailed information than theAccessibilityEventSource interface introduced in Android 1.6 (API Level 4). The expanded accessibility methods are part of the View class as well as the View.AccessibilityDelegate class. 

In order to support these accessibility methods for a custom view, you should take one of the following approaches:

• If your application targets Android 4.0 (API level 14) and higher, override and implement the accessibility methods listed above directly in your custom view class.
• If your custom view is intended to be compatible with Android 1.6 (API Level 4) and above, add the AndroidSupport Library, revision 5 or higher, to your project. Then, within your custom view class, call theViewCompat.setAccessibilityDelegate() method to implement the accessibility methods above. For an example of this approach, see the Android Support Library (revision 5 or higher) sampleAccessibilityDelegateSupportActivity in (<sdk>/extras/android/support/v4/samples/Support4Demos/)

In either case, you should implement the following accessibility methods for your custom view class:

• dispatchPopulateAccessibilityEvent()
• onPopulateAccessibilityEvent()
• onInitializeAccessibilityEvent()
• onInitializeAccessibilityNodeInfo()

> The View class provides a default implementation for these event types:

• Starting with API Level 4:
  • TYPE_VIEW_CLICKED
  • TYPE_VIEW_LONG_CLICKED
  • TYPE_VIEW_FOCUSED
• Starting with API Level 14:
  • TYPE_VIEW_SCROLLED
  • TYPE_VIEW_HOVER_ENTER
  • TYPE_VIEW_HOVER_EXIT

Note: Hover events are associated with the Explore by Touch feature, which uses these events as triggers for providing audible prompts for user interface elements.

<未完待续>