Presentation on theme: "Mobile Accessibility, Challenges, and Best Practices Hadi Rangin & Jim Hahn University of Illinois at Urbana- Champaign."— Presentation transcript:
Mobile Accessibility, Challenges, and Best Practices Hadi Rangin & Jim Hahn University of Illinois at Urbana- Champaign
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…
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
Discussion/demonstration of selected mobile apps on Ipad such as Mail, Contacts, Skype, etc. Common Accessibility issues with mobile apps
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.
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.
Fix: Explore turning off this element using CSS for the first level of the browser or use HTML disabled attribute. A few parts of the Dashcode templates are not accessible out of the box.
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.
Example: in UGL4EVA we have one video to play, however Voice Over reads this as next track
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 isnt a next track.
Multimedia Accessibility See also: http://www.w3.org/html/wg/wiki/Multimedia Accessibilty http://www.w3.org/html/wg/wiki/Multimedia Accessibilty
4. How do users know what items are related? Problem: how does Voice Over know what items go together
Example: There are a number of links here, and Voice Over reads list start where the grouping begins.
Fix: use a list element to group portions of the page together and provide a heading element preceding that indicates the purpose of list.
5. Table index outside the navigator Problem: This index is not read by Voice Over.
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).
6. Screen Reader View and Visual View Not Consistent Problem: Voice Over is reading portions of the page that are not displayed.
Example: see Page Once, Al Jeezera Live, AA.com
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.
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
Fix: Consider using a layout that will be easily navigated by a keyboard.
10. Proper Form Control Problem: Lack of form labels
Example: Use radio button if you cant select more than 1 item. Use checkbox to enable selection of more than one item.
Fix: Use label for the form control. Similar to HTML technique.
Conclusion Process: test your beta mobile apps with Voice Over before launching to App Store
Consulted Safari HTML Reference: http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHT MLRef/SafariHTMLRef.pdf See section: supported accessibility roles, p. 105