Mobile Accessibility, Challenges, and Best Practices

Hadi Rangin & Jim HahnUniversity 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

Samples drawn from UGL4EVA app

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.

The Xcode Developer Environment

1. Specify a button as button

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

• Example:

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

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.

• Example:

• 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.

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 isn’t a “next track.”

Multimedia Accessibility

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

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.

• Example

• 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

• Example: Plain Text example

• 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.

8. Page title -

• Problem: Identify the page with the proper heading.

• Example:

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

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.

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

• 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 can’t 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

ConsultedSafari HTML Reference:http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/SafariHTMLRef.pdf

See section: supported accessibility roles, p. 105