Mobile Accessibility, Challenges, and Best Practices

1. Mobile Accessibility, Challenges, and Best Practices HadiRangin&Jim Hahn University of Illinois at Urbana-Champaign

2. Introduction • Strong tendency in higher ed to go mobile • Users with disabilities can benefit from mobile apps substantially if they are accessible • Travel: Trip tracker… • Special Assistive Apps • Voice recognition software, color finder…

3. Goals of this presentation • Share some of accessibility/usability problems with common apps • Derive design & implementation Best Practices from our findings • Our knowledge and expertise is very limited so we need to do it collectively • Promote for the Best practices in our campus

4. Common Accessibility issues with mobile apps Discussion/demonstration of selected mobile apps on Ipad such as Mail, Contacts, Skype, etc.

5. Samples drawn from UGL4EVA app

6. Dashcode • Dashcode is a developer environment that allows you to apply web skills to mobile app design. We will model a few strategies for making apps accessible, while also pointing out limitations in this area. • In other words, some areas may be fixed in web based ways, while others using Xcode can be addressed in the Native developer environment.

7. Xcode • Xcode is the native development environment. It uses C, mostly Objective C but also C++. You can also work from Apple provided templates here as well.

8. The Xcode Developer Environment

9. 1. Specify a button as button • Problem: the text string doesn’t always indicate it is a button. Convey that action will occur.

10. Example:

11. Fix: use a <role> tag in the HTML of the app Voice Over will recognize this as a button with this additional tag used inside of Dashcode <div role="button"

12. 2. If a button is not available make sure it is dimmed or invisible to VO • Problem: Voice over is picking up a button that should be unavailable.

13. Example:

14. Fix: Explore turning off this element using CSS for the first level of the browser or use HTML disabled attribute. <li><input type="button" value="button 1"></li> <li><input disabled type="button" value="button 1"></li> • A few parts of the Dashcode templates are not accessible out of the box.

15. 3. Video Element • Problem: voice over is reading “next track,” but there is no next track, it will actually forward the video, to the end, if used.

16. Example: in UGL4EVA we have one video to play, however Voice Over reads this as “next track”

17. Fix: Use a video plugin that we can modify track controls. In Dashcode, we are unable to make controller modifications, since this is calling a QuickTime plugin. • We also tested HTML5 video element and are seeing the same behavior. • In Xcode we advise leaving out controller elements if there isn’t a “next track.”

18. Multimedia Accessibility • See also: http://www.w3.org/html/wg/wiki/MultimediaAccessibilty

19. 4. How do users know what items are related? • Problem: how does Voice Over know what items go together

20. Example: There are a number of links here, and Voice Over reads “list start” where the grouping begins.

21. Fix: use a list element to group portions of the page together and provide a heading element preceding that indicates the purpose of list.

22. 5. Table index outside the navigator • Problem: This index is not read by Voice Over.

23. Example

24. Fix: Designers should make certain the index of letters is accessible from the page navigation. Either make the table index (Skype) in a tab order (the user can access from Keyboard) or use alphabetical navigation with headings (example: Apple contact List).

25. 6. Screen Reader View and Visual View Not Consistent • Problem: Voice Over is reading portions of the page that are not displayed.

26. Example: see Page Once, Al Jeezera Live, AA.com

27. Fix: Developers should test the VoiceOver functionality for when portions of the page are hidden from view, since screen readers will be able to pick up portions of this.

28. 7. In Plain Text app menu, if you need to activate a menu… • Problem: Menu activation requires a user tap in the screen, but Voice Over has no way to indicate this

29. Example: Plain Text example

30. Fix: Avoid such events. Dedicate a funtion on the interface. Make sure we have a fixed or dedicated menu for this. Make the function keyboard accessible.

31. 8. Page title - • Problem: Identify the page with the proper heading.

32. Example:

33. Fix: main app home screen modified to indicate it is a video tour application

34. 9. Tab order when using a table layout • Problem: if you design with a table layout, the order of the items may be unintentionally confusing.

35. Example: AA.com mobile app is a good example

36. Fix: Consider using a layout that will be easily navigated by a keyboard.

37. 10. Proper Form Control • Problem: Lack of form labels

38. Example: Use radio button if you can’t select more than 1 item. Use checkbox to enable selection of more than one item.

39. Fix: Use label for the form control. Similar to HTML technique.

40. Conclusion • Process: test your beta mobile apps with Voice Over before launching to App Store

41. Consulted Safari HTML Reference: http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/SafariHTMLRef.pdf See section: supported accessibility roles, p. 105