The document discusses the AEGIS project, which aims to improve accessibility in mobile applications by implementing third-generation access techniques and utilizing an open accessibility framework (OAF). It identifies various barriers faced by users with impairments and presents guidelines for designing accessible mobile applications, emphasizing the need for customization and adaptability. The document highlights the importance of validating solutions with end users to ensure effectiveness and satisfaction across different accessibility groups.

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”