1. Designing Mobile Applications for All:
Accessible Contact Manager
Jon Azpiroz (Vodafone Spain
Foundation, Spain)
Karel Van Isacker (EPR, Belgium)

2. What is ÆGIS?
• Seeks to implement 3rd generation access
techniques in mainstream ICT (desktop, rich
Internet and mobile applications).
• Developed and explored with the Open
Accessibility Framework (OAF).
• OAF provides embedded/built-in accessibility
solutions, toolkits for developers, for “engraving”
accessibility in existing and emerging mass-
market ICT-based products.
• www.aegis-project.eu

3. Motivation, Problem area
• Accessibility for mobile devices is still way
behind compared to desktop computers
• Difficulties integrating accessibility in a
very fragmented market (not 1 fits for all).
• Few and rather expensive solutions .
• Time urgency: Increasing number of
mobile applications (Apple App Store:
Over 250,000 applications).

4. Research Approach, Methodology
Identify the barriers in the use of mainstream ICTs
Identify the specific mobile restrictions
Design guidelines for accessible mobile applications
Example application: Contact Manager
Validation and Refinement

5. • Barriers for:
– Visual impairment users:
• Screen readers and/or screen magnifiers
incompatibility with dynamic or graphical apps
• No emotional voices
• Lack of sufficient contrast
– Motor impairment users:
• Not able to use keyboards and/or mouse
• Difficulty to work with dynamic interfaces
• Poor quality of voice recognition
Barriers of Mainstream ICTs

6. Barriers of Mainstream ICTs
• Barriers for:
– Cognitive impairment users:
• Need for constant adaptation and learning
• Complex and overloaded menus
• Confusing or not standardized icons
– Hearing impairment users:
• Poor quality of sound and/or interferences
• Poor quality of images in video calls
• Lack of subtitles and sign language adaptations

7. Barriers of Mainstream ICTs
• Barriers for:
– Speech / Communication impairment
users:
• Difficulties typing messages
• Complex menus and constant learning required

8. Mobile Restrictions
• Screen size
– Very limited but increasing
– Orientation: Square, landscape, portrait,…
– Not standardized aspect ratio
• Limited Processor speed and memory
available to run applications and ATs

9. Mobile Restrictions
• User input
– Not standardized. Different methods
available:
• T9 keypad
• Extended QWERTY keyboards
• Touch-screen virtual keyboards
• Voice commands
– Can be improved with spell checkers and
predictive text

10. Designing Accessible Mobile Applications
• Two fundamental factors:
– Target a mobile platform that is capable of
running ATs
– Adaptability, personalization and
customization of mobile applications

11. Rules to support accessibility
• If a component does not display a short string, a
descriptive name for it has to be specified.
• A tool tip for each component has to be set
whenever it makes sense.
• If a tool tip for a component can not be provided,
a description alternatively can be provided that
assistive technologies can give the user.
• Specify keyboard alternatives wherever possible
and keep in mind that keyboard alternatives
varies by components.

12. Rules to support accessibility
• Assign textual description to all Images and
Icons objects in your application.
• In a bunch of components that form a logical
group, try to put them into one container.
• Any custom component is created, it should
support accessibility.

13. Designing Accessible Mobile Applications
• Targeting mobile platforms that are
capable of running ATs:
– Without accessibility APIs:
“Name:” label +
text box
ATs should replace or
chain the video driver
Off-screen model
On-screen

14. Designing Accessible Mobile Applications
• Targeting mobile platforms that are capable of
running ATs:
– With accessibility APIs:
• Accessible slider:
– Name: Age_slider
– Role: Slider
– Current Value: 30
– Minimum Value: 0
– Maximum Value: 100
– Background Color:
White
– Foreground Color: Light
Gray
ATs
User
presentation

15. Designing Accessible Mobile Applications
• Accessible environments that provide
accessibility APIs:
– BlackBerry OS
– Android OS
– iPhone OS
– (Work on progress) JavaME platform
• Accessible environments that do not provide
accessibility APIs:
– Symbian OS (although solution in the works)
– Windows Mobile OS

16. Designing Accessible Mobile Applications
• Optimization of user experience
– Input of information:
• Design of menus
• Text prediction
• Spell-checking
• Short-cuts (when possible)

17. Designing Accessible Mobile Applications
• Optimization of user experience
– Output of information
• Provide visual alternatives: text, icons, audio
• Make it configurable
– Naming and labelling
• Unique and meaningful names
– Theme support

18. Designing Accessible Mobile Applications
• Optimization of user experience
– User preferences
• Look and feel
• Font adjustment
• Number of options or icons
– Compatibility with accessibility services
– Documentation and help menu

19. Example Application
• Accessible Contact Manager and Phone Dialler

20. Validation and Refinement
• Accessible solutions should always be
validated by the end users
• What do first users think about it?
– Cognitive impaired users:
• High degree of satisfaction with the redundant
information: text + image + voice
– Visual impaired users:
• Text-only vertical contact list
• Translate UI frequently used settings to the home
page (image and font size adjustment)
• Separate applications for Contact Manager and
the phone dialler

21. Validation and Refinement
• What do first users think about it?
–Motor impaired user:
• Search field
• Scroll bar with alphabet letters
shortcutsVisual impairment users feedback

22. 1st Evaluation Phase
• Cognitive users report great acceptance of the
application
• Motor impairment users experience difficulties
using the touch screen
– Capacity touch screens are needed -> shift target
telephone to HTC HD2
– Navigation through the contact list should be
simplified -> gestures are much easier for the users
and the scroll bar is incorporated
– Screen saver affects some of the users before the
end of the task

23. Conclusion and outlook
• Mobile applications require specific solutions to solve
mobile restrictions
• Accessibility is more than providing compatibility with
ATs
• User needs are quite different: Adaptability and
configuration are key parameters, across different
platforms (OSs)
• Application design should focus on each accessibility
group, looking for specific solutions
• Continuous refinement and validation of the solutions
should by the users is required to obtain a “design for all”