Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing Mobile Applications for All: Accessible Contact Manager


Published on

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

Published in: Technology, Design
  • Be the first to comment

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. •
  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”