android-Accessibility Developer Checklist

Accessibility Developer Checklist

In this document

Accessibility Requirements
Accessibility Recommendations
Special Cases and Considerations

See also

Android Design: Accessibility
Accessibility Testing Checklist
Training: Implementing Accessibility
Designing Effective Navigation

Making an application accessible is about a deep commitment to usability, getting the details right and delighting your users. This document provides a checklist of accessibility requirements, recommendations
and considerations to help you make sure your application is accessible. Following this checklist does not guarantee your application is accessible, but it's a good place to start.
使应用程序可访问的是一个深刻的承诺,可用性,获得正确的细节并取悦你的用户。本文档提供了一个清单的易访问性需求,建议和考虑帮助你确保你的应用程序访问。下面这个清单并不能保证您的应用程序可访问,但这是一个很好的起点。

Creating an accessible application is not just the responsibility of developers. Involve your design and testing folks as well, and make them are aware of the guidelines for these other stages of development:
创建可理解的应用程序不仅仅是开发人员的责任。涉及你的设计和测试的人,让他们知道这些其他的指导方针的发展阶段:

Android Design: Accessibility
Accessibility Testing Checklist
In most cases, creating an accessible Android application does not require extensive code restructuring. Rather, it means working through the subtle details of how users interact with your application, so you can
provide them with feedback they can sense and understand. This checklist helps you focus on the key development issues to get the details of accessibility right.
在大多数情况下,创建一个访问Android应用程序代码不需要广泛的重组。相反,它意味着通过用户如何与应用程序交互的微妙的细节,这样你就可以为他们提供反馈,他们可以感知和理解。这个清单可以帮助你专注于关键发展问题得到正确的可访问性的细节

Accessibility Requirements

The following steps must be completed in order to ensure a minimum level of application accessibility.
必须完成以下步骤,以确保最低级别的应用程序的可访问性。

Describe user interface controls: Provide content descriptions for
user interface components that do not have visible text, particularly 

ImageButton

,

ImageView

 and 

CheckBox

 components.
Use the 

android:contentDescription

 XML layout attribute or
the 

setContentDescription(CharSequence)

method
to provide this information for accessibility services. (Exception: decorative graphics)
Enable focus-based navigation: Make sure users can
navigate your screen layouts using hardware-based or software directional controls (D-pads, trackballs, keyboards and navigation gestures). In a few cases, you may need to make user interface components focusable or
change the focus order to be more logical for user actions.
Custom view controls: If you build custom interface controls for
your application, implement accessibility interfaces for your custom views and provide content
descriptions. For custom controls that are intended to be compatible with versions of Android back to 1.6, use the Support
Library to implement the latest accessibility features.
No audio-only feedback: Audio feedback must always have a secondary feedback mechanism to support users who are deaf or hard of hearing. For example, a sound alert for the arrival of a message must be accompanied
by a system 

Notification

, haptic feedback (if available) or other visual alert.
Test: Test accessibility by navigating your application using directional controls, and using eyes-free navigation with TalkBack enabled. For more accessibility testing information, see the Accessibility
Testing Checklist.

Accessibility Recommendations

The following steps are recommended for ensuring the accessibility of your application. If you do not take these actions, it may impact the overall accessibility and quality of your application.
Android Design Accessibility Guidelines: Before building your layouts, review and follow the accessibility guidelines provided in the Design
guidelines.
Framework-provided controls: Use Android's built-in user interface controls whenever possible, as these components provide accessibility support by default.
Temporary or self-hiding controls and notifications: Avoid having user interface controls that fade out or disappear after a certain amount of time. If this behavior is important to your application, provide
an alternative interface for these functions.

Special Cases and Considerations

The following list describes specific situations where action should be taken to ensure an accessible app. Review this list to see if any of these special cases and considerations apply to your application, and
take the appropriate action.
Text field hints: 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 and allow the contents of the field to be spoken when it is filled.
Custom controls with high visual context: If your application contains a custom
control with a high degree of visual context (such as a calendar control), default accessibility services processing may not provide adequate descriptions for users, and you should consider providing a virtual
view hierarchy for your control using 

AccessibilityNodeProvider

.
Custom controls and click handling: If a custom control in your application performs specific handling of user touch interaction, such as listening with 

onTouchEvent(MotionEvent)

 for 

MotionEvent.ACTION_DOWN

 and 

MotionEvent.ACTION_UP

 and
treating it as a click event, you must trigger an

AccessibilityEvent

 equivalent
to a click and provide a way for accessibility services to perform this action for users. For more information, seeHandling
custom touch events.
Controls that change function: If you have buttons or other controls that change function during the normal activity of a user in your application (for example, a button that changes from Play to Pause),
make sure you also change the 

android:contentDescription

 of
the button appropriately.
Prompts for related controls: Make sure sets of controls which provide a single function, such as the 

DatePicker

,
provide useful audio feedback when an user interacts with the individual controls.
Video playback and captioning: If your application provides video playback, it must support captioning and subtitles to assist users who are deaf or hard of hearing. Your video playback controls must also clearly
indicate if captioning is available for a video and provide a clear way of enabling captions.
Supplemental accessibility audio feedback: Use only the Android accessibility framework to provide accessibility audio feedback for your app. Accessibility services such as TalkBack should
be the only way your application provides accessibility audio prompts to users. Provide the prompting information with a 

android:contentDescription

 XML
layout attribute or dynamically add it using accessibility framework APIs. For example, if your application takes action that you want to announce to a user, such as automatically turning the page of a book, use the

announceForAccessibility(CharSequence)

 method
to have accessibility services speak this information to the user.
Custom controls with complex visual interactions: For custom controls that provide complex or non-standard visual interactions, provide a virtual
view hierarchy for your control using 

AccessibilityNodeProvider

 that
allows accessibility services to provide a simplified interaction model for the user. If this approach is not feasible, consider providing an alternate view that is accessible.
Sets of small controls: If you have controls that are smaller than the minimum recommended touch size in your application screens, consider grouping these controls together using a 

ViewGroup

 and
providing a 

android:contentDescription

 for the group.
Decorative images and graphics: Elements in application screens that are purely decorative and do not provide any content or enable a user action should not have accessibility content descriptions.