Designing Mobile Applications for All:
Accessible Contact Manager
Jon Azpiroz (Vodafone Spain Foundation, Spain)
Karel Van Isacker (EPR, Belgium)
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
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).
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
• 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
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
Barriers of Mainstream ICTs
• Barriers for:
– Speech / Communication impairment
users:
• Difficulties typing messages
• Complex menus and constant learning required
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
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
Designing Accessible Mobile Applications
• Two fundamental factors:
– Target a mobile platform that is capable of
running ATs
– Adaptability, personalization and
customization of mobile applications
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.
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.
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
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
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
Designing Accessible Mobile Applications
• Optimization of user experience
– Input of information:
• Design of menus
• Text prediction
• Spell-checking
• Short-cuts (when possible)
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
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
Example Application
• Accessible Contact Manager and Phone Dialler
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
Validation and Refinement• What do first users think about it?
– Motor impaired user:
• Search field
• Scroll bar with alphabet letters shortcutsVisual impairment users feedback
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
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”