model-driven development for accessible mobile apps on
TRANSCRIPT
Submitted byDipl.-Ing.Elmar Krainz
Submitted atInstitut IntegriertStudieren
Supervisor andFirst Examinera.Univ.-Prof. Dr.Klaus Miesenberger
Second ExaminerProf. Dr.Roberto Manduchi
May 2018
JOHANNES KEPLERUNIVERSITY LINZAltenbergerstraße 694040 Linz, Österreichwww.jku.atDVR 0093696
Model-Driven Develop-ment for Accessible Mo-bile Apps on Android
Doctoral Thesis
to obtain the academic degree of
Doktor der technischen Wissenschaften
in the Doctoral Program
Technische Wissenschaften
Sworn Declaration
I hereby declare under oath that the submitted Doctoral Thesis has been written solelyby me without any third-party assistance, information other than provided sources oraids have not been used and those used have been fully documented. Sources forliteral, paraphrased and cited quotes have been accurately credited.
The submitted document here present is identical to the electronically submitted textdocument.
Linz, May 2018
Dipl.-Ing. Elmar Krainz, bakk. techn.
Abstract
The market for apps and mobile software is on the rise and this goes hand in hand withthe number of apps in the stores, which has recently hit 3 million available apps (seehttps://www.statista.com/statistics/266210/). Due to this development,the natural user interaction of smartphones plays a crucial role. People with disabilitiesbenefit from the increasing digital technology in general, but only if it is accessible.However, apps are often not accessible for people with disabilities since touch screensand visual representation very often overlook their needs.
According to the UN Convention on the Rights of Persons with Disabilities around 650million people of the world’s population are handicapped. Within the European Union(EU) about 80 million people are affected by disabilities prompting the union to enactthe Directive (EU) 2016/2102 which requests that websites and mobile applications ofpublic sector bodies are accessible for all.
Reviewing top apps in the Android store shows that even very popular apps suchas WhatsApp, Messenger and Instagram have accessibility problems, i.e. contrastof texts and images, missing object descriptions or too small touch target sizes, pre-venting users with disabilities from having equal access to those apps (see Chapter1).
The thesis at hand presents an innovative approach, supporting the implementationof accessibility in the design and development process of mobile applications fromthe very beginning. We propose a model-driven approach for better integration andaddressing accessibility requirements in the design and development process.
To prove this concept, developers receive a prototype-tool - called Accapto (Acces-sible App Tool) - to transfer an interaction prototype to a formal model. The abstractdefinition describes screens, user interface elements and interaction workflows in adomain-specific description language. The model is transformed into a working appprototype for the Android platform. In the generation process, the app is created withproper platform-specific accessibility support and enhanced with additional supportivefeatures and provides guidance to the developer to efficiently and effectively implementaccessibility.
In the course of the thesis, the level of accessibility of apps implemented with Accaptois evaluated against Web Content Accessibility Guidelines (WCAG 2.0) and also testedwith users with disabilities.
In particular, the new development tool is analyzed in an empirical study with 50 in-volved developers. In two test groups, the model-driven development approach usingAccapto is compared with the standard development method. The results show a
significant improvement in terms of accessibility for the model-driven development ap-proach.
Therefore the thesis proves that model-driven approaches have a high potential tosignificantly improving app accessibility from the beginning and helps developers toraise their awareness for the needs of special user groups.
Kurzfassung
Der Markt für Apps und mobile Software ist auf dem Vormarsch. Dies geht Hand inHand mit der Anzahl verfügbarer Apps, welche zuletzt die drei Millionen Marke über-schritten hat (siehe https://www.statista.com/statistics/266210/). Auf-grund dieser Entwicklung spielt die Bedienung von Smartphones eine entscheidendeRolle. Menschen mit Behinderungen profitieren von der zunehmenden digitalen Tech-nologie im Allgemeinen, aber nur, wenn sie zugänglich ist. Allerdings sind Appsfür Menschen mit Behinderungen oft nicht zugänglich, da Touchscreens und visuelleDarstellungen ihre Bedürfnisse oft übersehen.
Nach der UN-Konvention über die Rechte von Menschen mit Behinderungen sind rund650 Millionen Menschen der Weltbevölkerung behindert. Innerhalb der EuropäischenUnion (EU) sind etwa 80 Millionen Menschen von Behinderungen betroffen. Um auchdiese große Gruppe europäischer BürgerInnen einzubeziehen, hat die EuropäischeUnion die Richtlinie (EU) 2016/2102, in Kraft setzt, in der gefordert wird, dass Websitesund mobile Anwendungen öffentlicher Stellen für alle zugänglich sind.
Die Überprüfung der Top-Apps im Android Store zeigt, dass selbst sehr beliebte Appswie WhatsApp, Messenger und Instagram Probleme mit der Barrierefreiheit haben,z.B. Text- und Bildkontraste, fehlende Objektbeschreibungen oder zu kleine Berühr-ungszielbereichsgrößen, sodass Benutzer mit Behinderungen nicht den gleichen Zu-griff auf diese Apps haben (siehe Kapitel 1).
Die vorliegende Arbeit präsentiert einen innovativen Ansatz, der die Implementierungvon Barrierefreiheit in den Entwurfs- und Entwicklungsprozess von mobilen Anwen-dungen von Anfang an unterstützt. Diese Arbeit stellt einen modellgetriebenen Ansatzfür eine bessere Integration von Accessibility-Anforderungen im Entwurfs- und En-twicklungsprozess vor.
Um dieses Konzept zu untermauern, erhalten EntwicklerInnen ein Prototyp-Tool na-mens Accapto (Accessible App Tool), um einen Interaktionsprototyp auf ein formalesModell zu übertragen. Die abstrakte Definition beschreibt Screens, Elemente der Be-nutzeroberfläche und Interaktionsworkflows in einer domänenspezifischen Beschrei-bungssprache. Das Modell wird in einen funktionierenden App-Prototyp für die Android-Plattform umgewandelt. Im Generierungsprozess wird die App mit der richtigen platt-formspezifischen Accessibility-Unterstützung erstellt und um zusätzliche unterstützen-de Funktionen erweitert.
Im Zuge dieser Arbeit wird die Barrierefreiheit des generierten App-Prototyps mitplattformspezifischen Tools evaluiert, durch die Web Content Accessibility Guidelines(WCAG) überprüft und durch unterschiedliche Nutzern mit speziellen Bedürfnissen
getestet.
Insbesondere wird das neue Entwicklungswerkzeug in einer empirischen Studie mit 50beteiligten Entwicklern analysiert. In zwei Testgruppen wird der modellgetriebene En-twicklungsansatz mit Accapto mit der Standardentwicklungsmethode verglichen. DieErgebnisse zeigen eine signifikante Verbesserung der Zugänglichkeit für den modell-getriebenen Entwicklungsansatz. Daher zeigt die Arbeit, dass modellgetriebene An-sätze von Anfang an ein hohes Potenzial haben, die App-Barrierefreiheit signifikantzu verbessern und EntwicklerInnen dabei unterstützen, auf die Bedürfnisse speziellerNutzergruppen aufmerksam zu machen.
Acknowledgments
I am grateful to many people who were directly or indirectly involved in the preparationof this thesis. In particular, I want to thank
• my supervisor a.Univ.-Prof. Dr. Klaus Miesenberger for his support and guidanceduring my thesis
• Prof. Dr. Roberto Manduchi reading this thesis as the second examiner
• my colleagues at FH JOANNEUM and Johannes Kepler University (JKU) helpingme in my scientific work and their critical discussion when I needed fresh ideas
• my students for testing prototypes, filling out questionaries and evaluating gen-erated apps
• my family and friends for their motivating words and their support.
And finally, my biggest thanks goes to Beate, Julian, and Niklas, who always gave memotivation and encouraged me to go on.
Contents
1 Introduction 11.1 Accessibility Problems in Mobile Apps . . . . . . . . . . . . . . . . . . . 11.2 Why Should Your App be Accessible? . . . . . . . . . . . . . . . . . . . 61.3 Aims of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Proposed Solution: Accapto – Accessible App Tool . . . . . . . . . . . . 81.6 Methodology and Structure of this Thesis . . . . . . . . . . . . . . . . . 91.7 Published Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Background and Related Work 112.1 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Disabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 Accessibility Legislation . . . . . . . . . . . . . . . . . . . . . . . 132.1.3 Accessibility Standards . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Mobile Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1 Mobile Accessibility Mapping . . . . . . . . . . . . . . . . . . . . 172.2.2 Accessibility Features of Popular Mobile Platforms . . . . . . . . 182.2.3 Accessible Android Apps . . . . . . . . . . . . . . . . . . . . . . 182.2.4 Related Work on Mobile Accessibility . . . . . . . . . . . . . . . 19
2.3 Model-Driven Development (MDD) . . . . . . . . . . . . . . . . . . . . . 222.3.1 Model and Meta-Model . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Modeling Languages . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 Model Transformation and Code Generation . . . . . . . . . . . . 25
2.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.1 Model-driven Development for User Interfaces . . . . . . . . . . 262.4.2 Model-Driven Development for Mobile Applications . . . . . . . . 282.4.3 Model-Driven Development supporting Accessibility . . . . . . . 29
2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Model-Driven Development for Accessible Apps 313.1 Modeling with UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
i
CONTENTS ii
3.1.1 UML Diagrams for User Interaction . . . . . . . . . . . . . . . . . 333.1.2 Accessibility and UML . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 A Model for Accessible Apps . . . . . . . . . . . . . . . . . . . . . . . . 353.2.1 Elements of an Accessible Mobile App Model . . . . . . . . . . . 363.2.2 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3 Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Model Description (DSL) for Accessible Apps . . . . . . . . . . . . . . . 393.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Generation of Accessible Apps 434.1 Android Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Parsing the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 App Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 App Scaffolding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.2 Templating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Accessibility Enrichment in Android Apps . . . . . . . . . . . . . . . . . 494.4.1 Implementation of Accessibility on Android . . . . . . . . . . . . 494.4.2 Proper Implementation for Accessibility . . . . . . . . . . . . . . 514.4.3 Runtime Accessibility Extension . . . . . . . . . . . . . . . . . . 544.4.4 Runtime Theme Selection . . . . . . . . . . . . . . . . . . . . . . 554.4.5 SpeechOutput Helper . . . . . . . . . . . . . . . . . . . . . . . . 564.4.6 SpeechInput Helper . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5 Accapto - Accessible App Toolkit . . . . . . . . . . . . . . . . . . . . . . 564.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Accessibility Evaluation of the Resulting App Prototype 595.1 From Mockup to Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Accessibility Evaluation of the Resulting App . . . . . . . . . . . . . . . 61
5.2.1 Accessibility Evaluation Android Smartphone Apps . . . . . . . . 615.2.2 Evaluation with W3C Mobile Accessibility Guidelines . . . . . . . 645.2.3 Evaluation with Web Content Accessibility Guidelines (WCAG) . 665.2.4 Evaluation with Test Users . . . . . . . . . . . . . . . . . . . . . 695.2.5 Quick Accessibility Check . . . . . . . . . . . . . . . . . . . . . . 73
5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6 Empirical Evaluation of the Model-Driven Development Process 766.1 Study Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2 Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 Development Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.1 Model-driven Development with Accapto . . . . . . . . . . . . . . 796.3.2 Development with Android Studio . . . . . . . . . . . . . . . . . . 79
6.4 Accessibility Evaluation Task . . . . . . . . . . . . . . . . . . . . . . . . 80
CONTENTS iii
6.5 Results of the Empirical Evaluation . . . . . . . . . . . . . . . . . . . . . 816.5.1 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.5.2 Workload of Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 866.5.3 Awareness and Learning Effect . . . . . . . . . . . . . . . . . . 87
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7 Conclusion and Outlook 937.1 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Appendix A Accapto Model 113A.1 XSD Schema Definition of the Accapto Model . . . . . . . . . . . . . . 113A.2 Model of Routing app in XML . . . . . . . . . . . . . . . . . . . . . . . . 115
Appendix B Data Usertesting 117
Appendix C Details from the Empiric Evaluation 121C.1 Evaluation Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121C.2 Questionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.2.1 Pre-Questionary . . . . . . . . . . . . . . . . . . . . . . . . . . . 122C.2.2 Accessibility Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 123C.2.3 Post - Questionary . . . . . . . . . . . . . . . . . . . . . . . . . . 124C.2.4 Data from Participants . . . . . . . . . . . . . . . . . . . . . . . . 126C.2.5 Data A11y Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 127C.2.6 Data A11y awareness & learning effect . . . . . . . . . . . . . . 129C.2.7 Data A11y Interviews . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix D CV Elmar Krainz 135D.1 Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135D.2 Teaching and Working Experience . . . . . . . . . . . . . . . . . . . . . 135D.3 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136D.4 Main Research Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
D.4.1 Research Projects (Selection) . . . . . . . . . . . . . . . . . . . . 136D.4.2 Publications (Selection) . . . . . . . . . . . . . . . . . . . . . . . 137
D.5 Other scientific Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 138D.6 Profiles on Science Platforms . . . . . . . . . . . . . . . . . . . . . . . . 139
List of Tables
1.1 Accessibility Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Statistical data of problems - Normalisation and ranking after the best
accessibility ratings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Four-layer-metamodel hierarchy . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Evaluation with W3C Mobile Accessibility guidelines . . . . . . . . . . . 655.2 Evaluation with W3C WCAG 2.0 levels A and AA . . . . . . . . . . . . . 675.3 Evaluation with W3C WCAG 2.0 levels A and AA, part 2 . . . . . . . . . 685.4 Quick accessibility check - Assistive technologies . . . . . . . . . . . . . 745.5 Quick accessibility check - Errors from Accessibility Scanner . . . . . . 745.6 Quick accessibility check - manual checks . . . . . . . . . . . . . . . . . 745.7 Association of QAC Rules to WCAG Success criterions and guidelines . 75
6.1 Single Accessibility evaluation . . . . . . . . . . . . . . . . . . . . . . . . 816.2 Statistics of Accessibly Evaluation . . . . . . . . . . . . . . . . . . . . . 846.3 Usability in App Development . . . . . . . . . . . . . . . . . . . . . . . . 88
iv
List of Figures
1.1 The rise of available apps in Apple’s App Store and Google’s Play Storefrom 2008 to 2016. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Examples of accessibility problems detected by the Accessibility Scanner. 31.3 Over 90% reported at least three major issues regarding the Google
Play Store top 100 apps. . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Most of the top 10 apps actually have issues A4 and A5. . . . . . . . . 51.5 The best 10 apps according to accessibility report problems for A1 and
A2 only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Accapto overview [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 The context of the standards WCAG, UAAG and ATAG (from https:
//www.w3.org/WAI/guid-tech). . . . . . . . . . . . . . . . . . . . . 162.2 The basic idea of model-driven development. . . . . . . . . . . . . . . . 222.3 The relation between real objects, model and meta-model. . . . . . . . 232.4 The transformation process of model-driven development. . . . . . . . 252.5 Simplified version of the Cameleon Reference Framework [2] . . . . . . 262.6 The research focus is in the intersection of model-driven development,
mobile app development, and accessibility. . . . . . . . . . . . . . . . . 30
3.1 Typical paper prototype for the interaction flow in a mobile app. . . . . . 323.2 Storyboard in Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Example of a UML use case diagram for a simple routing app. . . . . . 343.4 Example of a UML sequence diagram for geocoding in routing app. . . 343.5 Example of a UML activity diagram for a simple routing app. . . . . . . 343.6 The UML class diagram of the model. . . . . . . . . . . . . . . . . . . . 383.7 Simple app model: (a) app mockup, (b) model. . . . . . . . . . . . . . . 39
4.1 Building chain of Accapto. . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Android app development project. . . . . . . . . . . . . . . . . . . . . . 444.3 XML to Java binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Overview of Accapto code generation. . . . . . . . . . . . . . . . . . . 474.5 Template processing for code generation. . . . . . . . . . . . . . . . . . 48
v
LIST OF FIGURES vi
4.6 Example of insufficient contrast and colour as only distinctive feature(left). Proper usage of contrast, colour and text (right). . . . . . . . . . . 51
4.7 Different styles of the Accapto Accessibility Pattern Library . . . . . . . 534.8 Generated input item with TextView and EditText. . . . . . . . . . . . . 544.9 Checkbox without and with touch extension. . . . . . . . . . . . . . . . 554.10 Accapto overview [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Mockup of routing app. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Generated app with (a) low vision and (b) standard theme. . . . . . . . 615.3 Setup of Lint for accessibility checks. . . . . . . . . . . . . . . . . . . . . 635.4 Code inspection with Lint using accessibility rules. . . . . . . . . . . . . 635.5 Results of the WCAG evaluation. Overall 20 rules passed, 2 rules failed
in the evaluation and 15 rules were not applicable. . . . . . . . . . . . . 685.6 Final app for usertest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.7 User tests: left: test person with cognitive disability, right: blind test
person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.8 Average TLX of the the task compared to the different user groups. . . . 725.9 Average SUS score by user groups. . . . . . . . . . . . . . . . . . . . . 73
6.1 Work experience of participants. . . . . . . . . . . . . . . . . . . . . . . 786.2 Programming skills of participants. . . . . . . . . . . . . . . . . . . . . . 796.3 UI design and accessibility skills . . . . . . . . . . . . . . . . . . . . . . 806.4 Mockup of the app prototype. . . . . . . . . . . . . . . . . . . . . . . . . 806.5 Boxplot of self-estimated accessibility rating. . . . . . . . . . . . . . . . 826.6 Barplot of accessibility rating. . . . . . . . . . . . . . . . . . . . . . . . . 836.7 Boxplot of accessibility rating. . . . . . . . . . . . . . . . . . . . . . . . 856.8 TLX of the evaluation task. . . . . . . . . . . . . . . . . . . . . . . . . . 866.9 TLX of the development task. . . . . . . . . . . . . . . . . . . . . . . . . 876.10 Q1- Before and after development task; model-driven vs. standard de-
velopment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.11 Q3- Before and after development task; model-driven vs. standard de-
velopment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.1 User tests with persons with motor and cognitive disabilities . . . . . . . 117B.2 User tests with elderly people . . . . . . . . . . . . . . . . . . . . . . . . 118B.3 User tests with visually impaired people . . . . . . . . . . . . . . . . . . 119B.4 User tests with persons without restrictions . . . . . . . . . . . . . . . . 120
C.1 Participants of the empiric evaluation. . . . . . . . . . . . . . . . . . . . 126C.2 A11y evaluation test group Accapto. . . . . . . . . . . . . . . . . . . . . 127C.3 A11y evaluation test group Android Studio. . . . . . . . . . . . . . . . . 128C.4 A11y awareness & learning effect data. . . . . . . . . . . . . . . . . . . 129
LIST OF FIGURES vii
C.5 A11y awareness & learning effect chart 1. . . . . . . . . . . . . . . . . . 130C.6 A11y awareness & learning effect chart 2. . . . . . . . . . . . . . . . . . 131
Listings
3.1 XML of the ScreenType . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 XSD of the ScreenType . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3 Model of WhereAmI App in XML. . . . . . . . . . . . . . . . . . . . . . . 414.1 Template code fragment for a method stub in Java class. . . . . . . . . . 474.2 Template code fragment for a method stub in Java class. . . . . . . . . . 484.3 Template for the UI element in the XML layout file. . . . . . . . . . . . . 484.4 Generated input item with TextView and EditText. . . . . . . . . . . . . . 545.1 XML model of routing app . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.1 XSD of the Accapto model . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.2 Model of the example routing app. . . . . . . . . . . . . . . . . . . . . . 115
viii
Chapter 1
Introduction
In the information age, software is the foundation of the connected world of comput-ers. With the introduction of the first modern smartphone in the year 20071 human-computer interaction moved from personal computers and laptops to tablets, phonesand other smart devices.
In the year 2013 the number of mobile Internet devices reached 10 billion, which isabout 1.4 device per person on the planet [3]. With the rise of smartphones the needfor special software products is also increasing.
The market for apps and mobile software is growing. Mobile users spend about 90 percent of their mobile time in apps [4]. People use various apps and most of these areeasy to operate, because of their simple and intuitive user interfaces.
Since 2008 the available apps have increased from 800 (2008, Apple App Store2) to3.500.000 (December 2017, Google Play3). Figure 1.1 shows the soaring progress inthe number of available apps in the two most popular app publishing platforms.
Mobile applications, or apps, come with a simple, intuitive user interface. Touchscreens and visual representation provide very natural user interaction, but unfortu-nately not for everyone. Not every app is accessible for people with disabilities.
1.1 Accessibility Problems in Mobile Apps
To use the features of a software product like a website or app, the first step is accessto the technology. Accessibility is the ability to perceive, understand, navigate and
1Apple presented the first iPhone in January 20072https://www.statista.com/statistics/263795/number-of-available-apps-in-t
he-apple-app-store/3http://www.statista.com/statistics/266210/number-of-available-application
s-in-the-google-play-store
Chapter 1
800
3,000
35,000
65,000
100,000
150,000 225,000 300,000
350,000 425,000 500,000 585,000
650,000
700,000 80
0,000
850,000
900,000 1,000,000
1,200,000
1,300,000
1,400,000
1,500,000
2,000,000
2,200,000
16,000
30,000
38,000
70,000
100,000 20
0,000
250,000
300,000 40
0,000
450,000
500,000 60
0,000 675,000
700,000
850,000
1,000,000
1,300,000
1,400,000
1,600,000
1,800,000
2,000,000
2,400,000
2,600,000
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000
AVAILABLEAPPSINANDROIDANDAPPLESTOREDATA FROM:HTTPS://WWW.STATISTA .C OM/S TATI S TICS/266210/NUMBER-OF -AVAILABLE-APPL ICA TIONS -IN - THE -G OOGLE -PLAY-S TOR E/HTTPS://WWW.STATISTA .C OM/S TATI S TICS/263795/NUMBER-OF -AVAILABLE-APP S-I N- TH E-APPL E-APP -S TORE/
Apple
Android
Figure 1.1: The rise of available apps in Apple’s App Store and Google’s Play Storefrom 2008 to 2016.
interact with a software product [5] unrestricted to the people’s abilities.
Smartphone apps tend to be intuitive and easy to use. People of all ages use appsto stay connected, consume media, use helpful tools or just play games. According toKane et.al [6], mobile devices give people with disabilities new chances and opportu-nities for an independent lifestyle. But not all apps are implemented with accessibilityin mind.
The following example of a shopping app explains the lack of awareness of accessibil-ity. Figure 1.2 shows a typical Android app including a representative dashboard withicons, textual descriptions and interactive elements. The app is also well designedto reflect the company’s visual corporate identity. However, typical accessibility errorscan also be found. In this screenshot, we can see a missing object item label fortext-to-speech, a contrast ratio lower than 3:0 in texts and images, and touch targetssmaller than 48x48dp.
To get an overview of possible accessibility issues of an app, Google provides a usefultool called Accessibility Scanner [7]. In order to measure accessibility, it is vital to de-fine metrics first. The metrics used by Accessibility Scanner, as listed in Table 1.1, arecontent label, object description, editable content label, clickable items, touch targetand text and image contrast. These criteria are explained and grouped on the websiteof the scanner into four main categories [8] content labelling, implementation, touchtarget size and low contrast.
2
Chapter 1
Figure 1.2: Examples of accessibility problems detected by the Accessibility Scanner.
Code MetricA1 Touch target sizeA2 Item label missingA3 Editable item labelA4 Text contrastA5 Object descriptionA6 Clickable linksA7 Image contrast
Table 1.1: Accessibility Metrics
In Reip’s study [9], the overall goal is to show how many, if any, of the selected GooglePlay store top apps consider accessibility properly. To gain deeper insight into mobileapps, they were evaluated by means of this accessibility inspection tool.
In fact, applications have different amounts of screens and as a result, the compara-bility decreases. Consequently, three major screens are evaluated, namely the homescreen, the logon screen and a preferences screen. Although some applications donot contain one of those screens, similar screens are taken. For instance, if an appdoes not include a logon screen, a contact screen is evaluated. Under those circum-stances, a meaningful result is provided.
Furthermore, the number of applications examined is equally important for a mean-ingful result. At first, about 200 of the first Google Play’s top apps were put on the
3
Chapter 1
91%
87%
4%
90%
52%
19%
52%
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
A1 A2 A3 A4 A5 A6 A7
Figure 1.3: Over 90% reported at least three major issues regarding the Google PlayStore top 100 apps.
long list, which was then reduced to a short list by filtering (for example, the main ideaof games can already breach accessibility guidelines, 87 of the first 193 applications(45,08%) are games and were therefore eliminated).
Analysing the data of the study [9] accessibility issues are found in every one of the100 top-rated apps. Even in simple ones like flash-lights problems were reported.Opon closer examination (see Figure 1.3) on to the different problem categories, onecan see that more than 50% of apps fail in five out of seven criteria. Nearly 90% haveproblems in touch target size (A1), missing item label (A2) and insufficient text contrast(A4). Missing objects descriptions (A5) and image contrast (A7) are reported in everyother app. Few problems were found according to clickable links (A6) and there werehardly any issues with editable item labels (A3).
Reported numbers of errors are sometimes very high because some iterative elementslike list or icons set occur more than ones on an app screen. For further qualitativeinformation about the accessibly issues, we normalised the error count to a dual repre-sentation. Errors A1 to A7 are transferred to a binary measurement. There are eithererrors in the selected section or no value. With this normalisation, multiple counting ofthe same categories is avoided.
Figure 1.4 shows the distribution of accessibility issues in the top 10, 20 and 100 apps.The number of different errors (A1 to A6) are consistent in all three ranking groups.This means the best ranked (top 10 and top 20) apps in the store have similar errorsin quantity and category to the top 100.
4
Chapter 1
10%
0%
20%
30%
40%
0% 0%
10%
0%
15%
40%
35%
0% 0%
3%
8%
15%
41%
31%
2%
0%
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
#1 #2 #3 #4 #5 #6 #7
Top10 Top20 Top100
Figure 1.4: Most of the top 10 apps actually have issues A4 and A5.
Top20 Top100 Diffmin. 1 1 0max. 3 6 3median 2 4 2average 2,3 3,95 1,65
Table 1.2: Statistical data of problems - Normalisation and ranking after the best ac-cessibility ratings.
To find out the top rated apps in ease of accessibility, we chose a different ranking.Sorting the apps in order of the number of reported accessibility errors, we got adifferent result. Comparing the top 20 best accessible apps to the top hundred, asignificant difference can be seen. The median of the top 20 best-accessibility ratedapps is only half and the average is 1.65 lower. In the top 20 we found a maximum of3 different errors, which is half of the top 100 (see Table 1.2).
In contrast to the first chart regarding the distribution of accessibility issues, we can seea different distribution in Figure 1.5. In the alternative sorting with the best accessibleapps first, we observe an offset to fewer reported accessibility issues. The top 10best accessibility rated apps show only errors in one or two categories, the top 20 inonly three categories. Here we can also visually show that there are differences inaccessibility with fewer reported errors.
5
Chapter 1
30%
70%
0% 0% 0% 0% 0%
15%
40%
45%
0% 0% 0% 0%
3%
8%
15%
41%
31%
2%
0%
0%
10%
20%
30%
40%
50%
60%
70%
80%
#1 #2 #3 #4 #5 #6 #7
Top10 Top20 Top100
Figure 1.5: The best 10 apps according to accessibility report problems for A1 and A2only.
This study provides insights about the current lack of accessibility support in mobileapplications. Analysing the 100 top apps of the Google Play Store has shown thatnone of the aforementioned apps would fully pass the automated accessibility evalua-tion with Accessibility Checker. The findings revealed several lacking features as wellas violations against the accessibility best practice guidelines.
1.2 Why Should Your App be Accessible?
Why should accessibility be respected? This can be answered in five ways.
A large part of humankind is excluded
According to the UN Convention on the Rights of Persons with Disabilities (CRUD) [10]around 10 per cent of the world’s population is handicapped. These 650 million peopleare a very large minority. Furthermore, the World report on disability [11] indicate that15,3% of the world population has a prevalence of a moderate disability; even 2.9%have a severe impairment. Regarding the European Union, about 80 million people inthe EU are affected by a disability [12].
6
Chapter 1
People with disabilities are an economically significant factor
About 10% of the world population is a significant economic factor. Due to the lack ofaccessibility, people are excluded from products and services. The proportion of olderpeople is also on the rise and this group has to fight on the one hand with physical andcognitive restriction and on the other hand, this is an economically potent group.
Accessibility is politically accepted and more and more legally required
The European Commission agreed to an EU-wide rule to make public-sector websitesand apps more accessible. 4,5. In 2016 the European Union enacted the Directive(EU) 2016/2102 which "..aims to ensure that the websites and mobile applications ofpublic sector bodies are made more accessible on the basis of common accessibilityrequirements." [13].
Accessibility has socio-economic reasons
Everything, which lacks accessibility requires social support and care. Accessibilityimproves independence and reduces care and support costs considerably.
Because we have the technology and it is easy or justifiable
Assistive technologies are now part of many operating systems (e.g. VoiceOver6) andwe have guidelines (e.g. Web Content Accessibility Guidelines [14]. To sum it up, thewords of lkka Pirttimaa, inventor of BlindSquare7 are accurate. "..accessibility is notjust an additional feature, but a best-practice" [15].
1.3 Aims of this Thesis
Software on mobile devices is on the rise, but this sector of software industry doesnot take every user group into consideration. People with disabilities, which is a largegroup of users, have more or less problems to use those apps.
The aims of this thesis are:
1. Research background of accessibility on mobile devices, considering standards,regulations and platform specifics; research the foundation of model-driven de-velopment with a focus on accessibility and mobile devices.
2. Research of state of the art Android app accessibility and exploring the poten-tial of model-driven development for pushing accessibility of app developmentforward.
4http://europa.eu/rapid/press-release_IP-16-1654_en.htm5http://www.consilium.europa.eu/en/press/press-releases/2016/07/18-accessi
ble-websites-apps-wide-rules/6https://www.apple.com/de/accessibility/7Blindsquare is an accessible GPS navigation app for blind people http://www.blindsquare.com.
7
Chapter 1
3. Find an intuitive model for designing accessible mobile applications.
4. Find a procedure to generate the prototype of an accessible app based on themodel.
5. Validate and evaluate the accessibility of the app prototype created.
6. Validate the accessibly improvement of the model-driven development tool withdevelopers
1.4 Research Questions
The objectives of this thesis lead to the following research questions
• RQ 1: How can model-driven development support the development of accessi-ble apps?
RQ 1.1: What kind of model is needed for the model-driven approach?
RQ 1.2: How can the model-transformation create an accessible app?
• RQ 2: Does model-driven development lead to better and more accessibleapps?
• RQ 3: Do model-driven approaches increase awareness of and practice in ac-cessible app development?
1.5 Proposed Solution: Accapto – Accessible App Tool
"Programming an accessible Android app is not technically difficult, but is often skippedin the rush of a deadline", said Kelly Schuster [16].
The proposed solution gives developers a toolset to include accessibility in mobile appdevelopment from the beginning. Accapto - Accessible App Tool -
consists of two components, the first being a model for accessible app interaction.The second one is a generator to transform models into accessible apps. The modeldescribes the main component and interactions of an app which are important for anaccessible user interface. The model components and the description language areexplained in Chapter 3. The generator transforms the model into an app project withthe enrichment of proper implementation of accessibility and additional components tosupport different kinds of user restrictions. Fig 1.6 shows the overview of the proposedsystem.
8
Chapter 1
Accapto
Parsing&Validation
ModelXML AppProjectModelXMLModelXML
AppComponents
UserInterfaces
AccessibilityEnrichment
App
NativeCode
creates
generates
dependson
Developer
Figure 1.6: Accapto overview [1]
1.6 Methodology and Structure of this Thesis
The scientific methodology of this work follows these procedures. The foundation ofany research in the field of computer science is solid background and related work.Budgen and Brereton [17] claim the basis for research in computer sciences and soft-ware engineering is to find the related work like standards, literature, and state ofthe art in development. Chapter 2 presents the literature relevant to the main topicscomputer accessibility and model-driven development.
The key factors for good research in software engineering are according to Shaw [18],[19] the type of question, the type of result and the type of validation.
Type of Question:Method or means of development: How can model-driven development support thedevelopment of accessible apps?
Type of Result:(1) Qualitative or descriptive model: A domain model for accessible mobile apps –Chapter 3 shows the design of the model for accessible mobile apps and the domainspecific language (DSL) to describe it.
(2) Procedure or technique: Integration of accessibility in the development processwith model-driven development – Chapter 4 focuses on the transformation process,the app generation process and the extension of selected assistive components.
Type of Validation:(1) Example: Implementation of an accessible routing app - Chapter 5 shows the
9
Chapter 1
implementation of an accessible routing app. Additionally, the accessibility of the re-sulting app is evaluated using common guidelines and with tested by users with dis-abilities. (c.f. Krainz et al. Accessible way finding on mobile devices for different usergroups, 2016 [20])
(2) Experience: Evaluation of the Accapto tool with developers - Chapter 6 points outhow developers use the tool in a test scenario and the improved accessibility of theresulting apps is tested.
1.7 Published Contributions
The research results of this thesis were previously published in the following papers:
• Krainz et al. Can We Improve App Accessibility with Advanced DevelopmentMethods? will be published at ICCHP 2018
• Krainz and Miesenberger Accapto, a Generic Design and Development Toolkitfor Accessible Mobile Apps. [1]
• Krainz et al. Accelerated Development for Accessible Apps - Model Driven De-velopment of Transportation Apps for Visually Impaired People [21]
• Krainz et al. Accessible way finding on mobile devices for different user groups[20]
• Krainz et al. Catching the Right Bus - Improvement of Vehicle Communicationwith Bluetooth Low Energy for Visually Impaired and Blind People [22]
Previous work related to mobile app accessibility:
• Krajnc et al. A touch-sensitive user interface approach on smartphones for visu-ally impaired and blind persons [23]
• Krajnc et al. User centered interaction design for mobile applications focused onvisually impaired and blind peoples [24]
• Mattheis & Krajnc Route Descriptions in Advance and Turn-by-Turn Instructions-Usability Evaluation of a Navigational System for Visually Impaired and BlindPeople in Public Transport [25]
• Bischof, Krajnc, Dornhofer, & Ulm NAVCOM–WLAN Communication with PublicTransport Vehicles to Support Visually Impaired and Blind People [26]
10
Chapter 2
Background and RelatedWork
According to RQ 1 – How can model-driven development support the development ofaccessible apps?, this chapter establishes the groundwork for this thesis. The first partof the literature review covers accessibility and the accessibility of mobile applicationsin detail. The second part considers the topic of model-driven development, with afocus on user interfaces, mobile applications and accessibility. Based on the literaturereview it can be argued that model-driven development enhances the development ofaccessible apps and is thus an original contribution to the field.
2.1 Accessibility
The usability of a software system is an important factor in order to give users a greatexperience. There are definitions and standards for the usability of a system (seeNielsen [27] and ISO 9241-11 [28]). For some people, however, user experience issubordinate if they are not able to get access to the system at all, which leads toaccessibility.
The ISO Standard ISO 9241-171:2008 [29] defines accessibility as:
<interactive system> usability of a product, service, environment or facilityby people with the widest range of capabilities
The ISO definition addresses all user abilities, not only limited to people who are for-mally disabled or restricted. Accessibility is part of usability, but access to a productor service is rather a necessary condition for usability [30].
The Web Accessibility Initiative WAI [5] of the W3C defines (Web) accessibility more
Chapter 2
accurately as the possibility for people with disabilities to use the Web. In other words,this means:
that people with disabilities can perceive, understand, navigate, and inter-act with the Web, and that they can contribute to the Web
2.1.1 Disabilities
The following section provides a summary of the most important groups of disabilities.The International Classification of Diseases (IDC) [31] defines all diseases, injuriesand disabilities in a standardised hierarchical categorisation. This classification is usedto give a clear distribution of these disabilities.
The W3C Web Accessibility Initiative (WAI) [32] gives an overview of the wide diversityof people and abilities. WAI also provides descriptions as well as some technicalaspects for people with special needs [33]. These personas are helpful to present atypical user with his or her restrictions to use the Web, an app or a computer.
2.1.1.1 Blind people
Blind people have either very limited or no visual perception. The IDC-10 H54.01
defines blindness as a visual acuity below 1/50 (0.02), which means an item must be50 times larger to be recognised compared to a person without visual restrictions.
For the usage of computers or smartphones blind people rely on screen reading sys-tems like Voiceover, Talkback or Jaws as well as special input/output-devices, such asa braille display. Interaction with a mouse is not possible and the use of touch screensis limited [33], [32].
2.1.1.2 Visually impaired people
Not everyone with a visual restriction is completely blind. Many people suffer from a vi-sual impairment like low vision (IDC-10 H54.1-9 2) or color blindness (IDC-10 H53.1-9).With these restrictions, one is not always handicapped in daily life but needs supportwhile using, for instance, a smartphone.
Websites and apps have to provide sufficient text sizes and visual information or properimplementation to use zooming. Adequate contrast in the user interfaces is also im-portant.
1http://apps.who.int/classifications/icd10/browse/2016/en#/H53-H542http://apps.who.int/classifications/icd10/browse/2016/en#/H53-H54
12
Chapter 2
2.1.1.3 People with hearing disabilities
People with hearing disabilities (IDC10 H60-H953) are not able to recognise soundsor spoken texts. Sometimes sign language is the mother tongue of a deaf person andwritten texts are not always feasible. In this context, we have to distinguish betweendeaf people and people with hearing impairments. These different groups also needdifferent assistive technologies.
User interfaces have to provide text alternatives to audio and video information. Al-ternatives to texts in sign language should be considered. Acoustic notifications oralarms are not reliable for this user group.
2.1.1.4 People with motor disabilities
Motor disabilities are unlike the ones described previously. People with a physicalhandicap can mostly retrieve information in a visual or audio form, but are limited inthe active interaction with a system. There are various diseases like paralysis, tremorsor temporary injuries which can cause a physical handicap.
People are reduced in their usage of standard input devices and touch gestures. Sim-plified interaction with less active input like selection rather than text entry helps toimprove accessibility
2.1.1.5 People with cognitive disabilities
People with cognitive disabilities are a very heterogeneous group. Older people withdementia (IDC G30-G32 4) or humans with intellectual disability (IDC F70-795) haveproblems perceiving and understanding complex user interfaces on computers. More-over, the reduced ability to read complicated texts and comprehend abstract conceptswhich are part of many IT systems is challenging.
This user group needs simple interaction and easily readable texts. Providing alterna-tive ways of interactions like icons instead of complex texts is a possible aid.
2.1.2 Accessibility Legislation
Besides best practices and standards to support handicapped people, there are alsolegal regulations and international acts to enable digital technologies for all humans.
3http://apps.who.int/classifications/icd10/browse/2016/en#/H90.04http://apps.who.int/classifications/icd10/browse/2016/en#/G30-G325http://apps.who.int/classifications/icd10/browse/2016/en#/F70-F79
13
Chapter 2
First of all the UN Convention on the Rights of Persons with Disabilities (CRPD) [10]is meant to protect the rights and dignity of any person with a disability.
In the EU, the European Accessibility Act [34] aims to provide accessible products andservices, this also includes accessible ICT. The European Council has enacted an EU-wide law for accessible websites and apps [35]. The Directive (EU) 2016/2102 of theEuropean Parliament and of the Council of 26 October 2016 on the accessibility of thewebsites and mobile applications of public sector bodies (ext with EEA relevance) [13]ensures that websites and mobile applications of public sector bodies are accessiblefor anyone.
Austrian’s main platform for both legal and technical information is Digitales Österreich[36]. EU wide regulations, the Austrian Federal Constitution and the national DisabilityDiscrimination act (Behindertengleichstellungsgesetz)citebehindertengesetz ensure theaccessibility of digital systems.
§6 Absatz (Abs.) 5 Behindertengleichstellungsgesetz definiert, dass (...)technische Gebrauchsgegenstände, Systeme der Informationsverarbeitungsowie andere gestaltete Lebensbereiche barrierefrei sind, wenn sie fürMenschen mit Behinderung in der allgemein üblichen Weise, ohne beson-dere Erschwernis und grundsätzlich ohne Hilfe nutzbar sind. Als Beurteilungs-maßstab werden für Angebote im Internet die WAI-Leitlinien herangezo-gen. [37]
It is also worth mentioning the Rehabilitation Act Amendments of 1998, Section 508[38] and the Americans with Disabilities Act (ADA) [39], which are the main legal reg-ulations for accessibility in the United States. Currently, more than 40 countries havetheir own (Web) accessibility laws and policies and it is common to refer to the inter-national standards of the World Wide Web Consortium6.
2.1.3 Accessibility Standards
The World Wide Web Consortium (W3C)7, the main authority for standards on theWeb, developed rules to grant access to the Web for anyone. In 1999 the Web Con-tent Accessibility Guidelines (WCAG) 1.0 [40] were published. This first standard ad-dressed the Web and the technical implementation of HTML. Nine years later, thisstandard was superseded by the WCAG 2.0 [14]. In 2012 the WCAG 2.0 became thestandard ISO/IEC 40500:2012, Information technology - W3C Web Content Accessi-bility Guidelines (WCAG) 2.0 [41].
The significant difference was the change from a technological viewpoint to a more
6https://www.w3.org/WAI/Policy/7https://www.w3.org/
14
Chapter 2
general interpretation. The WCAG 2.0 included four general principles with a corre-sponding set of guidelines and success criteria.
Principles of the WCAG 2.0:
• Perceivable - All information or components of the user interface must be per-ceivable for any user; for example, information only presented in a graphical waymust also have text alternatives.
• Operable - All components must be operable; for instance, keyboard accessmust be provided by the system.
• Understandable - All information within the user interface must be understand-able; texts should be not only readable, but users should also understand themeanings, interaction must be predictable and input assistance like instructionsor help should be available.
• Robust - Contents must be able to be interpreted reliably by different user agents.
A draft of the new version of this standard, WCAG 2.1 [42], is now in the review pro-cess. This new version extends the existing standard and adds new success criteria.
The WCAG are primarily a rule set for Web applications, but the transformation fromclassic desktop browser to mobile devices and also the generalisation of the four prin-ciples allows these guidelines to also be adapted for other systems
There are some related W3C standards to build a bridge from the Web to other tech-nologies. Not only accessibility issues, but also the switch to mobile web browsing, arethe focus of Mobile Web Best Practices (MWBP) [43]. Some adaptations for mobileweb are also applicable to increase the accessibility which can be found in the Rela-tionship between Mobile Web Best Practices (MWBP) and Web Content AccessibilityGuidelines (WCAG) [44].
The basic principles of the WCAG, which are not focused on technology but on theuser’s needs, can also be used in other domains of ICT. The Guidance on ApplyingWCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)[45] is the approach to use and adopt the principles of WCAG to other non-Web infor-mation and communications technologies (ICT).
The rise of mobile applications also demands the transfer of accessibility issues/needsto mobile platforms. Currently, there is no standard but the draft Mobile Accessibility:How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile [46] to adopt generalaccessibility guidelines to mobile platforms. The WCAG principles are transferred tosmartphones, tablets and also smart wearables with specific interpretations for mobiledevices. For example, the principle perceivable has to focus on smaller displays oreven not existing visuals on smart wear. Easy data entry and support of platform
15
Chapter 2
specific characteristics is part of the principle robustness. More detailed informationas well as more platforms related to accessibility can be found in Section 2.2. x
Not only contents are important for good accessibility, but also the programs to createand consume them. The User Agent Accessibility Guidelines (UAAG 2.0) [47] considerbrowsers, media players and other tools for users to consume (web) content. Theseguidelines cover accessibility of the tools along with the interfaces of other assistivetechnologies.
The Authoring Tool Accessibility Guidelines (ATAG 2.0) [48] considers the accessibilityof the software and services to create web content and offers guidance to make thetools accessible. More importantly, it provides support for authors and editors to createtheir web content in an accessible form.
Fig 2.1 shows the context of the standards for content (WCAG), the authoring tools(ATAG) and the user tools (UAAG). For good accessibility all three parts are comple-mentary.
Figure 2.1: The context of the standards WCAG, UAAG and ATAG (from https://www.w3.org/WAI/guid-tech).
16
Chapter 2
2.2 Mobile Accessibility
Mobile devices are universal companions for people with disabilities. Before the ageof smartphones, people with special needs also had to use special devices as theirpersonal digital assistants, such as the Pronto organizer from Baum8. These veryspecial devices were also quite expensive.
Today most people own a smartphone, which supports them in their daily life. Butactually, there is still a lot of improvement in the accessibility of smart mobile devices.
2.2.1 Mobile Accessibility Mapping
At the moment, iOS and Android are the two major platforms for smartphones. Bothmobile operating systems have their own accessibility support, but there is no generalstandard. The W3C has released a working draft to apply the commonly acceptedWCAG to mobile systems and applications. Mobile Accessibility: How WCAG 2.0 andOther W3C/WAI Guidelines Apply to Mobile [49] is based on the same principles asthe WCAG 2.0, but they are more specific on mobile. In this context, mobile is genericfor smartphones, tablets and smart wearables.
Principles for mobile:
• Perceivable: One common feature of mobile devices is the small screen sizeor even the absence of the screen. Users need the ability to zoom. Contentsshould be reduced; contrast and text size should be adaptive.
• Operable: Small devices also have challenges regarding user input. Touch tar-gets must have an adequate minimal size; touchscreen gestures must be avail-able to provide different operations like exploring, selecting or tabbing on thetouchscreen. Interactive user interface controls like buttons must be reachedeasily. External keyboards are also an important factor to be able to operate amobile device.
• Understandable: A consistent layout and a clear indication that elements provideinteraction are important factors to understand a user interface. Accessibilityproblems can also occur with unpredicted changes in the screen orientation.
• Robust: Robustness is provided with easy data entry and preselection of inputtypes. In custom solutions, the platform characteristics for accessibility supportlike changing the system text size have to be implemented, as well.
8http://www.baum.at/de/produkte/pronto.html
17
Chapter 2
2.2.2 Accessibility Features of Popular Mobile Platforms
According to the latest mobile OS market share statistics9 Android and iOS accountfor 99,8% of the market. Nevertheless, in a commercial context, Windows Mobile stillhas its users.
2.2.2.1 Accessibility on iOS
Apple, with its philosophy of providing a closed system, also has integrated accessibil-ity support directly in the mobile operating system. iOS has a system-wide integrationof the built-in screenreader VoiceOver, which reads captions and audio descriptions.Display customisation with appropriate fonts and colours (e.g. colour schemes for thevisually impaired) are part of the system. Apple’s iOS has a guided access for peoplewith attention and sensory challenges[50].
More detailed information and specially issues for proper development are availableon Accessibility Programming Guide for iOS [51]. Important points concerning theintegrated accessibility support, and guiding for developers and tester are online.
2.2.2.2 Accessibility on Windows Mobile
Things have been quiet for Microsoft’s mobile operating system. Less than 0,1% ofthe mobile market share belong to Windows 10 Mobile. Nevertheless the accessi-bility support is given. Windows Mobile supports hearing aids, teletypewriters (TTY),speech input and output and screen readers on its platform [52].
The foundation for accessibility in Windows-based programs is the Universal App Plat-form10. The UWP app of windows allows the development of software on a wide rangeof devices including mobile ones like phones and tablets. In this universal approach ofMicrosofts platform accessibility is included from the beginning [53].
2.2.3 Accessible Android Apps
Due to it having the argest market share and the openness of its system11, the mainfocus of this thesis is the Android platform. In the rapid evolution of Android, acces-sibility wasn’t always a included. In the version previous Android Jelly Bean (4.1), ascreen reader was not integrated in the system, but was available as app. Custom
9https://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems/
10https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp11The source code of Android is open source see https://source.android.com/
18
Chapter 2
solutions like TalkingTouch from Krajnc et al. [23] created self-voicing apps instead ofan system wide support.
In the latter versions of the mobile operating system Google provides guidelines andprogramming interfaces to implement accessible apps. The Material Design Guide-lines [54] provides three main principles for accessibility. The first one is clear. Sim-plified layout, visible elements and hierarchy of importance help users to navigate anduse an app. Robust, the second principle, adapts an app for a broad range of differ-ent users. Users have to understand the apps major tasks of have access to the app.Lastly the app has to support the specific assistive technologies of the platform.
Furthermore, Material Design gives guidance for accessible development on Android[54].
1. Colour and contrast: According to the WCAG, the app design has to use a propercontrast ratio. A ratio with a least 4.5:1 for the app’s primary, secondary, andaccent colours provides good usability and accessibility.
2. Sound and motion: Visual alternatives to sound should be available (see WCAG)and enable motion if it is just a decorative element. Like the WCAG, flashingcomponents should be avoided and for any timed controls the user must haveenough time for an accessible user experience.
3. Style: Touchable components must provide at least a minimum touch target sizeof 48x48dp. Smaller icons also have to expand the touch size. The spacingbetween elements has to be at least 8dp. The grouping of the belonging UIelements allows for simpler interaction.
4. Hierarchy and focus: Proper position of items in visual and also tabbing orderis crucial for linear navigation, for example while using a screen reader. Withthe help of the focus the right order is made possible. Linear navigation alsodepends on adequate grouping of the elements.
5. Writing: Reasonable and understandable apps rely on succinct texts for labelsand descriptions.
Android has different built-in assistive technologies to provide alternative use casesto handle an app. Via the system settings, supporting tools like magnification, switchaccess, screen reader and various display settings (e.g. color correction)[55].
2.2.4 Related Work on Mobile Accessibility
Portable and mobile devices are affordable and ubiquitous, but are not always acces-sible for everyone [56]. Bringing accessibility to mobile devices and applications is dis-cussed in literature. Mobile apps were already helpful devices in the pre-smartphone
19
Chapter 2
age. Kane et al. [3] shows different use-cases as to how people with disabilities select,adapt and use mobile devices to improve their daily lives. The project Blindsight [57]provides eyes-free interaction on mobile devices which had still been using physicalkeyboards. A more general approach of user centered design for accessible mobileprograms is part of Krajnc et al. [24]. With personas, paper prototypes and a finalimplementation blind people receive a tailored user experience on their phone.
With the rise of modern touch-based smartphones, physical keyboards and buttonsvanished. Especially, people with disabilities had to adapt to this new paradigm. Vi-sually impaired and blind people have new requirements regarding touchscreens [58].Rodrigues et al. [59] attempt to comprehend the adoption of smart phone interactionfor the blind, in a study on the different tasks of users. Not only touch input, but alsomotion input and gestures are new interactions methods on smartphones [60].
Smartphones are also transforming into digital assistants for people with disabilities,like the work of Narasimhan et al. [61] shows. Visually impaired and blind people arealso the target group of Sierra et al. [62]. They design apps for the visually impairedand blind for touch devices with a focus on iOS.
The integration of assistive technologies on Android phones was not always obvious.A custom solution is the TalkingTouch library of Krajnc et al. [23]. TalkingTouch givesdevelopers the aim of adding touch to speech within an Android app. Bonner et al.[63] support text input without eye sight on Android
What is notable is the eyes-free project12. The work of Raman et al. [64, 65] lead tosupportive tools like Talking Dialer, SoundBack, KickBack and finally TalkBack whichis now the foundation of Androids assistive technologies. One of the latest spin offs istJust Speak [66] a way to control an Android smartphone mainly with voice input.
Visually impaired and blind people are an important user group dealing with touch-based user interfaces. Another physical restriction like motor disabilities also facesnew challenges on smartphones. Naftali &Findlater [67] tried to understand this newneed. Their study reveals issues in touch input systems like text entry in small inputfields. The work of Zhong et al.[68] improves the the lives of people with hand tremors,enhancing the touch input for them. Smart Touch also improves the touch accuracy[69] using patterns and templates. Better input accuracy for people with tremors withthe help of the motion sensor on the Android phones is part of Plaumann et al. [70].
Another large user group consists of people with hearing disabilities. Smartphoneswith apps function as portable listening devices [71] or hearing aids [72]. Apps arehelpful to train children with hearing disabilities by means of voice recognition [73].
Text, however, is not always an alternative for the deaf. For communication in theirmother tongue, deaf people depend on sign language. Different research aims to
12http://eyes-free.blogspot.co.at/
20
Chapter 2
introduce sign language on mobile devices [74, 75, 76], but there is still no integratedapproach on mobile platforms. New challenges also arise with external content likemedia data. For example, video content has to be dubbed in sign language [77].
The last group in this literature review is older people. This is a very heterogeneousgroup as far as know-how and restrictions are concerned [78, 79]. Azuddin et al. [80]studied the motivation for the elderly to use smartphones. The most important factorsare the wish to communicate with friends and family as well as safety in emergencysituations. Older people also have problems with mobile devices and apps. Issuesare too small font or touch sizes, new gestures (e.g. swipe) and also with the ability tolearn new interaction models.
Still, smartphones are useful tools in healthcare for older people [81, 82]; new methodsof user interactions like augmented reality on mobile phones [83] also enhance thetarget groups of people with special needs on mobile applications.
The literature review shows that mobile devices are an assistive technology for bothdifferent situations and different disabilities. Diverse restrictions need specialised so-lutions to the problems. Many of these examples are focused on a special task ora special kind of restriction. A new challenge is the widespread support of differentdisabilities and the integration into the different systems.
It can be concluded that although accessibly is established in terms of ethical, econom-ical and legal constrains (i.e. WCAG, UAAG and others), developers and designershardly put this guidelines and recommendations into practice. The lack of awarenessand the missing support of developer-tools, which should guide and lead to better ac-cessibility in resulting software products, addresses the main research questions ofthis thesis.
21
Chapter 2
2.3 Model-Driven Development (MDD)
What is model-driven development? Software development is an elaborate proce-dure. Software engineering aims to increase the quality of SW products and reducethe complexity of the development process [84]. A model-based approach helps thestakeholders of a software project to reach these objectives [85], [86]. Models arehelpful for the communication between software engineers and other involved parties,to share the knowledge of the domain and the documentation of the resulting softwareproduct[87].
Model-driven architecture (MDA), model-driven development (MDD) or model-drivensoftware engineering (MDSE) are various terms for this development approach. Themethod of model-driven development creates software or source code automaticallyfrom a formal model [85]. In Figure 2.2, the core components and the basic idea areshown. The modeling language describes an application model; the transformationgenerates schematic repetitive code from an instance of the application model; gener-ated code and additional individual code finally build the resulting application
Transformation IndividualCode
Application
ModelingLanguage
ApplicationModeldescribes
transforms
defines
GeneratedCode
transforms
Figure 2.2: The basic idea of model-driven development.
There are several reasons to use model-driven development (MDD).
• Abstraction: with a higher level of abstraction, developers can focus on the prob-lem and the complexity is better manageable[85]
• Improved architecture: generalised models improve the reusability of code andtools [85]
22
Chapter 2
• Improved development: with automatisation the development speed increasesand the code quality improves [85]
For a deeper understanding we focus on models, domain specific languages and thetransformation in the following sections.
2.3.1 Model and Meta-Model
Models help to understand complex problems [88], which is why they are a useful con-cept to reduce complexity. With generalisation, classification and aggregation peoplecreate simpler models to deal with complex contexts [86]. Model-driven developmentuses several kinds of models. Even a model is an abstraction of a meta-model, whichis again an abstraction to a meta-meta-model. Figure 2.2 shows the relation in thesedifferent layers.
Elements of the Model
Model
“Real World” Objects
Domain
Elements of the Meta-Model
Meta-Model
describesdescribes
Figure 2.3: The relation between real objects, model and meta-model.
A common example is the four-layer-metamodel hierarchy [89]. Tab.2.1 presents thedifferent layers in this system. Beginning from the bottom up, there is an instance(M0) for example the person object p="John" of the user model (M1) the class Personwhich describes generic persons. The definition of the user model is provided by themeta-model (M2) for example UML, which is defined as Meta Object Facility - MOF(M3).
2.3.2 Modeling Languages
A modeling language is used for the description of a model. It is a tool to formalise themodels concept, which can be either textual or visual citebrambilla:2012aa. The mainparts are the following:
• Abstract syntax - the structure of the language
23
Chapter 2
Table 2.1: Four-layer-metamodel hierarchy
M3 Meta-Meta-Modellanguage to definethe meta-model
e.g. MOF
M2 Meta-ModelLanguage to definemodel
e.g. UML
M1 Modeldescribes a specificmodel in a domain
e.g. class Person
M0 Instancerunning instance ofthe model
e.g. Person p = "John"
• Concrete syntax - the notation of the modeling language
• Semantics - the meaning of the elements and possible combinations
There are general purpose languages (GPL) or more specific description within a do-main a so-called domain specific language (DSL) [86]. One example of GPL is theUnified Modelling Language (UML).
UML (Unified Modeling Language) is the standard modeling language for several partsof the software development process. UML is specified by the Object ManagementGroup (UMG). The current version is UML 2.5 and is online available [90].
Beside the general approach, DSL addresses a specific application domain. Theyare designed for a particular domain [91]. This is not only a limitation but also abenefit for clear definitions and the abstraction of the domain. A DSL is limited in itsexpressiveness [91]. It is not possible to build a whole software system based on thistype of modeling languages. Some typical examples of DSL are SQL, a language todescribe database operations [92], VHDL, to describe hardware and electronics [93]or WebML, a modeling language for the user interface and navigation of a website[94].
According to Brambilla et at. [86] every DSL should follow some principles. The lan-guage must give the right abstraction of the underlying problem. It has to be open forextension and closed for modification. The DSL has to be intuitive and easy to handle.It should make the the work of the developer easier, not harder.
There are two categories of DSL. An internal DSL is written or embedded in a hostlanguage. Typical host languages are Ruby or XML [95]. External DSL is a newlanguage built from scratch. This promises many possibilities because of its openness,but all additional tools like the parser needs implementations.
24
Chapter 2
2.3.3 Model Transformation and Code Generation
In the end, the main goal of model-driven development is to create software from themodel. To reach this goal, the model is transformed to another abstraction layer. Thisis either a model-to-text or a model-to-model transformation [86]. The latter approachcreates another model for special issues in the domain or for special needs of otherprojects members. For the process of automatic source code generation, the model istransformed into a textual form like program code or XML [87].
MetaModel
Model TransformationProcess
GeneratedCode
ModelLanguage TransformationToolchain
IndividualCode
Application
defind by
leadsto
dependson
Figure 2.4: The transformation process of model-driven development.
The typical process of software generation is described in Fig. 2.4. The model basedon the meta-model is the input for the transformation process. With various methodsof transformation the source code artefact is created. Developers can modify theresulting code and can also add their own indiviual program parts. This new codebasewith generated and individual code creates the final application in the domain of themodel.
Typical code generation patterns [96, 85] are:
• Templates + Filtering - the code is generated from the model and embedded ina template
• Templates + Meta-Model - this is an extension of the Templates + Filtering pat-tern. Templates are part of the meta-model, which is instantiated first.
• API-based Generators - the generator provides methods via an API
• Inline Code Generation - the generation is done directly in the compilation pro-cess
25
Chapter 2
2.4 Related Work
The aim of this thesis is a model-based approach creating accessible mobile appli-cations. This literature review presents existing work using MDD for user interfaces,mobile application and accessible software.
2.4.1 Model-driven Development for User Interfaces
The implementation of user interfaces is a demanding part of software development.In literature we can find examples of model-based techniques.
Model-Based User Interfaces (MDUI) has several benefits; faster development, alter-natives in design and adaptions to different devices or platforms [2],[97], [98],[99].
There are different levels in this model-based approach. An excellent example of thisis the Cameleon Reference Framework [100]. The highest levels are tasks within thedomain. Out of these emerges an Abstract UI which is independent from the imple-mentation and modality. Next is the Concrete UI, which depends on the modality butis still implementation-independent. At the end, we have the Final UI that representsthe implementation in the final source code [2], [101]. Fig. 2.5 shows this concept withsimplified version of the Cameleon Reference Framework.
Figure 2.5: Simplified version of the Cameleon Reference Framework [2]
An important part of MDUI is the definition of tasks. Task models provide the goals andaims in an interactive application [102]. One widely adopted task-modeling notation isConcurTaskTrees (CTT) [103]. CTT distinguishes different kinds such as system, in-teraction, user or abstract tasks and a designer can model the interaction of a processin a graphical tool.
26
Chapter 2
Another aspect is the Abstract UI models. Beuvens et al.[104] give a generic definitionof them for the definition of user interfaces corresponding to the Platform-IndependentModel (PIM) in model-driven engineering.
User interface description languages
Model-based approaches for UI development are often described in a user interfacedescription languages (UIDL). The UMIL is defined in a markup language and ren-dered to a final UI. User Interface Markup Language (UIML) from Abrams et al. [105]is an XML-based language. UIML uses abstract components like windows, menu, etc.,which are platform-independent. WebML form Ceri et al. [94] is a UIDL for designingand creating a complete website.
Mozilla’s version of an UIDL is XUL (XML User Interface Language)[106]. This lan-guage provides input controls, menus, dialogs, etc. in a generic form. The UI forapplications like Firefox are build fromut of this platform independent description.
IndieUI [107] from W3C is an approach to design the user interface of accessible webapplications. With events [108] and user context [109] applications can be built for awide range of different contexts and user needs.
UsiXML by Vanderdonckt et al.[110] follows the four stages of the Cameleon Ref-erence Framework and usees it for an multi-path development. A UI is defined bydifferent levels of abstraction; the transformation is done in three steps abstraction,reification and translation. These steps generate multi-modal user interfaces for differ-ent platforms [111, 112, 113].
Another modeling language based on XML is TeresaML [114]. TERESA is a model-based method for designing multi-platform user interfaces. A successor is MARIA(Model based lAnguage foR Interactive Applications) [115]. It is an universal, declar-ative, multiple abstraction-level language for interactive applications created from amodel.
The workflows are an important part of interactive software products. IFML (InteractionFlow Markup Language) by Brambilla & Fraternali [116] describes these flows in anabstract way. With view containers and their connection via events the interactionthrough an application is defined and is the basis for further development or codegeneration.
Finally. the work of Dittmar et al. [117] aims to answer the question of whether model-based UI design is helpful in end-user programming. With a case study, they show thepracticality of their method.
27
Chapter 2
2.4.2 Model-Driven Development for Mobile Applications
Examples of model-driven development approaches and mobile apps can be found inliterature. A starting point is the work of Umuhoza & Brambilla, which shows severaltechniques of MDD and defines criteria to classify these approaches [118]. Earlyexamples were still focused on web applications optimised for mobile devices. Braunet al. share their experience of MDD for mobile web [119]. The combination of user-centred design with software development is part of Balagtas et al.’s research [120].An iterative process creates a prototype of a mobile app with model based creationand evaluation.
MD2 (Heitkötter et al. [121]) creates cross-platform apps from a model. This workfocuses on business apps where common source code is compiled into native iOSand Android apps.
Another instance of a model-based method is Le Goaer & Waltham’s [122]. Theircustom DSL is used for mobile apps. Majchrzak et al. [123] engineer mobile businesscross-platform apps with the aims of model-driven development. Another approach ofa DSL for mobile apps is XIS [124]. The model is based on UML and the resultingapps are created for different platforms. The usage of this model-driven method hasbeen evaluated with several participants [125].
Native Android apps are the result of Paranda et al.’s work [126]. Activities and ser-vices are designed with class and sequence diagrams. Da Silva & Brito e Abreu [127]are also focused on Android-based apps. Their user interfaces for business informa-tion system app are modelled, using class diagrams.
The adaption of the interaction flow modeling language IMFL for the user interface ofmobile apps [128] as well as the usage for web and mobile applications [129] is partof the work of Brambilla et al.
Barrnet et al. [130] present a tool to generate data-driven apps based on a domainspecific language. In the work of Bernaschina [131] a web-based tool generates mo-bile applications online.
Model-driven development for Android apps is part of Vaupel et al.’s research [132].Different abstraction levels in the modeing process helps developers with the imple-mentation of mobile apps. The extension of this work to other platforms like iOS canbe found in [133].
These examples used the model-driven approaches for the generation of mobile ap-plications, but none of them have an explicit focus on the inclusion of accessibility.
28
Chapter 2
2.4.3 Model-Driven Development supporting Accessibility
The model-driven approach is also used to improve the accessibility in software devel-opment.
Gajos et al. show automatically generated UIs for users with physicals disabilities.The SUPPLE system creates different appearances of the user interfaces, dependingon the users restriction [134]. A framework for accessible applications is Johar byAndrews & Hussain. This approach covers a wide range of disabilities. The interfaceinterpreter transforms the interaction model into a final Java application.
The AT lab app framework [135] allows the creation of games for people with physicaldisabilities. The work of Gonzales Garcia al. [136, 137] presents the design andimplementation of an accessible media player based on model-driven development.
Minon et al. presents a model-based user interface for different types of users. It is aninterface generator to transform XML models via XSL into an adapted accessible userinterfaces [138].
Adaptive user interfaces based on a predefined model can be found in [139]. Integrat-ing adaptation rules for accessible digital service is part of [140].
Zouhaier et al. shows a context-aware techniques for automatic UI generation [141]and a UML model for accessible software [142]. The model-driven approach for anadaptive user interfaces and the context model includes accessibility [143].
Feld et al. [144] use the model-driven methods for adaptive user interfaces in automo-tive. The shift from tangible interface to digital apps in cars also requires adaption tothe users. Accessible user interfaces for ubiquitous services are automatic generatedin [145].
2.5 Summary
The literature review reveals that model-driven development is used in different areasof development. User interfaces or mobile applications based on MDD can be foundin literature. Even the usage to improve accessibility in software products is part ofcurrent research.
The research fields accessibility, mobile applications and model-driven developmentare widely discussed in literature. In Figure 2.6, the overlapping of these differentareas is shown. There has already been some exciting work done that deals with theouter intersections. For example, accessibility and mobile development or accessibilityand model-driven development have been covered by previous papers, but all threefields of research are seldom discussed together in the scientific community (see [21]).
29
Chapter 2
A11y+Mobile+MDD
MobileDevelopment
Accessibility
Model-drivenDevelopment
Figure 2.6: The research focus is in the intersection of model-driven development,mobile app development, and accessibility.
The combination of model-driven development to bring accessibility to mobile apps isan original contribution to the field. Hence it can be argued that model-driven devel-opment is a possibility to support developers and designer better and more efficientlyin situations where they miss profound knowledge in terms of accessibility. The aim ofthis thesis is therefore to find an intuitive model for designing accessible mobile appli-cations and a procedure to generate the prototype of an accessible app based on themodel.
30
Chapter 3
Model-Driven Developmentfor Accessible Apps
This chapter presents the model-driven development approach for accessible apps.The starting point of most app development processes is an app idea. To find a modelfor accessible apps we have to identify the components of the app.
Following the WAI the foundation for accessibility is using simple interactions to createcomplex ones.
The key to accessibility in interaction is starting with the simplest interac-tions and using those as the building blocks of more complex interactions.[146]
The main idea for modeling accessible apps is to find useful components and easyinteractions or workflows. Before designing an accessible app, however, one has todesign an app at all.
The user interface and the interaction design are the most relevant parts of an app foraccessibility. According to Banga and Weinhold [147] good mobile interaction designleads the user through an app. The key factors are clear and simple controls, but moreimportantly reducing the functionality of the app is essential. Banga and Weinhold[148] offer useful tools and techniques to design user interaction. Suitable tools todesign mobile interaction are:
• wireframes
• storyboards
• (paper) prototypes
Fig 3.1 shows an example of an app interaction process in an early development
Chapter 3
stage. Workflows and interaction can be sketched with pen and paper or with the helpof design tools.
Figure 3.1: Typical paper prototype for the interaction flow in a mobile app.
These methods are informal and are not integrated into the development process.Apple’s Xcode IDE for iOS development provides an integrated storyboard tool [149],which allows designers or developers to sketch the interaction workflow within thedevelopment process. Fig 3.2 illustrates this intuitive method to design the flow withinan app, but this tool is limited to iOS development. A similar tool to design interactionand navigation on the Android platform is the Navigation Editor (http://tools.android.com/navigation-editor). Unfortunately this tool was just experimental andis not available anymore [150].
3.1 Modeling with UML
For more general modeling of interaction, more generic modeling tools are necessary[151], [152]. UML is used in different aspects of software engineering. The next sectionpresents the usage of UML for user interaction and accessibility.
For more general modelling of interaction one needs also more generic modelling toolsUML is used in different within in software engineering. The next sections shows theusage of UML for user interaction and accessibility.
32
Chapter 3
Figure 3.2: Storyboard in Xcode
3.1.1 UML Diagrams for User Interaction
There are different diagrams in UML; possible diagram types to model user interac-tion related topics are use case diagram, sequence diagram, communication diagram,activity diagram or the interaction overview diagram.
UML Use Case Diagrams; this type of model explains requirements of the systemmostly from the perspective of a person’s needs. The user as a role e.g. a customerand their use-cases in the system. Fig. 3.3 gives an example of the use case for arouting app.
Interaction diagrams like sequence or communication focus on the flow between el-ements. For modeling the time-based event in a system, a Sequence Diagram isused. This model type shows the exchange of messages between objects in a time-based context. In Fig. 3.4 the timing of the geocoding in a routing app is modelled in asequence diagram [152].
A Collaboration/Communication Diagramm focuses on communication rather thanthe sequence of messages. An Activity Diagram describes behavioural flows in asystem, like procedures or logical flows. The process is described using action statesand activity edges. Fig. 3.5 shows the decision process of the address selection in
33
Chapter 3
Customize App
Routing
A11y Settings
Select TargetUser
<<include>>
<<include>>
Figure 3.3: Example of a UML use case diagram for a simple routing app.
Select Routing Target
getGPSPosition()
getGPSfromAddress()
checkStoredLocations()
Calculate RouteRouting Target
enterAddressgetAddressGPSPosition()
Figure 3.4: Example of a UML sequence diagram for geocoding in routing app.
Select Routing Target
Search Address
Routing
Stored Location
Figure 3.5: Example of a UML activity diagram for a simple routing app.
34
Chapter 3
the routing app. Finally, the Interaction Overview Diagrams is a combination ofsequence and activity diagram. This kind of diagram expresses the overall flow in asystem [152].
Ambler [153, 154] claims that UML does not support any diagrams related to flowchartsor storyboards. Nevertheless, Conallen [155] provides examples of employing UML inmodel Web applications. Communication (or collaboration) diagrams show the inter-action between components or parts in an interactive system.
Model-driven development, with the help of UML is also used in the process for appdevelopment. Kraemer [156] uses UML with statical and behavioural diagrams tomodelling mobile apps. With the help of building blocks and libraries an Android appis created from models. Specific aspects of Android app like intents, data/servicerequests are part of the approach of Parada et al. [126]. Le Goaer et al. [157] combinemodelling and code generation with standard coding for their method of model-drivendevelopment. User interfaces generation is the aim of Sabraoui et.al. [158] work. UMLis used for graphic user interfaces. Based on a meta-model for basic UI componentsan Android specific UI is the result.
3.1.2 Accessibility and UML
UML as a standard to model software systems and also accessibility matters in UML.In literature there are various example that enhance and validate the accessibility ofUML. King et al. [159] show how blind software engineers can use UML in the devel-opment process, while Müller [160] is works with blind students using UML diagrams.With AMWO, Grillo presents a tool for blind users to model web applications [161],[162] with UML. Providing guidelines as to how blind developers can use UML in tex-tual form is the work of Petrausch et al.[163].
There are few example of using UML to model accessibility. Gjøsæter et. al. givean example of defining accessibility constraints with UML [164] as well as testing theaccessibility of generated XHMTL documents [165].
3.2 A Model for Accessible Apps
Proper interaction design is the first step to satisfying accessibility in a mobile applica-tion. For the definition of the model we should define the requirements of an accessibleapp.
As written in the last section there are some requirements for an accessible mobileapp.
35
Chapter 3
• Simple interactions (components) to create complex ones [146]
• Clear interaction
• Reducing functionality [147]
What is relevant for users with disabilities? For simple interactions, building blocks areneeded. These are basic input and output components with different manifestations.In order to start an action, an active element is used. To cluster these building blocks,a grouping item is necessary. For interactivity and workflows, a navigation componentis used. These base elements for the accessible app model are described in detail inthe next section.
3.2.1 Elements of an Accessible Mobile App Model
Going along with these requirements, the base types for a model are as follows:
Grouping Component: The first idea for an app user interface, sketched in a proto-type, shows several screen or grouping elements. This allows the designer to breakdown the overall interaction flow into smaller parts. As seen in the storyboards orwireframes, these define the interaction flow with the connection of several containerelements.
This model uses the Screen as the grouping component. The screen element is onecomponent in the interaction flow and contains sub-elements for direct user interactionlike actions, transitions, inputs and outputs.
Screen:
name: String [1]
description: String [0..1]
subscreen: Screen [0..*]
action: Action [0..*]
transition: Transition [0..*]
input: Input [0..*]
output: Output [0..*]
Navigation Component: In the proposed interaction flow, an element to navigate fromone screen to another is required. The navigation component is Transition, which ispart of a screen and lets the user navigate to another target screen element or outsideof the app to the system (e.g. email).
Transition:
name: String [1]
description: String [0..1]
target: Target [1]
36
Chapter 3
Action Component: In some parts of the interaction process, an action like retriev-ing sensor data, starting a background service, loading or saving data in the app isrequired. The Action element allows a method or procedure to be triggered, which isprovided by either the system, a library or the developers. An action element is part ofa screen element, but not obligatory for every screen.
Action:
name: String [1]
description: String [0..1]
action: Action [1]
Output Component: Every app has content for the user’s information like texts, im-ages or sounds. To provide contents in various types the element Output is part ofthe model. Output is used to give the user context in the proper usage of the app.
Output:
name: String [1]
description: String [0..1]
type: String [0..1]
Input Component: For interacting, entering data and selecting among different choices,the model provides the Input element. Similar to output there are different types liketext, selection or choice as a mandatory attribute in the element.
Input:
name: String [1]
description: String [0..1]
type: String [0..1]
Every element of the model has a mandatory name attribute. To create an accessibleapp it is important to provide a textual information for any element related to userinteraction. Additionally, each element has an optional description attribute for moredetailed information, which is provided on demand.
App Container: Last but not least all these elements are part of one complete mobileapplication. An app element has at least one screen element. Meta information aboutthe app name and the package are also part of this element.
App:
name: String [1]
package: String [1]
profile: Profile [1..4]
37
Chapter 3
3.2.2 Profile
For proper implementation of accessible apps, it is important to deal with the right usergroups. In the context of accessibility, this model is focused on four different profiles.These profiles support different accessibility enhancements.
Profiles:
• No restrictions
• High contrast, possibility to read large fonts, problems with colour or contrast
• Blind, no visual abilities
• Easy touch, physical disabilities, problems with touch target sizes
3.2.3 Meta Model
The interaction elements and user profile define the meta model for accessible apps.Fig. 3.6 shows the overview of this meta model in a UML class diagram. A model ofan app needs a name, package and at least one screen element. Screen items mayhave input, output, action or transition elements.
Based on this meta model developers and designers may start with a sketch of anapp in a paper prototype or a mockup tool and are able to transfer the draft to a moreformal model.
Actionname:Stringdescription:String[0..1]
Transitionname:Stringdescription:String[0..1]target:String
Appprofil:String[1..5]appname:Stringpackage:String
Screenname:StringDescription:String[0..1]
Outputname:StringDescription:String[0..1]type:String
Inputname:StringDescription:String[0..1]type:String
1..*
0..* 0..* 0..*
0..*0..*
Figure 3.6: The UML class diagram of the model.
The app model based on the meta-model is shown in the following example - a simple
38
Chapter 3
Where am I? app. To get an impression of the app idea Fig. 3.7 illustrates (a) thebasic sketch of the app idea. The app has a dashboard with one flow to the secondinteractive screen. The position screen has a button to trigger the current locationwhich is shown in a text box. Both screens have a textual description on top.
The model in Fig. 3.7 (b) consists of an app with appname, package and the profileblind and two screen elements. Each screen has several sub items like textual output,transition (from start- screen to position) and action (to get the GPS position).
With the meta-model the design draft is transformed into a formal model, which is usedin the automatic part of the development process.
Start
WhereAmI
getGPS-Position
Position
47.31,9.64
appname:WhereAmIpackage: org.accapto.whereamiprofile: blind
Screen:StartOutput:WhereamITransition:Position
Screen:PositionOutput:PositionAction:getPositionInput:gpsData
(a) (b)
Figure 3.7: Simple app model: (a) app mockup, (b) model.
This graphical representation is just a formalisation of the model. For developers, ab-stract descriptions of concepts in text form are state of the art. For further processingof the model, text-based formats are also a benefit. The next section goes deeper intothe text form of the model.
3.3 Model Description (DSL) for Accessible Apps
For developers, textual descriptions of formal definitions are common. One possibleway of describing a model within a special domain is a domain-specific language [91].Before defining the model or meta-model one has to choose the base language orsyntax for the DSL. An external DSL is based on a new syntax. This provides freedomin the definition but beside creating the modelling language also the processing toolsare also new. For example, Barnet et al. [130] use a JSON-like syntax and theyimplemented a custom parser for their DSL.
When using an existing syntax (e.g. XML) as a hosting language, this is called an
39
Chapter 3
internal DSL. In the end, it is more or the less a personal of decision, which languageyou choose [166].
In this work an internal DSL based on XML is used. XML has many advantages. Firstof all XML all is a common standard by the W3C [167]. It has a strict ruleset to cre-ate well-formed documents and also provides also resources for grammar definitionsfor validation. XML is used in many different cases/parts in IT such as definitions,configurations and designs, to name a few.
Second, various tools are available to create and edit XML. Developers can choosetheir preferred editor to write new definitions in XML. Beside the creation of XML files,there are many tools available for processing this information. For reading, parsing andtransforming XML-based data, developers can mostly choose from various programson the selected platform.
The model definition in this works defines tags for each element. For example, theScreen element is represent with a screen-tag. Further information on the element isgiven in either in an attribute (e.g. name="Start Screen") or in a child element. Theexample below shows a typical screen element as an XML tag.
<p:screen name="Start Screen">
<p:output name="Where am I" type="text" />
<p:transition name="Start" description="get the actual position"
target="Position" />
</p:screen>
Listing 3.1: XML of the ScreenType
Not only the correct syntax (well-formed), but also the correct combination of all ele-ments of the XML file is essential. Only with the grammar definition can an XML filebe valid. The XML Schema Definition (XSD) describes the structure and constrains ofthe contents of XML documents [168, 169].
The meta-model for accessible apps is defined in XSD. Every valid tag in the definitionis defined as a complex type. This represents a composite tag with predefined childtags and attributes. The following example demonstrates the definition of the screentag. This tag has a sequence of child tags like an input tag. Every child tag can occurmore than once and is not mandatory. Every screen tag may have the attributes nameand description. The name attribute is mandatory because for proper implementationfor accessibility, each element needs at least one textual description.
<xs:complexType name="screenType" mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element type="actionType" name="action" minOccurs="0"
maxOccurs="unbounded" />
40
Chapter 3
<xs:element name="transition" type="transitionType"
minOccurs="0" maxOccurs="unbounded" />
<xs:element name="input" type="inputType" minOccurs="0"
maxOccurs="unbounded">
</xs:element>
<xs:element name="output" type="outputType" minOccurs="0"
maxOccurs="unbounded">
</xs:element>
<xs:element name="subscreen" type="screenType" minOccurs="0"
maxOccurs="unbounded"></xs:element>
</xs:sequence>
<xs:attribute type="xs:string" name="name" use="required" />
<xs:attribute type="xs:string" name="description" use="optional" />
</xs:complexType>
Listing 3.2: XSD of the ScreenType
The scheme definition includes alle possible elements of the DSL. The complete defi-nition can be found in Appendix A.1.
The following listing is the XML representation of the example model in Fig. 3.7. Theapp model contains a surrounding app element with appname and package. Therequired profile blind is also in the root tag. The model consists of two screen tagswith a name attribute. Both screens include child elements (e.g. output or transition).
<p:app appname="Where am I" package="org.accapto.whereami">
<p:profile>blind</p:profile>
<p:screen name="Start">
<p:output name="Where am I" type="text" />
<p:transition name="Start" description="get the actual position"
target="Position" />
</p:screen>
<p:screen name="Position">
<p:output name="Routing Target"
description="form for routing target input" type="text" />
<p:action function="getPosition" name="getPosition"
description="get the actual position via gps" />
<p:input name="gpsdata GPS"
description="gps coordinatesc of actual position" type="text" />
</p:screen>
</p:app>
Listing 3.3: Model of WhereAmI App in XML.
41
Chapter 3
3.4 Summary
This chapter presents the model for the development of accessible apps. In manycases, the design process of mobile applications starts with a draft of user interac-tion. This sketch of the user interface and interaction is transferred to a model for appdevelopment..
To answer the research question, What kind of model is needed for the model-drivenapproach? compared to Shaw [18] a type of result is a new (qualitative) model.
The Accapto model is a way of creating the basis for an accessible app. This modelconsists of several basic building components to design interactive mobile user inter-faces. First, the meta-model is defined in XSD; then, a concrete model is described inXML.
This is the first step in the model-driven development approach. The focus of the nextchapter (Chapter 4) is the transformation from XML model to Android app prototype.
42
Chapter 4
Generation of AccessibleApps
This chapter focuses on the process from model to final Android application. Fig. 4.1presents an overview of the app generation process. The first step is the model of theapp in the XML file; next comes parsing of the XML file, which leads to an instance ofthe model in the generator. The app scaffolding and accessibility enhancing is part ofthe generator; the resulting output is an Android Studio project.
According to Völter [96], code generation is getting important for the development ofa system in a similar domain. These are called software system families; in this case,the domain is a mobile application on the Android platform with automatic integrationof accessibility (features). The Accapto generator uses the Templates + Metamodelpattern for code generation (see Völter [96]) The model is an instances of the meta-model, the resulting code is generated by applying the template to the instance
XMLParsingModelXML
AppScaffolding AppGeneratedAppProject
AccessibilityExtension
ParsingXMLFileUnmarschal XMLCreateInstanceofmodel
CreateProjectStructureGenerateAppComponents
AddAccessibilityLibAdoptAppComponents
AddcustomCodeBuildApp
Figure 4.1: Building chain of Accapto.
Chapter 4
4.1 Android Applications
This approach of model-driven development for accessible apps is generic, but thesource code generation is different for distinct mobile operating systems. This thesisfocuses on Android.
Android covers about 85% of the market; it is the most widely spread mobile operatingsystem1. It has a layered architecture based on a multi user Linux kernel. The middlelayer consists of native libraries, the virtual machine and the application framework.Android apps makes up the top layer of the system. All interactive parts visible tothe user, like the app launcher, the phone application, various web browsers, etc., areapps. Every app runs in an own instance of the virtual machine [170, 171].
Android app development
Android app projects consists of several parts: Java classes, XML files for layout andother resources, image or media files and build configuration files (see Fig.4.2). Devel-opers design user interfaces with the help of a XML-based layout system and connectthem to an Activity, which is an Android component that represents an active screen[172]. The navigation and flow through an Android app is implemented with an Intent,a component to navigate from one screen to another.
Figure 4.2: Android app development project.
The build process compiles source code and resources and packages them into an
1https://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems
44
Chapter 4
.apk file (Android Package File)[173]. This final .apk is installed on an Android device.
For the automatic generation of an app project the following topics are relevant:
• package name: unique application ID
• app name: name of the installed app
• screen(s): activity and layout for each user interface screen
• navigation: intent to start another activity
4.2 Parsing the Model
The description of the Accapto model is an XML file. For further processing the in-put file has to be parsed and validated. With the Java Architecture for XML Binding2
(JAXB)[174] comes a practical and fast way to link XML and Java. Fig. 4.3 givesan overview of the XML-to-Java relations for the parsing process. In the first stepJava classes are created, which represent the XML based model from the XSD. Fromthe schema description the corresponding java classes are generated, These classesmatch the elements in the XML model (see Appendix A.1 for the complete XSD). Afterreading and parsing an XML input file, the JAXB framework unmarshals Java objectsfrom the XML content. The result is an instance of a complete Apptype-object includ-ing all screens and meta information of the designed app. This instance of the modelat runtime is the input for the next part in the Accapto generator, the app scaffoldingprocess.
4.3 App Generation Overview
Fig. 4.4 shows the Accapto generator classes. The ModelParser class is responsi-ble for the whole process of parsing. The input is an XML file and the output is aninstance of an AppType object. The AppScaffolder creates the whole Android projectstructure. All ScreenType objects of an AppType are used in the ManifestBuilder and inthe ScreenTemplating. ScreenTemplating creates an activity and the layout from eachscreen of the model. The ManifestBuilder adds the necessary entries in the AndroidManifest file.
2https://docs.oracle.com/javase/tutorial/jaxb/intro/arch.html
45
Chapter 4
Schema Classes
Document Objects
<?xml version="1.0"><xs:schema xmlns="org.accaptp" xmlns:xs="http://www.w3.org/2001/XMLSchema>
<xs:element name="app" type="appType"/><xs:complexType mixed="true"
name="screenType"><xs:sequence maxOccurs="unbounded"
minOccurs="0"><xs:element maxOccurs="unbounded”
minOccurs="0" name="action" type="actionType"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="transition" type="transitionType"/>
...
unmarshal
marshal
Instancesoffollows
bind
<?xml version="1.0"><app appname="DemoApp"
package="org.accapto.demoapp"><profile>normal</profile><screen name="Main">
<output name="Demo App”description="This is a demo app" type="text" />
<input name="search something" description="enter a text" type="text" />
<action function=”peformTask”name="Peform a Task”description="template function"/>
</screen><screen name="Settings">
<output name="Settings" type="text" /> </screen>...
package org.accapto.model;
public class AppType { @XmlElement(required = true) @XmlSchemaType(name = "string")
protected List<ProfileType> profile; protected List<ScreenType> screen;
@XmlAttribute(name = "appname") protected String appname;
@XmlAttribute(name = "package", required = true)
protected String _package;
...
..
AppType app = new AppType();
app.getAppname());app.getPackage());
..
Figure 4.3: XML to Java binding.
4.3.1 App Scaffolding
The app scaffolding process is the first step in the app generation after parsing theXML input. The input to create the app project prototype is an instance of the modelin the form of the Apptype-object. This object contains all meta information about theapp, the structure of the user interface and the flow through the app. The necessaryfiles and folders of an empty Android project are created based on the meta informationapp-name and package-name. Fig 4.2 shows the generated Android project structure.
The Apptype-object contains at least one Screentype. This object represents a singleuser interface screen including elements for user interaction (input and output widgetsand interactive components). For each Screen, the templating process transforms themodel into Java source-code for an activity and Java methods and the correspondingXML layout definition. The templating of the activity and layout files is described in thenext section.
4.3.2 Templating
The transformation from model to source code follows the Templates + Metamodelpattern [96]. The input for this pattern is a concrete instance of the model, for examplea Screen object. The template engine FreeMarker3 [175] uses this input to fill thetemplate placeholders. The example in Fig 4.5 shows the templating components the
3http://freemarker.org/index.html
46
Chapter 4
Figure 4.4: Overview of Accapto code generation.
Java object ScreenType, the template for an Android Activity and the resulting sourcecode after the templating process.
More details of this process reveals the following example of a transition from onescreen to another (see Listing 4.1). The createTransition() method gets a Transition-Type-object. The template uses a map structure with a key-value pair for each input.The maps for the layout and the code template are filled with the transition values. Thetemplate, which is stored in a separate file, is loaded and processed in the templateengine.
private void createTransition(TransitionType transition) {
layoutTemplate.put("name", transition.getName());
layoutTemplate.put("description", transition.getDescription());
47
Chapter 4
...ScreenType screen = new ScreenType();screen.setName("Start");...
JavaObject
Output
Templatepackage ${package};
public class ${activityname} extends BaseActivity{
public void onCreate(Bundle savedInstanceState){ setContentView(R.layout.${activity_layout});
}...
Freemarker
package org.accapto.app;
public class Start extends BaseActivity{
public void onCreate(Bundle savedInstanceState){ setContentView(R.layout.start_layout);
}...
Figure 4.5: Template processing for code generation.
layoutTemplate.put("function", "goTo" + transition.getTarget());
codeTemplate.put("transition", transition.getTarget());
Template template = cfg.getTemplate("accapto_action_layout.ftl");
template.process(layoutTemplate, layoutWriter);
Template templateCode = cfg.getTemplate("accapto_transition_code.ftl");
templateCode.process(codeTemplate, codeWriter);
..
}
Listing 4.1: Template code fragment for a method stub in Java class.
Listing 4.2 shows the template for the Java code generation. Each transition in theapps workflow starts a new user interface screen with an Android intent. The methodgets a composite name including the name of the transition target.
public void goTo${transition}(View view) {
Intent intent = new Intent(this, ${transition}.class);
startActivity(intent);
}
Listing 4.2: Template code fragment for a method stub in Java class.
To launch the interaction flow, the app also needs an active UI element. In Listing 4.3,the template for a button in the layout of the app screen is presented. The name of theresulting button is created with the name of the transition target.
48
Chapter 4
<Button
..
android:text="${name}"
android:id="@+id/btn${name}"
android:contentDescription="${description}"
android:onClick="${function}" />
Listing 4.3: Template for the UI element in the XML layout file.
The complete source-code of the Accapto generator is available as an open sourcesoftware project and can be found at https://github.com/elmarkrainz/accapto.
4.4 Accessibility Enrichment in Android Apps
Like most integrated development environments (IDE), Android Studio comes withmany features to help developers to create user interfaces. but many additional at-tributes or configurations to include accessibility are not provided in the default set-tings. Therefore, the accessibility enrichment is part of the Accapto generator.
4.4.1 Implementation of Accessibility on Android
Chapter 2 of this thesis already introduced mobile accessibility and the special caseson the Android platform. This section gives an overview of the right implementationfor accessibility. The official Android documentation provides help for accessible de-sign [54], implementation [176] and evaluation [177]. In the Github repository GoogleSamples a basic accessibility implementation is provided (https://github.com/googlesamples/android-BasicAccessibility). Ted Drake’s website [178] in-sists on referring the The Missing Manual for accessibility on Android. To sum upthese sources the following topics are most relevant for accessible implementation inAndroid.
Labeling UI Elements
An important factor for accessibility is perceiving the information. In many cases atextual description is critical for accessibility, because users without reading abilitiesdepend on Talkback. The attribute android:contentDescription should be usedfor graphical elements . This attribute is ignored for decorative elements having thevalue null or can be set at runtime applying the method setContentDescription().To indicate an element’s purpose the attribute android:hint adds a description toan editable textfield. In complex forms the android:label-for helps the user un-
49
Chapter 4
derstand the expected input. Wrong labelling of elements can be detected with Talk-back or Accessibility Scanner.
<TextView
android:layout_height="match_parent"
android:labelFor="@+id/edit_name"
android:text="Name"/>
<EditText
android:id="@+id/edit_name"
android:layout_height="wrap_content"
android:hint="Namet"/>
Large Touch Targets
Widgets like radio buttons or checkboxes are sometimes too small in the high reso-lution of a modern smartphone display. Images or touchable textfields in an app arealso too small. The attributes minWidth and maxWidth must have at least a value of48dp4. Even if the element is not displayed in this size the touchable target is larger.
<Checkbox
..
android:minWidth="48dp"
android:minHeight="48dp" />
Grouping of Elements
Sometimes the auditory feedback may not correspond to the visual or spatial arrange-ment. A common method of arranging non-focusable elements in a group is to embedthem in a container element. This allows the response of all the group elements whenthe container gets the focus [179].
<RelativeLayout
..
android:focusable="true">
<TextView
..
android:text="group-member 1" />
<TextView
..
android:text="group-member 2" />
</RelativeLayout>
Easy Navigation
Each app should have easy-to-follow navigation. Developers have to avoid disap-pearing UI elements e.g. fade out after some time. Interacting with the naviga-tion provides useful feedback. Navigating through the app by keyboard or tabbingis important. The attributes android:nextFocusUp, android:nextFocusDown,
4Density-independent pixels
50
Chapter 4
android:nextFocusRight, and android:nextFocusLeft determine the cor-rect order within the layout. The following code snippets defines the focus order intwo buttons of the layout (see Keyboard Navigation5).
<Button
..
android:id="@+id/buttonA"
android:nextFocusDown="@+id/buttonB "/>
<Button
..
android:id="@id/buttonB"
android:nextFocusUp="@id/buttonA" />
..
Colour and Contrast
The contrast of text and images on the user interface is important for accessibility.According to the WCAG large text (18 points or higher or 14 points in bold) shouldhave a minimum contrast ratio of 3.0 to 1. Smaller text requires a contrast ration of4.5 to 1. This ensures readability for handicapped people. If images are an essentialpart of the user interface (more than decorative purpose), they should also follow thisguideline.
To You want to continue?
To You want to continue?
NO YES
Figure 4.6: Example of insufficient contrast and colour as only distinctive feature (left).Proper usage of contrast, colour and text (right).
4.4.2 Proper Implementation for Accessibility
In the Accapto generation process every user interface is created with accessibility inmind. The basis for the accessible development is defined in an improved AndroidAccessibility example. The first part shows some examples for XML-based widgets
5https://developer.android.com/training/keyboard-input/navigation.html
51
Chapter 4
and the proper implementation for assistive technologies.The second part shows fourcode-based extensions to improve the accessibility of an Android app. These are:
• Speech-to-text input: adding speech input to a custom field in the app
• Text-to-speech output: self-voicing (without TalkBack) within the app
• TouchAreaExtension: extending the touch area of a small icon at runtime
• ThemeChanger: change the app theme to another one with for example largerfonts and more colour contrast at runtime
The complete source code is available in the open source repository https://gi
thub.com/elmarkrainz/AccaptoAccessibilityExample. In the source-codegeneration the following accessibility implementations are included automatically.
Non-text Content
Following the WCAG rule 1.1.1 every non-text content element needs a text equivalent.The model description language of the Accapto prototype includes for output elementsof the type image. In the code-generation this is transformed to an ImageView. Themandatory name and the optional description are used to create the content descrip-tion attribute.
Image output in modelling language:
<p:ouput type="image" name="routing direction"
description="shows the direction of the next waypointa routing target"/>
Generated ImageView component with non-text description:
<ImageView
android:id="@+id/imageViewrouting direction"
android:contentDescription="routing direction -
shows the direction of the next waypointa routing target"
...
</ImageView>
Use of Colour and Contrasts
Rules of the WCAG demand that colour is not the only way to convey information(success criterion 1.4.1) and that colour has suitable contrast ratio for texts and im-ages (success criterion 1.4.3). The default color settings are included with an Androidstyle theme. The prototype includes three styles: default, high-contrast and blind (seeFig 4.7). Each theme has a tailored contrast level, which is designed for differentrestrictions.
Fig 4.7 (a) shows the default style of the generation process. This style is based onthe standard Android user interface but with improvements in contrast and text-size.The screenshot in Fig 4.7 (b) presents a different style for blind people and the visually
52
Chapter 4
(a) (b) (c)
Figure 4.7: Different styles of the Accapto Accessibility Pattern Library
impaired. All text-sizes are larger, buttons are larger and the contrast is improved.Even more contrast provides can be seen in the high contrast theme in Fig 4.7 (c).
Easy Workflow and Naviagtion
The default layout of the generated screens follows a linear layout. This linear flowthrough the app makes the navigation simple. The interaction via external keyboard orvia tabbing is possible in this layout.
Touchsize
Every touchable element, especially smaller ones like checkboxes or radio buttonsgets a minimum width and height of 48dp. This makes the handling of smaller itemseasier and Accessibility Scanner reports no errors
Textual Descriptions
Proper labelling is essential for any input element for the support of assistive technolo-gies. Each component in the model language has a mandatory name field and anoptional description. These entities are used to create the name, hint, or an additionallabel in the resulting user interface.
The snippet below shows an input element with the type text. The item has the namesearch target and the description enter a routing target.
<p:input type="text" name="search target"
description="enter a routing target"/>
The transformation creates part of the XML-based layout. The resulting user interfaceis an EditText for the text input with a hint-attribute from the description. Additionally
53
Chapter 4
a TextView as label for the EditText is added above for an additional text description.Fig. 4.8 presents the generated part of the user interface.
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:importantForAccessibility="2"
android:labelFor="id/txtsearchtarget" -> labelFor
android:text="search target" />
<EditText
android:id="id/txtsearchtarget"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="enter a routing target" -> hint
android:minHeight="48dp" -> min height and width
android:minWidth="48dp" />
Listing 4.4: Generated input item with TextView and EditText.
Figure 4.8: Generated input item with TextView and EditText.
4.4.3 Runtime Accessibility Extension
The previous examples focused on the proper implementation of the user layout. Forfurther improvement, the Accapto framework includes a library of accessibility patternsto extend the accessibility at app runtime. The following examples show four differentuse cases for additional functionality to improve accessibility.
TouchAreaExtender
This supporting module allows the touch-target-area of an UI element to be extendedat runtime. For example, a person with a motor disability has problems selectinga checkbox control, because it is too small. Developers get an API to extend theclickable touch area of an already existing UI component at runtime.
The following code shows the usage of this helper. An instance of the TouchAreaEx-tender calls the method enhanceTouchArea(). The view object and the extra paddingare the parameters of this method. The area around the UI element can be touchedwhich is interpreted as a section of the component.
TouchAreaExtender tae = new TouchAreaExtender();
tae.enhanceTouchArea(chkSmallTouch, 100); // param: extra padding
54
Chapter 4
Fig 4.9 shows a checkbox with a normal touch area and one with an extra touch areaaround the user control element.
Figure 4.9: Checkbox without and with touch extension.
4.4.4 Runtime Theme Selection
This feature goes along with the pre-defined styles and themes. After the first setupof the app (an important factor of an accessible app is the possibility for own settingsand customisation) these settings are loaded at runtime every time the app is used.Furthermore, one aspect is switching users of the smartphone; the app has to changeits appearance.
The ThemeChange class allows the change of the the visual style of an app at runtime.It helps users to change from the standard visualisation to a special styles like thehigh contrast profile. The last selected theme is stored in the app and loaded again atevery restart. Fig 4.7 shows examples of the different styles and themes included inthe Accapto Accessibility Pattern Library. The following code is loaded for each activityin the starting onCreate() method.
void onCreate( .. ) {
..
// sets the last saved theme before the layout is loaded
ThemeChanger.getInstance().applyTheme(this);
}
Themes and styles can also be changed in any context of the running app. ThechangeTheme() method exchanges the visual style for the complete app
// change theme
ThemeChanger.getInstance().changeTheme(int is, context)
55
Chapter 4
4.4.5 SpeechOutput Helper
Those persons who need support from Talkback get spoken feedback from the userinterface, but Talkback also needs training to be a useful assistive technology. In somecases users need only selected spoken feedback, which is included in the app. Withthe SpeechOutput class developers get a fast way of integrating text-to-speech into anmobile applications.
The SpeechOutput helper class is a wrapper for easy access to the Android Text-ToSpeech (TTS) class. The listing below shows the smart integration simplifying thesetup of TTS.
speechOutput = new SpeechOutputHelper(activity);
speechOutput.speaking("this text is spoken by the app");
Android’s TTS feature and also the SpeechOutput helper is automatically turned offwhen the system-wide accessibility solution is activated. This helper class is is bene-ficial for users with restricted sight or for those without reading abilities.
4.4.6 SpeechInput Helper
The last helper class is the support for Speech-to-Text input. Users with motor orvisual disabilities can avoid the onscreen keyboard which is not always accessible. TheSpeechInput class wraps the speech input to give developers a fast way to integratethis feature.
The startSpeechInput() exchanges the onscreen keyboard with voice input. The methodstarts an Intent to bundle the RecognizerIntent ; the result of the system voice recog-nition is handed back to the app and is used as text input.
Intent intent = new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH);
These helper classes are part of the Accapto Accessibility Pattern Library, which isautomatically integrated into the generation process. Features are partly integratedfrom the beginning in the custom app or can be used by developers to improve theaccessibility of the app.
4.5 Accapto - Accessible App Toolkit
The model-driven development approach for accessible apps has led to a new proce-dure, the result being Accapto. Accapto stands for Accessible App Tool, which is atoolkit supporting mobile app development in implementing accessibility, enabling de-signers and developers to frame user interaction by people with disabilities, resulting in
56
Chapter 4
a model for the app that respects accessibility [1]. In Fig 4.10 provides an overview ofthe complete process from the model in XML, app generation, accessibility enhance-ment and individual code.
Accapto
Parsing&Validation
ModelXML AppProjectModelXMLModelXML
AppComponents
UserInterfaces
AccessibilityEnrichment
App
NativeCode
creates
generates
dependson
Developer
Figure 4.10: Accapto overview [1]
Accapto consists of two components [1]:
• A modeler for accessible app interaction and
• a generator to transform models into apps.
The model describes possible interactions and workflows within the app. These are:
• output: representing data, information or other context in various forms
• input: any user-related content such as active data entry
• action: any action triggered by user intention
• transition: any navigation or transition to other app components
An app model includes at least one screen, that provides the Human-Computer Inter-face (HCI) for entering data, giving response by the app, starting actions, which couldlead to transiting to other screens. The interaction model simplifies the interaction ofthe app as a linear communication process with defined workflows. This is also thefoundation where to implement accessibility.
The app generation tool is implemented in a Java command-line program. This ap-proach was chosen for several reasons. First, developers are used to elaborated toolsbased on the command line. These types of programs need improved know-how oncomputers, but these skills are presumed for app developers. A second reason is
57
Chapter 4
the possibility of including command line programs in integrated development environ-ments (IDE) or in an automatic software build process.
Usage of Accapto from the command line:
java -jar accapto.jar -i new_model.xml
The complete source code, documentation and an executable version of Accapto arepublicly available as an open source project at https://github.com/elmarkrainz/accapto.
4.6 Summary
This chapter presents the generation of accessible apps from an interaction designmodel (see Chapter 3). The generation process starts with parsing the model froman XML input file and creates an instance of the model in the generator. The modelis transformed into a concrete Android app project. The items of the model (screens,transactions, input, output, etc.) are processed with a templating engine to the corre-sponding Android components. In the source code generation accessibility featuresare automatically integrated. While the proper accessibility implementation on Android(e.g. sufficient touch-targets-size for small elements) and the accessibility improve-ments (e.g. the SpeechOutput-helper) are automated, the process of app building andindividual features have to be done manually.
To answer the research question, How can the model transformation create an acces-sible app? compared to Shaw [18] the result is a new procedure or technique.Thisprocedure is the accessible app toolkit – Accapto.
58
Chapter 5
Accessibility Evaluation ofthe Resulting App Prototype
The last chapter presented the generation process and the enrichment of accessibilityto the generated app prototype. According to Shaw [18], presenting an example isone possible way of validating a new procedure. This chapter shows the developmentof simple routing app prototype. The starting point is a simplified mockup of a rout-ing app for different user groups with disabilities. Fig 5.1 shows the paper prototypeof the demanded app. The final implementation was presented in Krainz et al [20].Furthermore, the accessibility of the generated app prototype is tested with differentmethods.
Start
Routing App
Settings
Search
Enter Routing Target
..
Routing Overview
Start Routing
New Target
From: …To: ....Duration: …Distance: ....
Routing Details
Direction: …
Settings
Normal
High Contrast
Talkback
Speech Outp.
Routing Profile
SettingsRouting Profile
Normal
Wheelchair
Blind
Figure 5.1: Mockup of routing app.
Chapter 5
5.1 From Mockup to Prototype
The first step in the model-driven development is the creation of the model. Analysingthe mockup (Fig 5.1) lead to six independent screens with common user interface ele-ments like labels, buttons and input fields. The interaction process is defined with thearrows from screen object to screen object. With the meta-model presented in Chap-ter 3 the model is defined in XML. Listing 20 shows a code snippet of the model withthe app meta information appname and package which is essential for any Androidapp. Furthermore, the model contains the Start screen with a textual output and thetransition to the RoutingTarget. The screen RoutingTarget has a textual input compo-nent and an active action element to trigger an underlying functionality. The completemodel of the routing app in XML is in Appendix A.
<p:app appname="RoutingAppDemo" package="org.accapto.routingapp"
..>
<p:profile>normal</p:profile>
<p:screen name="Start">
<p:output name="Routing App Demo" description="routing app"
type="text" />
<p:transition name="Start" description="select routing target"
target="RoutingTarget" />
...
</p:screen>
<p:screen name="RoutingTarget">
<p:output name="Routing Target" type="text"
description="form for routing target input" />
<p:input name="search target" description="enter a routing target"
type="text"/>
<p:action function="calculateRoute" name="calculate Route"
description="calculate Route" />
...
Listing 5.1: XML model of routing app
The next step in the development process is the code generation. The code generatoris designed as a command line program1. The benefits of this approach is that it is alean and clear tool. Developers are used to command line functionality2 and commandline programs are easily integrated into other programs. With the command
java -jar accapto.jar -i routing_model.xml
the app prototype is created. The resulting app project may be built with the AndroidSDK or opened with Android Studio.
1Linux command line program definition http://www.linfo.org/command_line_program.html
2For example the Cordova Framework is based on the command line http://cordova.apache.org/docs/en/latest/guide/cli/index.html.
60
Chapter 5
(a) (b)
Figure 5.2: Generated app with (a) low vision and (b) standard theme.
Fig 5.2 gives an impression of the resulting app. The left screenshot (a) shows thedashboard of the Start screen in the high contrast profile. This profile is designedfor people with low vision with very high contrast, large text size and large buttons.The other screenshot presents the RoutingTarget screen with text output and differentinput fields. This is the standard profile with proper implementation of accessibility likesuitable content descriptions for all elements.
5.2 Accessibility Evaluation of the Resulting App
The aim of model-driven development with Accapto is an accessible app prototypefor further development. The next section presents the accessibility evaluation of thegenerated app.
5.2.1 Accessibility Evaluation Android Smartphone Apps
The measurement of accessibility is not an easy target. Compared to other disciplinesin computer science it is not simple to name a value of accessibility. In literature,we can find examples about the evaluation and rating of accessibility. Serra et al.[180] presented a case study about the accessibility of e-government apps in Brazil.The apps are rated with the help of WCAG in different conformance levels and thenumber of rule violations is the resulting metric of accessibility. The approach of Chiti& Leporini [181] gives insights into the evaluation of Android apps for blind users. In
61
Chapter 5
the work of Shaik et al. [182] blind user are also in the focus of the evaluation process.The performance of typical tasks in an app prototype was compared with the usabilityattributes by Nielsen [27]. Mattheiss & Krajnc [25] present a user study with userobservation, identifying the task load index (TLX) [183] and the system usability scale(SUS)[184] with an Android navigation app for the blind.
Checklists and guidelines are helpful when preparing the evaluation process. A goodstarting point for accessibility testing with Talkback was shown by Henry [185]. Schus-ter [16] provides insights into the usage of Accessibility Scanner. Information aboutmethods which can be directly integrated into the software engineering process alsoexists (Lint, Expresso). A practical checklist for developers is the work of Diwan [186].
Part of the official Android developers? documentation [187] is the main resources foraccessibility testing. According to the official documentation, to evaluate the accessi-bility, these steps should be followed:
• Manual testing with integrated assistive technologies.
• Analytical tools
• Automatic testing in the software development process
• Testing with real users
5.2.1.1 Manual Testing
The Android operating system provides integrated assistive technologies. While usingthe supportive assistants Taklback, Switch Access, BrailleBack or Voice Access a de-veloper gets an impression as to how people with disabilities handle a smart phone.Proper implementation of the created app is important for accessibility and errors aredetected in this step.
In order to evaluate the app, one has to turn on the assistive technologies and use theapp. Navigating through the Android system or a native app with these helpful platformfeatures needs some training before the actual usage, but this first check is includedin each Android device
Manual Testing Prototype:
The generate app prototype supports the internal screen reader, all elements havesufficient textual description in the elements name or the related content description.The focus order allows the user to tab through the app. Voice access can be used andalso the custom implementation to support accessibility are satisfying.
62
Chapter 5
5.2.1.2 Analytical Tools
Analytical tools are helpful to detect missing accessibility support, which is possiblymissed with manual testing. Missing labels, wrong size of a touchable element or in-sufficient colour contrast can be detected. The tool Accessibility Scanner3 is integratedinto the Android system and can be easily activated 4. It scans the user interface of anactive app and reports errors in Content labeling, Implementation, Touch target sizeand Low contrast5
Analytical Tools Prototype:
The generated app prototype has no errors reported by Accessibility Scanner
5.2.1.3 Automatic Testing
The Android development environment includes a scanning tool to find structural prob-lems in the apps source code. The tool Lint checks the source code for issues inseveral categories, one of which is accessibility (see https://developer.andro
id.com/studio/write/lint.html). Fig 5.3 gives an example accessibility issuesreported by lint.
Figure 5.3: Setup of Lint for accessibility checks.
Figure 5.4: Code inspection with Lint using accessibility rules.
Inspection of Prototype with Lint:
The generated app prototype has no errors reported by Lint.3https://play.google.com/store/apps/details?id=com.google.android.apps.acces
sibility.auditor4https://support.google.com/accessibility/android/answer/63765705https://support.google.com/accessibility/android/answer/6376559
63
Chapter 5
Test tools and frameworks cover programmatically implemented features but testingwith real users with real disabilities is necessary to find out if an app is truly accessible.Furthermore, there are existing standards and guidelines from the W3C which providesupport to evaluate and rate accessibility.
5.2.2 Evaluation with W3C Mobile Accessibility Guidelines
Beside the platform-specific evaluation, more general rules or guidelines are impor-tant. With Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Applyto Mobile [49], the W3C provides a draft to transform actual standards into mobile.These resulting rules help to check the accessibility of mobile apps based on well-defined criteria.
The app generated in the model-driven development approach was checked with thisruleset manually. The first principle – perceivable – was fulfilled in all three guidelinessmall screen size, magnification and contrast.
Second the operability of the app was part of the inspection. Three out of five guide-lines (keyboard control, touch target size and touch gestures) were satisfying. Thecriterion device manipulation gestures was not part of the app and therefore neitherpassed nor failed. One criterion had failed the evaluation; the the position of appsuser interface elements (buttons, checkboxes, etc.) was too generic in the linear order(Linear Layout). Although this is no problem while tabbing through the app, handlingthe widgets with motor or haptic disabilities might be a problematic.
The next principle in these guidelines is understandable; five rules were passed(screen orientation, consistent layout, important elements without scrolling, groupingelements, indication of active elements), while the rule instruction for custom gestureswas not part of the app.
The robustness as the last principle was passed in the two guidelines easy dataentry and support of platform characteristics was passed. The criterion set keyboardto required entry data was not relevant for the app.
Table 5.1 shows the results of the evaluation process. To sum it up 13 out of 17 rulespassed, three were not relevant and only one failed in the evaluation. The MobileAccessibility guidelines miss a conformance level and are currently in a draft status.Therefore, the next section presents the evaluation with the WCAG.
64
Chapter 5
Table 5.1: Evaluation with W3C Mobile Accessibility guidelines
FulfilmentComment
Yes No N/APrinciple 1: Perceivable1.1 Small Screen Size x1.2 Zoom/Magnification x1.3 Contrast x checked with Accessi-
bility ScannerPrinciple 2: Operable2.1 Keyboard Control for TouchscreenDevices
x tested with differentkeyboards includingexternal keyboards
2.2 Touch Target Size and Spacing x checked with Accessi-bility Scanner
2.3 Touchscreen Gestures x2.4 Device Manipulation Gestures x2.5 Placing buttons where they are easyto access
x Improvement of widgetis possible
Principle 3: Understandable3.1 Changing Screen Orientation (Por-trait/Landscape)
x
3.2 Consistent Layout x3.3 Positioning important page elementsbefore the page scroll
x
3.4 Grouping operable elements that per-form the same action
x
3.5 Provide clear indication that elementsare actionable
x
3.6 Provide instructions for custom touch-screen and device manipulation gestures
x
Principle 4: Robust4.1 Set the virtual keyboard to the type ofdata entry required
x
4.2 Provide easy methods for data entry x4.3 Support the characteristic propertiesof the platform
x generated apps areonly availibe for An-droid
65
Chapter 5
5.2.3 Evaluation with Web Content Accessibility Guidelines (WCAG)
The Web Content Accessibility Guidelines (WCAG) 2.0 are the most relevant standardfor accessibility evaluation. Several legal regulations refer to this standard of the W3C[188, 189]. The WCAG also include also three levels of conformance (A, AA, AAA)to distinguish the quality of accessibility. Additionally, the WCAG is not only restrictedto the web; but its generic rules can also be adapted to all kinds of computer userinterfaces.
For the evaluation of the generated app prototype,levels A and AA were checked,which are 37 out of 59 guidelines. These two conformance levels are the most im-portant for mobile applications. The fulfilment of some AAA rules like Sign Language(Prerecorded) or Images of Text (No Exception) are not relevant for native mobile An-droid applications. A WCAG checklist adapted for the evaluation of mobile apps canbe found at http://pauljadam.com/demos/mobilechecklist.html by Adam[190].
In the evaluation 20 rules (17 Level A, 3 AA) passed the test. The generated app pro-totype showed no problems with text alternatives, adaptable content or the navigationwithin the app.
Overall 15 criteria (11 A, 4 AA) were not applicable for the native mobile application.For example guideline 2.2 Enough Time: Provide users enough time to read and usecontent is related to dynamic contents, which were not part of the example prototype.
Problems were found in the guideline 3.1 Readable: Make text content readable andunderstandable. This rule is related to the language of the content. In the prototype ofthe app generator, the dynamic multi language aspect was not implemented, which iswhy this guideline was failed in levels A and AA.
Fig. 5.5 shows an overview of the coverage of passed, failed and not applicable crite-ria. More details about the evaluation can be found in Table 5.2.
66
Chapter 5
Table 5.2: Evaluation with W3C WCAG 2.0 levels A and AA
FulfilmentLevel A Level AAYes No N/A Yes No N/A
Comment
Guideline 1.11.1.1 Non-text Content xGuideline 1.21.2.1 Audio-only and Video-only(Prerecorded)
x
1.2.2 Captions (Prerecorded) x1.2.3 Audio Description or MediaAlternative (Prerecorded)
x
1.2.4 Captions (Live) x1.2.5 Audio Description (Prere-corded)
x
Guideline 1.31.3.1 Info and Relationships x1.3.2 Meaningful Sequence x1.3.3 Sensory Characteristics xGuideline 1.41.4.1 Use of Color x1.4.2 Audio Control x1.4.3 Contrast (Minimum) x1.4.4 Resize text x1.4.5 Images of Text xGuideline 2.12.1.1 Keyboard x2.1.2 No Keyboard Trap xGuideline 2.22.2.1 Timing Adjustable x2.2.2 Pause, Stop, Hide x2.2.3 No Timing xGuideline 2.32.3.1 Three Flashes or BelowThreshold
x
Guideline 2.42.4.1 Bypass Blocks x2.4.2 Page Titled x2.4.3 Focus Order x2.4.4 Link Purpose (In Context) x2.4.5 Multiple Ways x2.4.6 Headings and Labels x2.4.7 Focus Visible x
67
Chapter 5
Pass Fail N/A
Results of WCAG Evaluation
05
1015
20
OverallLevel ALevel AA
Figure 5.5: Results of the WCAG evaluation. Overall 20 rules passed, 2 rules failed inthe evaluation and 15 rules were not applicable.
Table 5.3: Evaluation with W3C WCAG 2.0 levels A and AA, part 2
FulfilmentLevel A Level AAYes No N/A Yes No N/A
Comment
Guideline 3.13.1.1 Language of Page x not imple-
mented in thisversion
3.1.2 Language of Parts x not imple-mented in thisversion
Guideline 3.23.2.1 On Focus x3.2.2 On Input xGuideline 3.33.3.1 Error Identification x3.3.2 Labels or Instructions x3.3.3 Error Suggestion x3.3.4 Error Prevention (Legal, Fi-nancial, Data)
x
Guideline 4.14.1.1 Parsing x4.1.2 Name, Role, Value x
68
Chapter 5
Figure 5.6: Final app for usertest.
5.2.4 Evaluation with Test Users
To evaluate the model-driven development method with test users, a prototype is notenough. For a real user experience the app needs more functionality.
Based on the prototype generated with the model-driven development approach, therouting app was enhanced to a working prototype. app. The given user interface andapp work-flow was extended with a data connection to an existing routing service, theintegration of a built-in routing algorithm and a map.
The result is an accessible smartphone app on the Android platform. It allows accessto a routing service with different configurations for the needs of special user groupsand guides a handicapped person on the chosen path. The resulting app was evalu-ated by test users with different impairments. Fig 5.6 presents the screenshot of thesettings to change different visual styles for different disabilities. This evaluation hasalready been published by Krainz et al [20].
Details of the user evaluation
To evaluate this system, we decided to test the application with multiple groups thatmatch the pattern of our application. To get as many views as possible, we used threedifferent sources for our assessment:
1. The NASA Task Load Index (NASA-TLX) , which measures the needed effort in
69
Chapter 5
an objective way [183].
2. The System Usability Scale (SUS), which measures the acceptance of a systemamong the test persons [184].
3. User observation and personal questionnaires, which should provide more in-sight into the problems and wishes of the test persons.
In the field study we evaluated the accessibility of the app with 12 people. The testusers had different limitations such as visual or cognitive impairment. Among theparticipants there were eight men and four women between the ages of 20 and 65years. Three people had a very strong visual restriction (IDC-10 H54.0 - H54.1)6, theyrequired non-visual feedback from the app. Two test users had a cognitive disability(IDC-10 F70-79)7, five people were in the target group of people above the age of60. To acquire some data about the general usability of the app two tests with userswithout disabilities were done [20]. Fig 5.7 gives an impression of the user tests.
The tasks in the evaluation were the operation of the accessible routing app. Startingwith typical tasks like changing the app setting and the visual appearance, afterwardsthe participants had to navigate to a given target location. The location was providedin the form of an address. Users had two options: follow a turn by turn navigation withtextual output, or follow a path on a map with arrows showing the next turn point [20].
The tasks for the test users were typical activities of the routing app; starting with theapp settings for the routing profile and the setup of the visual appearance, then enter-ing a navigation target and finally following the routing instructions from the app. Theapp provided two navigation options; following the path on a visual map or followingturn by turn instructions [20].
5.2.4.1 User Tests
People with cognitive disabilities
In the first test session, two people with cognitive disabilities tested the application. Tomeet the specific needs of the group, a simpler version of the NASA-TLX was used.Instead of twenty steps, the scale offered only six, and adjusted the results to theregular ones later. The specific task of following the text output of navigation modewas not tested. The people in the test group would not have been able to focus onmore than one source of information. The routing app received positive feedback. Theaverage NASA-TLX score for the two tasks was 34.38 (ranging from 0-easy to 100-hard). The SUS rating shows a similar picture: average score of 72.5 out of 100 andthe lowest score of 62.5. The use of each subject was rated as positive. Although
6http://apps.who.int/classifications/icd10/browse/2016/en#/H53-H547http://apps.who.int/classifications/icd10/browse/2016/en#/F70-F79
70
Chapter 5
Figure 5.7: User tests: left: test person with cognitive disability, right: blind test person
the app was rated positively by the test users, they still gave feedback on what wouldbe an improvement for them later on. For example, voice control for the app might behelpful [20].
Elderly people
Testing the acceptance of the application in the elderly was the second step. As ex-pected, older people found the application less stressful than people with cognitivedisabilities. The average TLX score over the three tasks was 18.9, with the highestscore being 32.2. When ignoring the third task (navigating through the text output),the average score was even lower (16.25).
The SUS rating reflects these results, with the SUS average at 79.5 being slightlyhigher. On the other hand, the lowest value was 45, which is much lower than thelowest value in the first test group.
Similar to the first user test, the app got positive feedback. Testers requested thatthere be more waypoints along the route on the display for better orientation [20].
Blind and visually impaired people
In order to complete the evaluation with the target groups, blind and visually impairedpeople tested the application. This user group did not test the function "routing withthe help of the map" (this function cannot be used without eyesight).
This target group found the application less demanding than the group of people withcognitive disabilities. The average NASA TLX was 29.2. Comparing the averagescore of the tasks evaluated by the group of elderly people (average: 15.4 for thesetwo tasks), the default use of the application seems to be much easier than using itwith Google Talkback.
71
Chapter 5
Looking at the SUS score this test user group had only a slightly lower average (78.75)than the group of older people. Moreover, the lowest SUS score was higher than thelowest score in the second test group (57.5).
In contrast to the tests with the other participants, these tests showed limitations inthe application, which are partly due to the accuracy of the GPS signal. While theother two test groups could compensate for some inaccurate instructions with their fulleyesight, blind people depended on the information’s accuracy [20].
People without restrictions
The user evaluation was finished with two users without restrictions. Their averageNASA-TLX value (11.25) indicates, that the demand while using the app was lowerfor people without any restrictions. The average SUS score (85) showed that theapplication is more convenient to use. However, the results of this group are closeenough to the results of the target groups to consider both results valid.
Evaluation Results While it comes as no surprise that older people and non-impairedreference testers gave the best ratings, it is remarkable, that visually impaired peopleevaluated the settings-task to be the hardest, while it was considered an essential taskamong all the other test groups, as Fig. 5.8 shows.
change visual style navigation with textual description navigation with map
TLX of User Test
Workload
010
2030
40
Cognitive ImpairmentElder PersonsVisual ImpairmentNo ImpairmentOverall
Figure 5.8: Average TLX of the the task compared to the different user groups.
With the SUS-scores of all groups relatively close together and all them well above av-erage, it seems to safe to say, that groups of people with special needs would acceptthe application concept. However, Fig. 5.9 indicates that the most significant accep-tance of the tested application came from non-impaired people, whereas people withcognitive impairments gave our application the lowest ratings [20].
72
Chapter 5
SUS of User Test
SUS
7075
8085
90
Cognitive ImpairmentElder PersonsVisual ImpairmentNo ImpairmentOverall
Figure 5.9: Average SUS score by user groups.
5.2.5 Quick Accessibility Check
The evaluation of accessibility requires experience to handle assistive tools and com-plex guidelines. Still, the evaluation results are not simple measurable and comparablevalues. The Quick Accessibility Check (QAC) provides a method of achieving acces-sibility evaluation results that are quick and comparable.
QAC was inspired by the ideas of Guerrilla HCI [191], which aims to simplify the us-ability engineering process, and by the WAI Easy Checks [192], a method for a firstaccessibility review.
The Quick Accessibility Check helps to get an overview of the most significant acces-sibility problems of a mobile application. It has three parts, the first of which uses theintegrated assistive technologies (like Talkback) and rates the app’s support of these.The results are ranked on a Likert scale from very good (1) to very poor (5). Table 5.4shows an example of this rating.
The next step is the automatic check with the Accessibility Scanner. This tool givesfeedback about improper implementation in the visual appearance of an app. The toolfinds errors referring to the material accessibility guidelines. For the QAC all reportederrors in the categories touch size, image contrast, text contrast, missing label, double
73
Chapter 5
Table 5.4: Quick accessibility check - Assistive technologies
verygood (1)
good neutral poorvery
poor (5)not
reportedScreenreaderTabbingexternal keyboard
label and wrong implementation of accessibility are counted. The rating is presentedin Table 5.5.
Table 5.5: Quick accessibility check - Errors from Accessibility Scanner
ErrorsTouch sizeImage contrastText contrastMissing labelDouble labelWrong implantation of accessibility
Finally, the app is checked manually by the evaluators in the five criteria clear and sim-ple texts, clear navigation, readable font size, possibility of magnification and positionof the UI elements. These rules are also rated on a Likert scale from very good (1) tovery poor (5), as seen in Table 5.6.
Table 5.6: Quick accessibility check - manual checks
verygood (1)
good neutral poorvery
poor (5)not
reportedClear and simple textsClear navigationReadable font sizePossibility of magnificationPosition of the ui elements
Every checkpoint of the QAC provides quantitative results and can be summed up.The final value represents an error count and a rating scale. This numeric index canbe used to compare the accessibility of two similar apps or can measure the improve-ment of accessibility in the development process. QAC should help developers withoutdeeper knowledge of the complex rules of WCAG to get a status about the actual ac-cessibility of an app. This quick method is based on the established Web ContentAccessibility Guidlines. Table 5.7 shows the association of QAC rules and WCAGsuccess criteria and guidelines.
The Quick Accessibility Check is used in the empirical evaluation of the model-drivendevelopment process to create comparable values of similar apps. (see Chapter 6)
74
Chapter 5
Table 5.7: Association of QAC Rules to WCAG Success criterions and guidelines
QAC Rule WCAG Success CriterionAssistive technologies
Screenreader 1.1.1, 1.2.2Tabbing 1.3.2, 2.4.3external keyboard 2.1.1, 2.1.2, 2.1.3
Accessibility ScannerTouch size 2.1Image contrast 1.4.3Text contrast 1.4.3Missing label 1.1.1, 1.2.2Double label 1.1.1, 1.2.2Wrong implantation of accessibility 4.1
Manual checksClear and simple texts 3.1.1Clear navigation 1.3.1, 1.3.2, 2.4.1, 2.4.3Readable font size 1.4.4Possibility of magnification 1.4.4Position of the UI elements 2.1
5.3 Summary
This chapter deals with the research question How can the model-transformation cre-ate an accessible app? According to Shaw, we can validate a result (of the model-driven app development) with an example. In this chapter the model (see Chapter3) and the model-driven development approach (see Chapter 4) are used to create aprototype app.
The resulting mobile application was checked with assistive technologies, evaluatedwith state-of-the-art guidelines (WCAG) and tested by users with different restrictions.This comprehensive accessibility evaluation shows that model-driven developmentleads to an accessible app prototype. Furthermore, this chapter presents a fast way toevaluate accessibility. The Quick Accessibility Check gives developers without experi-ence in the field of accessibility a rule set to rate their app concerning accessibility.
75
Chapter 6
Empirical Evaluation of theModel-Driven DevelopmentProcess
This chapter covers the research questions:
• Does model-driven development lead to better and more accessible apps?
• Do model-driven approaches increase awareness of and practice in accessibleapp development?
To answer these questions the model-driven approach for the development of acces-sible Android apps was evaluated with developers.
Different methods of evaluating software engineering are found in literature. Grill etal. [193] use heuristic evaluation with four experts and a workshop with eight develop-ers to analyse the usability in software APIs. The usability of an existing persistenceAPI was the target in the work of Picconi et al. [194]. In this task-oriented study 25experienced developers evaluated the features of this API. To improve and redesignthe API of an existing business software framework Stylos et al. [195] used six partic-ipants. Ellis et al.[196] analyse the usage of the Factory Pattern in API design with 12developers.
Two studies with a larger number of involved users those of Salvaneschi et al. [197]and Acar et.al [198]. The first work involved 127 users to study the effect of reac-tive programming to understand software; the second work compared the usability ofcryptographic libraries in Python with 256 active participants.
The number of participants in the aforementioned related work varied from 6 to 256,which led to the setup of the empirical evaluation of model-driven development for
Chapter 6
accessible apps.
6.1 Study Design
To observe the improvement of accessibility in app development, we had to comparetwo groups of participants. While group A used the model-driven development ap-proach, group B implemented the app prototype with the conventional method
The first task was the pre-questionnaire. Beside personal information (age, gender,education), users were asked about their programming and usability skills. In thepre-questionnaire, there were also questions designed to get an impression as to theusers? awareness of the usability and accessibility of apps.
The second task was the implementation of a working app prototype. The startingpoint was an informal mockup prototype, which showed the essential screen with someuser interface elements like labels or checkboxes. Furthermore the interaction andnavigation from one screen to another was defined. The participants did not have toimplement any backend functionality.
The next step was the accessibility evaluation of the resulting app. For this task theQuick Accessibility Check QAC (see Chapter 5) was used.
The last task for the participants was the post questionary including a simplified TaskLoad Index to rate the workload of the development and self evaluation process and asecond look on the users awareness of usability an accessibility.
6.2 Target Group
The target group for the empirical evaluation was developers who had experiencein software development, with a special focus on mobile apps. All participants hadknowledge of user interface development on the Android platform to transform thegiven app draft into working implementation.
This study included 50 participants. They were between 21 and 58 years old, with7 female and 43 male programmers. 13,2 % were senior developers with a master’sdegree and several years in software development, 37% were students with workingexperience enrolled in a part time master’s program for mobile software developmentand 49% are currently students in a bachelor’s degree program with existing skills inprogramming, human computer interaction and mobile development (see Fig 6.1). Allparticipants were familiar with Java development and Android Studio.
77
Chapter 6
Senior developers
Junior developers
Students
Work experience of participants
Figure 6.1: Work experience of participants.
The self-rated skills in programming in Fig 6.2, left were mostly above the average(35). The skills related to mobile development were more rather good but rated lowerthan the programming skills (Fig 6.2 right).
The participant were also asked about their self-rated skills regarding user interfacedesign and accessibility. More than 30 developers rated their design skills above theaverage (Fig 6.3 left). The self-rated accessibility skills were more equally distributed(Fig 6.3 right).
Not all participants completed all tasks, the reasons being problems in the develop-ment process as well as problems with the assistive tools on the Android platform inthe evaluation part.
6.3 Development Tasks
All participants started with the same requirements for a simple app prototype. Theyreceived a short description of the expected app and a simple interaction sketch withthe requested user interfaces and flows through the app. Fig. 6.4 shows the paperprototype for developers.
With this requirement, the developers used two different development methods. Thefirst group developed their app with the help of the model-driven development ap-proach; the other group implemented by means of a typical Android project.
78
Chapter 6
6 very good 5 4 3 2 1 0 none
Programming Skills
number
05
1015
20
6 very good 5 4 3 2 1 0 none
Mobile Development Skills
number
05
1015
20Figure 6.2: Programming skills of participants.
6.3.1 Model-driven Development with Accapto
The first group of participants used the new model-driven development method withthe tool Accapto. They got a detailed description of the structure of the meta-modelin XSD and an example of the model description language in XML. From this startingpoint, they had to create a in the first step the model from the given app draft. With thecommand line tool Accapto, the model was transformed into an Android Studio appproject. There were no additional tasks to implement code functionality in the IDE, butthey had to use built-in tools to compile the source code and create a runnable app forthe Android platform.
6.3.2 Development with Android Studio
The control group created the native Android with the help of the standard develop-ment environment Android studio. They had to create a project from scratch with thegiven app and package name. Following the standard development method1, theyused Activities, XML-based layouts with UI elements and the intent system to createthe workflow with in the app.
As all participants had already used these tools and everyone had already created atleast one Android app, they had only minor problems with this task.
The detailed description of the tasks and the supporting material can be found inthe project’s Github repository https://github.com/elmarkrainz/accapto/t
ree/master/evaluation and in Appendix C.
1https://developer.android.com/training/basics/firstapp/index.html
79
Chapter 6
6 very good 5 4 3 2 1 0 none
User Interface Design Skills
number
05
1015
20
6 very good 5 4 3 2 1 0 none
Accessibility Skills
number
05
1015
20Figure 6.3: UI design and accessibility skills
appname: POIApppackagename: org.accapto.poiapp
New
Points of Interest
Settings
My POIs
Settings
GPS is Active
..
Username
All POIs
POI 1
Search
..
New
POI 2
POI 2
Add Photo
New POI
..
GPS
Save
Is Public
Name
Save & Back
Figure 6.4: Mockup of the app prototype.
6.4 Accessibility Evaluation Task
After the implementation of the prototype with one of these development methods,the next task was the evaluation of the resulting app. The user got a pre-definedaccessibility check – the QAC – to create comparable results.
Assistive technologies and manual checks were rated in a grading system from 1 (best)to 5 (worst) and the average of the single grades was used. The errors found with theAccessibility scanner in the different categories were counted. This showed an overallrating where a lower number represents better accessibility. Table 6.1 shows a typicalevaluation report from a single participant. This example presents a average rating ofthe assistive technologies at 1.33, the numbers ob errors found by the AccessibilityScanner was 0 and the manual checks got an average value of 2.8. The overall ac-
80
Chapter 6
cessibility rating is the sum of all these categories, which is in this sample is the value4.13. This is an objective and comparable result.
Table 6.1: Single Accessibility evaluation
Assistive TechnologiesScreenreader 1Tabbing 1External keyboard 2
average 1,33Accessibility Scanner
Touch size 0Image contrast 0Text contrast 0Missing label 0Double label 0Wrong implantation of accessibility 0
sum 0Manuelle Checks
Clear and simple texts 2Clear navigation 2Readable font size 3Possibility of magnification 4Position of the ui elements 3
average 2,8Overall Accessibility Rating 4,13
Not all participant finished the evaluation. Some users did not finish the developmentpart, other had problems with the accessibility tools. In the end 42 accessibility reportswhere analysed.
6.5 Results of the Empirical Evaluation
6.5.1 Accessibility
First of all, the participants (n=42; not all participants creates valid results) had toestimate the accessibility of their development results. On a scale from 1 (very good)to 10 (very bad) users rated the accessibility of their own app. The chart in Fig.6.5presents the first impressions. Participants of the model-driven development groupestimated the accessibility of their app with a mean of 3.27, better than that of thosewho used the conventional development (mean 5.19).
These are subjective results from the developers, but the model-driven approach re-ceived better feedback concerning accessibility. For objective results and to consoli-date the first impressions, the accessibility evaluations of all participating developers
81
Chapter 6
02
46
810
Self-estimated Accessibility of resulting app
good
sel
f-est
imat
ed A
cces
sibi
lity
bad
Model-driven DevelopmentConventional Android Development
Figure 6.5: Boxplot of self-estimated accessibility rating.
were analysed.
For each development method, 21 participants finished the accessibility evaluation,making are 42 reports to analyse. The reports were compared in the overall score aswell in the single parts, e.g. the errors found by the Accessibility Scanner.
The two groups of developers got different results in both the overall accessibility ratingand also in the three sub categories. Fig 6.7 presents the difference between bothmethods.
The first impression showed a big difference in the overall accessibility of the resultingapps. Those apps which were created with the model-driven development method hadan average overall accessibility rating of 6.19, compared to 12.29 for the conventionalmethod (a lower value indicated better accessibility). This is a significant difference; alook at the sub categories shows more observations.
Assistive technologies where better rated in the model-driven approach (mean 1.80)than the other development method (mean 2.97), the automatically integration of forexample, test alternatives or focus order for tabbing being a reason for this result.
With an average of 2.10 and median 0, the errors reported by the scanner were muchbetter with MDD compared to 6.76 (mean), 6.0 (median) of the alternative develop-
82
Chapter 6
ment. Manual checks were only slightly better in the new development method, with2.38 to 2.56.
Overall A11Y Rating AssistiveTech A11yScanner Manual_Checks
Accessibility Evaluationgo
od
A
cces
sibi
lity
Rat
ing
bad
02
46
810
12 Model-driven DevelopmentConventional Android Development
Figure 6.6: Barplot of accessibility rating.
The details of the descriptive statistics are shown in Table 6.2. The mean, variance,standard deviation and median in all categories are presented.
The box plot diagram in Fig. 6.7 is graphically depicts the grouping of numerical data.One can see the distribution of the model-driven method is smaller than that of theconventional development method.
To draw a conclusion about the evaluation data, the methods of inferential statis-tics were used. With this sample, this thesis aims to makes a proposition about thegenerality of this concept.
Statistical inference draws conclusions from existing statistical data, where the ob-served data is part of a larger population. This includes creating and testing hypothe-ses about a population and deriving estimates [199].
This work intends to answer the question: Does model-driven development lead tobetter accessibility?
To answer this question, the following statistical hypothesis was defined
• Null Hypothesis H0
83
Chapter 6
Table 6.2: Statistics of Accessibly Evaluation
Model-driven Development (n=21)Overall AssistiveTechologies Errors A11y Scanner Manual Checks
mean 6,19 1,80 2,10 2,38var 35,53 0,40 31,99 0,20SD 5,96 0,63 5,66 0,45median 4,40 1,58 0,00 2,40
Android Development (n=21)Overall AssistiveTechologies Errors A11y Scanner Manual Checks
mean 12,29 2,97 6,76 2,56var 93,93 1,02 79,89 0,32SD 9,69 1,01 8,94 0,57median 13,07 2,67 6,00 2,40
µ0 = µ1: App accessibility of model-driven development is the same as conven-tional development.
• Alternative Hypothesis H1
µ0¬µ1: App accessibility of model-driven development is not the same as con-ventional development.
To test a statistical hypothesis, the samples are checked by means of hypothesis test-ing. The commonly used method to compare two independent samples is the t-test[199]. This method is applicable to compare the means of two samples where the teststatistics are normally distributed.
The samples of observation are the two different data rows of the accessibility eval-uations. The t-test is only applicable if the sample follows a normal distribution. TheShapiro-Test [200] is used to clarify this. The following script shows this test in R.
##### Shapiro test in R
Shapiro-Wilk normality test
data: accessibility_android_development
W = 0.78025, p-value = 0.0003324
data: accessibility_modeldriven_development
W = 0.51511, p-value = 2.812e-07
With p-values (Android development: p-value = 0.0003324 and model-driven develop-ment: p-value = 0.00000281) lower than 0.05, both samples are significantly differentfrom a normal distribution. The two samples are not normal distributed. Therefore, thet-test cannot be used.
An alternative to the two-sample t-test is the Wilcoxon Rank-Sum or Wilcoxon-Mann-Whitney test, which is a nonparametric test of the null hypothesis.What sets it apart
84
Chapter 6
Model.Driven.Development Android.Studio.Development
010
2030
40
Boxplot Accessibility Evaluation
Development Method
good
A
cces
sibi
lity
Rat
ing
bad
Figure 6.7: Boxplot of accessibility rating.
from the t-test is that it does not need a normal distribution of the data and yieldssimilar results to the t-test for normal distributions [201].
The Wilcoxon-Mann-Whitney-test was used in R with the following results.
##### Wilcoxon Test in R
Wilcoxon rank sum test with continuity correction
data: accessibility_android_development and accessibility_modeldriven_development
W = 86.5, p-value = 0.0007789
alternative hypothesis: true location shift is not equal to 0
The Wilcoxon-Mann-Whitney test indicated that the group using model-driven devel-opment achieved better values for accessibility (mean = 6.19, SD = 5.96) than thegroup employing the classic development approach (mean = 12.29, SD= 9.69). With ap-value of p= 0.0007789 being lower than 0.05, the hypothesis H0 of statistical equalityof the means of two groups was rejected.
The analysis of the evaluation data of the model-driven development and the standardprocedure shows a significant difference in the accessibility of the resulting app. Themodel-driven approach with Accapto creates apps with better accessibility right fromthe beginning.
85
Chapter 6
6.5.2 Workload of Tasks
In the post questionnaire, all participants were asked about the workload of the de-velopment and the evaluation task. This should show if the model-driven approachhas a different workload than the conventional Android development. The results werealso compared with the workload of the evaluation task, which was the same for bothgroups.
To get comparable results the TLX [183] was used. The participants had to rate themental, physical and temporal demand, the performance, the effort and the frustrationof the tasks on a scale from 0 (low) to 10 (high).
Fig 6.8 shows the results of the evaluation task. The overall workload revealed no sig-nificant difference. The group using MDD rated this task with a mean of 3.8 (SD=1.2)with a higher workload compared to the other group (mean=3.6, SD=1.4). The singleitems in the TLX were balanced.
OverallMentalDemand
PhysicalDemand
TemporalDemand Performance Effort Frustration
TLX of Evaluation
Workload
02
46
810
Model-driven DevelopmentConventional Android Development
Figure 6.8: TLX of the evaluation task.
The the workload of the development task is displayed in the bar-plot diagram in Fig6.9. Here one sees a significant difference reported by the participants. In all subcat-egories, the workload of the model-driven method was higher. The overall taskloadindex from the model-driven participant group (mean=4.7, SD=1.0) was approximately20% higher than that of the other participants (mean=3.7, SD=1.3).
86
Chapter 6
OverallMentalDemand
PhysicalDemand
TemporalDemand Performance Effort Frustration
TLX of Development
Workload
02
46
810
Model-driven DevelopmentConventional Android Development
Figure 6.9: TLX of the development task.
Discussion:
The results were unexpected. With the support of model-driven development, the im-plementation of an app should have a lower workload. All participants in the empiricalevaluation were used to Android development. For that reason, creating a simple pro-totype was not a big challenge, but the model-driven approach was totally new for thedevelopers. They had to learn the modelling and generation process. Longer trainingin Accapto or direct integration in the development environment would be an improve-ment.
6.5.3 Awareness and Learning Effect
The last part of the empirical evaluation with developers was to assess the awarenessand learning effect of accessibility in the development process. This work aims to an-swer the question: Do model-driven approaches increase awareness of and practicein accessible app development?.
Interview questions in the pre- and post-questionnaire aimed to obtain feedback about
87
Chapter 6
Table 6.3: Usability in App Development
How important are the following pointsfor the development of mobile apps
impo
rtan
t
rath
erim
port
ant
neut
ral
rath
erun
impo
rtan
t
unim
port
ant
Q1 Satisfying user experienceQ2 Simple operating conceptQ3 Labeling of operating elementsQ4 Graphical representation of functionsQ5 Description of controlsQ6 New forms of interactionQ7 Physical accessibility of operator elementsQ8 Written instruction manualQ9 Record user dataQ10 Alternative display options
the awareness and learning effect of accessibility. All participants were asked ques-tions about usability in app development before and after the two tasks in the study.The general question about usability tried to camouflage the accessibility topics. Table6.3 presents these questions.
Questions Q2, Q3, Q5, Q7 and Q10 intended to consider the knowledge and aware-ness about accessibility in mobile development. The remaining questions dealt withmore general aspects and should camouflage the testing towards accessibility. Theresulting data compares the effect before and after the given tasks of developmentand evaluation. Tthe difference between the two different development methods iscompared, as well.
The analysis of the questionaire data shows no significant differences. Both dimen-sions of this comparison (before/after, model-driven/standard development) are bal-anced. Fig 6.10 shows an example regarding the question How important is the fol-lowing points for the development of mobile apps - satisfying user experience.
Question Q1 shows no significant differences in any dimension of this study. The re-sponse before and after the evaluation and also the different development approachesshow no considerable difference.
The next observed question is Q3, How important is the following points for the de-velopment of mobile apps – labelling of operating elements. This question intends toconsider an accessibility aspect. Before the tasks of this study, 70% of the partici-pants rated this question important or rather important, 20% neutral and 10% said itwas rather unimportant or unimportant.
88
Chapter 6
0%10%20%30%40%50%60%70%80%90%
100%
1 2 3 4 5
Q1: pre-questionary (grey)post-questionary (blue)
0%
20%
40%
60%
80%
100%
1 2 3 4 5
Q1: model-driven dev. (blue) standard-dev. (grey)
Figure 6.10: Q1- Before and after development task; model-driven vs. standard devel-opment.
After the evaluation 86% rated important or rather important, 2% neutral but still 12%of the participants answered this question with rather unimportant or unimportant. Aminor shift is recognised, but not significant improvement toward accessibility could beobserved (see Fig. 6.11 left).
The comparison of the two different developer groups indicated only minor differencesin the rating of question Q3 (see Fig. 6.11 right).
0%
10%
20%
30%
40%
50%
60%
1 2 3 4 5
Q3 pre-questionary (grey)post-questionary (blue)
0%
10%
20%
30%
40%
50%
60%
1 2 3 4 5
Q3 model-driven dev. (blue)standard-dev. (grey)
Figure 6.11: Q3- Before and after development task; model-driven vs. standard devel-opment.
The data analysis of all questions shows similar results. The complete data can befound in Appendix C.
Open Question and Interviews
The participants were also offered the possibility to give feedback about the new devel-
89
Chapter 6
opment method and the accessibility evaluation. Their feedback on the model-drivendevelopment method was positive. The fast way of development with Accapto "withmodel-driven development one can create simple apps very fast" and in the automaticintegration of accessibility "it is good to see how fast accessibility can be integratedin the app," were positive responses to the new method. However, some open issuesfrom the developers? point of view were reported, such as the lack of documentationand the need for more and better error messages during the transformation process.One participant summed it up by saying, "The system is the beginning of a promisingframework that saves development time by simply describing and generating proto-types / program skeletons."
The accessibility evaluation was commented on positively. The quick accessibilitycheck received good feedback; "Points for accessibility rating were well chosen andreflect questions that arise in the development," as did the automatic check with thescanner; "Reviewing with the Accessibility Scanner is very easy, but it did not findany bugs - which was a bit puzzling at first, until it was checked against anotherapp." Developers still suggested going beyond developer-based testing and insistedon conducting the test with real users ("For a real app you need real test persons withlimitations, because you can only estimate what your audience really wants from anapp").
Some participants had problems with the assistive technologies, especially the newmethod of interaction with Talkback ("The handling of the talkback application is hor-rendous"; "..Talk Back was unfamiliar to use and annoying..").
To get more qualitative data about the awareness, four participating developers wereinterviewed. In a semi-structured interview, the participants were asked the followingquestions:
• What do you know about (mobile) accessibility?
The interview partners already had basic knowledge of accessibility not only fromtheir education ("learned about it in lectures"), but also from literature and research("learned from book, web or colleagues, but sometimes annoying"). One participantnoted the legal regulations to include accessibility in public products ("I know aboutlegal regulations").
• How much have you considered accessibility so far in software projects?
Taking a closer look at their own experience regarding accessibility implementation,one interview partner was responsible for accessibility in web projects and also usedonline tools to evaluate problems ("..included alt-tags for images, web projects andused online tools to find issues"). The other ones replied to have not really cared aboutaccessibility in their recent projects if it was not a concrete requirement ("..accessibilitywasn?t a requirement in customer projects").
90
Chapter 6
• Did you learn more about accessibility in the evaluation?
All participants agreed that they learned more about accessibility in development. Thetopic is not always present in daily development tasks and they all gained new impres-sions ("new tools to check apps," "more details about implementations," "new issues").
• How far is the support of tools (IDEs) for accessibility from your point of view?
Their impression of accessibility support was rather disillusioning. Quotes like "ac-cessibility is more the less ignored in development" or "not really, accessibility is acomplicated topic" showed that the developers would like to have more support fromIDEs or coding tools.
• How well is model-driven development suitable for integrating accessibility?
The subjective lack of accessibility support in software development programs led tothis question. All participants liked the idea of model-driven development to include ac-cessibility in app projects. MDD depends on proper modeling ".. tools forces descrip-tions" and provides a good starting point including accessibility from the beginning.However, model-driven development was also commented on critically. The missingbi-directional workflows in many tools and also in Accapto can bring problems in thepractical usage ("mdd is sometimes one-way, and changes are not reported back tothe model").
• How far have your knowledge and awareness of accessibility increased?
The measurement of accessibility awareness is problematic. Following the responsesof all interview partners, they had previous know-how about and awareness of acces-sibility (?there is already awareness"). But during the interview, they also reported notalways including it in the development process. When developers are concerned withthe topic of software accessibility, their awareness increases a little bit ("another inputto think about it".
All comments from the empirical study as well as the interviews can be found in theAppendix C.
Discussion
The participants already had sufficient knowledge and awareness of accessibility. Theimportance of supporting technologies and proper implementation is beyond debate.Adding accessibility to software is an extra step for most developers, which is some-times skipped. Improved tools or new development approaches that constrain acces-sibility as a mandatory factor result in accessible software products.
91
Chapter 6
6.6 Summary
This chapter presents the evaluation of model-driven development to improve appaccessibility. The empirical study with 50 developers answered the questions
• Does model-driven development lead to better and more accessible apps?
• Do model-driven approaches increase awareness of and practice in accessibleapp development?
The first impression showed a big difference in the overall accessibility of the resultingapps. Those apps which were created with the model-driven development method hadan average overall accessibility rating of 6.19, compared to 12.29 for the conventionalmethod (a lower value indicated better accessibility). This is a significant difference; alook at the sub categories provides more insights.
The analysis of the evaluation data of the model-driven development and the standardprocedure shows a significant difference in the accessibility of the resulting app. Themodel-driven approach with Accapto creates apps with better accessibility from thebeginning.
The evaluation of the development workload showed no reduction due to the model-driven method. Improvements in the tool’s utility and usability would probably help toreduce the demand. The questions about practice in and awareness of accessibleapps did not report any enhancement. Developers have knowledge and awareness,but still, accessibility is not something obvious to include in the development process.
92
Chapter 7
Conclusion and Outlook
This chapter summarises the findings of this thesis. The outcomes from the researchquestions are presented along with an outlook on further work in this field. Finally, thisthesis concludes with the support for accessibility in development.
7.1 Findings
The lack of accessibility is a problem of many apps on the Android platform. This the-sis presents the novel combination of model-driven development for accessible apps.How to apply this approach and its conclusion is answered in the following researchquestions.
RQ 1: How can model-driven development support the developmentof accessible apps?
Model-driven development needs a suitable model and a tailored transformation pro-cess. Both of these aspects led to the following sub-questions:
RQ 1.1 Which kind of model is needed for the model-driven approach?
Accessibility problems are related to the user interaction. The different screens, the in-teraction and the workflow through a mobile app are important factors for accessibility.The more informal methods in interaction design e.g. paper prototyping are transferredto a formal model. This model includes screen, transitions, and user interaction in anXML definition. This model is the foundation for further model-driven development.
RQ 1.2 How can the model transformation create an accessible app?
The model for an accessible mobile app is transformed in the generator into an Androidapp prototype. The required source code for layouts in XML and basic functionality in
Chapter 7
Java is generated within the transformation using a templating engine. The code gen-eration creates the proper platform-specific implementation to establish an accessibleprototype. Furthermore, the accessibility pattern library gives developers an additionaltool to improve the accessibility of apps.
The accessibility of the resulting app prototype was evaluated with the help of system-integrated assistive technologies, international guidelines (e.g. WCAG) and test userswith different restrictions. The evaluation showed that the integration of accessibilityfrom the beginning leads to accessible apps.
The result is a new procedure. The accessible app toolkit – Accapto – contains amodel for accessible app interaction and a generator to transform models into apps.Accapto includes accessibility from the beginning. Furthermore, the following researchquestions are part of this thesis:
RQ 2 Does model-driven development lead to better and more acces-sible apps?
The Accapto tool was evaluated with a group of developers. In an empirical studywith more than 50 developers, the new model-driven method was compared with thestandard development tool regarding accessibility.
The model-driven development method had an average overall accessibility rating of6.19, compared to 12.29 for the standard method (a lower value indicated better ac-cessibility). Applying the Wilcoxon-Mann-Whitney test indicated the significance of thisresult, with a p-value of p= 0.0007789, lower than 0.05.
RQ 3 Do model-driven approaches increase awareness of and prac-tice in accessible app development?
The participants in the study gave feedback on the new method and about app acces-sibility. Another four developers were interviewed regarding their personal experienceand know-how of accessibility in development. Developers already had knowledgeand awareness of accessibility. The importance of supporting technologies and theirproper implementation is not to be discussed. Including accessibility software is anextra step for most developers, and sometimes skipped. Improved tools or new devel-opment approaches that limit accessibility as a mandatory factor score for accessiblesoftware products.
Based on the findings it can be concluded, that model-driven development significantlyenhances the development process and thus the accessibility of the resulting prod-ucts. Although Accapto generates many accessibility related features automatically,developers still have to add programatic functions manually. Apart from supportive de-velopment tools, the awareness to create apps also for people with disabilities is stillan issue developers need to be confronted with.
94
Chapter 7
7.2 Future Work
The Accapto framework shows that model-driven development can improve the ac-cessibility of the generated apps. But the model is still limited. Further improvementwill be the extension of the model with, e.g. more user interaction elements or differ-ent navigation styles. Additionally, a graphical model editor may help to design appsmore efficiently. For better usability and non-programmers, a visual editor to createthe model based on the DSL would be helpful.
Direct integration of Accapto into a modelling tool or the integration directly into AndroidStudio could help developers integrate accessibility. This could be done via a pluginfor app scaffolding.
Another improvement regarding the awareness of and practice in accessibility of de-velopers would be more and better integration of accessibility evaluation in the IDE.Simplified rules for evaluation and comparison of accessibility like the Quick Accessi-bility Check already provide fast feedback and show errors in the implementation.
Last but not least, this approach is a prototype and limited to only the Android platform.An extension to iOS or cross-platform development would improve accessibility for awider range of developers and users.
7.3 Conclusion
Accessibility is a basic human right, ..It benefits everyone. Eve Andersson(Google)1
Accessibility is sometimes treated like an extra feature. The importance of accessi-bility is beyond dispute; software developers have knowledge and awareness of thisimportant issue. In spite of that, it is often ignored in the rush of the fast-moving devel-opment. Legal regulations or standards are difficult and not a helpful tool for everyone.The support for proper implementation concerning accessibility should be included inthe programs to create new software like apps or webpages.
Finally, improved development methods like model-driven development with Accaptoinclude proper implementation and additional support for developers to improve theaccessibility of mobile applications.
1https://www.fastcodesign.com/3060090/how-designing-for-the-disabled-is-giving-google-an-edge
95
Bibliography
[1] E. Krainz and K. Miesenberger, “Accapto, a generic design and developmenttoolkit for accessible mobile apps.” Studies in health technology and informatics,vol. 242, pp. 660–664, 2017.
[2] G. Meixner and G. Calvary, “Introduction to model-based user interfaces,”W3C, W3C Note, Jan. 2014, http://www.w3.org/TR/2014/NOTE-mbui-intro-20140107/.
[3] University of Alabama at Birmingham, “The future of mobile application.”[Online]. Available: http://businessdegrees.uab.edu/resources/infographics/the-future-of-mobile-application/
[4] D. Chaffey, “Mobile marketing statistics compilation,” 2016. [Online]. Avail-able: http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics
[5] Web accessibility initiative (wai). [Online]. Available: https://www.w3.org/WAI/
[6] S. K. Kane, C. Jayant, J. O. Wobbrock, and R. E. Ladner, “Freedom to roam:A study of mobile device adoption and accessibility for people with visual andmotor disabilities,” in Proceedings of the 11th international ACM SIGACCESSconference on Computers and accessibility, 2009, pp. 115–122.
[7] Google Inc. Google play - accessibility scanner. [Online]. Avail-able: https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditor&hl=de
[8] Google Inc.. Android accessibility scanner help. [Online]. Available: https://support.google.com/accessibility/android/faq/6376582
[9] S. Reip, “Accessibility evaluation für mobile android devices,” Bachelor’s Thesis,FH JOANNEUM, Tech. Rep., 2017.
[10] The United Nations, “Convention on the rights of persons with disabilities,”Treaty Series, vol. 2515, p. 3, dec 2006. [Online]. Available: http://www.un.org/disabilities/convention/conventionfull.shtml
96
Chapter 7
[11] WHO, “World report on disability,” World Health Organization, Tech. Rep., 2011.[Online]. Available: http://www.who.int/disabilities/world_report/2011/en/
[12] European Commission, “Web accessibility.” [Online]. Available: http://ec.europa.eu/ipg/standards/accessibility/index_en.htm
[13] European Union, “Directive (eu) 2016/2102 of the european parliament andof the council of 26 october 2016 on the accessibility of the websites andmobile applications of public sector bodies,” October 2016. [Online]. Available:http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016L2102
[14] B. Caldwell, L. G. Reid, M. Cooper, and G. Vanderheiden, “Web content ac-cessibility guidelines (WCAG) 2.0,” W3C, W3C Recommendation, Dec. 2008,http://www.w3.org/TR/2008/REC-WCAG20-20081211/.
[15] I. Pirttimaa, “Why making your apps accessible is just the right thing to do.”[Online]. Available: http://blindsquare.com/2015/05/why-making-your-apps-accessible-is-just-the-right-thing-to-do/
[16] K. Shuster. (2016, April) Accessibility testing on android. [Online]. Available:https://robots.thoughtbot.com/accessibility-testing-on-android
[17] D. Budgen and P. Brereton, “Performing systematic literature reviews in softwareengineering,” in Proceedings of the 28th international conference on Softwareengineering. ACM, 2006, pp. 1051–1052.
[18] M. Shaw, “What makes good research in software engineering?” InternationalJournal on Software Tools for Technology Transfer, vol. 4, no. 1, pp. 1–7, 2002.[Online]. Available: http://dx.doi.org/10.1007/s10009-002-0083-4
[19] M. Shaw, “Writing good software engineering research papers: Minitutorial,”in Proceedings of the 25th International Conference on Software Engineering,ser. ICSE ’03. Washington, DC, USA: IEEE Computer Society, 2003, pp.726–736. [Online]. Available: http://dl.acm.org/citation.cfm?id=776816.776925
[20] E. Krainz, V. Lind, W. Moser, and M. Dornhofer, “Accessible way findingon mobile devices for different user groups,” in Proceedings of the 18thInternational Conference on Human-Computer Interaction with Mobile Devicesand Services Adjunct, ser. MobileHCI ’16. New York, NY, USA: ACM, 2016,pp. 799–806. [Online]. Available: http://doi.acm.org/10.1145/2957265.2961847
[21] E. Krainz, J. Feiner, and M. Fruhmann, Accelerated Development for AccessibleApps – Model Driven Development of Transportation Apps for Visually ImpairedPeople. Cham: Springer International Publishing, 2016, pp. 374–381. [Online].Available: http://dx.doi.org/10.1007/978-3-319-44902-9_25
97
Chapter 7
[22] E. Krainz, W. Bischof, M. Dornhofer, and J. Feiner, Catching the Right Bus -Improvement of Vehicle Communication with Bluetooth Low Energy for VisuallyImpaired and Blind People. Cham: Springer International Publishing, 2016,pp. 9–15. [Online]. Available: https://doi.org/10.1007/978-3-319-41267-2_2
[23] E. Krajnc, M. Knoll, J. Feiner, and M. Traar, “A touch sensitive user interfaceapproach on smartphones for visually impaired and blind persons,” InformationQuality in e-Health, pp. 585–594, 2011.
[24] E. Krajnc, J. Feiner, and S. Schmidt, “User centered interaction design for mobileapplications focused on visually impaired and blind people,” HCI in Work andLearning, Life and Leisure, pp. 195–202, 2010.
[25] E. Mattheiss and E. Krajnc, “Route descriptions in advance and turn-by-turninstructions-usability evaluation of a navigational system for visually impairedand blind people in public transport,” Human Factors in Computing and Infor-matics, pp. 284–295, 2013.
[26] W. Bischof, E. Krajnc, M. Dornhofer, and M. Ulm, “Navcom–wlan communicationwith public transport vehicles to support visually impaired and blind people,” in19th ITS World Congress, 2012.
[27] J. Nielsen, Usability Engineering. San Francisco: Morgan Kaufmann, sep 1993.
[28] ISO, “ISO/DIS 9241-11 ergonomics of human-system interaction – part 11: Us-ability: Definitions and concepts,” International Organization for Standardization,Standard, 2000.
[29] ISO, “ISO/DIS 9241-171: 2008 ergonomics of human-system interaction –part 171: Guidance on software accessibility,” International Organization forStandardization, Standard, 2008. [Online]. Available: http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=39080
[30] F. Puhretmair and K. Miesenberger, “Making sense of accessibility in it design-usable accessibility vs. accessible usability,” in 16th International Workshop onDatabase and Expert Systems Applications (DEXA’05). IEEE, 2005, pp. 861–865.
[31] WHO. Who | international classification of diseases. [Online]. Available:http://www.who.int/classifications/icd/en/
[32] W3C Web Accessibility Initiative (WAI). (2017, May) Diversity of web users.[Online]. Available: https://www.w3.org/WAI/intro/people-use-web/diversity
[33] W3C Web Accessibility Initiative (WAI). (2012, August) Stories of web users.[Online]. Available: https://www.w3.org/WAI/intro/people-use-web/stories
98
Chapter 7
[34] European Commission. European accessibility act. [Online]. Available:http://ec.europa.eu/social/main.jsp?catId=1202
[35] European Council. (2016, 07) http://www.consilium.europa.eu/en/press/press-releases/2016/07/18-accessible-websites-apps-wide-rules/. [Online]. Avail-able: http://www.consilium.europa.eu/en/press/press-releases/2016/07/18-accessible-websites-apps-wide-rules/
[36] Digitales Österreich. Barrierefreies web – internet-zugang für alle. [Online].Available: https://www.digitales.oesterreich.gv.at/barrierefreies-web-zugang-fur-alle
[37] “Bundesgesetz über die gleichstellung von menschen mit behinderun-gen (bundes-behindertengleichstellungsgesetz – bgstg),” 2017. [On-line]. Available: https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20004228&ShowPrintPreview=True
[38] Section-508-of-the-rehabilitation-act. [Online]. Available: https://www.section508.gov/section-508-of-the-rehabilitation-act
[39] US. Americans with disabilities act. [Online]. Available: https://www.ada.gov/cguide.htm#anchor62335
[40] G. Vanderheiden, I. Jacobs, and W. Chisholm, “Web content ac-cessibility guidelines 1.0,” W3C, W3C Recommendation, May 1999,http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[41] ISO/IEC, “Information technology – w3c web content accessibility guidelines(wcag) 2.0,” ISO/IEC, Standard, 2012. [Online]. Available: https://www.iso.org/standard/58625.html
[42] A. Kirkpatrick, M. Cooper, and J. O. Connor, “Web content accessi-bility guidelines (WCAG) 2.1,” W3C, W3C Working Draft, Aug. 2017,https://www.w3.org/TR/2017/WD-WCAG21-20170816/.
[43] C. McCathieNevile and J. Rabin, “Mobile web best practices 1.0,” W3C,W3C Recommendation, Jul. 2008, http://www.w3.org/TR/2008/REC-mobile-bp-20080729/.
[44] A. Chuter and Y. Yesilada, “Relationship between mobile web best practices(MWBP) and web content accessibility guidelines (WCAG),” W3C, W3C Note,Jul. 2009, http://www.w3.org/TR/2009/NOTE-mwbp-wcag-20090709/.
[45] G. Vanderheiden, P. Korn, A. Snow-Weaver, and M. Cooper, “Guidance on ap-plying WCAG 2.0 to non-web information and communications technologies(WCAG2ICT),” W3C, W3C Note, Sep. 2013, http://www.w3.org/TR/2013/NOTE-wcag2ict-20130905/.
99
Chapter 7
[46] W3C, “Mobile accessibility: How wcag 2.0 and other w3c/wai guidelines applyto mobile,” 2015, http://www.w3.org/TR/mobile-accessibility-mapping/.
[47] K. Patch, J. Allan, G. Lowney, and J. F. Spellman, “User agentaccessibility guidelines (UAAG) 2.0,” W3C, W3C Note, Dec. 2015,http://www.w3.org/TR/2015/NOTE-UAAG20-20151215/.
[48] J. Treviranus, J. Richards, and J. F. Spellman, “Authoring tool acces-sibility guidelines (ATAG) 2.0,” W3C, W3C Recommendation, Sep. 2015,http://www.w3.org/TR/2015/REC-ATAG20-20150924/.
[49] K. Patch, J. Spellman, and K. Wahlbin, “Mobile accessibility: How wcag 2.0 andother w3c/wai guidelines apply to mobile,” W3C, Tech. Rep., 2015.
[50] Apple. Accessibility on ios. [Online]. Available: https://developer.apple.com/accessibility/ios/
[51] Apple. (2016) Accessibility programming guide for ios. [Online]. Available:https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html#//apple_ref/doc/uid/TP40008785-CH100-SW1
[52] Microsoft. Accessibility - microsoft - global. [Online]. Available: https://www.microsoft.com/en-ww/mobile/accessibility/
[53] M. D. Center, “Accessibility overview - uwp app developer,” 2017. [Online].Available: https://docs.microsoft.com/en-us/windows/uwp/accessibility/accessibility-overview
[54] Google. Accessibility - usability - material design guidelines. [Online]. Available:https://material.io/guidelines/usability/accessibility.html
[55] Google. Android accessibility overview. [Online]. Available: https://support.google.com/accessibility/android/answer/6006564?hl=en
[56] R. Manduchi and J. Coughlan, “Portable and mobile systems in assistive tech-nology,” in International Conference on Computers for Handicapped Persons.Springer, 2008, pp. 1078–1080.
[57] K. A. Li, P. Baudisch, and K. Hinckley, “Blindsight: eyes-free access to mobilephones,” in Proceedings of the SIGCHI Conference on Human Factors in Com-puting Systems. ACM, 2008, pp. 1389–1398.
[58] D. McGookin, S. Brewster, and W. Jiang, “Investigating touchscreenaccessibility for people with visual impairments,” in Proceedings of the 5thNordic Conference on Human-computer Interaction: Building Bridges, ser.NordiCHI ’08. New York, NY, USA: ACM, 2008, pp. 298–307. [Online].Available: http://doi.acm.org/10.1145/1463160.1463193
100
Chapter 7
[59] A. Rodrigues, K. Montague, H. Nicolau, and T. Guerreiro, “Getting smartphonesto talkback: Understanding the smartphone adoption process of blind users,”in Proceedings of the 17th International ACM SIGACCESS Conferenceon Computers & Accessibility, ser. ASSETS ’15. New York, NY,USA: ACM, 2015, pp. 23–32. [Online]. Available: http://doi.acm.org/10.1145/2700648.2809842
[60] M. Romano, A. Bellucci, and I. Aedo, “Understanding touch and motion gesturesfor blind people on mobile devices,” Human-Computer Interaction–INTERACT2015, pp. 38–46, 2015.
[61] P. Narasimhan, R. Gandhi, and D. Rossi, “Smartphone-based assistive tech-nologies for the blind,” in Proceedings of the 2009 international conference onCompilers, architecture, and synthesis for embedded systems. ACM, 2009, pp.223–232.
[62] J. S. Sierra, J. Selva, R. Togores, and R. S. Tecnológicas, “Designing mobileapps for visually impaired and blind users using touch screen based mobiledevices: iphone/ipad,” 2012.
[63] M. N. Bonner, J. T. Brudvik, G. D. Abowd, and W. K. Edwards, “No-look notes:accessible eyes-free multi-touch text entry,” in International Conference on Per-vasive Computing. Springer, 2010, pp. 409–426.
[64] T. Raman and C. L. Chen, “Eyes-free user interfaces,” Computer, vol. 41, no. 10,2008.
[65] T. Raman and C. L. Chen, “Eyes-free user interaction,” Google Research, Feb,vol. 9, 2009.
[66] Y. Zhong, T. Raman, C. Burkhardt, F. Biadsy, and J. P. Bigham, “Justspeak:enabling universal voice control on android,” in Proceedings of the 11th Web forAll Conference. ACM, 2014, p. 36.
[67] M. Naftali and L. Findlater, “Accessibility in context: understanding the truly mo-bile experience of smartphone users with motor impairments,” in Proceedingsof the 16th international ACM SIGACCESS conference on Computers & acces-sibility. ACM, 2014, pp. 209–216.
[68] Y. Zhong, A. Weber, C. Burkhardt, P. Weaver, and J. P. Bigham, “Enhancingandroid accessibility for users with hand tremor by reducing fine pointing andsteady tapping,” in Proceedings of the 12th Web for All Conference. ACM,2015, p. 29.
[69] M. E. Mott, R.-D. Vatavu, S. K. Kane, and J. O. Wobbrock, “Smart touch: Improv-ing touch accuracy for people with motor impairments with template matching,”
101
Chapter 7
in Proceedings of the 2016 CHI Conference on Human Factors in ComputingSystems. ACM, 2016, pp. 1934–1946.
[70] K. PLAUMANN, M. BABIC, T. DREY, W. HEPTING, and D. STOOSS, “Improvinginput accuracy on smartphones for persons who are affected by tremor usingmotion sensors,” 2017.
[71] S. A. Lesner and M. Klingler, “Apps with amps: Mobile devices, hearing assistivetechnology, and older adults,” The ASHA Leader, vol. 16, no. 12, pp. 14–17,2011.
[72] S. Peer and J. J. Fagan, “Hearing loss in the developing world: evaluating theiphone mobile device as a screening tool,” SAMJ: South African Medical Journal,vol. 105, no. 1, pp. 35–39, 2015.
[73] W. S. Yue and N. A. M. Zin, “Voice recognition and visualization mobile appsgame for training and teaching hearing handicaps children,” Procedia Technol-ogy, vol. 11, pp. 479–486, 2013.
[74] M. Boulares and M. Jemni, “Mobile sign language translation system for deafcommunity,” in Proceedings of the international cross-disciplinary conferenceon web accessibility. ACM, 2012, p. 37.
[75] M. B. Motlhabi, M. Glaser, and W. D. Tucker, “Signsupport: A limited communi-cation domain mobile aid for a deaf patient at the pharmacy,” 2013.
[76] S. A. El-Seoud, I. Taj-Eddin, A. Nosseir, H. El-Sofany, and N. A. Rumman, “Aproposed pedagogical mobile application for learning sign language,” Interna-tional Journal of Interactive Mobile Technologies (iJIM), vol. 7, no. 1, pp. 46–55,2013.
[77] F. Niederl, P. Bußwald, G. Tschare, J. Hackl, and J. Philipp, “Dubbing of videosfor deaf people–a sign language approach,” in International Conference onComputers for Handicapped Persons. Springer, 2012, pp. 225–228.
[78] A. Holzinger, G. Searle, and A. Nischelwitzer, “On some aspects of improvingmobile applications for the elderly,” in International Conference on Universal Ac-cess in Human-Computer Interaction. Springer, 2007, pp. 923–932.
[79] J.-M. Díaz-Bossini and L. Moreno, “Accessibility to mobile interfaces for olderpeople,” Procedia Computer Science, vol. 27, pp. 57–66, 2014.
[80] M. Azuddin, S. A. Malik, L. M. Abdullah, and M. Mahmud, “Older people andtheir use of mobile devices: Issues, purpose and context,” in Information andCommunication Technology for The Muslim World (ICT4M), 2014 The 5th Inter-national Conference on. IEEE, 2014, pp. 1–6.
102
Chapter 7
[81] M. N. K. Boulos, S. Wheeler, C. Tavares, and R. Jones, “How smartphonesare changing the face of mobile and participatory healthcare: an overview, withexample from ecaalyx,” Biomedical engineering online, vol. 10, no. 1, p. 24,2011.
[82] S. J. Parker, S. Jessel, J. E. Richardson, and M. C. Reid, “Older adults aremobile too! identifying the barriers and facilitators to older adults’ use of mhealthfor pain management,” BMC geriatrics, vol. 13, no. 1, p. 43, 2013.
[83] S. A. Malik, L. M. Abdullah, M. Mahmud, and M. Azuddin, “Mobile applicationsusing augmented reality to support older people,” in Research and innovation ininformation systems (ICRIIS), 2013 international conference on. IEEE, 2013,pp. 374–379.
[84] I. Sommerville, “Software engineering. international computer science series,”ed: Addison Wesley, 2004.
[85] M. Völter, T. Stahl, J. Bettin, A. Haase, and S. Helsen, Model-driven software de-velopment: technology, engineering, management. John Wiley & Sons, 2013.
[86] M. Brambilla, J. Cabot, and M. Wimmer, “Model-driven software engineering inpractice,” Synthesis Lectures on Software Engineering, vol. 1, no. 1, pp. 1–182,2012.
[87] A. R. da Silva, “Model-driven engineering: A survey supported by the unifiedconceptual model,” Computer Languages, Systems & Structures, vol. 43, pp.139–155, 2015.
[88] B. Selic, “The pragmatics of model-driven development,” IEEE software, vol. 20,no. 5, p. 19, 2003.
[89] OMG. (2017, March) Meta - modeling and the omg meta object facility (mof).[Online]. Available: http://www.omg.org/ocup-2/documents/Meta-ModelingAndtheMOF.pdf
[90] OMG, “Omg unified modeling language 2.5,” OMG, Tech. Rep., 2015. [Online].Available: http://www.omg.org/spec/UML/2.5/
[91] M. Fowler, Domain-specific languages. Pearson Education, 2010.
[92] D. D. Chamberlin and R. F. Boyce, “Sequel: A structured english query lan-guage,” in Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshopon Data description, access and control. ACM, 1974, pp. 249–264.
[93] Z. Navabi, VHDL: Analysis and modeling of digital systems. McGraw-Hill, Inc.,1997.
103
Chapter 7
[94] S. Ceri, P. Fraternali, and A. Bongio, “Web modeling language (webml): a mod-eling language for designing web sites,” Computer Networks, vol. 33, no. 1, pp.137–157, 2000.
[95] M. Fowler. (2008) Dsl q and a. https://martinfowler.com/bliki/DslQandA.html.
[96] M. Völter, “A catalog of patterns for program generation.” in EuroPLoP, 2003,pp. 285–320.
[97] F. Paterno and C. Santoro, “One model, many interfaces,” in Computer-AidedDesign of User interfaces III. Springer, 2002, pp. 143–154.
[98] F. Paterno, Model-based design and evaluation of interactive applications.Springer Science & Business Media, 2012.
[99] F. Paterno, “Model-based design of interactive applications,” Intelligence,vol. 11, no. 4, pp. 26–38, Dec. 2000. [Online]. Available: http://doi.acm.org/10.1145/355137.358311
[100] G. Calvary, J. Coutaz, L. Bouillon, M. Florins, Q. Limbourg, L. Marucci, F. Pa-ternò, C. Santoro, N. Souchon, D. Thevenin et al., “The cameleon referenceframework, deliverable 1.1, cameleon project,” 2002.
[101] L. Balme, A. Demeure, N. Barralon, J. Coutaz, and G. Calvary, “Cameleon-rt:A software architecture reference model for distributed, migratable, and plasticuser interfaces,” in European Symposium on Ambient Intelligence. Springer,2004, pp. 291–302.
[102] F. Paternò, S. L. Davide, D. Raggett, and C. Santoro, “MBUI - task models,”W3C, W3C Note, Apr. 2014, http://www.w3.org/TR/2014/NOTE-task-models-20140408/.
[103] L. D. S. Fabio Paternò, Carmen Santoro, “Concur task trees (ctt).”
[104] F. Beuvens, J. Melchior, V. G. Motti, N. Mezhoudi, J. Vanderdonckt, andR. Tesoriero, “MBUI - abstract user interface models,” W3C, W3C Note, Apr.2014, http://www.w3.org/TR/2014/NOTE-abstract-ui-20140408/.
[105] M. Abrams, C. Phanouriou, A. L. Batongbacal, S. M. Williams, and J. E. Shus-ter, “Uiml: an appliance-independent xml user interface language,” Computernetworks, vol. 31, no. 11-16, pp. 1695–1708, 1999.
[106] Mozilla.org, “Xul.” [Online]. Available: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
[107] W3C. (2014) Indieui overview. [Online]. Available: https://www.w3.org/WAI/intro/indieui
104
Chapter 7
[108] J. Craig and M. Cooper, “IndieUI: Events 1.0,” W3C, W3C Working Draft, Apr.2015, http://www.w3.org/TR/2015/WD-indie-ui-events-20150430/.
[109] J. Craig and M. Cooper, “IndieUI: User context 1.0,” W3C, W3C Working Draft,Apr. 2015, http://www.w3.org/TR/2015/WD-indie-ui-context-20150430/.
[110] J. Vanderdonckt, Q. Limbourg, B. Michotte, L. Bouillon, D. Trevisan, andM. Florins, “Usixml: a user interface description language for specifying mul-timodal user interfaces,” in Proceedings of W3C Workshop on Multimodal Inter-action WMI, vol. 2004, 2004.
[111] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, and V. López-Jaquero,“Usixml: a language supporting multi-path development of user interfaces,” inInternational Workshop on Design, Specification, and Verification of InteractiveSystems. Springer, 2004, pp. 200–220.
[112] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, and M. Florins, “Usixml:A user interface description language supporting multiple levels of indepen-dence.” in ICWE Workshops, 2004, pp. 325–338.
[113] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, M. Florins, and D. Tre-visan, “Usixml: A user interface description language for context-sensitive userinterfaces,” in Proceedings of the ACM AVI’2004 Workshop" Developing UserInterfaces with XML: Advances on User Interface Description Languages, 2004,pp. 55–62.
[114] S. Berti, F. Correani, F. Paterno, and C. Santoro, “The teresa xml languagefor the description of interactive systems at multiple abstraction levels,” in Pro-ceedings workshop on developing user interfaces with XML: advances on userinterface description languages, 2004, pp. 103–110.
[115] F. Paterno, C. Santoro, and L. D. Spano, “Maria: A universal, declarative, mul-tiple abstraction-level language for service-oriented applications in ubiquitousenvironments,” ACM Transactions on Computer-Human Interaction (TOCHI),vol. 16, no. 4, p. 19, 2009.
[116] M. Brambilla and P. Fraternali, Interaction flow modeling language: Model-drivenUI engineering of web and mobile apps with IFML. Morgan Kaufmann, 2014.
[117] A. Dittmar, A. García Frey, and S. Dupuy-Chessa, “What can model-based uidesign offer to end-user software engineering?” in Proceedings of the 4th ACMSIGCHI symposium on Engineering interactive computing systems. ACm,2012, pp. 189–194.
[118] E. Umuhoza and M. Brambilla, “Model driven development approaches for mo-bile applications: A survey,” in International Conference on Mobile Web andInformation Systems. Springer, 2016, pp. 93–107.
105
Chapter 7
[119] P. Braun and R. Eckhaus, “Experiences on model-driven software developmentfor mobile applications,” in Engineering of Computer Based Systems, 2008.ECBS 2008. 15th Annual IEEE International Conference and Workshop on the.IEEE, 2008, pp. 490–493.
[120] F. T. Balagtas-Fernandez and H. Hussmann, “Model-driven development of mo-bile applications,” in Automated Software Engineering, 2008. ASE 2008. 23rdIEEE/ACM International Conference on. IEEE, 2008, pp. 509–512.
[121] H. Heitkötter, T. A. Majchrzak, and H. Kuchen, “Cross-platform model-drivendevelopment of mobile applications with md2,” in Proc 28th Annual ACM Sympo-sium on Applied Computing, ser. SAC 2013. ACM, 2013, pp. 526–533.
[122] O. Le Goaer and S. Waltham, “Yet another dsl for cross-platforms mobile devel-opment,” in Proceedings of the First Workshop on the globalization of domainspecific languages. ACM, 2013, pp. 28–33.
[123] T. A. Majchrzak and J. Ernsting, “Reengineering an approach to model-drivendevelopment of business apps,” in EuroSymposium on Systems Analysis andDesign. Springer, 2015, pp. 15–31.
[124] A. Ribeiro and A. R. da Silva, “Xis-mobile: A dsl for mobile applications,” inProceedings of the 29th Annual ACM Symposium on Applied Computing. ACM,2014, pp. 1316–1323.
[125] A. Ribeiro and A. R. da Silva, “Evaluation of xis-mobile, a domain specific lan-guage for mobile application development,” Journal of Software Engineering andApplications, vol. 7, no. 11, p. 906, 2014.
[126] A. G. Parada and L. B. de Brisolara, “A model driven approach for android appli-cations development,” in Computing System Engineering (SBESC), 2012 Brazil-ian Symposium on. IEEE, 2012, pp. 192–197.
[127] L. P. da Silva and F. B. e Abreu, “Model-driven gui generation and navigationfor android bis apps,” in Model-Driven Engineering and Software Development(MODELSWARD), 2014 2nd International Conference on. IEEE, 2014, pp.400–407.
[128] M. Brambilla, A. Mauri, and E. Umuhoza, “Extending the interaction flow model-ing language (ifml) for model driven development of mobile applications frontend,” in International Conference on Mobile Web and Information Systems.Springer, 2014, pp. 176–191.
[129] M. Brambilla, A. Mauri, M. Franzago, and H. Muccini, “A model-based methodfor seamless web and mobile experience,” in Proceedings of the 1st InternationalWorkshop on Mobile Development. ACM, 2016, pp. 33–40.
106
Chapter 7
[130] S. Barnett, R. Vasa, and J. Grundy, “Bootstrapping mobile app development,”in Proceedings of the 37th International Conference on Software Engineering -Volume 2, ser. ICSE ’15. Piscataway, NJ, USA: IEEE Press, 2015, pp. 657–660.[Online]. Available: http://dl.acm.org/citation.cfm?id=2819009.2819130
[131] C. Bernaschina, S. Comai, and P. Fraternali, “Online model editing, simulationand code generation for web and mobile applications,” in Proceedings of the 9thInternational Workshop on Modelling in Software Engineering. IEEE Press,2017, pp. 33–39.
[132] S. Vaupel, G. Taentzer, J. P. Harries, R. Stroh, R. Gerlach, and M. Guckert,“Model-driven development of mobile applications allowing role-driven variants,”in International Conference on Model Driven Engineering Languages and Sys-tems. Springer, 2014, pp. 1–17.
[133] S. Vaupel, G. Taentzer, R. Gerlach, and M. Guckert, “Model-driven developmentof mobile applications for android and ios supporting role-based app variability,”Software & Systems Modeling, vol. 17, no. 1, pp. 35–63, 2018.
[134] K. Z. Gajos, J. J. Long, and D. S. Weld, “Automatically generating custom userinterfaces for users with physical disabilities,” in Proceedings of the 8th interna-tional ACM SIGACCESS conference on Computers and accessibility. ACM,2006, pp. 243–244.
[135] K. Miesenberger, P. Heumader, R. Koutny, W. Kurschl, H. Stitz, M. Augstein,M. Vieghofer, D. Hofer, and C. Pointner, “Atlab: An app-framework for physicaldisabilities,” 2014.
[136] M. González-García, L. Moreno, P. Martínez, R. Miñon, and J. Abascal, “Amodel-based graphical editor to design accessible media players.” J. UCS,vol. 19, no. 18, pp. 2656–2676, 2013.
[137] M. González-García, L. Moreno, and P. Martínez, “A model-based tool to de-velop an accessible media player,” in Proc. 17th International ACM SIGACCESSConference on Computers & Accessibility, ser. ASSETS 2015. New York, NY,USA: ACM, 2015, pp. 415–416.
[138] R. Miñón, J. Abascal, A. Aizpurua, I. Cearreta, B. Gamecho, and N. Garay,“Model-based accessible user interface generation in ubiquitous environments,”in IFIP Conference on Human-Computer Interaction. Springer, 2011, pp. 572–575.
[139] M. Peissner, D. Häbe, D. Janssen, and T. Sellner, “Myui: generating accessi-ble user interfaces from multimodal design patterns,” in Proceedings of the 4thACM SIGCHI symposium on Engineering interactive computing systems. ACM,2012, pp. 81–90.
107
Chapter 7
[140] R. Miñón, F. Paternò, M. Arrue, and J. Abascal, “Integrating adaptation rules forpeople with special needs in model-based ui development process,” UniversalAccess in the Information Society, vol. 15, no. 1, pp. 153–168, 2016.
[141] L. Zouhaier and L. J. B. Ayed, “Automatic generation of uis for disabled usersusing context-aware techniques and reasoning.”
[142] L. Zouhaier, Y. B. Hlaoui, and L. J. B. Ayed, “A model driven approach for im-proving the generation of accessible user interfaces,” in Software Technologies(ICSOFT), 2015 10th International Joint Conference on, vol. 2. IEEE, 2015, pp.1–6.
[143] L. Zouhaier, Y. B. Hlaoui, and L. J. B. Ayed, “A mda-based approach for en-abling accessibility adaptation of user interface for disabled people.” in ICEIS(3)), 2014, pp. 120–127.
[144] M. Feld, G. Meixner, A. Mahr, and B. Kalyanasundaram, “A model-based ap-proach to the design and rendering of adaptive automotive user interfaces.” inGI-Jahrestagung, 2013, pp. 2634–2648.
[145] B. Gamecho, R. Minón, A. Aizpurua, I. Cearreta, M. Arrue, N. Garay-Vitoria,and J. Abascal, “Automatic generation of tailored accessible user interfaces forubiquitous services,” IEEE Transactions on Human-Machine Systems, vol. 45,no. 5, pp. 612–623, 2015.
[146] T. Hughes-Croucher. (2014, 3) Accessibility basics. [Online]. Available:https://www.w3.org/wiki/Accessibility_basics#Defining_interaction
[147] C. Banga and J. Weinhold. Five interaction design tips for your mobile app.[Online]. Available: http://www.informit.com/articles/article.aspx?p=2208699
[148] C. Banga and J. Weinhold, Essential mobile interaction design: perfecting inter-face design in mobile apps. Pearson Education, 2014.
[149] Apple. (2013, September) Storyboard. [Online]. Avail-able: https://developer.apple.com/library/content/documentation/General/Conceptual/Devpedia-CocoaApp/Storyboard.html
[150] Android Studio Project Site, “Navigation editor.” [Online]. Available: http://tools.android.com/navigation-editor
[151] M. Fowler, UML distilled: a brief guide to the standard object modeling language.Addison-Wesley Professional, 2004.
[152] D. Pilone, UML 2.0 pocket reference. " O’Reilly Media, Inc.", 2006.
108
Chapter 7
[153] S. W. Ambler. User interface flow diagrams (ui storyboards): An agileintroduction. [Online]. Available: http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm
[154] S. W. Ambler, The object primer: Agile model-driven development with UML 2.0.Cambridge University Press, 2004.
[155] J. Conallen, Building Web applications with UML. Addison-Wesley LongmanPublishing Co., Inc., 2002.
[156] F. A. Kraemer, “Engineering android applications based on uml activities,” in In-ternational Conference on Model Driven Engineering Languages and Systems.Springer, 2011, pp. 183–197.
[157] O. Le Goaer, F. Barbier, E. Cariou, and S. Pierre, “Android executable modeling:Beyond android programming,” in Future Internet of Things and Cloud (FiCloud),2014 International Conference on. IEEE, 2014, pp. 411–414.
[158] A. Sabraoui, M. El Koutbi, and I. Khriss, “Gui code generation for android appli-cations using a mda approach,” in Complex Systems (ICCS), 2012 InternationalConference on. IEEE, 2012, pp. 1–6.
[159] A. King, P. Blenkhorn, D. Crombie, S. Dijkstra, G. Evans, and J. Wood, “Present-ing uml software engineering diagrams to blind people,” in International Confer-ence on Computers for Handicapped Persons. Springer, 2004, pp. 522–529.
[160] K. Müller, “How to make unified modeling language diagrams accessible for blindstudents,” Computers Helping People with Special Needs, pp. 186–190, 2012.
[161] F. D. N. Grillo and R. P. de Mattos Fortes, “Tests with blind programmers usingawmo: an accessible web modeling tool,” in International Conference on Univer-sal Access in Human-Computer Interaction. Springer, 2014, pp. 104–113.
[162] F. D. N. Grillo and R. P. de Mattos Fortes, “Accessible modeling on the web: acase study,” Procedia Computer Science, vol. 27, pp. 460–470, 2014.
[163] V. Petrausch, S. Seifermann, and K. Müller, “Guidelines for accessible textualuml modeling notations,” in International Conference on Computers HelpingPeople with Special Needs. Springer, 2016, pp. 67–74.
[164] T. Gjøsæter, J. Nytun, A. Prinz, M. Snaprud, and M. Tveit, “Modelling acces-sibility constraints,” Computers Helping People with Special Needs, pp. 40–47,2006.
[165] T. Gjøsæter, J. P. Nytun, A. Prinz, and M. S. Tveit, “Accessibility testing xhtmldocuments using uml,” in The 3rd Nordic Workshop on UML and Software Mod-eling, 2005, p. 108.
109
Chapter 7
[166] M. Fowler. (2008) Parserfear. http://martinfowler.com/bliki/ParserFear.html.
[167] M. Sperberg-McQueen, F. Yergeau, T. Bray, J. Paoli, and E. Maler, “Extensiblemarkup language (XML) 1.0 (fifth edition),” W3C, W3C Recommendation, Nov.2008, http://www.w3.org/TR/2008/REC-xml-20081126/.
[168] M. Maloney, D. Beech, S. Gao, M. Sperberg-McQueen, H. Thomp-son, and N. Mendelsohn, “W3C xml schema definition language (XSD)1.1 part 1: Structures,” W3C, W3C Recommendation, Apr. 2012,http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/.
[169] P. V. Biron, M. Sperberg-McQueen, H. Thompson, D. Peterson,S. Gao, and A. Malhotra, “W3C xml schema definition language (XSD)1.1 part 2: Datatypes,” W3C, W3C Recommendation, Apr. 2012,http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/.
[170] Android Open Source Project, “The android source code.” [Online]. Available:https://source.android.com/source/
[171] Android, “Platform architecture.” [Online]. Available: https://developer.android.com/guide/platform/index.html
[172] Android, “Introduction to android.” [Online]. Available: https://developer.android.com/guide/index.html
[173] ——, “The build process.” [Online]. Available: https://developer.android.com/studio/build/index.html
[174] E. Ort and B. Mehta, “Java architecture for xml binding (JAXB),” Sun DeveloperNetwork, Mar 2003. [Online]. Available: http://www.oracle.com/technetwork/articles/javase/index-140168.html
[175] FreeMarker, “What is apache freemarker?” [Online]. Available: http://freemarker.org/index.html
[176] Android, “Making apps more accessible.” [Online]. Available: https://developer.android.com/guide/topics/ui/accessibility/apps.html
[177] Android. Accessibility testing checklist. [Online]. Available: https://developer.android.com/training/accessibility/testing.html
[178] T. Drake. (2015, October) Android accessibility - the missing manual. [Online].Available: http://www.last-child.com/android-a11y-missing-manual/
[179] G. Developers, “Basic android accessibility : making sure everyone can usewhat you create!” [Online]. Available: https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html?index=..%2F..%2Findex#0
110
Chapter 7
[180] L. C. Serra, L. P. Carvalho, L. P. Ferreira, J. B. S. Vaz, and A. P. Freire, “Ac-cessibility evaluation of e-government mobile applications in brazil,” ProcediaComputer Science, vol. 67, pp. 348–357, 2015.
[181] S. Chiti and B. Leporini, “Accessibility of android-based mobile devices: a pro-totype to investigate interaction with blind users,” in International Conference onComputers for Handicapped Persons. Springer, 2012, pp. 607–614.
[182] A. S. Shaik, G. Hossain, and M. Yeasin, “Design, development and performanceevaluation of reconfigured mobile android phone for people who are blind orvisually impaired,” in Proceedings of the 28th ACM International Conference onDesign of Communication. ACM, 2010, pp. 159–166.
[183] S. G. Hart and L. E. Staveland, “Development of nasa-tlx (task load index): Re-sults of empirical and theoretical research,” Advances in psychology, vol. 52, pp.139–183, 1988.
[184] J. Brooke, “Sus-a quick and dirty usability scale,” Usability evaluation in industry,vol. 189, no. 194, pp. 4–7, 1996.
[185] S. L. Henry. (2015, October) Accessibility testing with android talkback.[Online]. Available: https://developer.paciellogroup.com/blog/2015/10/accessibility-testing-with-android-talkback/
[186] A. Diwan. (2017, February) Android app accessibility checklist. [Online].Available: https://www.sitepoint.com/android-app-accessibility-checklist/
[187] Google Inc. Testing your app’s accessibility. [Online]. Available: https://developer.android.com/training/accessibility/testing.html
[188] R. Rutter, P. H. Lauke, C. Waddell, J. Thatcher, S. L. Henry, B. Lawson, A. Kirk-patrick, C. Heilmann, M. R. Burks, B. Regan et al., Web accessibility: Webstandards and regulatory compliance. Apress, 2007.
[189] W3C. Web accessibility laws and policies. [Online]. Available: https://www.w3.org/WAI/Policy/
[190] P. J. Adam, “Mobile accessibility qa testing checklist.” [Online]. Available:http://pauljadam.com/demos/mobilechecklist.html
[191] J. Nielsen, “Guerrilla hci: Using discount usability engineering to penetrate theintimidation barrier,” Cost-justifying usability, pp. 245–272, 1994.
[192] S. L. Henry. (2013, jun) Easy checks – a first review of web accessibility.https://www.w3.org/WAI/eval/preliminary.html. Retrieved 2013-06. [Online].Available: https://www.w3.org/WAI/eval/preliminary.html
111
Chapter
[193] T. Grill, O. Polacek, and M. Tscheligi, “Methods towards api usability: A struc-tural analysis of usability problem categories,” Human-Centered Software Engi-neering, pp. 164–180, 2012.
[194] M. Piccioni, C. A. Furia, and B. Meyer, “An empirical study of api usability,” in Em-pirical Software Engineering and Measurement, 2013 ACM/IEEE InternationalSymposium on. IEEE, 2013, pp. 5–14.
[195] J. Stylos, B. Graf, D. K. Busse, C. Ziegler, R. Ehret, and J. Karstens, “A casestudy of api redesign for improved usability,” in Visual Languages and Human-Centric Computing, 2008. VL/HCC 2008. IEEE Symposium on. IEEE, 2008,pp. 189–192.
[196] B. Ellis, J. Stylos, and B. Myers, “The factory pattern in api design: A usabilityevaluation,” in Proceedings of the 29th international conference on SoftwareEngineering. IEEE Computer Society, 2007, pp. 302–312.
[197] G. Salvaneschi, S. Proksch, S. Amann, S. Nadi, and M. Mezini, “On the positiveeffect of reactive programming on software comprehension: An empirical study,”IEEE Transactions on Software Engineering, 2017.
[198] Y. Acar, M. Backes, S. Fahl, S. Garfinkel, D. Kim, M. L. Mazurek, and C. Stransky,“Comparing the usability of cryptographic apis,” in Proceedings of the 38th IEEESymposium on Security and Privacy, 2017.
[199] U. Kuckartz, S. Rädiker, T. Ebert, and J. Schehl, Statistik: eine verständlicheEinführung. Springer-Verlag, 2013.
[200] S. S. Shapiro and M. B. Wilk, “An analysis of variance test for normality (com-plete samples),” Biometrika, vol. 52, no. 3/4, pp. 591–611, 1965.
[201] H. B. Mann and D. R. Whitney, “On a test of whether one of two random variablesis stochastically larger than the other,” The annals of mathematical statistics, pp.50–60, 1947.
112
Appendix A
Accapto Model
A.1 XSD Schema Definition of the Accapto Model
This XSD file is the base for the Java class generation with JAXB.
<?xml version="1.0"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified" targetNamespace="org.accapto"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="org.accapto">
<xs:element name="app" type="appType" />
<xs:complexType name="screenType" mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element type="actionType" name="action" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="transition" type="transitionType"
minOccurs="0" maxOccurs="unbounded" />
<xs:element name="input" type="inputType" minOccurs="0"
maxOccurs="unbounded">
</xs:element>
<xs:element name="output" type="outputType" minOccurs="0"
maxOccurs="unbounded">
</xs:element>
<xs:element name="subscreen" type="screenType" minOccurs="0"
maxOccurs="unbounded"></xs:element>
</xs:sequence>
<xs:attribute type="xs:string" name="name" use="required" />
<xs:attribute type="xs:string" name="description" use="optional" />
</xs:complexType>
<xs:complexType name="inputType">
<xs:attribute type="xs:string" name="type" />
<xs:attribute type="xs:string" name="name" use="required" />
113
Chapter A
<xs:attribute type="xs:string" name="description" use="optional" />
</xs:complexType>
<xs:complexType name="outputType">
<xs:attribute type="xs:string" name="type" />
<xs:attribute type="xs:string" name="name" use="required" />
<xs:attribute type="xs:string" name="description" use="optional" />
</xs:complexType>
<xs:complexType name="actionType">
<xs:attribute type="xs:string" name="function" use="required" />
<xs:attribute type="xs:string" name="name" use="required" />
<xs:attribute type="xs:string" name="description" use="optional" />
</xs:complexType>
<xs:complexType name="appType">
<xs:sequence minOccurs="1">
<xs:element name="profile" type="profileType" minOccurs="1"
maxOccurs="5"></xs:element>
<xs:element type="screenType" name="screen" maxOccurs="unbounded"
minOccurs="0" />
</xs:sequence>
<xs:attribute type="xs:string" name="appname" />
<xs:attribute type="xs:string" name="package" use="required"/>
</xs:complexType>
<xs:complexType name="transitionType">
<xs:attribute name="target" type="xs:string" use="required"></xs:attribute>
<xs:attribute name="name" type="xs:string" use="required"></xs:attribute>
<xs:attribute name="description" type="xs:string" use="optional"></xs:attribute>
</xs:complexType>
<xs:simpleType name="profileType">
<xs:restriction base="xs:string">
<xs:enumeration value="no restrictions" />
<xs:enumeration value="high contrast" />
<xs:enumeration value="blind" />
<xs:enumeration value="easy read" />
<xs:enumeration value="easy touch" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
Listing A.1: XSD of the Accapto model
114
Chapter A
A.2 Model of Routing app in XML
The following listings shows the model of the example routing app described in Chap-ter 5.
<p:app appname="RoutingAppDemo" package="org.accapto.routingapp"
xmlns:p="org.accapto" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="org.accapto accapto_model.xsd">
<p:profile>normal</p:profile>
<p:screen name="Start">
<p:output name="Routing App Demo" description="routing app" type="text" />
<p:transition name="Start" description="select routing target"
target="RoutingTarget" />
<p:transition name="Settings" description="modify app settings"
target="Settings" />
</p:screen>
<p:screen name="RoutingTarget">
<p:output name="Routing Target" description="form for routing target input"
type="text" />
<p:input name="search target" description="enter a routing target"
type="text"/>
<p:action function="calculateRoute" name="calculate Route"
description="calculate Route" />
<p:transition name="route Overview" description="show Route overview"
target="RoutingOverview" />
<p:input name="use GPS" description="use GPS for routing" type="checkbox" />
</p:screen>
<p:screen name="RoutingOverview">
<p:output name="Routing Overview" description="Routing Overview"
type="text" />
<p:output name="Overview " description="description of the calucaled route"
type="text" />
<p:action function="startRouting" name="start routing"
description="start Routing" />
<p:transition name="new Route" description="select new routing target"
target="RoutingTarget" />
</p:screen>
<p:screen name="RoutingDetails">
<p:output name="Routing Details" description="Routing Details"
type="text" />
<p:output name="Direction" description="moving direction"
type="text" />
<p:output name="directionsymbol" description="moving direction"
type="image" />
</p:screen>
115
Chapter A
<p:screen name="Settings">
<p:output name="Settings" description="app settings" type="text"/>
</p:screen>
</p:app>
Listing A.2: Model of the example routing app.
116
Appendix B
Data Usertesting
The improved prototype of the routing app was tested with four different user groups.
Kognitive beeinträchtige Rollstuhlfahrer Linz 08.04.16Aufgrund der Beieinträchtigung Auswahl zwischen 1-7
männlich (25-34 Jahre), Lese-, Schreib,- Sprechschwierigkeitensehr viel Erfahrung mit Smartphones und Android, verlässt nie ohne Begleitung das Haus, kann das App nur mit Unterstützung der Begleitperson bedienenTLX Style ändern Linie folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 5 100 1 0 1körperl. A. 100 5 2 4zeitl. A. 5 100 3 4 Anzahl der benötigten Tipps:Ausführung 5 75 4 0 7Anstrengung 50 60 5 2Frustration 50 5 6 4Total 215 345 7 4Normalisiert 35,83 57,5 8 4
9 210 1
Summe 25SUS-Score 62,5
männlich (25-34 Jahre), Schreibschwierigkeitensehr viel Erfahrung mit Smartphones und etwas mit Android, verlässt mehrmals täglich ohne Begleitung das HausTLX Style ändern Linie folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 45 60 1 4 6körperl. A. 30 30 2 4zeitl. A. 5 5 3 2 Anzahl der benötigten Tipps:Ausführung 5 5 4 4 2Anstrengung 40 30 5 4Frustration 5 5 6 4Total 130 135 7 4Normalisiert 21,67 22,5 8 4
9 410 4
Summe 38SUS-Score 95
Figure B.1: User tests with persons with motor and cognitive disabilities
117
Chapter B
Altere Menschen Salzburg 21.04.16
weiblich (55-65), leichte visuelle Beeinträchtigung, die im Alter entwickelt wurdeetwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 5 5 5 1 0 1körperl. A. 5 5 5 2 4zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps:Ausführung 65 70 70 4 2 5Anstrengung 5 5 5 5 4Frustration 5 5 5 6 4Total 90 95 95 7 4Normalisiert 15 15,83 15,83 8 4
9 410 4
Summe 34SUS-Score 85
weiblich (über 65), leichte visuelle Beeinträchtigung, die im Alter entwickelt wurdeetwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 5 5 5 1 4 1körperl. A. 5 5 5 2 4zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps:Ausführung 5 50 30 4 0 4Anstrengung 5 10 15 5 3Frustration 5 5 5 6 3Total 30 80 65 7 4Normalisiert 5 13,33 10,83 8 4
9 310 4
Summe 33SUS-Score 82,5
weiblich (über 65), Alterserscheinungen die ab ca 70 entwickelt wurdenetwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 5 5 5 1 4 3körperl. A. 5 5 5 2 4zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps:Ausführung 15 15 15 4 4 4Anstrengung 5 5 15 5 3Frustration 5 5 5 6 4Total 40 40 50 7 4Normalisiert 6,67 6,67 8,33 8 4
9 310 4
Summe 38SUS-Score 95
weiblich (55-65), leichte visuelle Beeinträchtigung, die im Alter entwickelt wurdeetwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 5 45 25 1 3 2körperl. A. 5 5 15 2 4zeitl. A. 5 5 25 3 4 Anzahl der benötigten Tipps:Ausführung 45 50 50 4 4 0Anstrengung 5 5 10 5 2Frustration 5 5 10 6 4Total 70 115 135 7 4Normalisiert 11,67 19,17 22,50 8 4
9 310 4
Summe 36SUS-Score 90
männlich (über 65), Alterserscheinungen die ab ca 60 entwickelt wurdensehr viel Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 40 35 50 1 1 2körperl. A. 15 25 20 2 3zeitl. A. 20 25 35 3 2 Anzahl der benötigten Tipps:Ausführung 50 50 50 4 2 0Anstrengung 20 25 30 5 2Frustration 40 20 30 6 1Total 185 180 215 7 1Normalisiert 30,83 30,00 35,83 8 2
9 110 3
Summe 18SUS-Score 45
Figure B.2: User tests with elderly people
118
Chapter B
Blinde Menschen Wien 22.04.16
männlich (55-65), Blindheit mit 0,5% Restsehfähigkeit, im Alter von 2 Jahren entwickeltsehr viel Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 50 40 1 2 7körperl. A. 5 15 2 4zeitl. A. 55 15 3 3 Anzahl der benötigten Tipps:Ausführung 25 30 4 4 2Anstrengung 5 5 5 2Frustration 5 5 6 2Total 145 110 7 4Normalisiert 24,17 18,33 8 4
9 410 4
Summe 33SUS-Score 82,5
männlich (55-65), Blindheit mit Restsehfähigkeit, im Alter von 40 Jahren entwickeltsehr viel Erfahrung mit Smartphones und gar keine mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 100 5 1 2 8körperl. A. 5 5 2 2zeitl. A. 5 5 3 3 Anzahl der benötigten Tipps:Ausführung 75 70 4 4 ständige Unterstützung (iOS-Nutzer)Anstrengung 5 5 5 0 TalkBack Unkenntnisse schuldFrustration 5 5 6 2Total 195 95 7 0 für Blinde, wegen TalkBackNormalisiert 32,50 15,83 8 4
9 4das Ändern der Stylse wurde als sinnlos angesehen 10 2
Summe 23SUS-Score 57,5
männlich (35-44), Blindheit mit 20% Restsehfähigkeit, seit 2007 entwickeltsehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 25 50 1 3 9körperl. A. 25 25 2 4zeitl. A. 50 75 3 4 Anzahl der benötigten Tipps:Ausführung 100 50 4 4 ständige Unterstützung (iOS-Nutzer)Anstrengung 50 25 5 2Frustration 25 5 6 4Total 275 230 7 2Normalisiert 45,83 38,33 8 2
9 310 3
Summe 31SUS-Score 77,5
Figure B.3: User tests with visually impaired people
119
Chapter B
Personen ohne Beeinträchtigung Kapfenberg 26.04.16
männlich (25-34), keine Beeinträchtigungensehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 10 30 25 1 3 2körperl. A. 10 30 15 2 3zeitl. A. 5 20 20 3 3 Anzahl der benötigten Tipps:Ausführung 25 15 15 4 4 0Anstrengung 10 10 10 5 2Frustration 5 5 10 6 3Total 65 110 95 7 3Normalisiert 10,83 18,33 15,83 8 4
9 310 4
Summe 32SUS-Score 80
männlich (unter 25), keine Beeinträchtigungensehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegenTLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge:geistige A. 15 5 10 1 2 0körperl. A. 25 5 5 2 4zeitl. A. 5 5 5 3 3 Anzahl der benötigten Tipps:Ausführung 10 5 5 4 4 0Anstrengung 5 5 5 5 3Frustration 10 5 5 6 4Total 70 30 35 7 4Normalisiert 11,67 5 5,83 8 4
9 410 4
Summe 36SUS-Score 90
Figure B.4: User tests with persons without restrictions
120
Appendix C
Details from the EmpiricEvaluation
C.1 Evaluation Instruction
The survey serves to compare two different development approaches for Androidapps. For this purpose, four steps were necessary in this study (time 1 - 2h).
The process worked like this:
1. Pre-survey (see Questionary)
2. Development: Implement an Android app prototype using one of the two meth-ods.
Method A - Build an Android Studio project in the usual way. Method B - Cre-ate an app prototype with Accapto (Model-Driven Development). Assignment tomethod A or B by the Elmar Krainz
3. Evaluation of the created prototype
4. Follow-up questions (see Questionary)
The complete instructions and tools can be found at https://github.com/elmarkrainz/accapto/tree/master/evaluation.
C.2 Questionary
The questionaries were done with before and after implementing an app prototypewith two different development methods.
121
Chapter C
C.2.1 Pre-Questionary
The participants were asked about their personal data, their development skills andabout usability in app development with an online questionary (https://docs.google.com/forms/d/e/1FAIpQLSfhkozWEBS-AR7vYv-8s3rolItkVQs-Bx548q-A
C6ZZfzGtVA/viewform)
TeilnehmerInnen Nr. *
TeilnehmerInnen Name (opt.)
AlterGeschlecht weiblich maennlich keine Angabe
o o o
Genutzte Mobile PlatformAndroid iOS andere
Eigene Verwendung o o oEntwicklung o o o
Hoechste AusbildungMatura Bachelor Master andereo o o o
IT AusbildungkeineIT Ausbildung
auto-ditaktisch
HTL FH Universitaet
o o o o o
IT Kenntnissesehr gut 6 5 4 3 2 1 0 keine
Allgemeine Programmierkenntnisse o o o o o o o oKenntnisse zu mobiler App Entwicklung o o o o o o o oKenntnisse zu Android Entwicklung o o o o o o o oKenntnisse zu Model-Driven Development o o o o o o o oKenntnisse zu User Interfaces Design o o o o o o o oKenntnisse zu User Interface Umsetzung o o o o o o o oKenntnisse zu Usability/UX o o o o o o o oKenntnisse zu Barrierefreiheit o o o o o o o o
Usability Kenntnissesehr gut 6 5 4 3 2 1 0 keine
Usability Heuristiken o o o o o o o oUser Interfaces Design Prinzipien o o o o o o o oAndroid Material Design Guidelines o o o o o o o oW3C Standards zu Accessibility o o o o o o o oRechtliche Bestimmungen zu Barrierefreiheit o o o o o o o o
122
Chapter C
Usabilty in App Development
wichtigeher
wichtigneutral
eherunwichtig
unwichtig
Zufriedenstellende User Experience o o o o oEinfaches Bedienungskonzept o o o o oBeschriftung von Bedienungselementen o o o o oGraphische Darstellung von Funktionen o o o o oBeschreibung von Bedienungselementen o o o o oNeue Interaktionsformen (z.b Swipe) o o o o oPhysische Erreichbarkeitvon Bedienungselementen o o o o oSchriftliche Bedienungsanleitung o o o o oAufzeichnen von Benutzerdaten o o o o oAlternative Darstellungsmoeglichkeiten(z.b. Farbschema)
o o o o o
C.2.2 Accessibility Test
The participants entered their accessibility evaluation results in an online form (https://docs.google.com/forms/d/e/1FAIpQLScz64xFbaaEqXcPuA_bMj9jOtNn
h00qezvaj_sE2TrSJK2xAg/viewform).
TeilnehmerInnen Nr. (wird von Testleiter vergeben)
TeilnehmerInnen Name (wird anonymisiert)
Development Methode
Getestet auf folgendem Device (virtuelles Device, Model, Android Version, ...)
AT - Assitive Tech.Sehr gut gut neutral weniger gut nicht gut keine Angabe
Screenreader o o o o o oTabbing o o o o o oAssitive Technologies Android o o o o o oAnmerkungFehler Accessibility Scanner
Anzahl der FehlerTouchsizeBildkontrastTextkontrastfehlendes Beschreibungsfelddoppeltes BeschreibungsfeldFehler in der ImplementierungAnmerkungManuelle Checks
Sehr gut gut neutral weniger gut nicht gut keine AngabeKlare und einfache Texte o o o o o oKlare Navigation o o o o o oPassende Schriftgroesse o o o o o oVergroesserung mˆglich o o o o o oPosition der Bedienungselemente o o o o o oAnmerkung
123
Chapter C
C.2.3 Post - Questionary
The participants were asked about their workload, about their own impressions ofthe tasks (see online questionary (https://docs.google.com/forms/d/e/1FAIpQLSdBfKAQvDvqsVFnFbk-cruydMjPgcRO3qNwGxE1ySbTOThtNA/viewform).
TeilnehmerInnen Nr. *
TeilnehmerInnen Name (opt.)
Workload App Developmentnieder 1 2 3 4 5 6 7 8 9 10 hoch
Geistige Anforderung o o o o o o o o o oKoerperliche Anforderung o o o o o o o o o oZeitliche Anforderung o o o o o o o o o oLeistung o o o o o o o o o oAnstrengung o o o o o o o o o oFrustration o o o o o o o o o o
Workload Accessibility Checknieder 1 2 3 4 5 6 7 8 9 10 hoch
Geistige Anforderung o o o o o o o o o oKoerperliche Anforderung o o o o o o o o o oZeitliche Anforderung o o o o o o o o o oLeistung o o o o o o o o o oAnstrengung o o o o o o o o o oFrustration o o o o o o o o o o
Wie schaetzen Sie die Usability der entstandenen App ein?nieder 1 2 3 4 5 6 7 8 9 10 hoch
o o o o o o o o o o
Wie schaetzen Sie die Barrierefreiheit der entstandenen App ein?nieder 1 2 3 4 5 6 7 8 9 10 hoch
o o o o o o o o o o
124
Chapter C
Usabilty in App Development
wichtigeher
wichtigneutral
eherunwichtig
unwichtig
Zufriedenstellende User Experience o o o o oEinfaches Bedienungskonzept o o o o oBeschriftung von Bedienungselementen o o o o oGraphische Darstellung von Funktionen o o o o oBeschreibung von Bedienungselementen o o o o oNeue Interaktionsformen (z.b Swipe) o o o o oPhysische Erreichbarkeitvon Bedienungselementen o o o o oSchriftliche Bedienungsanleitung o o o o oAufzeichnen von Benutzerdaten o o o o oAlternative Darstellungsmoeglichkeiten(z.b. Farbschema)
o o o o o
Was hat ihnen am Entwicklungsprozess gefallen oder nicht gefallen?
Was hat ihnen an der Accessibity Bewertung gefallen oder nicht gefallen? Bewertung
Persoenliche Anmerkungen
125
Chapter C
C.2.4 Data from Participants
The participants were asked about their personal data (age, gender, education), theirIT skills and about their knowhow in usability.
IT Kenntnisse Usability Skills
Teiln
ehm
erIn
nen
Nr.
Alte
r
Ges
chle
cht
Gen
utzt
e M
obile
Pla
tfor
m
Pla
tfor
m E
ntw
ickl
ung
Höch
ste
Ausb
ildun
g
IT A
usbi
ldun
g
IT S
KILL
S
Allg
. Pro
gram
mie
rken
ntni
sse
zu m
obile
r App
Ent
wic
klun
g
zu A
ndro
id E
ntw
ickl
ung
zu M
odel
-Driv
en D
evel
opm
ent
Use
r Int
erfa
ces
Desi
gn
Use
r Int
erfa
ce U
mse
tzun
g
Usa
bilit
y/U
X
Kenn
tnis
se z
u Ba
rrie
refr
eihe
it
Usa
b Sk
ills
Usa
bilit
y He
uris
tiken
Use
r Int
erfa
ces
Desi
gn P
rinzi
pien
Andr
oid
Mat
eria
l Des
ign
Gui
delin
es
W3C
Sta
ndar
ds z
u Ac
cess
ibili
ty
Rech
tlich
ea z
u Ba
rrie
refr
eihe
it
101 Developer 23 m Android Android BSc FH 32 6 4 4 3 4 3 4 4 16 4 4 2 3 3102 Developer 27 m Android Android BSc FH 40 6 4 4 4 5 5 6 6 26 6 5 4 6 5103 Developer 23 w Android Android BSc FH 21 4 3 4 2 3 3 2 0 8 1 2 3 2 0104 Developer 23 m Android;iOS Android BSc FH 28 6 4 4 1 4 3 4 2 9 3 3 2 1 0105 Developer 32 m Android Android BSc FH 35 6 5 5 4 4 4 4 3 18 5 5 3 3 2106 Developer 24 m iOS Android BSc FH 20 6 3 4 2 1 3 1 0 3 1 2 0 0 0107 Developer 28 m Android Android BSc FH 26 5 3 3 4 4 2 4 1 8 2 3 2 1 0108 Developer 21 m iOS iOS BSc FH 27 5 2 2 4 3 5 3 3 6 3 2 0 1 0109 Developer 25 m Android;andereAndroid BSc FH 32 5 3 5 5 3 4 4 3 13 4 4 2 3 0110 Developer 35 m Android Android BSc FH 27 5 4 4 4 3 3 2 2 16 3 4 3 3 3111 Developer 28 m Android Android BSc FH 36 6 4 4 6 4 4 4 4 21 5 5 4 5 2112 Developer 25 m Android;iOS BSc FH 21 5 0 0 0 4 4 4 4 10 3 4 1 1 1113 Developer 58 m MSc FH 12 3 2 2 1 1 1 1 1 1 0 0 1 0 0114 Developer 46 w iOS Android BSc FH 6 1 0 0 0 1 1 2 1 2 0 1 0 0 1115 Developer 27 m Android Android BSc UNI 31 5 5 5 3 4 3 4 2 11 1 4 4 1 1116 Developer 24 m Android Android;andereBSc FH 31 4 3 3 4 4 3 5 5 28 6 5 6 6 5117 Developer 23 m Android Android Matura HTL 33 5 5 5 2 4 4 4 4 9 2 3 2 1 1118 Developer 25 m Android;iOS Android BSc HTL 39 5 4 3 5 6 6 6 4 24 6 6 5 4 3119 Developer 26 m iOS Matura FH 20 3 2 2 3 2 2 3 3 11 3 2 2 3 1120 Developer 24 m Android;iOS Android BSc F 28 6 4 4 2 3 4 3 2 8 0 2 2 2 2201 Student 22 m Android Android Matura FH 30 4 3 3 2 5 4 5 4 23 5 5 5 5 3202 Student 22 m Android Android Matura - 30 4 4 3 3 4 4 4 4 18 4 4 3 4 3203 Student 22 m Android Android Matura HTL 21 6 5 4 3 2 1 0 0 3 0 0 0 2 1204 Student 21 m iOS iOS Matura FH 35 6 4 4 3 4 5 5 4 25 5 6 4 6 4205 Student 25 m iOS Android Matura FH 31 4 3 3 3 5 4 5 4 14 4 4 0 4 2206 Student 23 m Android Android Matura HTL 17 4 2 3 1 2 2 2 1 10 3 2 2 2 1207 Student 22 m Android Android Matura HTL 20 6 4 4 0 2 4 0 0 6 1 1 3 1 0208 Student 24 w Android Android Matura - 24 3 2 2 1 4 3 5 4 15 3 3 1 4 4209 Student 22 w iOS Android Matura FH 26 3 2 1 2 5 3 5 5 19 5 4 4 3 3210 Student 22 w iOS Android Matura FH 27 3 2 1 2 5 4 5 5 18 4 5 2 3 4211 Student 25 m iOS Android Matura FH 12 2 3 3 1 1 2 0 0 9 2 2 2 3 0212 Student 21 m Android Android Matura HTL 34 5 4 4 4 5 4 4 4 17 4 4 3 3 3213 Student 22 m Android;iOS Android Matura FH 29 5 2 2 1 5 3 6 5 22 6 5 2 5 4214 Student 22 m Android Android Matura HTL 18 4 2 2 0 3 3 3 1 3 0 1 0 2 0215 Student 24 m Android Android Matura - 24 6 6 6 6 0 0 0 0 0 0 0 0 0 0216 Student 24 m Android Android Matura HTL 16 3 1 1 2 2 2 3 2 10 3 3 1 2 1217 Student 22 m Android;andereAndroid Matura FH 34 5 4 4 3 4 4 5 5 25 5 5 6 5 4218 Student 22 m Android Android Matura FH 35 4 4 4 5 4 6 3 5 21 5 4 4 4 4301 Senior Developer47 m iOS Android;iOS MSc UNI 35 5 5 4 3 4 5 5 4 17 5 5 3 4 0303 Senior Developer43 m iOS Android;iOS MSc UNI 32 5 4 4 4 4 5 3 3 16 2 5 3 4 2304 Senior Developer32 m Android;iOS;andereAndroid MSc FH 29 6 4 4 4 3 3 3 2 14 3 4 3 2 2305 Senior Developer27 m Android Android BSc FH 29 4 4 4 3 4 3 4 3 14 3 4 4 3 0306 Senior Developer27 m Android Android;iOS BSc FH 28 4 3 3 4 4 4 4 2 11 2 4 2 3 0307 Senior Developer22 w iOS Android;iOS BSc FH 31 5 5 5 2 1 3 5 5 14 3 3 3 4 1309 Senior Developer24 m Android Android BSc FH 32 5 5 5 2 4 4 4 3 16 3 4 3 3 3310 Senior Developer48 m Android Android;iOS BSc FH 34 6 4 4 3 5 5 4 3 16 4 4 3 3 2311 Senior Developer28 m iOS iOS BSc UNI 33 5 5 2 4 5 5 4 3 16 3 5 2 3 3312 Senior Developer29 m Android BSc UNI 40 6 4 5 3 5 5 6 6 23 4 6 1 6 6313 Senior Developer27 m Android Android MSc FH 34 6 6 6 5 3 4 2 2 7 1 0 4 2 0314 Senior Developer24 w Android andere BSc FH 31 6 4 3 5 4 3 3 3 6 1 1 0 2 2
Figure C.1: Participants of the empiric evaluation.
126
Chapter C
C.2.5 Data A11y Evaluation
Data from the accessibility evaluation of the two test groups.AT
- As
sitiv
e Te
ch.Fe
hler
Acc
essi
bilit
y Sc
anne
rM
anue
lle C
heck
s
#
TeilnehmerInnen Nr.
Development Methode
Getestet auf folgendem Device
A11Y Rating
Rating_AssistiveTech
ErrorsA11yScanner
Rating_Manual_Checks
Screenreader
Tabbing
Assitive Technologies Android
Touchsize
Bildkontrast
Textkontrast
fehlendes Beschreibungsfeld
doppeltes Beschreibungsfeld
Fehler in der Implementierung
Klare und einfache Texte
Klare Navigation]
Passende Schriftgröße
Vergrößerung möglich
Position der Bedienungselemente
Anmerkungen
110
2M
DD m
it Ac
capt
oVi
rtue
llen
Devi
ce, A
PI 2
4, A
ndro
id 7
, x864,13
1,33
0,00
2,80
11
20
00
00
02
23
43
210
4M
DD m
it Ac
capt
oN
exus
5 A
PI 2
5 (e
mul
ator
)4,
602,
000,
002,
603
21
00
00
00
32
14
3Ei
ne Ä
nder
ung
der G
röße
nein
stel
lung
en h
at s
ich
nich
t auf
die
Dem
o Ap
p au
sgew
irkt.
310
6M
DD m
it Ac
capt
oAV
D3,
001,
000,
002,
001
10
00
00
01
13
41
GPS
Che
ckbo
x lä
sst s
ich
aus
irgen
dein
em G
rund
nic
ht a
ktiv
iere
n4
108
MDD
mit
Acca
pto
4,10
1,50
1,00
1,60
12
00
00
10
12
11
3N
atür
lich
ist d
ie A
nord
nung
nic
ht p
erfe
kt (d
a di
e Ap
p ge
nerie
rt w
urde
). Es
ist a
ber l
eich
t mit
acca
pto
eine
gut
Ba
sis
zu s
chaf
fen.
511
0M
DD m
it Ac
capt
oEm
ulat
or25
,60
3,00
20,0
02,
602
34
34
24
52
32
23
3kö
nnte
noc
h op
timie
rt w
erde
n6
112
MDD
mit
Acca
pto
5.1
WVG
A AP
I 25
3,60
1,00
0,00
2,60
11
10
00
00
02
12
44
711
6M
DD m
it Ac
capt
oAn
droi
d Em
ulat
or, P
ixel
5, A
PI 2
5, A
ndro
id 7
.1.1
5,13
1,33
1,00
2,80
21
10
00
01
01
43
33
EditT
ext L
abel
s w
urde
nic
ht v
orge
lese
n vo
m S
cree
nrea
der;
Zu A
11y
Scan
ner:
Am d
oppe
lten
Labe
l bin
ich
schu
ld.Z
u m
anue
llen
Chec
ks: B
ack-
Butt
on s
ollte
obe
n lin
ks s
ein.
ggf
. Nav
igat
ionD
raw
er. T
exte
gef
ühlt
zu s
ehr
am li
nken
Ran
d "k
lebe
nd",
abe
r ist
Ges
chm
acks
ache
812
0M
DD m
it Ac
capt
ovi
rtua
l Dev
ice
4,50
2,00
0,00
2,50
20
00
00
03
21
49
204
MDD
mit
Acca
pto
virt
uelle
s De
vice
, Nex
us 5
X, A
PI 2
44,
301,
500,
002,
801
20
00
00
02
34
32
ok, a
ber n
ervi
g di
e Sp
rach
ausg
abe,
ver
lang
sam
t Rea
ktio
nene
rfor
dert
vie
l Vor
ausd
enke
n be
im E
rste
llen
des
XML,
vie
l Erf
ahru
ng10
206
MDD
mit
Acca
pto
One
Plu
s 3t
3,60
2,00
0,00
1,60
21
30
00
00
02
22
11
1120
8M
DD m
it Ac
capt
oN
exus
5 A
ndro
id 7
4,40
2,00
0,00
2,40
22
20
00
00
03
23
22
1221
0M
DD m
it Ac
capt
oN
exus
_5x
5,73
1,33
2,00
2,40
11
20
02
00
02
13
42
1321
2M
DD m
it Ac
capt
oVi
rtue
lles
Devi
ce4,
271,
670,
002,
602
21
00
00
00
12
34
314
214
MDD
mit
Acca
pto
Gal
axy
S7 E
dge
2,80
0,00
2,80
00
00
00
22
33
415
216
MDD
mit
Acca
pto
P10L
ite A
ndro
id 7
.07,
003,
001,
003,
003
33
00
00
10
33
33
316
218
MDD
mit
Acca
pto
Nex
us 6
P, 8
.0, O
REO
5,67
2,67
1,00
2,00
42
20
01
00
02
22
22
Talk
back
is v
ery
slow
mak
ing
it ha
rd to
opp
erat
e th
e m
achi
ne17
301
MDD
mit
Acca
pto
Goo
gle
Pixe
l And
roid
82,
251,
000,
001,
251
10
00
00
01
11
218
305
MDD
mit
Acca
pto
Sony
G81
41, A
ndro
id V
ersi
on 8
.0.0
21,9
01,
5018
,00
2,40
21
180
00
00
12
42
3Be
i Che
ckbo
xen
wird
die
Des
crip
tion
vom
XM
L ni
cht b
erüc
ksic
htig
t.Bei
"Bu
tton
s" w
erde
n be
i mir
Chec
kbox
en
dazu
gene
riert
.Bei
jede
r "In
tera
ctio
n" w
ird e
ine
neue
Act
ivity
ges
tart
et u
nd w
ird je
des
Mal
neu
in d
ie A
ctiv
ity
Hist
ory
aufg
enom
men
. Bsp
.: M
an d
rück
t im
Sta
rtSc
reen
auf
"Se
ttin
gs"
-> Im
Set
tings
Scre
en a
uf "
Save
and
Ba
ck"
und
das
öfte
rs h
inte
rein
ande
r, so
mer
kt m
an d
ie v
iele
n "o
ffen
en"
Scre
ens,
wen
n m
an p
er "
Back
" 19
309
MDD
mit
Acca
pto
Virt
uelle
s De
vice
, Nex
us 5
, Api
Lev
el 2
45,07
2,67
0,00
2,40
23
30
00
00
01
12
44
Talk
back
read
s ap
p tit
le 2
xNo
Labe
l per
App
Scr
een,
just
one
for t
he w
hole
app
.20
311
MDD
mit
Acca
pto
virt
uelle
s De
vice
- N
exus
5X
3,90
1,50
0,00
2,40
12
00
00
00
32
32
2Fu
nktio
nier
t mit
acca
pto
wirk
lich
sehr
ein
fach
(bzw
. man
wird
bei
m E
ntw
ickl
en d
azu
"gez
wun
gen"
)21
313
MDD
mit
Acca
pto
Nex
us 5
X4,
402,
000,
002,
404
11
00
00
00
12
33
3Zu
m S
cree
nrea
der:
Die
Bedi
enun
g is
t tro
tz A
nlei
tung
ein
ein
zige
r Gra
us -
ich
kann
mir
nich
t vor
stel
len,
dam
it al
s bl
inde
r ode
r sch
lech
t seh
ende
r Men
sch
an m
ein
gew
ünsc
htes
Zie
l zu
kom
men
. Was
bei
m S
cree
nrea
der
auff
ällt:
Man
öff
net d
ie A
pp u
nd h
ört d
ie g
eöff
nete
Sei
te. W
enn
aber
kei
n El
emen
t den
Fok
us b
ekom
mt (
das
könn
te A
ccap
to b
eisp
iels
wei
se im
mer
sic
hers
telle
n) w
arte
t man
ver
gebe
ns a
uf e
ine
Mel
dung
was
es
jetz
t au
f die
ser S
eite
gib
t - m
an m
uss
in d
er G
egen
d ru
mkl
icke
n bz
w ta
bben
und
"sc
haue
n" w
elch
e El
emen
te e
s so
gib
t. Ta
stat
urbe
dien
ung
funk
tioni
ert i
m G
egen
satz
zur
Tou
chsc
reen
bedi
enun
g gu
t.m
ean
6,19
1,80
2,10
2,38
var
35,5
30,
4031
,99
0,20
SD5,
960,
635,
660,
45M
edia
n4,
401,
580,
002,
40
Figure C.2: A11y evaluation test group Accapto.
127
Chapter C
AT -
Assi
tive
Tech
.Fehl
er A
cces
sibi
lity
Scan
ner
Man
uelle
Che
cks
#
TeilnehmerInnen Nr.
Development Methode
Getestet auf folgendem Device
A11Y Rating
Rating_AssistiveTech
ErrorsA11yScanner
Rating_Manual_Checks
Screenreader
Tabbing
Assitive Technologies Android
Touchsize
Bildkontrast
Textkontrast
fehlendes Beschreibungsfeld
doppeltes Beschreibungsfeld
Fehler in der Implementierung
Klare und einfache Texte
Klare Navigation]
Passende Schriftgröße
Vergrößerung möglich
Position der Bedienungselemente
Anmerkungen
110
1An
droi
d St
udio
AVD,
Nex
us 5
X, A
PI25
13,4
02,
009,
002,
402
26
03
00
02
43
12
210
3An
droi
d St
udio
Nex
us 5
X An
droi
d 7
6,90
4,50
0,00
2,40
45
00
00
00
22
33
2N
ervi
g am
AVD
zu
test
en. M
ehrm
alig
es b
etät
igen
von
But
ton
bis
korr
ekte
Akt
ion
ausg
efüh
rt w
ird. Z
u be
ginn
ni
cht u
bedi
ngt k
lar ü
ber d
ie F
unkt
iona
lität
. Für
mic
h ke
inen
unb
edin
gten
Meh
rwer
t. W
enig
Spi
elra
um d
a El
emen
te b
erei
ts d
urch
Auf
gabe
nste
llung
vor
defin
iert
310
5An
droi
d St
udio
Virt
ual D
evic
e: A
PI 2
5; R
eal D
evic
e: S
amsu
ng G
alax
y S7
edg
e, A
PI 2
416
,80
4,00
10,0
02,
804
70
03
00
12
44
34
107
Andr
oid
Stud
ioAV
D, N
exus
5X,
26
Mar
shm
allo
w5,
673,
670,
002,
005
51
00
00
00
21
14
Ich
hoff
e ic
h w
erde
soe
twas
nie
mal
s be
nötig
enIs
t jet
zt n
icht
die
Hig
h-En
d Ap
p, a
ber v
om K
onze
pt h
er s
ollte
es
so
funk
tioni
ern
510
9An
droi
d St
udio
virt
uelle
s De
vice
4,47
2,67
0,00
1,80
23
30
00
00
02
11
41
Scre
enre
ader
-> g
ut b
eim
Abk
ürze
n, v
ielle
icht
dau
ert e
s et
was
lang
e bi
s vi
el T
ext v
orge
lese
n w
urde
611
1An
droi
d St
udio
AVD
API 2
5 5X
-2,1
31,
67-6
,00
2,20
22
1-1
-1-1
-1-1
-12
22
32
Tabb
ing
am A
VD m
it M
aus
fast
nic
ht m
öglic
h. T
alkb
ack
Befe
hle
schr
eckl
ich
am A
VD. K
eine
Wer
te v
om A
cc.
Scan
ner m
it AP
I25
jede
s m
al b
eim
Sca
n ab
gest
ürzt
.7
115
Andr
oid
Stud
ioAV
D, N
exus
5X,
And
roid
7.0
(Nou
gat,
API 2
4)13
,07
1,67
9,00
2,40
22
16
00
30
03
22
23
- Tex
te k
önn
ten
etw
as m
ehr a
ussa
gen
z.B.
che
ckbo
x G
PS (w
ird h
ier A
ktiv
ieru
ng G
PS g
emei
nt o
der
hinz
ufü
gen
der G
PS lo
catio
n de
r PO
I) - U
I/Po
sitio
nen
der E
lem
ente
kö
nnte
noc
h ve
rbes
sert
wer
den
z.B.
m
argi
ns, G
rupp
ieru
ng e
tc...
811
7An
droi
d St
udio
ZTE
BLAD
E V8
. And
roid
Ver
sion
7.0
15,2
03,
009,
003,
203
40
41
00
22
44
4Be
im T
este
n de
r APP
, mitt
els
Talk
back
, mer
kt m
an, d
ass
die
Besc
hrift
unge
n, fü
r Ele
men
te, f
ehle
n.Di
e Be
dien
ungs
elem
ente
kö
nnte
n ei
n w
eite
r aus
eina
nder
sei
n. D
ie C
heck
boxe
n in
der
NEW
-Obe
rfl√
§che
sin
d zu
na
h an
eina
nder
. Die
Tex
tein
gabe
n si
nd a
lle fo
kuss
iert
.9
119
Andr
oid
Stud
ioN
exus
5x,
API
26,
And
roid
818
,20
4,00
11,0
03,
204
44
60
31
01
14
34
410
203
Andr
oid
Stud
ioHT
C O
ne m
913
,40
5,00
6,00
2,40
54
00
20
02
22
42
ich
hass
e ta
lkba
ck11
207
Andr
oid
Stud
ioG
alax
y S8
, And
roid
7.0
13,3
01,
509,
002,
801
26
03
00
02
32
43
1220
9An
droi
d St
udio
Nex
us 6
API
27
15,6
73,
679,
003,
004
43
60
30
00
13
44
313
211
Andr
oid
Stud
ioN
EXU
S 7
47,0
04,
0039
,00
4,00
44
44
05
156
94
44
44
Hat n
icht
gle
ich
funk
tioni
ert,
hat e
inen
Feh
ler g
ewor
fend
urch
die
sch
nelle
man
uelle
Ent
wic
klun
g pa
ssen
Sc
hrift
größ
e us
w n
icht
gan
z14
213
Andr
oid
Stud
ioVi
rtua
l Dev
ice
Nex
us 5
X AP
I 26
x86
5,27
2,67
0,00
2,60
23
30
00
00
02
24
23
1521
5An
droi
d St
udio
API 2
5 cu
stom
Rom
18,0
03,
0013
,00
2,00
312
01
00
01
11
43
1621
7An
droi
d St
udio
Emul
ator
, Nex
us 5
X AP
I 26,
Orio
4,27
2,67
0,00
1,60
23
30
00
00
01
13
21
kein
e17
304
Andr
oid
Stud
ioN
okia
67,
702,
503,
002,
201
40
03
00
01
22
42
dopp
elkl
ick
ist e
in d
reck
wen
n m
an u
ngeü
bt is
t (w
enn
das
mit
tabb
ing
gem
eint
ist)
die
Frag
este
llung
kön
nte
etw
as m
ehr e
rklä
rt s
ein.
anm
erku
ng z
um u
ploa
d, e
s w
äre
gut i
n de
r anl
eitu
ng a
nzug
eben
wie
die
Dat
ei
bena
nnt w
erde
n so
ll, w
enn
ich
das
zipp
e is
t sta
ndar
d PO
IAPP
und
hilf
t vl n
icht
vie
l wei
ter,
ich
hab
304
ange
häng
t.18
306
Andr
oid
Stud
ioVi
rtua
l Dev
ice,
And
roid
7.1
.18,
751,
505,
002,
252
12
01
02
02
23
2Li
est k
eine
Anm
erku
ngen
von
requ
ired
field
s vo
r19
310
Andr
oid
Stud
ioLG
Nex
us 5
X An
droi
d 8.
1.0
16,5
03,
5010
,00
3,00
34
60
30
01
24
24
3Ke
ine
exte
rne
Tast
atur
vor
hand
en, d
aher
nic
ht g
etes
tet.
Um
stän
dlic
he A
usga
ben
durc
h Sc
reen
read
er b
ei
Chec
kbox
("N
icht
akt
ivie
rt is
publ
ic K
ästc
hen"
), Li
ste
mit
QW
ERTZ
Tas
tatu
r hat
lang
e Sc
reen
read
erau
sgab
en:
("Se
arch
Bea
rbei
tung
sfel
d De
utsc
h Q
WER
TZ T
asta
tur w
ird a
ngez
eigt
")Ke
ine
Einh
eitli
che
Nav
igat
ion:
Bei
Se
ttin
gs g
ibt e
s Bu
tton
"Sa
ve &
Bac
k", B
ei N
ew h
eißt
der
But
ton
nur S
ave
und
kehr
t nic
ht a
uf 1
. Sei
te z
urüc
k.
Une
inhe
itlic
he D
ialo
g (N
ew P
OI:
zuer
st T
ext-
Inpu
t, da
nn C
heck
boxe
s, b
ei S
ettin
gs z
uers
t Che
ckbo
x, d
ann
Text
-In
put)
. Mai
nAct
ivity
: alle
But
tons
im o
bere
n Be
reic
h de
r Sei
te, d
aher
Pro
blem
e be
i Ein
hand
bedi
enun
g.
2031
2An
droi
d St
udio
Huaw
ei M
edia
Pad
M3,
And
roid
7.0
11,8
72,
676,
003,
202
33
60
00
00
24
44
221
314
Andr
oid
Stud
ioph
ysis
ches
Dev
ice,
Huw
ai 5
x, 6
.0.1
4,90
2,50
0,00
2,40
23
00
00
00
12
24
3m
ean
12,2
92,
976,
762,
56va
r93
,93
1,02
79,8
90,
32SD
9,69
1,01
8,94
0,57
Med
ian
13,0
72,
676,
002,
40
Figure C.3: A11y evaluation test group Android Studio.
128
Chapter C
C.2.6 Data A11y awareness & learning effect
This section contains the data of the questions to awareness and learning effect.Q1 Satisfying user experienceQ2 Simple operating conceptQ3 Labeling of operating elementsQ4 Graphical representation of functionsQ5 Description of controlsQ6 New forms of interactionQ7 Physical accessibility of operator elementsQ8 Written instruction manualQ9 Record user dataQ10 Alternative display options
Awareness & learn effect: Accapto vs. Android StudioQ1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Developers Accaptowichtig 19 14 7 2 7 2 13 0 0 2eher wichtig 3 8 11 7 10 4 9 4 5 7neutral 0 0 1 11 3 8 0 6 8 10eher unwichtig 0 0 3 2 2 7 0 5 7 1unwichtig 0 0 0 0 0 1 0 7 2 2in %wichtig 86,4% 63,6% 31,8% 9,1% 31,8% 9,1% 59,1% 0,0% 0,0% 9,1%eher wichtig 13,6% 36,4% 50,0% 31,8% 45,5% 18,2% 40,9% 18,2% 22,7% 31,8%neutral 0,0% 0,0% 4,5% 50,0% 13,6% 36,4% 0,0% 27,3% 36,4% 45,5%eher unwichtig 0,0% 0,0% 13,6% 9,1% 9,1% 31,8% 0,0% 22,7% 31,8% 4,5%unwichtig 0,0% 0,0% 0,0% 0,0% 0,0% 4,5% 0,0% 31,8% 9,1% 9,1%
Android Studio Developerswichtig 18 15 9 2 6 1 8 0 2 3eher wichtig 3 6 10 10 7 10 7 1 2 6neutral 0 0 0 7 8 8 5 7 11 7eher unwichtig 0 0 1 1 0 1 0 5 2 3unwichtig 0 0 1 1 0 1 1 8 4 2in %wichtig 85,7% 71,4% 42,9% 9,5% 28,6% 4,8% 38,1% 0,0% 9,5% 14,3%eher wichtig 14,3% 28,6% 47,6% 47,6% 33,3% 47,6% 33,3% 4,8% 9,5% 28,6%neutral 0,0% 0,0% 0,0% 33,3% 38,1% 38,1% 23,8% 33,3% 52,4% 33,3%eher unwichtig 0,0% 0,0% 4,8% 4,8% 0,0% 4,8% 0,0% 23,8% 9,5% 14,3%unwichtig 0,0% 0,0% 4,8% 4,8% 0,0% 4,8% 4,8% 38,1% 19,0% 9,5%
T-Test 0,969615 0,962279 0,948195 0,943196 0,938447 0,935856 0,951604 0,922805 0,932906 0,922805
Awareness & learn effect: Before vs. AfterQ1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Beforewichtig 44 35 7 9 8 4 25 1 5 6eher wichtig 6 14 28 17 16 22 14 8 9 18neutral 0 1 10 20 16 15 7 12 24 12eher unwichtig 0 0 5 3 8 7 3 15 8 9unwichtig 0 0 0 1 2 2 1 14 4 5
wichtig 88,0% 70,0% 14,0% 18,0% 16,0% 8,0% 50,0% 2,0% 10,0% 12,0%eher wichtig 12,0% 28,0% 56,0% 34,0% 32,0% 44,0% 28,0% 16,0% 18,0% 36,0%neutral 0,0% 2,0% 20,0% 40,0% 32,0% 30,0% 14,0% 24,0% 48,0% 24,0%eher unwichtig 0,0% 0,0% 10,0% 6,0% 16,0% 14,0% 6,0% 30,0% 16,0% 18,0%unwichtig 0,0% 0,0% 0,0% 2,0% 4,0% 4,0% 2,0% 28,0% 8,0% 10,0%
After wichtig 37 29 16 4 13 3 21 0 2 5eher wichtig 6 14 21 17 17 14 16 5 7 13neutral 0 0 1 18 11 16 5 13 19 17eher unwichtig 0 0 4 3 2 8 0 10 9 4unwichtig 0 0 1 1 0 2 1 15 6 4
wichtig 86,0% 67,4% 37,2% 9,3% 30,2% 7,0% 48,8% 0,0% 4,7% 11,6%eher wichtig 14,0% 32,6% 48,8% 39,5% 39,5% 32,6% 37,2% 11,6% 16,3% 30,2%neutral 0,0% 0,0% 2,3% 41,9% 25,6% 37,2% 11,6% 30,2% 44,2% 39,5%eher unwichtig 0,0% 0,0% 9,3% 7,0% 4,7% 18,6% 0,0% 23,3% 20,9% 9,3%unwichtig 0,0% 0,0% 2,3% 2,3% 0,0% 4,7% 2,3% 34,9% 14,0% 9,3%
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
T-Test 0,903577 0,879092 0,83069 0,796101 0,748948 0,77224 0,822945 0,71762 0,768629 0,705348
Figure C.4: A11y awareness & learning effect data.
129
Chapter C
0%
20%
40%
60%
1 2 3 4 5
Q3 voerher(rot) nacher(blau) %
0%
20%
40%
60%
1 2 3 4 5
Q3 mdd (blau) vs as (rot)
0%
10%
20%
30%
40%
50%
1 2 3 4 5
Q5 voerher(rot) nacher(blau) %
0%
20%
40%
60%
1 2 3 4 5
Q5 mdd (blau) vs as (rot)
0%
20%
40%
60%
80%
1 2 3 4 5
Q2 voerher(rot) nacher(blau) %
0%
50%
100%
1 2 3 4 5
Q2 mdd (blau) vs as (rot)
0%
10%
20%
30%
40%
50%
1 2 3 4 5
Q10 voerher(rot) nacher(blau) %
0%
10%
20%
30%
40%
50%
1 2 3 4 5
Q10 mdd (blau) vs as (rot)
0%10%20%30%40%50%60%
1 2 3 4 5
Q9 voerher(rot) nacher(blau) %
0%10%20%30%40%50%60%
1 2 3 4 5
Q9 mdd (blau) vs as (rot)
Figure C.5: A11y awareness & learning effect chart 1.
130
Chapter C
0%
50%
100%
1 2 3 4 5
Q1 pre-questionary (grey)post-questionary (blue)
0%
50%
100%
1 2 3 4 5
Q1 model-driven dev. (blue)standard-dev. (grey)
0%
20%
40%
60%
1 2 3 4 5
Q4 pre-questionary (grey)post-questionary (blue)
0%
20%
40%
60%
1 2 3 4 5
Q6 pre-questionary (grey)post-questionary (blue)
0%
20%
40%
1 2 3 4 5
Q8 pre-questionary (grey)post-questionary (blue)
0%
20%
40%
60%
1 2 3 4 5
Q7 pre-questionary (grey)post-questionary (blue)
0%
20%
40%
60%
1 2 3 4 5
Q4 model-driven dev. (blue)standard-dev. (grey)
0%
20%
40%
60%
1 2 3 4 5
Q6 model-driven dev. (blue)standard-dev. (grey)
0%
50%
100%
1 2 3 4 5
Q7 model-driven dev. (blue)standard-dev. (grey)
0%
20%
40%
1 2 3 4 5
Q8 model-driven dev. (blue)standard-dev. (grey)
Figure C.6: A11y awareness & learning effect chart 2.
131
Chapter C
C.2.7 Data A11y Interviews
This sections contains the notes from four participants interviews after the data analy-sis.
Fragen:
F1: Was haben Sie zu Accessibility bzw. mobiler Accessibility gewusst?
F2: Wie sehr haben Sie Accessibility bisher in Software-Projekten berücksichtigt?
F3: Haben Sie in der Evaluierung mehr zu Accessibility gelernt?
F4: Wie weit ist die Unterstützung von Tools/IDEs für Accessibility aus Ihrer Sicht?
F5: Wie gut is Model-driven Development für die Integration von Accessibility geeignet?
F6: Wie weit ist Ihr Wissen zu und Bewußtsein für Accessibility gestiegen?
Interview 1: Teilnehmer 304, 2.3.2017, 15:40, Entwicklung mit Android Studio
F1: Wenig, bisher nicht berücksichtigt in Projekten, ich habe schon Projekte im Bere-ich mobiler Entwicklung gemacht, wußte daß man es im allgemeinen bzw. geset-zlichen Gründen machen muß.
F2: Es war bisher noch keine Kundenanforderung wo Accessibility explizit gefordertwar. Ich hatte erst eine Anfrage, die war nicht relevant. Die war im Web- Bereich. Immobilen Bereich bis jetzt noch nicht.
F3: Ja, z.B. Berücksichtigung von Abständen, Kontrast ist wichtig und man kann esautomatisch prüfen
F4: Gar nicht vorhanden, kein Menü Punkt A11y Check. Es gibt zu viele Einstellungen,ohne Detailwissen ist es schwer möglich. (Anm. Verwendete IDE: Androidstudio, PhpStorm, IntelliJ)
F5: Guter start, aber nur am beginn, schwierig wird es bei nachträglichen änderungen,bei individuelle Anpaßungen für a11y nicht so gut geeignet
F6: Gering, (Nachfrage Warum) Das Bewußtsein ist da, Wissen nur wenig bessergeworden
Interview 2: Teilnehmer 305, 2.3, 17:22, MDD mit Accapto
F1: Im Zuge des Studiums kennengelernt, ist wichtig. Die App muß ja schon so en-twickelt sein, das alles von Talkback verwendend werden kann, auch bei Texteingabe,welche Art von Daten, Zahlen oder Text ist wichtig. Man benötigt Content-sensitiveHilfseinträge, nicht nur Titel, man soll sprechende Namen verwenden. Ich habe auchschon Validierungsmöglichkeiten gekannt.
132
Chapter C
F2: Man muß unterscheiden zw. privaten und öffentlichen Projekte. Aber eigentlichbisher nicht berücksichtigt, ich glaube, daß die wenigsten das machen. Die wenigstenApp-Anbieter berücksichtigen A11y. Ich habe bisher selten eigene Apps auf A11yüberprüft.
F3: Hmm, ja, ist schwierig zu benennen. Für mich waren es weniger Details derUmsetzung. Durch Vorgaben achtet man mehr auf A11y. Nicht etwas speziell Neuesgelernt, aber Wissen aufgefrischt.
F4: Schwierig. Weil feature ohnehin ausprogrammiert werden müssen und ich ver-wende keine Tools dafür. Gibts so was schon?
F5: Ja, gut. Das Tool hat mir gut gefallen, erst XML und man wird gezwungen schondie descriptions zu verwenden. Der geführte Prozess ist gut. Das Ergebnis ist sicherstrukturierter als mit herkömmlicher Methodik
F6: Mein Wissen ist subjektiv nicht so sehr gestiegen, war aber nicht der Hauptfokus.Aber man soll sensibler werden. Das Bewußtsein der Wichtigkeit von Acceßibility istauf jeden Fall gestiegen. Man kann mit tool-generierten Layout auch noch nachsehenwie es richtig umgesetzt sein sollte.
Interview 3: Teilnehmer 301, 5.3.2017, 9:05, MDD mit Accapto
F1: Bücher gelesen, aber eher im Webbereich, von Kollegen gebrieft, aber auch alslästige Arbeit empfunden. Ich habe mein Bewußtsein durch Forschungsprojekte indiesem Bereich bereits gebildet. Bei iOS hat man das Gefühl, daß es ohnehin vomSystem gemacht wird.
F2: Mir war es bewußt, jedoch habe ich es trotzdem nicht umgesetzt. In kleinenProjekte ist A11y nicht nötig gewesen.
F3: Ja klar, und neue Tools von Google (Anm. Acceßibility Scanner) kennengelernt.Auch den Output der Tools kennen gelernt. Die Tools sind aber nur ein Ausschnitt,aber keine Lösung. Ich lass die Tools laufen und dann geht alles, ist nicht der Fall.
F4: Aus meiner Sicht wird es ziemlich ignoriert. Es gibt externe Tools vor allem imWeb, wenn man nicht darauf, achtet ist es nicht vorhanden.
F5: Für mich eher nicht, da MDD Ansätze nicht geigend sind. Es ist eine Einbahn, beiÄnderungen und updates passt das Model nicht mehr. Ich persönlich arbeite liebermit Code als mit visuellen Tools.
F6: Ich weiß nicht, ob man das messen kann. Es war wieder ein Impuls und Erin-nerung. (Was fehlt?) Man bekommt wenig Feedback, man hat das Gefühl es brauchtniemand. Es gibt kein Zertifikat A11y check, und fehlende Wertschätzung der En-twickler. Accapto passt gut zum Entwickler Workflow, ein Command-Line Programmist ein Teil der Toolchain und bietet gutes Handling.
133
Chapter C
Interview 4: Teilnehmer 201, 20.3.2017, 9:50, MDD mit Accapto
F1: In welcher Hinsicht? Direkt vom Unterricht angewendet, sonst nicht direkt damitbeschäftigt
F2: In Projekten habe ich es versucht sehr zu berücksichtigen (Frage - in welcherForm?) ich habe für Sehbehinderte Bilder mit alt-Tags versehen, habe Internet Toolsverwendet und Fehler ausgebessert.
F3: Ja, es gab neue Sachen, die ich vorher nicht gekannt habe. Aber ich habe nichtsAllgemeines dazugelernt.
F4: Noch nicht so gut wie es sein könnte. In einer Wertung von 1-10 wäre es 6. Eskönnte mehr vorgeben werden.
F5: Ja, es erleichtert einiges. Im Gegensatz zur zweiten Art (Anm. Vergleichsgruppeohne MDD) ist es viel einfacher
F6: Im Laufe der Jahre achtet man mehr darauf. Wissen habe ich ausgebaut. GewißeDinge, die noch nicht Routine sind, sind hier wieder aufgetaucht. Ich kann aber nichtmehr genau sagen welche (Anm. Nachfrage welche Details).
134
Appendix D
CV Elmar Krainz
D.1 Personal
• Name: Elmar Krainz (born Krajnc)
• Date of Birth: 7. March 1976
• Place of Birth: Bruck an der Mur, Austria
• Address: Neue Welt 4, 8131 Mixnitz
• email: [email protected]
• Nationality: Austria
D.2 Teaching and Working Experience
• since 2017 Senior Lecturer FH JOANNEUM University of Applied Sciences,Kapfenberg, Austria
• 2007 to 2017 Lecturer and Researcher FH JOANNEUM University of AppliedSciences, Kapfenberg, Austria
• 2000 to 2006 Working in industry as web- and software developer, Austria
• 2015 and 2017 Lecturer for Secure Mobile App Development, Hochschule Bre-men, Germany
• 2012 and 2013 Guest lecturer for Software development and Usability, JonkopingUniversity, Schweden
• 2010 Lecturer for Computer Science 1, Technical University Graz, Austria
135
Chapter D
• 2009 and 2010 Guest lecturer for Usability Engineering. Savonia University ofApplied Sciences, Finland
D.3 Education
• 2015 to 2018 PhD Computer Science, Johannes-Kepler-University Linz
• 1995 to 2003 Telematik (Computer Science), Technical University Graz
June 2003 Master Degree
September 2002 Bachelor Degree
• 1990 to 1995 Technical Collage for Electrical Engineering Kapfenberg
D.4 Main Research Area
Research and Teaching in the field of mobile application development including thedesign, usability and accessibility of software applications (Human Computer Interac-tion), the developing process in object oriented languages and the implementation ofmobile apps.
App development and creation of frameworks for rapid application development, cross-platform development and development for people with special needs is a key part ofmy research.
Other research interest are the various methods and aspects of eLearning and didacticconcepts in computer science education.
D.4.1 Research Projects (Selection)
• PONS, Work package lead, 2/2014 - 1/2016
• NASCA, Work package lead, 4/2013 - 7/2014
• KMU goes Mobile, Consulting und development for regional companies, 1/2013- 8/2017
• Ways4me, mobile software development and accessibility evaluation, nationalresearch award, 12/2012- 10/2014
• Way4All Complete, Project lead, 1/2011 - 12/2013
• NAVCOM, software development and accessibility evaluation, 5/2010 - 10/2011
136
Chapter D
• Ways4All, software development and accessibility evaluation, 12/2009 - 3/ 2011
• various projects for app- and web development
D.4.2 Publications (Selection)
Elmar Krainz, Klaus Miesenberger, and Johannes Feiner. Can We Improve App Ac-cessibility with Advanced Development Methods?, accepted Paper ICCHP2018, 2018.
Johannes Feiner, Elmar Krainz, and Keith Andrews. A new approach to visualizeaccessibility problems of mobile apps in source code. In Proc. 20. InternationalConference on Enterprise Information Systems , volume 2 of ICEIS 2018 , pages 519-526. SCITEPRESS - Science and Technology Publications, 2018.
Elmar Krainz and Klaus Miesenberger. Accapto, a generic design and developmenttoolkit for accessible mobile apps. Studies in health technology and informatics, 242:660-664, 2017.
Elmar Krainz, Werner Bischof, Markus Dornhofer, and Johannes Feiner. Catching theRight Bus – Improvement of Vehicle Communication with Bluetooth Low Energy forVisually Impaired and Blind People, pages 9-15. Springer International Publishing,Cham, 2016.
Elmar Krainz, Johannes Feiner, and Martin Fruhmann. Accelerated development foraccessible apps – model driven development of transportation apps for visually im-paired people. In Human-Centered and Error-Resilient Systems Development - IFIPWG 13.2/13.5 Joint Working Conference 6th International Conference on Human-Centered Software Engineering, HCSE 2016, and 8th International Conference onHuman Error, Safety, and System Development, HESSD 2016, Proceedings, pages374-381, 2016.
Elmar Krainz, Viktoria Lind, Werner Moser, and Markus Dornhofer. Accessible wayfind-ing on mobile devices for different user groups. In Proceedings of the 18th Interna-tional Conference on Human-Computer Interaction with Mobile Devices and ServicesAdjunct, MobileHCI ’16, pages 799-806, ACM, New York, USA, 2016.
Markus Dornhofer, Werner Bischof, and Elmar Krajnc. Comparison of open sourcerouting services with Openstreetmap data for blind pedestrians. In FOSS4G-Europe2014, 2014.
Elmar Krajnc, Wilhelm Zugaj, Mathias Knoll, and Johannes Feiner. Generic mobileapplications for small and medium enterprises. In International Scientific ConferenceUNITECH’2014, volume II, pages 363-367, Bulgaria, 2014. Technical University ofGabrovo.
137
Chapter D
Elke Mattheiss and Elmar Krajnc. Route Descriptions in Advance and Turn-by-TurnInstructions – Usability Evaluation of a Navigational System for Visually Impaired andBlind People in Public Transport , pages 284-295. Springer Berlin Heidelberg, 2013.
Werner Bischof, Elmar Krajnc, Markus Dornhofer, and Michael Ulm. NAVCOM –WLAN Communication between Public Transport Vehicles and Smart Phones to Sup-port Visually Impaired and Blind People , pages 91-98. Springer Berlin Heidelberg,2012.
Martijn Kiers, W Bischof, E Krajnc, and M Dornhofer. Evaluation and improvementsof an RFID based indoor navigation system for visually impaired and blind people. In2011 International Conference on Indoor Positioning and Indoor Navigation; Paper,Guimaraes, Portugal, 2011.
Elmar Krajnc, Mathias Knoll, Johannes Feiner, and Mario Traar. A Touch SensitiveUser Interface Approach on Smartphones for Visually Impaired and Blind Persons ,pages 585-594. Springer Berlin Heidelberg, 2011.
Johannes Feiner, Keith Andrews, and Elmar Krajnc. UsabML - the usability reportmarkup language: Formalising the exchange of usability findings. In Proc. 2nd ACMSIGCHI Symposium on Engineering Interactive Computing Systems (EICS 2010),pages 297-302, New York, USA, May 2010. ACM.
Elmar Krajnc, Johannes Feiner, and Stefan Schmidt. User Centered Interaction De-sign for Mobile Applications Focused on Visually Impaired and Blind People , pages195-202. Springer Berlin Heidelberg, 2010.
D.5 Other scientific Activities
• Co-Chair UX Community Showcase, UX Day Graz 2016https://uxday.fh-joanneum.at/team/
• Reviewer UXPA 2017 in Seattle http://uxpa2016.orgAchieved: May 2016
• Observer of the IFIP TC 13.1 HCI Educationhttp://ifip-tc13.org/
• Chairperson UX Community Showcase, UX Day Graz 2015http://uxdaygraz2015.iicm.tugraz.at/team
• Reviewer UXPA 2016 in Seattle http://uxpa2016.orgAchieved: May 2015
138
Chapter D
• Reviewer: May 2015, Future Generation Computer Systems, Volume 62, Septem-ber 2016, ElsevierAchieved: May 2015https://www.reviewerrecognition.elsevier.com/recognition/detai
ls?type=recognized&id=2502464&key=A002F298890F30D8C525E8FB7E
CFF01D3F02C4875DF9E88D
• Reviewer: International Programme Committee oft the 23rd International Con-ference on Information Systems Development (ISD2014 Croatia)http://isd2014.foi.hr/index.php#committees
• Chairperson UX Community Showcase, UX Day Graz 2013http://uxdaygraz2013.iicm.tugraz.at/team
• Conference Organisation "The Future of the Internet" FH JOANNEUM, 11.11.2011Organiser and Editor
D.6 Profiles on Science Platforms
• Profil Google Scholarhttp://scholar.google.at/citations?user=E5Fgx0MAAAAJ&hl=de
• Profil ResearchGatehttps://www.researchgate.net/profile/Elmar_Krainz
139