1 page.title=Accessibility Developer Checklist 2 parent.title=Accessibility 3 parent.link=index.html 4 @jd:body 5 6 <div id="qv-wrapper"> 7 <div id="qv"> 8 9 <h2>In this document</h2> 10 <ol> 11 <li><a href="#requirements">Accessibility Requirements</a></li> 12 <li><a href="#recommendations">Accessibility Recommendations</a></li> 13 <li><a href="#special-cases">Special Cases and Considerations</a></li> 14 </ol> 15 16 <h2>See also</h2> 17 <ol> 18 <li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li> 19 <li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing Checklist</a></li> 20 <li><a href="{@docRoot}training/accessibility/index.html">Training: Implementing Accessibility</a></li> 21 <li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a></li> 22 </ol> 23 24 </div> 25 </div> 26 27 <p>Making an application accessible is about a deep commitment to usability, getting the 28 details right and delighting your users. This document provides a checklist of accessibility 29 requirements, recommendations and considerations to help you make sure your application is 30 accessible. Following this checklist does not guarantee your application is accessible, but it's a 31 good place to start.</p> 32 33 <p>Creating an accessible application is not just the responsibility of developers. Involve your 34 design and testing folks as well, and make them are aware of the guidelines for these other stages 35 of development:</p> 36 37 <ul> 38 <li><a href="{@docRoot}design/patterns/accessibility.html">Android Design: Accessibility</a></li> 39 <li><a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing 40 Checklist</a></li> 41 </ul> 42 43 <p>In most cases, creating an accessible Android application does not require extensive code 44 restructuring. Rather, it means working through the subtle details of how users interact with your 45 application, so you can provide them with feedback they can sense and understand. This checklist 46 helps you focus on the key development issues to get the details of accessibility right.</p> 47 48 49 <h2 id="requirements">Accessibility Requirements</h2> 50 51 <p>The following steps must be completed in order to ensure a minimum level of application 52 accessibility.</p> 53 54 <ol> 55 <li><strong>Describe user interface controls:</strong> Provide content 56 <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#label-ui">descriptions</a> for user 57 interface components that do not have visible text, particularly 58 {@link android.widget.ImageButton}, {@link android.widget.ImageView} 59 and {@link android.widget.CheckBox} components. Use the 60 <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription"> 61 {@code android:contentDescription}</a> XML layout attribute or the {@link 62 android.view.View#setContentDescription} method to provide this information for accessibility 63 services. (Exception: <a href="#decorative">decorative graphics</a>)</li> 64 <li><strong>Enable focus-based navigation:</strong> Make sure 65 <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#focus-nav">users can navigate</a> 66 your screen layouts using hardware-based or software directional controls (D-pads, trackballs, 67 keyboards and navigation gestures). In a few cases, you may need to make user interface components 68 <a href="{@docRoot}reference/android/view/View.html#attr_android:focusable">focusable</a> 69 or change the <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#focus-order">focus 70 order</a> to be more logical for user actions.</li> 71 <li><strong>Custom view controls:</strong> If you build 72 <a href="{@docRoot}guide/topics/ui/custom-components.html">custom interface controls</a> for 73 your application, <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#custom-views"> 74 implement accessibility interfaces</a> for your custom views and provide content descriptions. 75 For custom controls that are intended to be compatible with versions of Android back to 1.6, 76 use the <a href="{@docRoot}tools/support-library/index.html">Support Library</a> to implement 77 the latest accessibility features.</li> 78 <li><strong>No audio-only feedback:</strong> Audio feedback must always have a secondary 79 feedback mechanism to support users who are deaf or hard of hearing. For example, a sound alert 80 for the arrival of a message must be accompanied by a system 81 {@link android.app.Notification}, haptic feedback (if available) or other visual alert.</li> 82 <li><strong>Test:</strong> Test accessibility by navigating your application 83 using directional controls, and using eyes-free navigation with TalkBack enabled. 84 For more accessibility testing information, see the 85 <a href="{@docRoot}tools/testing/testing_accessibility.html">Accessibility Testing 86 Checklist</a>.</li> 87 </ol> 88 89 90 <h2 id="recommendations">Accessibility Recommendations</h2> 91 92 <p>The following steps are recommended for ensuring the accessibility of your application. If you 93 do not take these actions, it may impact the overall accessibility and quality of your 94 application.</p> 95 96 <ol> 97 <li><strong>Android Design Accessibility Guidelines:</strong> Before building your layouts, 98 review and follow the accessibility guidelines provided in the 99 <a href="{@docRoot}design/patterns/accessibility.html">Design guidelines</a>.</li> 100 <li><strong>Framework-provided controls:</strong> Use Android's built-in user interface 101 controls whenever possible, as these components provide accessibility support by default.</li> 102 <li><strong>Temporary or self-hiding controls and notifications:</strong> Avoid having user 103 interface controls that fade out or disappear after a certain amount of time. If this behavior 104 is important to your application, provide an alternative interface for these functions.</li> 105 </ol> 106 107 108 <h2 id="special-cases">Special Cases and Considerations</h2> 109 110 <p>The following list describes specific situations where action should be taken to ensure an 111 accessible app. Review this list to see if any of these special cases and considerations apply to 112 your application, and take the appropriate action.</p> 113 114 <ol> 115 <li><strong>Text field hints:</strong> For {@link android.widget.EditText} fields, provide an 116 <a href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">android:hint</a> 117 attribute <em>instead</em> of a content description, to help users understand what content is 118 expected when the text field is empty and allow the contents of the field to be spoken when 119 it is filled.</li> 120 <li><strong>Custom controls with high visual context:</strong> If your application contains a 121 <a href="{@docRoot}guide/topics/ui/custom-components.html">custom control</a> with a high degree 122 of visual context (such as a calendar control), default accessibility services processing may 123 not provide adequate descriptions for users, and you should consider providing a 124 <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#virtual-hierarchy">virtual 125 view hierarchy</a> for your control using 126 {@link android.view.accessibility.AccessibilityNodeProvider}.</li> 127 <li><strong>Custom controls and click handling:</strong> If a custom control in your 128 application performs specific handling of user touch interaction, such as listening with 129 {@link android.view.View#onTouchEvent} for {@link android.view.MotionEvent#ACTION_DOWN 130 MotionEvent.ACTION_DOWN} and {@link android.view.MotionEvent#ACTION_UP MotionEvent.ACTION_UP} 131 and treating it as a click event, you must trigger an {@link 132 android.view.accessibility.AccessibilityEvent} equivalent to a click and provide a way for 133 accessibility services to perform this action for users. For more information, see 134 <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#custom-touch-events">Handling custom 135 touch events</a>.</li> 136 <li><strong>Controls that change function:</strong> If you have buttons or other controls 137 that change function during the normal activity of a user in your application (for example, a 138 button that changes from <strong>Play</strong> to <strong>Pause</strong>), make sure you also 139 change the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription"> 140 {@code android:contentDescription}</a> of the button appropriately.</li> 141 <li><strong>Prompts for related controls:</strong> Make sure sets of controls which provide a 142 single function, such as the {@link android.widget.DatePicker}, provide useful audio feedback 143 when an user interacts with the individual controls.</li> 144 <li><strong>Video playback and captioning:</strong> If your application provides video 145 playback, it must support captioning and subtitles to assist users who are deaf or hard of 146 hearing. Your video playback controls must also clearly indicate if captioning is available for 147 a video and provide a clear way of enabling captions.</li> 148 <li><strong>Supplemental accessibility audio feedback:</strong> Use only the Android accessibility 149 framework to provide accessibility audio feedback for your app. Accessibility services such as 150 <a href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback" 151 >TalkBack</a> should be the only way your application provides accessibility audio prompts to 152 users. Provide the prompting information with a 153 <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code 154 android:contentDescription}</a> XML layout attribute or dynamically add it using accessibility 155 framework APIs. For example, if your application takes action that you want to announce to a 156 user, such as automatically turning the page of a book, use the {@link 157 android.view.View#announceForAccessibility} method to have accessibility services speak this 158 information to the user.</li> 159 <li><strong>Custom controls with complex visual interactions:</strong> For custom controls that 160 provide complex or non-standard visual interactions, provide a 161 <a href="{@docRoot}guide/topics/ui/accessibility/apps.html#virtual-hierarchy">virtual view 162 hierarchy</a> for your control using {@link android.view.accessibility.AccessibilityNodeProvider} 163 that allows accessibility services to provide a simplified interaction model for the user. If 164 this approach is not feasible, consider providing an alternate view that is accessible.</li> 165 <li><strong>Sets of small controls:</strong> If you have controls that are smaller than 166 the minimum recommended touch size in your application screens, consider grouping these controls 167 together using a {@link android.view.ViewGroup} and providing a 168 <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code 169 android:contentDescription}</a> for the group.</li> 170 <li id="decorative"><strong>Decorative images and graphics:</strong> Elements in application 171 screens that are purely decorative and do not provide any content or enable a user action should 172 not have accessibility content descriptions.</li> 173 </ol> 174
