Mobile Accessibility, Challenges,
and Best Practices
Hadi Rangin & Jim Hahn
University of Illinois at UrbanaChampaign
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
Common Accessibility issues with
mobile apps
Discussion/demonstration of selected mobile
apps on Ipad such as Mail, Contacts, Skype, etc.
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 app
Voice 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/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.
• 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
Consulted
Safari HTML Reference:
http://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHT
MLRef/SafariHTMLRef.pdf
See section: supported accessibility roles, p. 105