Upgrade to Pro — share decks privately, control downloads, hide ads and more …

To be or not to be... accessible

To be or not to be... accessible

Android accessibility. Presented on Droidcon Zagreb 2015

Avatar for Marijan Juresic

Marijan Juresic

April 30, 2015

Other Decks in Programming

Transcript

  1. Why bother? aged 15 to 64 in the European Union

    have reported a disability 5.5.2015. 2 44 million people
  2. Universal design • Universal design (often inclusive design) refers to

    broad-spectrum ideas meant to produce products and environments that are inherently accessible to: – older people, – people without disabilities – people with disabilities. 5.5.2015. 3
  3. Accessibility A product is accessible when all people, regardless of

    ability can: • navigate it • understand it • and use it successfully 5.5.2015. 4
  4. Accessibility Imagine using your product in the following ways: •

    Without sound • Without color • With high-contrast mode enabled 5.5.2015. 5
  5. Accessibility Imagine using your product in the following ways: •

    With the screen magnified • With a screen reader (no visible screen) • With voice control only • With a combination of the above 5.5.2015. 6
  6. TalkBack Designed for blind or low-vision users, TalkBack will speak

    aloud content that’s on your screen. For example, when you place your finger anywhere on the screen, the system will tell you what’s underneath your finger. Once an item is selected, you’ll need to double-tap anywhere to confirm that option 5.5.2015. 7
  7. What can a developer do? It is not only up

    to user interface to make application accessible! 5.5.2015. 9
  8. Content Descriptions If you have a label that's likely not

    to change during the lifecycle of the application, you can add it via the XML layout, by setting a UI element's android:contentDescription attribute 5.5.2015. 10
  9. Content Descriptions To edit the content description at runtime, use

    the setContentDescription() method, like this: String contentDescription = "Droidcon rules”; label.setContentDescription(content Description); 5.5.2015. 12
  10. Content Descriptions Try to add content descriptions wherever there's useful

    information, but avoid labelling everything with useless information! 5.5.2015. 13
  11. Content Descriptions For EditText fields, provide an android:hint attribute instead

    of a content description, to help users understand what content is expected when the text field is empty and allow the contents of the field to be spoken when it is filled. 5.5.2015. 14
  12. Focus Navigation In order to enable this form of navigation,

    all navigational elements that the user should be able to reach need to be set as focusable. 5.5.2015. 15
  13. Focus Navigation This can be done at runtime using the

    View.setFocusable() method on that UI control, or by setting the android:focusable attribute in your XML layout files. 5.5.2015. 16
  14. Focus Navigation each UI control has 4 attributes, android:nextFocusUp, android:nextFocusDown,

    android:nextFocusLeft, android:nextFocusRight, which you can use to designate the next view to receive focus when the user navigates in that direction. 5.5.2015. 17
  15. Accessibility Events If you're using the view components in the

    Android framework, an AccessibilityEvent is created whenever you select an item or change focus in your UI. These events are examined by the accessibility service, enabling it to provide features like text-to-speech to the user. 5.5.2015. 18
  16. Accessibility Events If you write a custom view, make sure

    it fires events at the appropriate times. Generate events by calling sendAccessibilityEvent(int), with a parameter representing the type of event that occurred. 5.5.2015. 19
  17. Captioning If your application provides video playback, it must support

    captioning 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. 5.5.2015. 20
  18. Guidelines - position • Present the most important information first.

    How easy is it to navigate the page quickly and? Small changes, like bringing a “New” button to the top, can make navigation much faster. 5.5.2015. 21
  19. Guidelines – size • Make touch targets at least 48

    x 48 pixels The recommended minimum touch target size for any element is 48 x 48 dp. Space between elements of your mobile design should be at least 8dp. 5.5.2015. 22
  20. Guidelines - keyboard • Support mouse-free and gesture navigation Are

    all parts of the design, including every user task and mouse over information, keyboard-accessible on web interfaces and accessible with the basic interaction gestures on mobile devices? Keyboard shortcuts should be consistent with platform standards. 5.5.2015. 23
  21. Guidelines - navigation • Manage navigation between screens Could a

    user get lost when navigating between dropdowns, alerts and various screens? Think about how users will return to a screen after closing a dropdown window. Make sure that their focus will return to where it was before the dropdown opened. 5.5.2015. 24
  22. Guidelines - zoom • Ensure your app is usable with

    larger font sizes Is the text still legible when a user magnifies the screen or enlarges the font? Are the essential elements still visible, usable, and not overlapping? Test font adjustments on your app using any of the built-in OS/Browser/App accessibility tools for zooming and viewing large fonts. 5.5.2015. 25
  23. Guidelines - contrast • Ensure critical text has enough contrast

    Using a contrast ratio of 4.5:1 between the background and text or critical elements addresses most contrast issues and allows users, particularly those with poor vision, to read text more easily. Smaller text needs lots of contrast, while big headings can tolerate a wider range of colors and backgrounds. 5.5.2015. 26
  24. Guidelines – color • Use more than just color to

    convey information. This is especially crucial for color blind users. If colors in a design communicate specific information it is important to offer an alternate way for the user to get the same information. Combining color with other elements like shapes, patterns, texture, or text can leverage multiple ways to articulate the information. 5.5.2015. 27
  25. Guidelines – relationships • Represent spatial relationships Is any information

    conveyed spatially, using layout, that wouldn't be discoverable to a blind user who navigates one element at a time? As assistive technologies don't indicate the distance between elements, provide additional clues about how elements are related, such as sharing a common heading. 5.5.2015. 28
  26. Guidelines – sound • Give visual alternatives to sound If

    you have audio elements or system sound alerts, do you provide closed captions, a transcript, or another visual alternative? Any flashing or blinking needs to be translated into a sound, and vice versa. 5.5.2015. 29
  27. Guidelines • Make interactive controls clear and discoverable Do all

    interactive controls have text labels, tooltips, or placeholder text to indicate their purpose? Provide the most relevant information first to the assistive technologies. When naming elements, be consistent in your terminology throughout your app. 5.5.2015. 30
  28. Guidelines • Provide alternative text for images and video Are

    you relying on graphical elements to convey information that isn't also provided in a written format? Do labels provide sufficient semantic context for the task (e.g., not just "download" but "download dinner menu")? Provide alternative text for all images and icons, and avoid using images of text in cases where a standard widget would work. 5.5.2015. 31
  29. Guidelines – describe UI • Provide content descriptions for user

    interface components that do not have visible text, particularly ImageButton, ImageView and CheckBox components. • Use theandroid:contentDescription XML layout attribute or the setContentDescription(CharSequence) method to provide this information for accessibility services 5.5.2015. 32
  30. Guidelines • Offer guidance and help Can the user find

    help quickly when they do not know what an element means? If a critical element times out, is there a way for the user to reactivate it? Provide clear and easy-to-find contextual help so that the user can look up keyboard shortcuts, gestures, and how to access and use features. 5.5.2015. 33
  31. Guidelines • Give meaning to links Some assistive technology modes

    make navigation more efficient by letting the user scan just the links, ignoring other content. Is the purpose of each link clear? Put the purpose of the link in the link text itself. Generic anchor text like “click here” does not serve this purpose. A better solution is a concrete link, like “Device settings." 5.5.2015. 34