Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge "docs: Accessibility DevGuide, Jelly Bean edition" into jb-dev

Browse Source
This commit is contained in:
Scott Main
2012-09-05 11:50:18 -07:00
committed by Android (Google) Code Review
parent d4107dca29 ba4cf3c850
commit 253483dd97
8 changed files with 1001 additions and 261 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/html/guide/guide_toc.cs
View File

@@ -8,7 +8,7 @@
<ul id="nav">
<!-- Walkthrough for Developers -- quick overview of what it's like to develop on Android -->
<!--<li style="color:red">Overview</li> -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/components/index.html">
<span class="en">App Components</span>
@@ -223,7 +223,7 @@
<li><a href="<?cs var:toroot ?>guide/topics/search/adding-custom-suggestions.html">Adding Custom Suggestions</a></li>
<li><a href="<?cs var:toroot ?>guide/topics/search/searchable-config.html">Searchable Configuration</a></li>
</ul>
</li>
</li>
<li><a href="<?cs var:toroot ?>guide/topics/ui/drag-drop.html">
<span class="en">Drag and Drop</span>
</a></li>
@@ -235,6 +235,9 @@
<li><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/apps.html">
<span class="en">Making Applications Accessible</span>
</a></li>
<li><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/checklist.html">
<span class="en">Accessibility Developer Checklist</span>
</a></li>
<li><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/services.html">
<span class="en">Building Accessibility Services</span>
</a></li>
@@ -382,9 +385,9 @@
</a></li>
</ul>
</li><!-- end of location and sensors -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/topics/connectivity/index.html">
<span class="en">Connectivity</span>
@@ -419,10 +422,10 @@
<span class="en">SIP</span>
</a>
</li>
</ul>
</li><!-- end of connectivity -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/topics/text/index.html">
<span class="en">Text and Input</span>
@@ -439,7 +442,7 @@
</a></li>
</ul>
</li><!-- end of text and input -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/topics/data/index.html">
<span class="en">Data Storage</span>
@@ -457,7 +460,7 @@
</ul>
</li><!-- end of data storage -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot?>guide/topics/admin/index.html">
<span class="en">Administration</span>
@@ -475,7 +478,7 @@
-->
</ul>
</li><!-- end of administration -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/webapps/index.html">
<span class="en">Web Apps</span>
@@ -498,7 +501,7 @@
</a></li>
</ul>
</li><!-- end of web apps -->
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/practices/index.html">
<span class="en">Best Practices</span>
@@ -555,13 +558,13 @@
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/google/index.html">
<span class="en">Google Services</span>
</a></div>
<ul>
<ul>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot?>guide/google/play/billing/index.html">
@@ -623,7 +626,7 @@
<li><a href="<?cs var:toroot ?>guide/google/play/expansion-files.html">
<span class="en">APK Expansion Files</span></a>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/google/gcm/index.html">
<span class="en">Google Cloud Messaging</span></a>
@@ -649,9 +652,9 @@
</ul>
</li><!-- end Google Play -->
<!-- this needs to move
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/index.html">
@@ -691,9 +694,9 @@
</a></div>
</li>
</ul>
</li>
</li>
</ul> -->
<!-- Remove
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>guide/appendix/index.html">
@@ -710,7 +713,7 @@
<li><a href="<?cs var:toroot ?>guide/appendix/g-app-intents.html">
<span class="en">Intents List: Google Apps</span>
</a></li>
<li><a href="<?cs var:toroot ?>guide/appendix/glossary.html">
<span class="en">Glossary</span>

422
docs/html/guide/topics/ui/accessibility/apps.jd
View File

@@ -21,14 +21,11 @@ parent.link=index.html
<li><a href="#accessibility-methods">Implementing accessibility API methods</a></li>
<li><a href="#send-events">Sending accessibility events</a></li>
<li><a href="#populate-events">Populating accessibility events</a></li>
<li><a href="#virtual-hierarchy">Providing a customized accessibility context</a></li>
<li><a href="#custom-touch-events">Handling custom touch events</a></li>
</ol>
</li>
<li><a href="#test">Testing Accessibility</a>
<ol>
<li><a href="#test-audibles">Testing audible feedback</a></li>
<li><a href="#test-navigation">Testing focus navigation</a></li>
</ol>
</li>
<li><a href="#test">Testing Accessibility</a></li>
</ol>
<h2>Key classes</h2>
@@ -42,60 +39,79 @@ parent.link=index.html
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li>
<li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a>
</li>
<li><a href="{@docRoot}design/index.html">Android Design</a></li>
<li><a href="checklist.html">Accessibility Developer Checklist</a><li>
<li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing Checklist</a><li>
<li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li>
<li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a></li>
<li><a href="{@docRoot}training/accessibility/index.html">Training: Implementing Accessibility</a></li>
</ol>
</div>
</div>
<p>Applications built for Android are accessible to users with visual, physical or age-related
disabilities when they activate accessibility features and services on a device. By default,
these services make your application more accessible. However, there are further steps you should
take to optimize the accessibility of your application and ensure a pleasant experience for all your
users.</p>
<p>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.</p>
<p>Making sure your application is accessible to all users is relatively easy, particularly when you
use framework-provided user interface components. If you only use these standard components for your
application, there are just a few steps required to ensure your application is accessible:</p>
<p>Making sure your application is accessible to all users requires only a few steps, particularly
when you create your user interface with the components provided by the Android framework. If you
use only the standard components for your application, the steps are:</p>
<ol>
<li>Label your {@link android.widget.ImageButton}, {@link android.widget.ImageView}, {@link
android.widget.EditText}, {@link android.widget.CheckBox} and other user interface controls using
the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> attribute.</li>
<li>Make all of your user interface elements accessible with a directional controller,
such as a trackball or D-pad.</li>
<li>Test your application by turning on accessibility services like TalkBack and Explore by
Touch, and try using your application using only directional controls.</li>
<li>Add descriptive text to user interface controls in your application using the
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> attribute. Pay particular attention to
{@link android.widget.ImageButton}, {@link android.widget.ImageView}
and {@link android.widget.CheckBox}.</li>
<li>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
navigation <a href="http://support.google.com/android/bin/topic.py?hl=en&topic=2492346">gestures
</a>.</li>
<li>Make sure that audio prompts are always accompanied by another visual prompt or notification,
to assist users who are deaf or hard of hearing.</li>
<li>Test your application using only accessibility navigation services and features. Turn on
<a href="{@docRoot}tools/testing/testing_accessibility.html#testing-talkback">TalkBack</a> and
<a href="{@docRoot}tools/testing/testing_accessibility.html#testing-ebt">Explore by Touch</a>,
and then try using your application using only directional controls. For more information on
testing for accessibility, see the <a href="{@docRoot}tools/testing/testing_accessibility.html">
Accessibility Testing Checklist</a>.</li>
</ol>
<p>Developers who create custom controls that extend from the {@link android.view.View} class have
some additional responsibilities for making sure their components are accessible for users. This
document also discusses how to make custom view controls compatible with accessibility services.</p>
<p>If you build custom controls that extend the {@link android.view.View} class, you must complete
some additional work to make sure your components are accessible. This document discusses how to
make custom view controls compatible with accessibility services.</p>
<p class="note">
<strong>Note:</strong> The implementation steps in this document describe the requirements for
making your application accessible for users with blindness or low-vision. Be sure to review the
requirements for serving users who are deaf and hard of hearing in the
<a href="{@docRoot}guide/topics/ui/accessibility/checklist.html">Accessibility Developer
Checklist</a></p>.
<h2 id="label-ui">Labeling User Interface Elements</h2>
<p>Many user interface controls rely on visual cues to inform users of their meaning. For
<p>Many user interface controls depend on visual cues to indicate their meaning and usage. For
example, a note-taking application might use an {@link android.widget.ImageButton} with a
picture of a plus sign to indicate that the user can add a new note. Or, an {@link
android.widget.EditText} component may have a label near it that indicates its purpose. When a user
with impaired vision accesses your application, these visual cues are often useless.</p>
picture of a plus sign to indicate that the user can add a new note. An {@link
android.widget.EditText} component may have a label near it that indicates its purpose. A user
with impaired vision can't see these cues well enough to follow them, which makes them useless.</p>
<p>To provide textual information about interface controls (as an alternative to the visual cues),
use the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> attribute. The text you provide in this attribute is not
visible on the screen, but if a user has enabled accessibility services that provide audible
prompts, then the description in this attribute is read aloud to the user.</p>
<p>You can make these controls more accessible with the
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> 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.</p>
<p>Set the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
<p>For this reason, set the
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> attribute for every {@link android.widget.ImageButton},
{@link android.widget.ImageView}, {@link android.widget.EditText}, {@link android.widget.CheckBox}
in your application's user interface, and on any other input controls that might require additional
information for users who are not able to see it.</p>
{@link android.widget.ImageView}, {@link android.widget.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.</p>
<p>For example, the following {@link android.widget.ImageButton} sets the content description for
the plus button to the {@code add_note} string resource, which could be defined as “Add note" for an
@@ -108,32 +124,38 @@ English language interface:</p>
android:contentDescription=”@string/add_note”/&gt;
</pre>
<p>By including the description, speech-based accessibility services can announce "Add note" when a
user moves focus to this button or hovers over it.</p>
<p>By including the description, an accessibility service that provides spoken feedback can announce
"Add note" when a user moves focus to this button or hovers over it.</p>
<p class="note"><strong>Note:</strong> For {@link android.widget.EditText} fields, provide an
<a href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">android:hint</a>
attribute to help users understand what content is expected.</p>
attribute <em>instead</em> 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.</p>
<h2 id="focus-nav">Enabling Focus Navigation</h2>
<p>Focus navigation allows users with disabilities to step through user interface controls using a
directional controller. Directional controllers can be physical, such as a clickable trackball,
directional pad (D-pad) or arrow keys, tab key navigation with an attached keyboard or a software
application, such as the
directional controller. Directional controllers can be physical, such as a trackball, directional
pad (D-pad) or arrow keys, or virtual, such as the
<a href="https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.inputmethod.latin">
Eyes-Free Keyboard</a>, that provides an on-screen directional control.</p>
Eyes-Free Keyboard</a>, or the gestures navigation mode available in Android 4.1 and higher.
Directional controllers are a primary means of navigation for many Android users.
</p>
<p>To ensure that users can navigate your application using only a directional controller, verify
that all user interface (UI) input controls in your application can be reached and activated
without using the touchscreen. You should also verify that clicking with the center button (or OK
button) of a directional controller has the same effect as touching a control that already has
focus. For information on testing directional controls, see
<a href="{@docRoot}tools/testing/testing_accessibility.html#test-navigation">Testing
focus navigation</a>.</p>
<p>A directional controller is a primary means of navigation for many users.
Verify that all user interface (UI) controls in your application are accessible
without using the touchscreen and that clicking with the center button (or OK button) of a
directional controller has the same effect as touching the controls on the touchscreen. For
information on testing directional controls, see <a href="#test-navigation">Testing focus
navigation</a>.</p>
<h3 id="focus-enable">Enabling view focus</h3>
<p>A user interface element is accessible using directional controls when its
<p>A user interface element is reachable using directional controls when its
<a href="{@docRoot}reference/android/view/View.html#attr_android:focusable">
{@code android:focusable}</a> attribute is set to {@code true}. This setting allows users to focus
on the element using the directional controls and then interact with it. The user interface controls
@@ -149,44 +171,44 @@ and even request that a control be given focus:</p>
<li>{@link android.view.View#requestFocus requestFocus()}</li>
</ul>
<p>When working with a view that is not focusable by default, you can make it focusable from the XML
layout file by setting the
<a href="{@docRoot}reference/android/view/View.html#attr_android:focusable">
{@code android:focusable}</a> attribute to {@code true} or by using the {@link
<p>If a view is not focusable by default, you can make it focusable in your layout file by setting
the <a href="{@docRoot}reference/android/view/View.html#attr_android:focusable">
{@code android:focusable}</a> attribute to {@code true} or by calling the its {@link
android.view.View#setFocusable setFocusable()} method.</p>
<h3 id="focus-order">Controlling focus order</h3>
<p>When users navigate in any direction using directional controls, focus is passed from one
user interface element (View) to another, as determined by the focus ordering. The ordering of the
focus movement is based on an algorithm that finds the nearest neighbor in a given direction. In
rare cases, the default algorithm may not match the order that you intended for your UI. In these
situations, you can provide explicit overrides to the ordering using the following XML attributes in
the layout file:</p>
user interface element (view) to another, as determined by the focus order. This order is based on
an algorithm that finds the nearest neighbor in a given direction. In rare cases, the algorithm may
not match the order that you intended or may not be logical for users. In these situations, you can
provide explicit overrides to the ordering using the following XML attributes in your layout file:
</p>
<dl>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown"
>{@code android:nextFocusDown}</a></dt>
<dd>Defines the next view to receive focus when the user navigates down.</dd>
<a><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusLeft"
>{@code android:nextFocusLeft}</a></dt>
<dd>Defines the next view to receive focus when the user navigates left.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusRight"
>{@code android:nextFocusRight}</a></dt>
<dd>Defines the next view to receive focus when the user navigates right.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp"
>{@code android:nextFocusUp}</a></dt>
<dd>Defines the next view to receive focus when the user navigates up.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown">
{@code android:nextFocusDown}</a></dt>
<dd>Defines the next view to receive focus when the user navigates down.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusLeft">
{@code android:nextFocusLeft}</a></dt>
<dd>Defines the next view to receive focus when the user navigates left.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusRight">
{@code android:nextFocusRight}</a></dt>
<dd>Defines the next view to receive focus when the user navigates right.</dd>
<dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp">
{@code android:nextFocusUp}</a></dt>
<dd>Defines the next view to receive focus when the user navigates up.</dd>
</dl>
<p>The following example XML layout shows two focusable user interface elements where the <a
href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown"
>{@code android:nextFocusDown}</a> and <a
href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp"
>{@code android:nextFocusUp}</a> attributes have been explicitly set. The {@link android.widget.TextView} is
<p>The following example XML layout shows two focusable user interface elements where the
<a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown">{@code
android:nextFocusDown}</a> and
<a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp">{@code
android:nextFocusUp}</a> attributes have been explicitly set. The {@link android.widget.TextView} is
located to the right of the {@link android.widget.EditText}. However, since these properties have
been set, the {@link android.widget.TextView} element can now be reached by pressing the down arrow
when focus is on the {@link android.widget.EditText} element: </p>
when focus is on the {@link android.widget.EditText} element:</p>
<pre>
&lt;LinearLayout android:orientation="horizontal"
@@ -218,8 +240,9 @@ These are the main tasks for ensuring the accessibility of your view:</p>
<ul>
<li>Handle directional controller clicks</li>
<li>Implement Accessibility API methods</li>
<li>Send {@link android.view.accessibility.AccessibilityEvent} objects specific to your custom view</li>
<li>Implement accessibility API methods</li>
<li>Send {@link android.view.accessibility.AccessibilityEvent} objects specific to your custom
view</li>
<li>Populate {@link android.view.accessibility.AccessibilityEvent} and {@link
android.view.accessibility.AccessibilityNodeInfo} for your view</li>
</ul>
@@ -243,9 +266,9 @@ full keyboard much easier for users.</p>
<p>Accessibility events are messages about users interaction with visual interface components in
your application. These messages are handled by <a href="services.html">Accessibility Services</a>,
which use the information in these events to produce supplemental feedback and prompts when users
have enabled accessibility services. As of Android 4.0 (API Level 14) and higher, the methods for
generating accessibility events have been expanded to provide more detailed information beyond the
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 the
{@link android.view.accessibility.AccessibilityEventSource} interface introduced in Android 1.6 (API
Level 4). The expanded accessibility methods are part of the {@link android.view.View} class as well
as the {@link android.view.View.AccessibilityDelegate} class. The methods are as follows:</p>
@@ -262,12 +285,12 @@ sendAccessibilityEventUnchecked()}</dt>
<dd>(API Level 4) This method is used when the calling code needs to directly control the check
for accessibility being enabled on the device ({@link
android.view.accessibility.AccessibilityManager#isEnabled AccessibilityManager.isEnabled()}). If
you do implement this method, you must assume that the calling method has already checked that
accessibility is enabled and the result is {@code true}. You typically do not need to implement this
method for a custom view.</dd>
you do implement this method, you must perform the call as if accessibility is enabled, regardless
of the actual system setting. You typically do not need to implement this method for a custom view.
</dd>
<dt>{@link android.view.View#dispatchPopulateAccessibilityEvent
dispatchPopulateAccessibilityEvent()} </dt>
dispatchPopulateAccessibilityEvent()}</dt>
<dd>(API Level 4) The system calls this method when your custom view generates an
accessibility event. As of API Level 14, the default implementation of this method calls {@link
android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} for this view and
@@ -276,21 +299,21 @@ dispatchPopulateAccessibilityEvent()} method for each child of this view. In ord
accessibility services on revisions of Android <em>prior</em> to 4.0 (API Level 14) you
<em>must</em> override this method and populate {@link
android.view.accessibility.AccessibilityEvent#getText} with descriptive text for your custom
view.</dd>
view, which is spoken by accessibility services, such as TalkBack.</dd>
<dt>{@link android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()}</dt>
<dd>(API Level 14) This method sets the text output of an {@link
<dd>(API Level 14) This method sets the spoken text prompt of the {@link
android.view.accessibility.AccessibilityEvent} for your view. This method is also called if the
view is a child of a view which generates an accessibility event.
<p class="note"><strong>Note:</strong> Modifying additional attributes beyond the text within
this method potentially overwrites properties set by other methods. So, while you are able modify
this method potentially overwrites properties set by other methods. While you can modify
attributes of the accessibility event with this method, you should limit these changes
to text content only and use the {@link android.view.View#onInitializeAccessibilityEvent
to text content, and use the {@link android.view.View#onInitializeAccessibilityEvent
onInitializeAccessibilityEvent()} method to modify other properties of the event.</p>
<p class="note"><strong>Note:</strong> If your implementation of this event calls for completely
overiding the output text without allowing other parts of your layout to modify its content, then
<p class="note"><strong>Note:</strong> If your implementation of this event completely
overrides the output text without allowing other parts of your layout to modify its content, then
do not call the super implementation of this method in your code.</p>
</dd>
@@ -306,7 +329,7 @@ that have not been set by the super class.</dd>
<dt>{@link android.view.View#onInitializeAccessibilityNodeInfo
onInitializeAccessibilityNodeInfo()}</dt>
<dd>(API Level 14) This method provides accessibility services with information about the state of
the view. The default {@link android.view.View} implementation sets a standard set of view
the view. The default {@link android.view.View} implementation has a standard set of view
properties, but if your custom view provides interactive control beyond a simple {@link
android.widget.TextView} or {@link android.widget.Button}, you should override this method and set
the additional information about your view into the {@link
@@ -315,7 +338,7 @@ android.view.accessibility.AccessibilityNodeInfo} object handled by this method.
<dt>{@link android.view.ViewGroup#onRequestSendAccessibilityEvent
onRequestSendAccessibilityEvent()}</dt>
<dd>(API Level 14) The system calls this method when a child of your view has generated an
{@link android.view.accessibility.AccessibilityEvent}. This step allows the the parent view to amend
{@link android.view.accessibility.AccessibilityEvent}. This step allows the parent view to amend
the accessibility event with additional information. You should implement this method only if your
custom view can have child views and if the parent view can provide context information to the
accessibility event that would be useful to accessibility services.</dd>
@@ -333,7 +356,7 @@ higher, to your project. Then, within your custom view class, call the
{@link android.support.v4.view.ViewCompat#setAccessibilityDelegate
ViewCompat.setAccessibilityDelegate()} method to implement the accessibility methods
above. For an example of this approach, see the Android Support Library (revision 5 or higher)
sample {@code AccessibilityDelegateSupportActivity} in
sample {@code AccessibilityDelegateSupportActivity} in
({@code &lt;sdk&gt;/extras/android/support/v4/samples/Support4Demos/})
</li>
</ul>
@@ -446,20 +469,20 @@ public void dispatchPopulateAccessibilityEvent(AccessibilityEvent event) {
}
</pre>
<p>On Android 4.0 (API Level 14) and higher, the {@link
<p>For Android 4.0 (API Level 14) and higher, use the {@link
android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} and
{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()}
methods are the recommended way to populate or modify the information in an {@link
android.view.accessibility.AccessibilityEvent}. Use the
methods to populate or modify the information in an {@link
android.view.accessibility.AccessibilityEvent}. Use the
{@link android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} method
specifically for adding or modifying the text content of the event, which is turned into audible
prompts by accessibility services such as TalkBack. Use the
{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()} method for
populating additional information about the event, such as the selection state of the view.</p>
<p>In addition, you should also implement the
<p>In addition, implement the
{@link android.view.View#onInitializeAccessibilityNodeInfo onInitializeAccessibilityNodeInfo()}
method. {@link android.view.accessibility.AccessibilityNodeInfo} objects populated by this method
method. The {@link android.view.accessibility.AccessibilityNodeInfo} objects populated by this method
are used by accessibility services to investigate the view hierarchy that generated an accessibility
event after receiving that event, to obtain a more detailed context information and provide
appropriate feedback to users.</p>
@@ -467,8 +490,8 @@ appropriate feedback to users.</p>
<p>The example code below shows how override these three methods by using
{@link android.support.v4.view.ViewCompat#setAccessibilityDelegate
ViewCompat.setAccessibilityDelegate()}. Note that this sample code requires that the Android
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> for API Level 4 (revision 5
or higher) is added to your project.</p>
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> for API Level 4 (revision
5 or higher) is added to your project.</p>
<pre>
ViewCompat.setAccessibilityDelegate(new AccessibilityDelegateCompat() {
@@ -509,10 +532,10 @@ ViewCompat.setAccessibilityDelegate(new AccessibilityDelegateCompat() {
}
</pre>
<p>On applications targeting Android 4.0 (API Level 14) and higher, these methods can be implemented
<p>In applications targeting Android 4.0 (API Level 14) and higher, you can implement these methods
directly in your custom view class. For another example of this approach, see the Android
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> (revision 5 or higher) sample
{@code AccessibilityDelegateSupportActivity} in
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> (revision 5 or higher)
sample {@code AccessibilityDelegateSupportActivity} in
({@code &lt;sdk&gt;/extras/android/support/v4/samples/Support4Demos/}).</p>
<p class="note"><strong>Note:</strong> You may find information on implementing accessibility for
@@ -525,50 +548,141 @@ approach is to use the
methods.</p>
<h3 id="virtual-hierarchy">Providing a customized accessibility context</h3>
<p>In Android 4.0 (API Level 14), the framework was enhanced to allow accessibility services to
inspect the containing view hierarchy of a user interface component that generates an
accessibility event. This enhancement allows accessibility services to provide a much richer set
of contextual information with which to aid users.</p>
<p>There are some cases where accessibility services cannot get adequate information
from the view hierarchy. An example of this is a custom interface control that has two or more
separately clickable areas, such as a calendar control. In this case, the services cannot get
adequate information because the clickable subsections are not part of the view hierarchy.</p>
<img src="calendar.png" alt="" id="figure1" />
<p class="img-caption">
<strong>Figure 1.</strong> A custom calendar view with selectable day elements.
</p>
<p>In the example shown in Figure 1, the entire calendar is implemented as a single view, so if you
do not do anything else, accessibility services do not receive enough information about the
content of the view and the user's selection within the view. For example, if a user clicks on the
day containing <strong>17</strong>, the accessibility framework only receives the description
information for the whole calendar control. In this case, the TalkBack accessibility service would
simply announce "Calendar" or, only slightly better, "April Calendar" and the user would be left
to wonder what day was selected.</p>
<p>To provide adequate context information for accessibility services in situations like this,
the framework provides a way to specify a virtual view hierarchy. A <em>virtual view
hierarchy</em> is a way for application developers to provide a complementary view hierarchy
to accessibility services that more closely matches the actual information on screen. This
approach allows accessibility services to provide more useful context information to users.</p>
<p>Another situation where a virtual view hierarchy may be needed is a user interface containing
a set of controls (views) that have closely related functions, where an action on one control
affects the contents of one or more elements, such as a number picker with separate up and down
buttons. In this case, accessibility services cannot get adequate information because action on
one control changes content in another and the relationship of those controls may not be apparent
to the service. To handle this situation, group the related controls with a containing view and
provide a virtual view hierarchy from this container to clearly represent the information and
behavior provided by the controls.</p>
<p>In order to provide a virtual view hierarchy for a view, override the {@link
android.view.View#getAccessibilityNodeProvider} method in your custom view or view group and
return an implementation of {@link android.view.accessibility.AccessibilityNodeProvider}. For an
example implementation of this accessibility feature, see
{@code AccessibilityNodeProviderActivity} in the ApiDemos sample project. You can implement a
virtual view hierarchy that is compatible with Android 1.6 and later by using the
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> with the
{@link android.support.v4.view.ViewCompat#getAccessibilityNodeProvider
ViewCompat.getAccessibilityNodeProvider()} method and providing an implementation with
{@link android.support.v4.view.accessibility.AccessibilityNodeProviderCompat}.</p>
<h3 id="custom-touch-events">Handling custom touch events</h3>
<p>Custom view controls may require non-standard touch event behavior. For example, a custom
control may use the {@link android.view.View#onTouchEvent} listener method to detect the
{@link android.view.MotionEvent#ACTION_DOWN} and {@link android.view.MotionEvent#ACTION_UP} events
and trigger a special click event. In order to maintain compatibility with accessibility services,
the code that handles this custom click event must do the following:</p>
<ol>
<li>Generate an appropriate {@link android.view.accessibility.AccessibilityEvent} for the
interpreted click action.</li>
<li>Enable accessibility services to perform the custom click action for users who are not able to
use a touch screen.</li>
</ol>
<p>To handle these requirements in an efficient way, your code should override the
{@link android.view.View#performClick} method, which must call the super implementation of this
method and then execute whatever actions are required by the click event. When the custom click
action is detected, that code should then call your {@code performClick()} method. The following
code example demonstrates this pattern.</p>
<pre>
class CustomTouchView extends View {
public CustomTouchView(Context context) {
super(context);
}
boolean mDownTouch = false;
&#64;Override
public boolean onTouchEvent(MotionEvent event) {
super.onTouchEvent(event);
// Listening for the down and up touch events
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
mDownTouch = true;
return true;
case MotionEvent.ACTION_UP:
if (mDownTouch) {
mDownTouch = false;
performClick(); // Call this method to handle the response, and
// thereby enable accessibility services to
// perform this action for a user who cannot
// click the touchscreen.
return true;
}
}
return false; // Return false for other touch events
}
&#64;Override
public boolean performClick() {
// Calls the super implementation, which generates an AccessibilityEvent
// and calls the onClick() listener on the view, if any
super.performClick();
// Handle the action for the custom click here
return true;
}
}
</pre>
<p>The pattern shown above makes sure that the custom click event is compatible with
accessibility services by using the {@link android.view.View#performClick} method to both generate
an accessibility event and provide an entry point for accessibility services to act on behalf of a
user to perform this custom click event.</p>
<p class="note"><strong>Note:</strong> If your custom view has distinct clickable regions, such as
a custom calendar view, you must implement a <a href="#virtual-hierarchy">virtual view
hierarchy</a> by overriding {@link android.view.View#getAccessibilityNodeProvider} in your custom
view in order to be compatible with accessibility services.</p>
<h2 id="test">Testing Accessibility</h2>
<p>Testing the accessibility of your application is an important part of ensuring your users have a
great experience. You can test the most important parts of accessibility by testing your application
with audible feedback enabled and testing navigation within your application using directional
controls.</p>
great experience. You can test the most important accessibility features by using your application
with audible feedback enabled and navigating within your application using only directional
controls. For more information on testing accessibility in your application, see the
<a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing Checklist</a>.
</p>
<h3 id="test-audibles">Testing audible feedback</h3>
<p>You can simulate the experience for many users by enabling an accessibility service that speaks
as you move around the screen. The Explore by Touch accessibility service, which is available on
devices with Android 4.0 and later. The <a
href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a>
accessibility service, by the <a href="http://code.google.com/p/eyes-free/">Eyes-Free
Project</a> comes preinstalled on many Android devices.</p>
<p>To enable TalkBack on revisions of Android prior to Android 4.0:</p>
<ol>
<li>Launch the Settings application.</li>
<li>Navigate to the <strong>Accessibility</strong> category and select it.</li>
<li>Select <strong>Accessibility</strong> to enable it.</li>
<li>Select <strong>TalkBack</strong> to enable it.</li>
</ol>
<p class="note"><strong>Note:</strong> If the TalkBack accessibility service is not available, you
can install it for free from <a href="http://play.google.com">Google Play</a>.</p>
<p>To enable Explore by Touch on Android 4.0 and later:</p>
<ol>
<li>Launch the Settings application.</li>
<li>Navigate to the <strong>Accessibility</strong> category and select it.</li>
<li>Select the <strong>TalkBack</strong> to enable it.</li>
<li>Return to the <strong>Accessibility</strong> category and select <strong>Explore by
Touch</strong> to enable it.
<p class="note"><strong>Note:</strong> You must turn on TalkBack <em>first</em>, otherwise this
option is not available.</p>
</li>
</ol>
<h3 id="test-navigation">Testing focus navigation</h3>
<p>As part of your accessibility testing, you can test navigation of your application using focus,
even if your test devices does not have a directional controller. The <a
href="{@docRoot}tools/help/emulator.html">Android Emulator</a> provides a
simulated directional controller that you can easily use to test navigation. You can also use a
software-based directional controller, such as the one provided by the
<a href="https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.inputmethod.latin">
Eyes-Free Keyboard</a> to simulate use of a D-pad.</p>

BIN
docs/html/guide/topics/ui/accessibility/calendar.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

173
docs/html/guide/topics/ui/accessibility/checklist.jd Normal file
View File

@@ -0,0 +1,173 @@
page.title=Accessibility Developer Checklist
parent.title=Accessibility
parent.link=index.html
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol>
<li><a href="#requirements">Accessibility Requirements</a></li>
<li><a href="#recommendations">Accessibility Recommendations</a></li>
<li><a href="#special-cases">Special Cases and Considerations</a></li>
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li>
<li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing Checklist</a></li>
<li><a href="{@docRoot}training/accessibility/index.html">Training: Implementing Accessibility</a></li>
<li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a></li>
</ol>
</div>
</div>
<p>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.</p>
<p>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:</p>
<ul>
<li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li>
<li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing
Checklist</a></li>
</ul>
<p>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.</p>
<h2 id="requirements">Accessibility Requirements</h2>
<p>The following steps must be completed in order to ensure a minimum level of application
accessibility.</p>
<ol>
<li><strong>Describe user interface controls:</strong> Provide content
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html#label-ui">descriptions</a> for user
interface components that do not have visible text, particularly
{@link android.widget.ImageButton}, {@link android.widget.ImageView}
and {@link android.widget.CheckBox} components. Use the
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> XML layout attribute or the {@link
android.view.View#setContentDescription} method to provide this information for accessibility
services. (Exception: <a href="#decorative">decorative graphics</a>)</li>
<li><strong>Enable focus-based navigation:</strong> Make sure
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html#focus-nav">users can navigate</a>
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
<a href="{@docRoot}reference/android/view/View.html#attr_android:focusable">focusable</a>
or change the <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#focus-order">focus
order</a> to be more logical for user actions.</li>
<li><strong>Custom view controls:</strong> If you build
<a href="{@docRoot}guide/topics/ui/custom-components.html">custom interface controls</a> for
your application, <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#custom-views">
implement accessibility interfaces</a> 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 <a href="{@docRoot}tools/extras/support-library.html">Support Library</a> to implement
the latest accessibility features.</li>
<li><strong>No audio-only feedback:</strong> 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
{@link android.app.Notification}, haptic feedback (if available) or other visual alert.</li>
<li><strong>Test:</strong> Test accessibility by navigating your application
using directional controls, and using eyes-free navigation with TalkBack enabled.
For more accessibility testing information, see the
<a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing
Checklist</a>.</li>
</ol>
<h2 id="recommendations">Accessibility Recommendations</h2>
<p>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.</p>
<ol>
<li><strong>Android Design Accessibility Guidelines:</strong> Before building your layouts,
review and follow the accessibility guidelines provided in the
<a href="{@docRoot}design/patterns/accessibility.html">Design guidelines</a>.</li>
<li><strong>Framework-provided controls:</strong> Use Android's built-in user interface
controls whenever possible, as these components provide accessibility support by default.</li>
<li><strong>Temporary or self-hiding controls and notifications:</strong> 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.</li>
</ol>
<h2 id="special-cases">Special Cases and Considerations</h2>
<p>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.</p>
<ol>
<li><strong>Text field hints:</strong> For {@link android.widget.EditText} fields, provide an
<a href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">android:hint</a>
attribute <em>instead</em> 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.</li>
<li><strong>Custom controls with high visual context:</strong> If your application contains a
<a href="{@docRoot}guide/topics/ui/custom-components.html">custom control</a> 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
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html#virtual-hierarchy">virtual
view hierarchy</a> for your control using
{@link android.view.accessibility.AccessibilityNodeProvider}.</li>
<li><strong>Custom controls and click handling:</strong> If a custom control in your
application performs specific handling of user touch interaction, such as listening with
{@link android.view.View#onTouchEvent} for {@link android.view.MotionEvent#ACTION_DOWN
MotionEvent.ACTION_DOWN} and {@link android.view.MotionEvent#ACTION_UP MotionEvent.ACTION_UP}
and treating it as a click event, you must trigger an {@link
android.view.accessibility.AccessibilityEvent} equivalent to a click and provide a way for
accessibility services to perform this action for users. For more information, see
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html#custom-touch-events">Handling custom
touch events</a>.</li>
<li><strong>Controls that change function:</strong> 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 <strong>Play</strong> to <strong>Pause</strong>), make sure you also
change the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">
{@code android:contentDescription}</a> of the button appropriately.</li>
<li><strong>Prompts for related controls:</strong> Make sure sets of controls which provide a
single function, such as the {@link android.widget.DatePicker}, provide useful audio feedback
when an user interacts with the individual controls.</li>
<li><strong>Video playback and captioning:</strong> 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.</li>
<li><strong>Supplemental accessibility audio feedback:</strong> Use only the Android accessibility
framework to provide accessibility audio feedback for your app. Accessibility services such as
<a href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback"
>TalkBack</a> should be the only way your application provides accessibility audio prompts to
users. Provide the prompting information with a
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code
android:contentDescription}</a> 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 {@link
android.view.View#announceForAccessibility} method to have accessibility services speak this
information to the user.</li>
<li><strong>Custom controls with complex visual interactions:</strong> For custom controls that
provide complex or non-standard visual interactions, provide a
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html#virtual-hierarchy">virtual view
hierarchy</a> for your control using {@link android.view.accessibility.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.</li>
<li><strong>Sets of small controls:</strong> If you have controls that are smaller than
the minimum recommended touch size in your application screens, consider grouping these controls
together using a {@link android.view.ViewGroup} and providing a
<a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code
android:contentDescription}</a> for the group.</li>
<li id="decorative"><strong>Decorative images and graphics:</strong> 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.</li>
</ol>

62
docs/html/guide/topics/ui/accessibility/index.jd
View File

@@ -8,47 +8,67 @@ parent.link=../index.html
<h2>Topics</h2>
<ol>
<li><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">Making Applications Accessible</a>
</li>
<li><a href="{@docRoot}guide/topics/ui/accessibility/services.html">Building Accessibility
Services</a></li>
<li><a href="apps.html">
Making Applications Accessible</a></li>
<li><a href="checklist.html">
Accessibility Developer Checklist</a></li>
<li><a href="services.html">
Building Accessibility Services</a></li>
</ol>
<h2>Key classes</h2>
<ol>
<li>{@link android.view.accessibility.AccessibilityEvent}</li>
<li>{@link android.accessibilityservice.AccessibilityService}</li>
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li>
<li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li>
<li><a href="{@docRoot}training/accessibility/index.html">Training: Implementing Accessibility</a></li>
<li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing Checklist</a></li>
</ol>
<h2>Related Videos</h2>
<ol>
<li>
<iframe title="Google I/O 2012 - Making Android Apps Accessible"
width="210" height="160"
src="http://www.youtube.com/embed/q3HliaMjL38?rel=0&amp;hd=1"
frameborder="0" allowfullscreen>
</iframe>
<li>
</ol>
</div>
</div>
<p>Many Android users have disabilities that require them to interact with their Android devices in
different ways. These include users who have visual, physical or age-related disabilities that
prevent them from fully seeing or using a touchscreen.</p>
<p>Many Android users have different abilities that require them to interact with their Android
devices in different ways. These include users who have visual, physical or age-related limitations
that prevent them from fully seeing or using a touchscreen, and users with hearing loss who may not
be able to perceive audible information and alerts.</p>
<p>Android provides accessibility features and services for helping these users navigate their
devices more easily, including text-to-speech, haptic feedback, trackball and D-pad navigation that
augment their experience. Android application developers can take advantage of these services to
make their applications more accessible and also build their own accessibility services.</p>
devices more easily, including text-to-speech, haptic feedback, gesture navigation, trackball and
directional-pad navigation. Android application developers can take advantage of these services to
make their applications more accessible.</p>
<p>Android developers can also build their own accessibility services, which can provide
enhanced usability features such as audio prompting, physical feedback, and alternative navigation
modes. Accessibility services can provide these enhancements for all applications, a set of
applications or just a single app.</p>
<p>The following topics show you how to use the Android framework to make applications more
accessible.</p>
<dl>
<dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">Making Applications
Accessible</a></strong>
<dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">
Making Applications Accessible</a></strong>
</dt>
<dd>Development practices and API features to ensure your application is accessible to users with
disabilities.</dd>
<dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/services.html">Building Accessibility
Services</a></strong>
<dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/checklist.html">
Accessibility Developer Checklist</a></strong>
</dt>
<dd>A checklist to help developers ensure that their applications are accessible.</dd>
<dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/services.html">
Building Accessibility Services</a></strong>
</dt>
<dd>How to use API features to build services that make other applications more accessible for
users.</dd>

273
docs/html/guide/topics/ui/accessibility/services.jd
View File

@@ -14,8 +14,16 @@ parent.link=index.html
<li><a href="#service-config">Accessibility service configuration</a></li>
</ol>
</li>
<li><a href="#register">Registering for Accessibility Events</a></li>
<li><a href="#methods">AccessibilityService Methods</a></li>
<li><a href="#event-details">Getting Event Details</a></li>
<li><a href="#act-for-users">Taking Action for Users</a>
<ol>
<li><a href="#detect-gestures">Listening for gestures</a></li>
<li><a href="#using-actions">Using accessibility actions</a></li>
<li><a href="#focus-types">Using focus types</a></li>
</ol>
</li>
<li><a href="#examples">Example Code</a></li>
</ol>
@@ -30,7 +38,7 @@ parent.link=index.html
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li>
<li><a href="{@docRoot}training/accessibility/index.html">Training: Implementing Accessibility</a></li>
</ol>
</div>
@@ -45,20 +53,20 @@ might need additional or alternative interface feedback.</p>
create and distribute their own services. This document explains the basics of building an
accessibility service.</p>
<p>The ability for you to build and deploy accessibility services was introduced with Android
1.6 (API Level 4) and received significant improvements with Android 4.0 (API Level 14). The Android
Support Library was also updated with the release of Android 4.0 to provide support for these
enhanced accessibility features back to Android 1.6. Developers aiming for widely compatible
accessibility services are encouraged to use the
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> and develop for the more
advanced accessibility features introduced in Android 4.0.</p>
<p>The ability for you to build and deploy accessibility services was introduced with Android 1.6
(API Level 4) and received significant improvements with Android 4.0 (API Level 14). The Android
<a href="{@docRoot}tools/extras/support-library.html">Support Library</a> was also updated with
the release of Android 4.0 to provide support for these enhanced accessibility features back to
Android 1.6. Developers aiming for widely compatible accessibility services are encouraged to use
the Support Library and develop for the more advanced accessibility features introduced in
Android 4.0.</p>
<h2 id="manifest">Manifest Declarations and Permissions</h2>
<p>Applications that provide accessibility services must include specific declarations in their
application manifests in order to be treated as an accessibility service by an Android system.
This section explains the required and optional settings for accessibility services.</p>
application manifests to be treated as an accessibility service by the Android system. This
section explains the required and optional settings for accessibility services.</p>
<h3 id="service-declaration">Accessibility service declaration</h3>
@@ -66,7 +74,9 @@ advanced accessibility features introduced in Android 4.0.</p>
<p>In order to be treated as an accessibility service, your application must include the
{@code service} element (rather than the {@code activity} element) within the {@code application}
element in its manifest. In addition, within the {@code service} element, you must also include an
accessibility service intent filter, as shown in the following sample:</p>
accessibility service intent filter. For compatiblity with Android 4.1 and higher, the manifest
must also request the {@link android.Manifest.permission#BIND_ACCESSIBILITY_SERVICE} permission
as shown in the following sample:</p>
<pre>
&lt;application&gt;
@@ -76,6 +86,7 @@ accessibility service intent filter, as shown in the following sample:</p>
&lt;action android:name=&quot;android.accessibilityservice.AccessibilityService&quot; /&gt;
&lt;/intent-filter&gt;
&lt;/service&gt;
&lt;uses-permission android:name="android.permission.BIND_ACCESSIBILITY_SERVICE" /&gt;
&lt;/application&gt;
</pre>
@@ -123,27 +134,6 @@ shows example contents for the service configuration file:</p>
/&gt;
</pre>
<p>One of the most important functions of the accessibility service configuration parameters is to
allow you to specify what types of accessibility events your service can handle. Being able to
specify this information enables accessibility services to cooperate with each other, and allows you
as a developer the flexibility to handle only specific events types from specific applications. The
event filtering can include the following criteria:</p>
<ul>
<li><strong>Package Names</strong> - Specify the package names of applications whose accessibility
events you want your service to handle. If this parameter is omitted, your accessibility service is
considered available to service accessibility events for any application. This parameter can be set
in the accessibility service configuration files with the {@code android:packageNames} attribute as
a comma-separated list, or set using the {@link
android.accessibilityservice.AccessibilityServiceInfo#packageNames
AccessibilityServiceInfo.packageNames} member.</li>
<li><strong>Event Types</strong> - Specify the types of accessibility events you want your service
to handle. This parameter can be set in the accessibility service configuration files with the
{@code android:accessibilityEventTypes} attribute as a comma-separated list, or set using the
{@link android.accessibilityservice.AccessibilityServiceInfo#eventTypes
AccessibilityServiceInfo.eventTypes} member. </li>
</ul>
<p>For more information about the XML attributes which can be used in the accessibility service
configuration file, follow these links to the reference documentation:</p>
@@ -162,9 +152,45 @@ AccessibilityServiceInfo.eventTypes} member. </li>
the {@link android.accessibilityservice.AccessibilityServiceInfo} reference documentation.</p>
<h2 id="register">Registering for Accessibility Events</h2>
<p>One of the most important functions of the accessibility service configuration parameters is to
allow you to specify what types of accessibility events your service can handle. Being able to
specify this information enables accessibility services to cooperate with each other, and allows you
as a developer the flexibility to handle only specific events types from specific applications. The
event filtering can include the following criteria:</p>
<ul>
<li><strong>Package Names</strong> - Specify the package names of applications whose accessibility
events you want your service to handle. If this parameter is omitted, your accessibility service is
considered available to service accessibility events for any application. This parameter can be set
in the accessibility service configuration files with the {@code android:packageNames} attribute as
a comma-separated list, or set using the {@link
android.accessibilityservice.AccessibilityServiceInfo#packageNames
AccessibilityServiceInfo.packageNames} member.</li>
<li><strong>Event Types</strong> - Specify the types of accessibility events you want your service
to handle. This parameter can be set in the accessibility service configuration files with the
{@code android:accessibilityEventTypes} attribute as a list separated by the {@code |} character
(for example {@code accessibilityEventTypes="typeViewClicked|typeViewFocused"}), or set using the
{@link android.accessibilityservice.AccessibilityServiceInfo#eventTypes
AccessibilityServiceInfo.eventTypes} member. </li>
</ul>
<p>When setting up your accessibility service, carefully consider what events your service is able
to handle and only register for those events. Since users can activate more than one accessibility
services at a time, your service must not consume events that it is not able to handle. Remember
that other services may handle those events in order to improve a user's experience.</p>
<p class="note"><strong>Note:</strong> The Android framework dispatches accessibility events to
more than one accessibility service if the services provide different
<a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_accessibilityFeedbackType">
feedback types</a>. However, if two or more services provide the same feedback type, then only the
first registered service receives the event.</p>
<h2 id="methods">AccessibilityService Methods</h2>
<p>An application that provides accessibility service must extend the {@link
<p>An accessibility service must extend the {@link
android.accessibilityservice.AccessibilityService} class and override the following methods from
that class. These methods are presented in the order in which they are called by the Android system,
from when the service is started
@@ -188,15 +214,15 @@ onAccessibilityEvent()} - (required) This method is called back by the system wh
{@link android.view.accessibility.AccessibilityEvent} that matches the event filtering parameters
specified by your accessibility service. For example, when the user clicks a button or focuses on a
user interface control in an application for which your accessibility service is providing feedback.
When this happens, the system calls this method of your service with the associated {@link
android.view.accessibility.AccessibilityEvent}, which you can then interpret and provide feedback to
the user. This method may be called many times over the lifecycle of your service.</li>
When this happens, the system calls this method, passing the associated {@link
android.view.accessibility.AccessibilityEvent}, which the service can then interpret and use to
provide feedback to the user. This method may be called many times over the lifecycle of your
service.</li>
<li>{@link android.accessibilityservice.AccessibilityService#onInterrupt onInterrupt()} -
(required) This method is called when the system wants to interrupt the feedback your service is
providing, usually in response to a user taking action, such as moving focus to a different user
interface control than the one for which you are currently providing feedback. This method may be
called many times over the lifecycle of your service.</li>
providing, usually in response to a user action such as moving focus to a different control. This
method may be called many times over the lifecycle of your service.</li>
<li>{@link android.accessibilityservice.AccessibilityService#onUnbind onUnbind()} - (optional)
This method is called when the system is about to shutdown the accessibility service. Use this
@@ -206,7 +232,9 @@ services, such as the audio manager or device vibrator.</li>
<p>These callback methods provide the basic structure for your accessibility service. It is up to
you to decide on how to process data provided by the Android system in the form of {@link
android.view.accessibility.AccessibilityEvent} objects and provide feedback to the user.</p>
android.view.accessibility.AccessibilityEvent} objects and provide feedback to the user. For more
information about getting information from an accessibility event, see the
<a href="{@docRoot}training/accessibility/service.html">Implementing Accessibility</a> training.</p>
<h2 id="event-details">Getting Event Details</h2>
@@ -214,15 +242,15 @@ android.view.accessibility.AccessibilityEvent} objects and provide feedback to t
<p>The Android system provides information to accessibility services about the user interface
interaction through {@link android.view.accessibility.AccessibilityEvent} objects. Prior to Android
4.0, the information available in an accessibility event, while providing a significant amount of
detail about a user interface control selected by the user, typically provided limited contextual
detail about a user interface control selected by the user, offered limited contextual
information. In many cases, this missing context information might be critical to understanding the
meaning of the selected control.</p>
<p>A typical example of an interface where context is of critical importance is a calendar or day
planner. If a user selects a 4:00 PM time slot in a Monday to Friday day list and the accessibility
service announces “4 PM”, but fails to indicate this is a Friday a Monday, the month or day, this is
hardly ideal feedback for the user. In this case, the context of a user interface control is of
critical importance to a user who wants to schedule a meeting.</p>
<p>An example of an interface where context is critical is a calendar or day planner. If the
user selects a 4:00 PM time slot in a Monday to Friday day list and the accessibility service
announces “4 PM”, but does not announce the weekday name, the day of the month, or the month name,
the resulting feedback is confusing. In this case, the context of a user interface control is
critical to a user who wants to schedule a meeting.</p>
<p>Android 4.0 significantly extends the amount of information that an accessibility service can
obtain about an user interface interaction by composing accessibility events based on the view
@@ -245,26 +273,167 @@ can obtain additional information about the event using these calls:</p>
AccessibilityEvent.getRecordCount()} and {@link
android.view.accessibility.AccessibilityEvent#getRecord getRecord(int)} - These methods allow you to
retrieve the set of {@link android.view.accessibility.AccessibilityRecord} objects which contributed
to the {@link android.view.accessibility.AccessibilityEvent} passed to you by the system, which can
provide more context for your accessibility service.</li>
to the {@link android.view.accessibility.AccessibilityEvent} passed to you by the system. This level
of detail provides more context for the event that triggered your accessibility service.</li>
<li>{@link android.view.accessibility.AccessibilityEvent#getSource
AccessibilityEvent.getSource()} - This method returns an {@link
android.view.accessibility.AccessibilityNodeInfo} object. This object allows you to request the
parents and children of the component that originated the accessibility event and investigate their
contents and state in order to provide
android.view.accessibility.AccessibilityNodeInfo} object. This object allows you to request view
layout hierarchy (parents and children) of the component that originated the accessibility event.
This feature allows an accessibility service to investigate the full context of an event, including
the content and state of any enclosing views or child views.
<p class="caution"><strong>Important:</strong> The ability to investigate the full view
<p class="caution"><strong>Important:</strong> The ability to investigate the view
hierarchy from an {@link android.view.accessibility.AccessibilityEvent} potentially exposes private
user information to your accessibility service. For this reason, your service must request this
level of access through the accessibility <a href="#service-config">service configuration XML</a>
file, by including the {@code canRetrieveWindowContent} attribute and setting it to {@code true}. If
you do not include this setting in your service configuration xml file, calls to {@link
android.view.accessibility.AccessibilityEvent#getSource getSource()} fail.</p>
<p class="note"><strong>Note:</strong> In Android 4.1 (API Level 16) and higher, the
{@link android.view.accessibility.AccessibilityEvent#getSource getSource()} method,
as well as {@link android.view.accessibility.AccessibilityNodeInfo#getChild
AccessibilityNodeInfo.getChild()} and
{@link android.view.accessibility.AccessibilityNodeInfo#getParent getParent()}, return only
view objects that are considered important for accessibility (views that draw content or respond to
user actions). If your service requires all views, it can request them by setting the
{@link android.accessibilityservice.AccessibilityServiceInfo#flags flags} member of the service's
{@link android.accessibilityservice.AccessibilityServiceInfo} instance to
{@link android.accessibilityservice.AccessibilityServiceInfo#FLAG_INCLUDE_NOT_IMPORTANT_VIEWS}.</p>
</li>
</ul>
<h2 id="act-for-users">Taking Action for Users</h2>
<p>Starting with Android 4.0 (API Level 14), accessibility services can act on behalf
of users, including changing the input focus and selecting (activating) user interface elements.
In Android 4.1 (API Level 16) the range of actions has been expanded to include scrolling lists
and interacting with text fields. Accessibility services can
also take global actions, such as navigating to the Home screen, pressing the Back button, opening
the notifications screen and recent applications list. Android 4.1 also includes a new type of
focus, <em>Accessibilty Focus</em>, which makes all visible elements selectable by an
accessibility service.</p>
<p>These new capabilities make it possible for developers of accessibility services to create
alternative navigation modes such as
<a href="{@docRoot}tools/testing/testing_accessibility.html#test-gestures">gesture navigation</a>,
and give users with disabilities improved control of their Android devices.</p>
<h3 id="detect-gestures">Listening for gestures</h3>
<p>Accessibility services can listen for specific gestures and respond by taking action on behalf
of a user. This feature, added in Android 4.1 (API Level 16), and requires that your
accessibility service request activation of the Explore by Touch feature. Your service can
request this activation by setting the
{@link android.accessibilityservice.AccessibilityServiceInfo#flags flags} member of the service’s
{@link android.accessibilityservice.AccessibilityServiceInfo} instance to
{@link android.accessibilityservice.AccessibilityServiceInfo#FLAG_REQUEST_TOUCH_EXPLORATION_MODE},
as shown in the following example.
</p>
<pre>
public class MyAccessibilityService extends AccessibilityService {
&#64;Override
public void onCreate() {
getServiceInfo().flags = AccessibilityServiceInfo.FLAG_REQUEST_TOUCH_EXPLORATION_MODE;
}
...
}
</pre>
<p>Once your service has requested activation of Explore by Touch, the user must allow the
feature to be turned on, if it is not already active. When this feature is active, your service
receives notification of accessibility gestures through your service's
{@link android.accessibilityservice.AccessibilityService#onGesture onGesture()} callback method
and can respond by taking actions for the user.</p>
<h3 id="using-actions">Using accessibility actions</h3>
<p>Accessibility services can take action on behalf of users to make interacting with applications
simpler and more productive. The ability of accessibility services to perform actions was added
in Android 4.0 (API Level 14) and significantly expanded with Android 4.1 (API Level 16).</p>
<p>In order to take actions on behalf of users, your accessibility service must
<a href="#register">register</a> to receive events from a few or many applications and request
permission to view the content of applications by setting the
<a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_canRetrieveWindowContent">
{@code android:canRetrieveWindowContent}</a> to {@code true} in the
<a href="#service-config">service configuration file</a>. When events are received by your
service, it can then retrieve the
{@link android.view.accessibility.AccessibilityNodeInfo} object from the event using
{@link android.view.accessibility.AccessibilityEvent#getSource getSource()}.
With the {@link android.view.accessibility.AccessibilityNodeInfo} object, your service can then
explore the view hierarchy to determine what action to take and then act for the user using
{@link android.view.accessibility.AccessibilityNodeInfo#performAction performAction()}.</p>
<pre>
public class MyAccessibilityService extends AccessibilityService {
&#64;Override
public void onAccessibilityEvent(AccessibilityEvent event) {
// get the source node of the event
AccessibilityNodeInfo nodeInfo = event.getSource();
// Use the event and node information to determine
// what action to take
// take action on behalf of the user
nodeInfo.performAction(AccessibilityNodeInfo.ACTION_SCROLL_FORWARD);
// recycle the nodeInfo object
nodeInfo.recycle();
}
...
}
</pre>
<p>The {@link android.view.accessibility.AccessibilityNodeInfo#performAction performAction()} method
allows your service to take action within an application. If your service needs to perform a
global action such as navigating to the Home screen, pressing the Back button, opening the
notifications screen or recent applications list, then use the
{@link android.accessibilityservice.AccessibilityService#performGlobalAction performGlobalAction()}
method.</p>
<h3 id="focus-types">Using focus types</h3>
<p>Android 4.1 (API Level 16) introduces a new type of user interface focus called <em>Accessibility
Focus</em>. This type of focus can be used by accessibility services to select any visible user
interface element and act on it. This focus type is different from the more well known <em>Input
Focus</em>, which determines what on-screen user interface element receives input when a user
types characters, presses <strong>Enter</strong> on a keyboard or pushes the center button of a
D-pad control.</p>
<p>Accessibility Focus is completely separate and independent from Input Focus. In fact, it is
possible for one element in a user interface to have Input Focus while another element has
Accessibility Focus. The purpose of Accessibility Focus is to provide accessibility services with
a method of interacting with any visible element on a screen, regardless of whether or not the
element is input-focusable from a system perspective. You can see accessibility focus in action by
testing accessibility gestures. For more information about testing this feature, see
<a href="{@docRoot}tools/testing/testing_accessibility.html#test-gestures">Testing gesture
navigation</a>.</p>
<p class="note">
<strong>Note:</strong> Accessibility services that use Accessibility Focus are responsible for
synchronizing the current Input Focus when an element is capable of this type of focus. Services
that do not synchronize Input Focus with Accessibility Focus run the risk of causing problems in
applications that expect input focus to be in a specific location when certain actions are taken.
</p>
<p>An accessibility service can determine what user interface element has Input Focus or
Accessibility Focus using the {@link android.view.accessibility.AccessibilityNodeInfo#findFocus
AccessibilityNodeInfo.findFocus()} method. You can also search for elements that can be selected
with Input Focus using the
{@link android.view.accessibility.AccessibilityNodeInfo#focusSearch focusSearch()} method.
Finally, your accessibility service can set Accessibility Focus using the
{@link android.view.accessibility.AccessibilityNodeInfo#performAction
performAction(AccessibilityNodeInfo.ACTION_SET_ACCESSIBILITY_FOCUS)} method.</p>
<h2 id="examples">Example Code</h2>
<p>The API Demo project contains two samples which can be used as a starting point for generating

257
docs/html/tools/testing/testing_accessibility.jd Normal file
View File

@@ -0,0 +1,257 @@
page.title=Accessibility Testing Checklist
parent.title=Testing
parent.link=index.html
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol>
<li><a href="#goals">Testing Goals</a></li>
<li><a href="#requirements">Testing Requirements</a></li>
<li><a href="#recommendations">Testing Recommendations</a></li>
<li><a href="#special-cases">Special Cases and Considerations</a></li>
<li><a href="#how-to">Testing Accessibility Features</a>
<ol>
<li><a href="#test-audibles">Testing audible feedback</a></li>
<li><a href="#test-navigation">Testing focus navigation</a></li>
<li><a href="#test-gestures">Testing gesture navigation</a></li>
</ol>
</li>
</ol>
<h2>See Also</h2>
<ol>
<li>
<a href="{@docRoot}guide/topics/ui/accessibility/checklist.html">
Accessibility Developer Checklist</a>
</li>
<li>
<a href="{@docRoot}design/patterns/accessibility.html">
Android Design: Accessibility</a>
</li>
<li>
<a href="{@docRoot}guide/topics/ui/accessibility/apps.html">
Making Applications Accessible</a>
</li>
</ol>
</div>
</div>
<p>
Testing is an important part of making your application accessible to users with varying
abilities. Following <a href="{@docRoot}design/patterns/accessibility.html">design</a> and
<a href="{@docRoot}guide/topics/ui/accessibility/checklist.html">development</a> guidelines for
accessibility are important steps toward that goal, but testing for accessibility can uncover
problems with user interaction that are not obvious during design and development.</p>
<p>This accessibility testing checklist guides you through the important aspects of
accessibility testing, including overall goals, required testing steps, recommended testing and
special considerations. This document also discusses how to enable accessibility features on
Android devices for testing purposes.</p>
<h2 id="goals">Testing Goals</h2>
<p>Your accessibility testing should have the following, high level goals:</p>
<ul>
<li>Set up and use the application without sighted assistance</li>
<li>All task workflows in the application can be easily navigated using directional controls and
provide clear and appropriate feedback</li>
</ul>
<h2 id="requirements">Testing Requirements</h2>
<p>The following tests must be completed in order to ensure a minimum level of application
accessibility.</p>
<ol>
<li><strong>Directional controls:</strong> Verify that the application can be operated
without the use of a touch screen. Attempt to use only directional controls to accomplish the
primary tasks in the application. Use the keyboard and directional-pad (D-Pad) controls in the
Android <a href="{@docRoot}tools/devices/emulator.html">Emulator</a> or use
<a href="http://support.google.com/nexus/bin/answer.py?hl=en&answer=2700718">gesture
navigation</a> on devices with Android 4.1 (API Level 16) or higher.
<p class="note"><strong>Note:</strong> Keyboards and D-pads provide different navigation paths
than accessibility gestures. While gestures allow users to focus on nearly any on-screen
content, keyboard and D-pad navigation only allow focus on input fields and buttons.</p>
</li>
<li><strong>TalkBack audio prompts:</strong> Verify that user interface controls that provide
information (graphics or text) or allow user action have clear and accurate audio descriptions
when <a href="#testing-talkback">TalkBack is enabled</a> and controls are focused. Use
directional controls to move focus between application layout elements.</li>
<li><strong>Explore by Touch prompts:</strong> Verify that user interface controls that
provide information (graphics or text) or allow user action have appropriate audio descriptions
when <a href="#testing-ebt">Explore by Touch is enabled</a>. There should be no
regions where contents or controls do not provide an audio description.</li>
<li><strong>Touchable control sizes:</strong> All controls where a user can select or take an
action must be a minimum of 48 dp (approximately 9mm) in length and width, as recommended by
<a href="{@docRoot}design/patterns/accessibility.html">Android Design</a>.</li>
<li><strong>Gestures work with TalkBack enabled:</strong> Verify that app-specific gestures,
such as zooming images, scrolling lists, swiping between pages or navigating carousel controls
continue to work when <a href="#testing-talkback">TalkBack is enabled</a>. If these gestures do
not function, then an alternative interface for these actions must be provided.</li>
<li><strong>No audio-only feedback:</strong> 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 should also be accompanied by a system
{@link android.app.Notification}, haptic feedback (if available) or another visual alert.</li>
</ol>
<h2 id="recommendations">Testing Recommendations</h2>
<p>The following tests are recommended for ensuring the accessibility of your application. If you
do not test these items, it may impact the overall accessibility and quality of your
application.</p>
<ol>
<li><strong>Repetitive audio prompting:</strong> Check that closely related controls (such as
items with multiple components in a list) do not simply repeat the same audio prompt. For
example, in a contacts list that contains a contact picture, written name and title, the prompts
should not simply repeat “Bob Smith” for each item.</li>
<li><strong>Audio prompt overloading or underloading:</strong> Check that closely related
controls provide an appropriate level of audio information that enables users to understand and
act on a screen element. Too little or too much prompting can make it difficult to understand
and use a control.</li>
</ol>
<h2 id="special-cases">Special Cases and Considerations</h2>
<p>The following list describes specific situations that should be tested to ensure an
accessible app. Some, none or all of the cases described here may apply to your application. Be
sure to review this list to find out if these special cases apply and take appropriate action.</p>
<ol>
<li><strong>Review developer special cases and considerations:</strong> Review the list of
<a href="{@docRoot}guide/topics/ui/accessibility/checklist.html#special-cases">special cases</a>
for accessibility development and test your application for the cases that apply.</li>
<li><strong>Prompts for controls that change function:</strong> Buttons or other controls
that change function due to application context or workflow must provide audio prompts
appropriate to their current function. For example, a button that changes function from play
video to pause video should provide an audio prompt which is appropriate to its current state.</li>
<li><strong>Video playback and captioning:</strong> If the application provides video
playback, verify that it supports captioning and subtitles to assist users who are deaf or hard
of hearing. The video playback controls must clearly indicate if captioning is available for a
video and provide a clear way of enabling captions.</li>
</ol>
<h2 id="how-to">Testing Accessibility Features</h2>
<p>Testing of accessibility features such as TalkBack, Explore by Touch and accessibility Gestures
requires setup of your testing device. This section describes how to enable these features for
accessibility testing.</p>
<h3 id="test-audibles">Testing audible feedback</h3>
<p>Audible accessibility feedback features on Android devices provide audio prompts that speaks
the screen content as you move around an application. By enabling these features on an Android
device, you can test the experience of users with blindness or low-vision using your application.
</p>
<p>Audible feedback for users on Android is typically provided by TalkBack accessibility service and
the Explore by Touch system feature. The TalkBack accessibility service comes preinstalled on most
Android devices and can also be downloaded for free from
<a href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">Google
Play</a>. The Explore by Touch system feature is available on devices running Android 4.0 and later.
</p>
<h4 id="testing-talkback">Testing with TalkBack</h4>
<p>The <em>TalkBack</em> accessibility service works by speaking the contents of user interface
controls as the user moves focus onto controls. This service should be enabled as part of testing
focus navigation and audible prompts.</p>
<p>To enable the TalkBack accessibility service:</p>
<ol>
<li>Launch the <strong>Settings</strong> application.</li>
<li>Navigate to the <strong>Accessibility</strong> category and select it.</li>
<li>Select <strong>Accessibility</strong> to enable it.</li>
<li>Select <strong>TalkBack</strong> to enable it.</li>
</ol>
<p class="note">
<strong>Note:</strong> While TalkBack is the most available Android accessibility service for
users with disabilities, other accessibility services are available and may be installed by users.
</p>
<p>For more information about using TalkBack, see
<a href="http://support.google.com/nexus/bin/answer.py?hl=en&answer=2700928">Use TalkBack</a>.</p>
<h4 id="testing-ebt">Testing with Explore by Touch</h4>
<p>The <em>Explore by Touch</em> system feature is available on devices running Android 4.0 and
later, and works by enabling a special accessibility mode that allows users to drag a finger
around the interface of an application and hear the contents of the screen spoken. This feature
does not require screen elements to be focused using an directional controller, but listens for
hover events over user interface controls.
</p>
<p>To enable Explore by Touch on Android 4.0 and later:</p>
<ol>
<li>Launch the <strong>Settings</strong> application.</li>
<li>Navigate to the <strong>Accessibility</strong> category and select it.</li>
<li>Select the <strong>TalkBack</strong> to enable it.
<p class="note"><strong>Note:</strong> On Android 4.1 (API Level 16) and higher, the system
provides a popup message to enable Explore by Touch. On older versions, you must follow the
step below.</p>
</li>
<li>Return to the <strong>Accessibility</strong> category and select <strong>Explore by
Touch</strong> to enable it.
<p class="note"><strong>Note:</strong> You must turn on TalkBack <em>first</em>, otherwise this
option is not available.</p>
</li>
</ol>
<p>For more information about using the Explore by Touch features, see
<a href="http://support.google.com/nexus/bin/answer.py?hl=en&answer=2700722">Use Explore by
Touch</a>.</p>
<h3 id="test-navigation">Testing focus navigation</h3>
<p>Focus navigation is the use of directional controls to navigate between the individual user
interface elements of an application in order to operate it. Users with limited vision or limited
manual dexterity often use this mode of navigation instead of touch navigation. As part of
accessibility testing, you should verify that your application can be operated using only
directional controls.</p>
<p>You can test navigation of your application using only focus controls, even if your test devices
does not have a directional controller. The <a href="{@docRoot}tools/help/emulator.html">Android
Emulator</a> provides a simulated directional controller that you can use to test navigation. You
can also use a software-based directional controller, such as the one provided by the
<a href="https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.inputmethod.latin"
>Eyes-Free Keyboard</a> to simulate use of a D-pad on a test device that does not have a physical
D-pad.</p>
<h3 id="test-gestures">Testing gesture navigation</h3>
<p>Gesture navigation is an accessibility navigation mode that allows users to navigate Android
devices and applications using specific
<a href="http://support.google.com/nexus/bin/answer.py?hl=en&answer=2700718">gestures</a>. This
navigation mode is available on Android 4.1 (API Level 16) and higher.</p>
<p class="note"><strong>Note:</strong> Accessibility gestures provide a different navigation path
than keyboards and D-pads. While gestures allow users to focus on nearly any on-screen
content, keyboard and D-pad navigation only allow focus on input fields and buttons.</p>
<p>To enable gesture navigation on Android 4.1 and later:</p>
<ul>
<li>Enable both TalkBack and the Explore by Touch feature as described in the
<a href="#testing-ebt">Testing with Explore by Touch</a>. When <em>both</em> of these
features are enabled, accessibility gestures are automatically enabled.</li>
<li>You can change gesture settings using <strong>Settings &gt; Accessibility &gt; TalkBack &gt;
Settings &gt; Manage shortcut gestures</strong>.
</ul>
<p>For more information about using Explore by Touch accessibility gestures, see
<a href="http://support.google.com/android/bin/topic.py?hl=en&topic=2492346">Accessibility
gestures</a>.</p>
<p class="note">
<strong>Note:</strong> Accessibility services other than TalkBack may map accessibility gestures
to different user actions. If gestures are not producing the expected actions during testing, try
disabling other accessibility services before proceeding.</p>

32
docs/html/tools/tools_toc.cs
View File

@@ -5,7 +5,7 @@
<a href="<?cs var:toroot ?>tools/index.html"><span class="en">Developer Tools</span></a>
</div>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot
?>sdk/index.html"><span class="en">Download</span></a></div>
@@ -29,7 +29,7 @@
</li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="/tools/workflow/index.html"><span class="en">Workflow</span></a>
@@ -39,8 +39,8 @@
<div class="nav-section-header"><a href="/tools/devices/index.html"><span class="en">Setting Up Virtual Devices</span></a></div>
<ul>
<li><a href="/tools/devices/managing-avds.html"><span class="en">With AVD Manager</span></a></li>
<li><a href="/tools/devices/managing-avds-cmdline.html"><span class="en">From the Command Line</span></a></li>
<li><a href="/tools/devices/emulator.html"><span class="en">Using the Android Emulator</span></a></li>
<li><a href="/tools/devices/managing-avds-cmdline.html"><span class="en">From the Command Line</span></a></li>
<li><a href="/tools/devices/emulator.html"><span class="en">Using the Android Emulator</span></a></li>
</ul>
</li>
<li><a href="/tools/device.html"><span class="en">Using Hardware Devices</span></a></li>
@@ -48,16 +48,16 @@
<div class="nav-section-header"><a href="/tools/projects/index.html"><span class="en">Setting Up Projects</span></a></div>
<ul>
<li><a href="/tools/projects/projects-eclipse.html"><span class="en">From Eclipse with ADT</span></a></li>
<li><a href="/tools/projects/projects-cmdline.html"><span class="en">From the Command Line</span></a></li>
<li><a href="/tools/projects/projects-cmdline.html"><span class="en">From the Command Line</span></a></li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="/tools/building/index.html"><span class="en">Building and Running</span></a></div>
<ul>
<li><a href="/tools/building/building-eclipse.html"><span class="en">From Eclipse with ADT</span></a></li>
<li><a href="/tools/building/building-cmdline.html"><span class="en">From the Command Line</span></a></li>
<li><a href="/tools/building/building-cmdline.html"><span class="en">From the Command Line</span></a></li>
</ul>
</li>
@@ -76,7 +76,7 @@
</li>
<li><a href="<?cs var:toroot ?>tools/testing/testing_otheride.html">
<span class="en">From Other IDEs</span></a>
</li>
</li>
<li>
<a href="<?cs var:toroot?>tools/testing/activity_testing.html">
<span class="en">Activity Testing</span></a>
@@ -89,6 +89,10 @@
<a href="<?cs var:toroot?>tools/testing/contentprovider_testing.html">
<span class="en">Content Provider Testing</span></a>
</li>
<li>
<a href="<?cs var:toroot?>tools/testing/testing_accessibility.html">
<span class="en">Accessibility Testing</span></a>
</li>
<li>
<a href="<?cs var:toroot ?>tools/testing/what_to_test.html">
<span class="en">What To Test</span></a>
@@ -160,7 +164,7 @@ class="en">MonkeyRunner</span></a></li>
<li><a href="<?cs var:toroot ?>tools/help/zipalign.html">zipalign</a></li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot
?>tools/revisions/index.html"><span class="en">Revisions</span></a></div>
@@ -178,8 +182,8 @@ class="en">MonkeyRunner</span></a></li>
class="en">Platforms</span></a></li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot
?>tools/extras/index.html"><span class="en">Extras</span></a></div>
@@ -192,13 +196,13 @@ class="en">USB Drivers</span></a>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header empty"><a href="<?cs var:toroot
?>tools/samples/index.html"><span class="en">Samples</span></a></div>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>tools/adk/index.html">
@@ -217,7 +221,7 @@ class="en">USB Drivers</span></a>
</li>
</ul>
</li>
</ul><!-- nav -->
<script type="text/javascript">