Designing Mobile Applications for All: Accessible Contact Manager

1,047 views

Published on

ITAG 2010, Nottingham, UK, Jon Azpiroz (Vodafone Spain Foundation, Spain), Karel Van Isacker (EPR, Belgium)

Published in: Technology, Design
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,047
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Designing Mobile Applications for All: Accessible Contact Manager

  1. 1. Designing Mobile Applications for All: Accessible Contact Manager Jon Azpiroz (Vodafone Spain Foundation, Spain) Karel Van Isacker (EPR, Belgium)
  2. 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. 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. 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. 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. 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. 7. Barriers of Mainstream ICTs • Barriers for: – Speech / Communication impairment users: • Difficulties typing messages • Complex menus and constant learning required
  8. 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. 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. 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. 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. 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. 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. 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. 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. 16. Designing Accessible Mobile Applications • Optimization of user experience – Input of information: • Design of menus • Text prediction • Spell-checking • Short-cuts (when possible)
  17. 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. 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. 19. Example Application • Accessible Contact Manager and Phone Dialler
  20. 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. 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. 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. 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”

×