Submitted by Dipl.-Ing. Elmar Krainz
Submitted at Institut Integriert Studieren
Supervisor and First Examiner a.Univ.-Prof. Dr. Klaus Miesenberger
Second Examiner Model-Driven Develop- Prof. Dr. Roberto Manduchi ment for Accessible Mo- May 2018 bile Apps on Android
Doctoral Thesis to obtain the academic degree of Doktor der technischen Wissenschaften in the Doctoral Program Technische Wissenschaften
JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, Österreich www.jku.at DVR 0093696 Sworn Declaration
I hereby declare under oath that the submitted Doctoral Thesis has been written solely by me without any third-party assistance, information other than provided sources or aids have not been used and those used have been fully documented. Sources for literal, paraphrased and cited quotes have been accurately credited. The submitted document here present is identical to the electronically submitted text document. 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 with the number of apps in the stores, which has recently hit 3 million available apps (see https://www.statista.com/statistics/266210/). Due to this development, the natural user interaction of smartphones plays a crucial role. People with disabilities benefit 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 screens and visual representation very often overlook their needs. According to the UN Convention on the Rights of Persons with Disabilities around 650 million 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 enact the Directive (EU) 2016/2102 which requests that websites and mobile applications of public sector bodies are accessible for all. Reviewing top apps in the Android store shows that even very popular apps such as WhatsApp, Messenger and Instagram have accessibility problems, i.e. contrast of 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 Chapter 1). The thesis at hand presents an innovative approach, supporting the implementation of accessibility in the design and development process of mobile applications from the very beginning. We propose a model-driven approach for better integration and addressing 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 abstract definition describes screens, user interface elements and interaction workflows in a domain-specific description language. The model is transformed into a working app prototype for the Android platform. In the generation process, the app is created with proper platform-specific accessibility support and enhanced with additional supportive features and provides guidance to the developer to efficiently and effectively implement accessibility. In the course of the thesis, the level of accessibility of apps implemented with Accapto is evaluated against Web Content Accessibility Guidelines (WCAG 2.0) and also tested with 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 using Accapto 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 to significantly improving app accessibility from the beginning and helps developers to raise 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 in Hand 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 entscheidende Rolle. Menschen mit Behinderungen profitieren von der zunehmenden digitalen Tech- nologie im Allgemeinen, aber nur, wenn sie zugänglich ist. Allerdings sind Apps für Menschen mit Behinderungen oft nicht zugänglich, da Touchscreens und visuelle Darstellungen ihre Bedürfnisse oft übersehen. Nach der UN-Konvention über die Rechte von Menschen mit Behinderungen sind rund 650 Millionen Menschen der Weltbevölkerung behindert. Innerhalb der Europäischen Union (EU) sind etwa 80 Millionen Menschen von Behinderungen betroffen. Um auch diese große Gruppe europäischer BürgerInnen einzubeziehen, hat die Europäische Union die Richtlinie (EU) 2016/2102, in Kraft setzt, in der gefordert wird, dass Websites und mobile Anwendungen öffentlicher Stellen für alle zugänglich sind. Die Überprüfung der Top-Apps im Android Store zeigt, dass selbst sehr beliebte Apps wie 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 Implementierung von Barrierefreiheit in den Entwurfs- und Entwicklungsprozess von mobilen Anwen- dungen von Anfang an unterstützt. Diese Arbeit stellt einen modellgetriebenen Ansatz fü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 formales Modell 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 mit plattformspezifischen 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 50 beteiligten Entwicklern analysiert. In zwei Testgruppen wird der modellgetriebene En- twicklungsansatz mit Accapto mit der Standardentwicklungsmethode verglichen. Die Ergebnisse 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 signifikant zu verbessern und EntwicklerInnen dabei unterstützen, auf die Bedürfnisse spezieller Nutzergruppen aufmerksam zu machen. Acknowledgments
I am grateful to many people who were directly or indirectly involved in the preparation of this thesis. In particular, I want to thank • my supervisor a.Univ.-Prof. Dr. Klaus Miesenberger for his support and guidance during my thesis • Prof. Dr. Roberto Manduchi reading this thesis as the second examiner • my colleagues at FH JOANNEUM and Johannes Kepler University (JKU) helping me 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 me motivation and encouraged me to go on. Contents
1 Introduction1 1.1 Accessibility Problems in Mobile Apps ...... 1 1.2 Why Should Your App be Accessible? ...... 6 1.3 Aims of this Thesis ...... 7 1.4 Research Questions ...... 8 1.5 Proposed Solution: Accapto – Accessible App Tool ...... 8 1.6 Methodology and Structure of this Thesis ...... 9 1.7 Published Contributions ...... 10
2 Background and Related Work 11 2.1 Accessibility ...... 11 2.1.1 Disabilities ...... 12 2.1.2 Accessibility Legislation ...... 13 2.1.3 Accessibility Standards ...... 14 2.2 Mobile Accessibility ...... 17 2.2.1 Mobile Accessibility Mapping ...... 17 2.2.2 Accessibility Features of Popular Mobile Platforms ...... 18 2.2.3 Accessible Android Apps ...... 18 2.2.4 Related Work on Mobile Accessibility ...... 19 2.3 Model-Driven Development (MDD) ...... 22 2.3.1 Model and Meta-Model ...... 23 2.3.2 Modeling Languages ...... 23 2.3.3 Model Transformation and Code Generation ...... 25 2.4 Related Work ...... 26 2.4.1 Model-driven Development for User Interfaces ...... 26 2.4.2 Model-Driven Development for Mobile Applications ...... 28 2.4.3 Model-Driven Development supporting Accessibility ...... 29 2.5 Summary ...... 29
3 Model-Driven Development for Accessible Apps 31 3.1 Modeling with UML ...... 32
i CONTENTS ii
3.1.1 UML Diagrams for User Interaction ...... 33 3.1.2 Accessibility and UML ...... 35 3.2 A Model for Accessible Apps ...... 35 3.2.1 Elements of an Accessible Mobile App Model ...... 36 3.2.2 Profile ...... 38 3.2.3 Meta Model ...... 38 3.3 Model Description (DSL) for Accessible Apps ...... 39 3.4 Summary ...... 42
4 Generation of Accessible Apps 43 4.1 Android Applications ...... 44 4.2 Parsing the Model ...... 45 4.3 App Generation Overview ...... 45 4.3.1 App Scaffolding ...... 46 4.3.2 Templating ...... 46 4.4 Accessibility Enrichment in Android Apps ...... 49 4.4.1 Implementation of Accessibility on Android ...... 49 4.4.2 Proper Implementation for Accessibility ...... 51 4.4.3 Runtime Accessibility Extension ...... 54 4.4.4 Runtime Theme Selection ...... 55 4.4.5 SpeechOutput Helper ...... 56 4.4.6 SpeechInput Helper ...... 56 4.5 Accapto - Accessible App Toolkit ...... 56 4.6 Summary ...... 58
5 Accessibility Evaluation of the Resulting App Prototype 59 5.1 From Mockup to Prototype ...... 60 5.2 Accessibility Evaluation of the Resulting App ...... 61 5.2.1 Accessibility Evaluation Android Smartphone Apps ...... 61 5.2.2 Evaluation with W3C Mobile Accessibility Guidelines ...... 64 5.2.3 Evaluation with Web Content Accessibility Guidelines (WCAG) . 66 5.2.4 Evaluation with Test Users ...... 69 5.2.5 Quick Accessibility Check ...... 73 5.3 Summary ...... 75
6 Empirical Evaluation of the Model-Driven Development Process 76 6.1 Study Design ...... 77 6.2 Target Group ...... 77 6.3 Development Tasks ...... 78 6.3.1 Model-driven Development with Accapto ...... 79 6.3.2 Development with Android Studio ...... 79 6.4 Accessibility Evaluation Task ...... 80 CONTENTS iii
6.5 Results of the Empirical Evaluation ...... 81 6.5.1 Accessibility ...... 81 6.5.2 Workload of Tasks ...... 86 6.5.3 Awareness and Learning Effect ...... 87 6.6 Summary ...... 92
7 Conclusion and Outlook 93 7.1 Findings ...... 93 7.2 Future Work ...... 95 7.3 Conclusion ...... 95
Appendix A Accapto Model 113 A.1 XSD Schema Definition of the Accapto Model ...... 113 A.2 Model of Routing app in XML ...... 115
Appendix B Data Usertesting 117
Appendix C Details from the Empiric Evaluation 121 C.1 Evaluation Instruction ...... 121 C.2 Questionary ...... 121 C.2.1 Pre-Questionary ...... 122 C.2.2 Accessibility Test ...... 123 C.2.3 Post - Questionary ...... 124 C.2.4 Data from Participants ...... 126 C.2.5 Data A11y Evaluation ...... 127 C.2.6 Data A11y awareness & learning effect ...... 129 C.2.7 Data A11y Interviews ...... 132
Appendix D CV Elmar Krainz 135 D.1 Personal ...... 135 D.2 Teaching and Working Experience ...... 135 D.3 Education ...... 136 D.4 Main Research Area ...... 136 D.4.1 Research Projects (Selection) ...... 136 D.4.2 Publications (Selection) ...... 137 D.5 Other scientific Activities ...... 138 D.6 Profiles on Science Platforms ...... 139 List of Tables
1.1 Accessibility Metrics ...... 3 1.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 ...... 65 5.2 Evaluation with W3C WCAG 2.0 levels A and AA ...... 67 5.3 Evaluation with W3C WCAG 2.0 levels A and AA, part 2 ...... 68 5.4 Quick accessibility check - Assistive technologies ...... 74 5.5 Quick accessibility check - Errors from Accessibility Scanner ...... 74 5.6 Quick accessibility check - manual checks ...... 74 5.7 Association of QAC Rules to WCAG Success criterions and guidelines . 75
6.1 Single Accessibility evaluation ...... 81 6.2 Statistics of Accessibly Evaluation ...... 84 6.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 Store from 2008 to 2016...... 2 1.2 Examples of accessibility problems detected by the Accessibility Scanner.3 1.3 Over 90% reported at least three major issues regarding the Google Play Store top 100 apps...... 4 1.4 Most of the top 10 apps actually have issues A4 and A5...... 5 1.5 The best 10 apps according to accessibility report problems for A1 and A2 only...... 6 1.6 Accapto overview [1]...... 9
2.1 The context of the standards WCAG, UAAG and ATAG (from https: //www.w3.org/WAI/guid-tech)...... 16 2.2 The basic idea of model-driven development...... 22 2.3 The relation between real objects, model and meta-model...... 23 2.4 The transformation process of model-driven development...... 25 2.5 Simplified version of the Cameleon Reference Framework [2]...... 26 2.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...... 32 3.2 Storyboard in Xcode ...... 33 3.3 Example of a UML use case diagram for a simple routing app...... 34 3.4 Example of a UML sequence diagram for geocoding in routing app. . . 34 3.5 Example of a UML activity diagram for a simple routing app...... 34 3.6 The UML class diagram of the model...... 38 3.7 Simple app model: (a) app mockup, (b) model...... 39
4.1 Building chain of Accapto...... 43 4.2 Android app development project...... 44 4.3 XML to Java binding...... 46 4.4 Overview of Accapto code generation...... 47 4.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 ...... 53 4.8 Generated input item with TextView and EditText...... 54 4.9 Checkbox without and with touch extension...... 55 4.10 Accapto overview [1]...... 57
5.1 Mockup of routing app...... 59 5.2 Generated app with (a) low vision and (b) standard theme...... 61 5.3 Setup of Lint for accessibility checks...... 63 5.4 Code inspection with Lint using accessibility rules...... 63 5.5 Results of the WCAG evaluation. Overall 20 rules passed, 2 rules failed in the evaluation and 15 rules were not applicable...... 68 5.6 Final app for usertest...... 69 5.7 User tests: left: test person with cognitive disability, right: blind test person ...... 71 5.8 Average TLX of the the task compared to the different user groups. . . . 72 5.9 Average SUS score by user groups...... 73
6.1 Work experience of participants...... 78 6.2 Programming skills of participants...... 79 6.3 UI design and accessibility skills ...... 80 6.4 Mockup of the app prototype...... 80 6.5 Boxplot of self-estimated accessibility rating...... 82 6.6 Barplot of accessibility rating...... 83 6.7 Boxplot of accessibility rating...... 85 6.8 TLX of the evaluation task...... 86 6.9 TLX of the development task...... 87 6.10 Q1- Before and after development task; model-driven vs. standard de- velopment...... 89 6.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 ...... 117 B.2 User tests with elderly people ...... 118 B.3 User tests with visually impaired people ...... 119 B.4 User tests with persons without restrictions ...... 120
C.1 Participants of the empiric evaluation...... 126 C.2 A11y evaluation test group Accapto...... 127 C.3 A11y evaluation test group Android Studio...... 128 C.4 A11y awareness & learning effect data...... 129 LIST OF FIGURES vii
C.5 A11y awareness & learning effect chart 1...... 130 C.6 A11y awareness & learning effect chart 2...... 131 Listings
3.1 XML of the ScreenType ...... 40 3.2 XSD of the ScreenType ...... 40 3.3 Model of WhereAmI App in XML...... 41 4.1 Template code fragment for a method stub in Java class...... 47 4.2 Template code fragment for a method stub in Java class...... 48 4.3 Template for the UI element in the XML layout file...... 48 4.4 Generated input item with TextView and EditText...... 54 5.1 XML model of routing app ...... 60 A.1 XSD of the Accapto model ...... 113 A.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, phones and other smart devices.
In the year 2013 the number of mobile Internet devices reached 10 billion, which is about 1.4 device per person on the planet [3]. With the rise of smartphones the need for special software products is also increasing.
The market for apps and mobile software is growing. Mobile users spend about 90 per cent of their mobile time in apps [4]. People use various apps and most of these are easy to operate, because of their simple and intuitive user interfaces.
Since 2008 the available apps have increased from 800 (2008, Apple App Store2) to 3.500.000 (December 2017, Google Play3). Figure 1.1 shows the soaring progress in the number of available apps in the two most popular app publishing platforms.
Mobile applications, or apps, come with a simple, intuitive user interface. Touch screens 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 access to the technology. Accessibility is the ability to perceive, understand, navigate and
1Apple presented the first iPhone in January 2007 2https://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
AVAILABLE APPS IN ANDROID AND APPLE STORE DATA FROM: HTTPS://WWW.STATISTA.COM/STATISTICS/266210/NUMBER- OF-AVAILABLE-APPLICATIONS-IN- THE-GOOGLE-PLAY-STORE/ HTTPS://WWW.STATISTA.COM/STATISTICS/263795/NUMBER- OF-AVAILABLE-APPS-IN- TH E-APPLE-APP-STORE/ 3,000,000 2,600,000 Apple 2,500,000 2,400,000
Android 2,200,000 2,000,000 2,000,000 2,000,000 1,800,000 1,600,000 1,500,000 1,500,000 1,400,000 1,400,000 1,300,000 1,300,000 1,200,000 1,000,000 1,000,000 1,000,000 900,000 850,000 850,000 800,000 700,000 700,000 675,000 650,000 600,000 585,000 500,000 500,000
450,000 500,000 425,000 400,000 350,000 300,000 300,000 250,000 225,000 200,000 150,000 100,000 100,000 70,000 65,000 38,000 35,000 30,000 16,000 3,000 800 0
Figure 1.1: The rise of available apps in Apple’s App Store and Google’s Play Store from 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 apps to stay connected, consume media, use helpful tools or just play games. According to Kane 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 accessibility in 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 with icons, textual descriptions and interactive elements. The app is also well designed to reflect the company’s visual corporate identity. However, typical accessibility errors can also be found. In this screenshot, we can see a missing object item label for text-to-speech, a contrast ratio lower than 3:0 in texts and images, and touch targets smaller than 48x48dp.
To get an overview of possible accessibility issues of an app, Google provides a useful tool 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, are content label, object description, editable content label, clickable items, touch target and text and image contrast. These criteria are explained and grouped on the website of the scanner into four main categories [8] content labelling, implementation, touch target size and low contrast.
2 Chapter 1
Figure 1.2: Examples of accessibility problems detected by the Accessibility Scanner.
Code Metric A1 Touch target size A2 Item label missing A3 Editable item label A4 Text contrast A5 Object description A6 Clickable links A7 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 Google Play store top apps consider accessibility properly. To gain deeper insight into mobile apps, 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 home screen, the logon screen and a preferences screen. Although some applications do not contain one of those screens, similar screens are taken. For instance, if an app does 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
1 91% 90%
0.9 87%
0.8
0.7
0.6 52% 52% 0.5
0.4
0.3
0.2 19%
0.1 4% 0 A1 A2 A3 A4 A5 A6 A7
Figure 1.3: Over 90% reported at least three major issues regarding the Google Play Store top 100 apps. long list, which was then reduced to a short list by filtering (for example, the main idea of 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 the 100 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, one can see that more than 50% of apps fail in five out of seven criteria. Nearly 90% have problems 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 every other app. Few problems were found according to clickable links (A6) and there were hardly any issues with editable item labels (A3).
Reported numbers of errors are sometimes very high because some iterative elements like list or icons set occur more than ones on an app screen. For further qualitative information 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 either errors in the selected section or no value. With this normalisation, multiple counting of the 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 errors in quantity and category to the top 100.
4 Chapter 1
Top10 Top20 Top100 45% 41% 40% 40% 40% 35% 35% 31% 30% 30%
25% 20% 20% 15% 15% 15% 10% 10% 10% 8%
5% 3% 2% 0% 0% 0% 0% 0% 0% 0% 0% #1 #2 #3 #4 #5 #6 #7
Figure 1.4: Most of the top 10 apps actually have issues A4 and A5.
Top20 Top100 Diff min. 1 1 0 max. 3 6 3 median 2 4 2 average 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 a different result. Comparing the top 20 best accessible apps to the top hundred, a significant difference can be seen. The median of the top 20 best-accessibility rated apps is only half and the average is 1.65 lower. In the top 20 we found a maximum of 3 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 see a different distribution in Figure 1.5. In the alternative sorting with the best accessible apps first, we observe an offset to fewer reported accessibility issues. The top 10 best accessibility rated apps show only errors in one or two categories, the top 20 in only three categories. Here we can also visually show that there are differences in accessibility with fewer reported errors.
5 Chapter 1
Top10 Top20 Top100 80% 70% 70%
60%
50% 45% 41% 40% 40% 31% 30% 30%
20% 15% 15%
10% 8% 3% 2% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% #1 #2 #3 #4 #5 #6 #7
Figure 1.5: The best 10 apps according to accessibility report problems for A1 and A2 only.
This study provides insights about the current lack of accessibility support in mobile applications. Analysing the 100 top apps of the Google Play Store has shown that none of the aforementioned apps would fully pass the automated accessibility evalua- tion with Accessibility Checker. The findings revealed several lacking features as well as 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 people are a very large minority. Furthermore, the World report on disability [11] indicate that 15,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 in the 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 of accessibility, people are excluded from products and services. The proportion of older people is also on the rise and this group has to fight on the one hand with physical and cognitive 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 websites and 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 of public sector bodies are made more accessible on the basis of common accessibility requirements." [13].
Accessibility has socio-economic reasons
Everything, which lacks accessibility requires social support and care. Accessibility improves 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) and we have guidelines (e.g. Web Content Accessibility Guidelines [14]. To sum it up, the words of lkka Pirttimaa, inventor of BlindSquare7 are accurate. "..accessibility is not just 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 does not take every user group into consideration. People with disabilities, which is a large group 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 development forward. 4http://europa.eu/rapid/press-release_IP-16-1654_en.htm 5http://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 the model.
5. Validate and evaluate the accessibility of the app prototype created.
6. Validate the accessibly improvement of the model-driven development tool with developers
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 accessible apps?
• 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 skipped in the rush of a deadline", said Kelly Schuster [16].
The proposed solution gives developers a toolset to include accessibility in mobile app development 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 model describes the main component and interactions of an app which are important for an accessible user interface. The model components and the description language are explained in Chapter3. The generator transforms the model into an app project with the enrichment of proper implementation of accessibility and additional components to support different kinds of user restrictions. Fig 1.6 shows the overview of the proposed system.
8 Chapter 1
Accapto creates Accessibility generates Enrichment depends on
App Model Components Model XMLModel Parsing & XML App Project XML Validation
User Interfaces App
Native Code
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 of any 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 of the art in development. Chapter2 presents the literature relevant to the main topics computer 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 the development of accessible apps?
Type of Result: (1) Qualitative or descriptive model: A domain model for accessible mobile apps – Chapter3 shows the design of the model for accessible mobile apps and the domain specific language (DSL) to describe it.
(2) Procedure or technique: Integration of accessibility in the development process with model-driven development – Chapter4 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 - Chapter5 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 user groups, 2016 [20])
(2) Experience: Evaluation of the Accapto tool with developers - Chapter6 points out how developers use the tool in a test scenario and the improved accessibility of the resulting 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 Development Methods? will be published at ICCHP 2018
• Krainz and Miesenberger Accapto, a Generic Design and Development Toolkit for 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 Communication with 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 on visually 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 Blind People in Public Transport [25]
• Bischof, Krajnc, Dornhofer, & Ulm NAVCOM–WLAN Communication with Public Transport Vehicles to Support Visually Impaired and Blind People [26]
10 Chapter 2
Background and Related Work
According to RQ 1 – How can model-driven development support the development of accessible apps?, this chapter establishes the groundwork for this thesis. The first part of the literature review covers accessibility and the accessibility of mobile applications in detail. The second part considers the topic of model-driven development, with a focus on user interfaces, mobile applications and accessibility. Based on the literature review it can be argued that model-driven development enhances the development of accessible 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 great experience. There are definitions and standards for the usability of a system (see Nielsen [27] and ISO 9241-11 [28]). For some people, however, user experience is subordinate if they are not able to get access to the system at all, which leads to accessibility.
The ISO Standard ISO 9241-171:2008 [29] defines accessibility as:
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 product or 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, injuries and disabilities in a standardised hierarchical categorisation. This classification is used to give a clear distribution of these disabilities.
The W3C Web Accessibility Initiative (WAI) [32] gives an overview of the wide diversity of people and abilities. WAI also provides descriptions as well as some technical aspects for people with special needs [33]. These personas are helpful to present a typical 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 be 50 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 as a braille display. Interaction with a mouse is not possible and the use of touch screens is 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 support while using, for instance, a smartphone.
Websites and apps have to provide sufficient text sizes and visual information or proper implementation to use zooming. Adequate contrast in the user interfaces is also im- portant.
1http://apps.who.int/classifications/icd10/browse/2016/en#/H53-H54 2http://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 sounds or spoken texts. Sometimes sign language is the mother tongue of a deaf person and written texts are not always feasible. In this context, we have to distinguish between deaf people and people with hearing impairments. These different groups also need different 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 or alarms 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 physical handicap can mostly retrieve information in a visual or audio form, but are limited in the active interaction with a system. There are various diseases like paralysis, tremors or 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 to improve accessibility
2.1.1.5 People with cognitive disabilities
People with cognitive disabilities are a very heterogeneous group. Older people with dementia (IDC G30-G32 4) or humans with intellectual disability (IDC F70-795) have problems perceiving and understanding complex user interfaces on computers. More- over, the reduced ability to read complicated texts and comprehend abstract concepts which 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 also legal regulations and international acts to enable digital technologies for all humans.
3http://apps.who.int/classifications/icd10/browse/2016/en#/H90.0 4http://apps.who.int/classifications/icd10/browse/2016/en#/G30-G32 5http://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 and services, 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 the European Parliament and of the Council of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies (ext with EEA relevance) [13] ensures that websites and mobile applications of public sector bodies are accessible for 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 Disability Discrimination act (Behindertengleichstellungsgesetz)citebehindertengesetz ensure the accessibility of digital systems.
§6 Absatz (Abs.) 5 Behindertengleichstellungsgesetz definiert, dass (...) technische Gebrauchsgegenstände, Systeme der Informationsverarbeitung sowie andere gestaltete Lebensbereiche barrierefrei sind, wenn sie für Menschen 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 have their 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 the Web, 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, this standard was superseded by the WCAG 2.0 [14]. In 2012 the WCAG 2.0 became the standard 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 way must also have text alternatives.
• Operable - All components must be operable; for instance, keyboard access must 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 the meanings, interaction must be predictable and input assistance like instructions or 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 from classic 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, are the focus of Mobile Web Best Practices (MWBP) [43]. Some adaptations for mobile web are also applicable to increase the accessibility which can be found in the Rela- tionship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) [44].
The basic principles of the WCAG, which are not focused on technology but on the user’s needs, can also be used in other domains of ICT. The Guidance on Applying WCAG 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/needs to 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 general accessibility guidelines to mobile platforms. The WCAG principles are transferred to smartphones, tablets and also smart wearables with specific interpretations for mobile devices. For example, the principle perceivable has to focus on smaller displays or even 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 information as 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 create and consume them. The User Agent Accessibility Guidelines (UAAG 2.0) [47] consider browsers, media players and other tools for users to consume (web) content. These guidelines cover accessibility of the tools along with the interfaces of other assistive technologies.
The Authoring Tool Accessibility Guidelines (ATAG 2.0) [48] considers the accessibility of the software and services to create web content and offers guidance to make the tools accessible. More importantly, it provides support for authors and editors to create their 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 age of smartphones, people with special needs also had to use special devices as their personal digital assistants, such as the Pronto organizer from Baum8. These very special devices were also quite expensive.
Today most people own a smartphone, which supports them in their daily life. But actually, 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. Both mobile operating systems have their own accessibility support, but there is no general standard. The W3C has released a working draft to apply the commonly accepted WCAG to mobile systems and applications. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile [49] is based on the same principles as the WCAG 2.0, but they are more specific on mobile. In this context, mobile is generic for smartphones, tablets and smart wearables.
Principles for mobile:
• Perceivable: One common feature of mobile devices is the small screen size or even the absence of the screen. Users need the ability to zoom. Contents should 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 the touchscreen. Interactive user interface controls like buttons must be reached easily. External keyboards are also an important factor to be able to operate a mobile device.
• Understandable: A consistent layout and a clear indication that elements provide interaction are important factors to understand a user interface. Accessibility problems can also occur with unpredicted changes in the screen orientation.
• Robust: Robustness is provided with easy data entry and preselection of input types. In custom solutions, the platform characteristics for accessibility support like 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 account for 99,8% of the market. Nevertheless, in a commercial context, Windows Mobile still has 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 integration of the built-in screenreader VoiceOver, which reads captions and audio descriptions. Display customisation with appropriate fonts and colours (e.g. colour schemes for the visually impaired) are part of the system. Apple’s iOS has a guided access for people with attention and sensory challenges[50].
More detailed information and specially issues for proper development are available on Accessibility Programming Guide for iOS [51]. Important points concerning the integrated 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% of the 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 range of devices including mobile ones like phones and tablets. In this universal approach of Microsofts 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 main focus 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), a screen reader was not integrated in the system, but was available as app. Custom
9https://www.statista.com/statistics/266136/global-market-share-held-by-s martphone-operating-systems/ 10https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp 11The 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 of an system wide support.
In the latter versions of the mobile operating system Google provides guidelines and programming 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 and use 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 proper contrast ratio. A ratio with a least 4.5:1 for the app’s primary, secondary, and accent 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, flashing components should be avoided and for any timed controls the user must have enough time for an accessible user experience.
3. Style: Touchable components must provide at least a minimum touch target size of 48x48dp. Smaller icons also have to expand the touch size. The spacing between elements has to be at least 8dp. The grouping of the belonging UI elements allows for simpler interaction.
4. Hierarchy and focus: Proper position of items in visual and also tabbing order is crucial for linear navigation, for example while using a screen reader. With the help of the focus the right order is made possible. Linear navigation also depends on adequate grouping of the elements.
5. Writing: Reasonable and understandable apps rely on succinct texts for labels and descriptions.
Android has different built-in assistive technologies to provide alternative use cases to handle an app. Via the system settings, supporting tools like magnification, switch access, 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 physical keyboards. A more general approach of user centered design for accessible mobile programs is part of Krajnc et al. [24]. With personas, paper prototypes and a final implementation blind people receive a tailored user experience on their phone.
With the rise of modern touch-based smartphones, physical keyboards and buttons vanished. 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 interaction for the blind, in a study on the different tasks of users. Not only touch input, but also motion 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 are also the target group of Sierra et al. [62]. They design apps for the visually impaired and 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 gives developers 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 to supportive tools like Talking Dialer, SoundBack, KickBack and finally TalkBack which is now the foundation of Androids assistive technologies. One of the latest spin offs ist Just 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 faces new challenges on smartphones. Naftali &Findlater [67] tried to understand this new need. Their study reveals issues in touch input systems like text entry in small input fields. 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 with the 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. Smartphones with apps function as portable listening devices [71] or hearing aids [72]. Apps are helpful 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 their mother 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 integrated approach on mobile platforms. New challenges also arise with external content like media 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 heterogeneous group 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 factors are the wish to communicate with friends and family as well as safety in emergency situations. Older people also have problems with mobile devices and apps. Issues are too small font or touch sizes, new gestures (e.g. swipe) and also with the ability to learn new interaction models.
Still, smartphones are useful tools in healthcare for older people [81, 82]; new methods of user interactions like augmented reality on mobile phones [83] also enhance the target groups of people with special needs on mobile applications.
The literature review shows that mobile devices are an assistive technology for both different situations and different disabilities. Diverse restrictions need specialised so- lutions to the problems. Many of these examples are focused on a special task or a special kind of restriction. A new challenge is the widespread support of different disabilities 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 designers hardly put this guidelines and recommendations into practice. The lack of awareness and the missing support of developer-tools, which should guide and lead to better ac- cessibility in resulting software products, addresses the main research questions of this 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 reduce the complexity of the development process [84]. A model-based approach helps the stakeholders of a software project to reach these objectives [85], [86]. Models are helpful for the communication between software engineers and other involved parties, to share the knowledge of the domain and the documentation of the resulting software product[87].
Model-driven architecture (MDA), model-driven development (MDD) or model-driven software engineering (MDSE) are various terms for this development approach. The method of model-driven development creates software or source code automatically from a formal model [85]. In Figure 2.2, the core components and the basic idea are shown. The modeling language describes an application model; the transformation generates schematic repetitive code from an instance of the application model; gener- ated code and additional individual code finally build the resulting application
describes Application Model
Modeling Language transforms
Transformation defines Individual Code
Application transforms
Generated Code
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 and tools [85]
22 Chapter 2
• Improved development: with automatisation the development speed increases and the code quality improves [85]
For a deeper understanding we focus on models, domain specific languages and the transformation 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 people create simpler models to deal with complex contexts [86]. Model-driven development uses several kinds of models. Even a model is an abstraction of a meta-model, which is again an abstraction to a meta-meta-model. Figure 2.2 shows the relation in these different layers.
Domain Model Meta-Model
“Real World” Elements of the Elements of the Objects Model Meta-Model
describes describes
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 the different 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 Person which describes generic persons. The definition of the user model is provided by the meta-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 the models concept, which can be either textual or visual citebrambilla:2012aa. The main parts are the following:
• Abstract syntax - the structure of the language
23 Chapter 2
Table 2.1: Four-layer-metamodel hierarchy
language to define M3 Meta-Meta-Model e.g. MOF the meta-model Language to define M2 Meta-Model e.g. UML model describes a specific M1 Model e.g. class Person model in a domain running instance of M0 Instance e.g. Person p = "John" the model
• 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 the Unified Modelling Language (UML).
UML (Unified Modeling Language) is the standard modeling language for several parts of the software development process. UML is specified by the Object Management Group (UMG). The current version is UML 2.5 and is online available [90].
Beside the general approach, DSL addresses a specific application domain. They are designed for a particular domain [91]. This is not only a limitation but also a benefit for clear definitions and the abstraction of the domain. A DSL is limited in its expressiveness [91]. It is not possible to build a whole software system based on this type of modeling languages. Some typical examples of DSL are SQL, a language to describe 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 for extension 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 host language. Typical host languages are Ruby or XML [95]. External DSL is a new language 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 the model. To reach this goal, the model is transformed to another abstraction layer. This is either a model-to-text or a model-to-model transformation [86]. The latter approach creates another model for special issues in the domain or for special needs of other projects members. For the process of automatic source code generation, the model is transformed into a textual form like program code or XML [87].
defind by
Meta Model leads to depends on
Transformation Individual Model Language Toolchain Code
Transformation Generated Model Application Process Code
Figure 2.4: The transformation process of model-driven development.
The typical process of software generation is described in Fig. 2.4. The model based on the meta-model is the input for the transformation process. With various methods of transformation the source code artefact is created. Developers can modify the resulting code and can also add their own indiviual program parts. This new codebase with generated and individual code creates the final application in the domain of the model.
Typical code generation patterns [96, 85] are:
• Templates + Filtering - the code is generated from the model and embedded in a 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 this is the Cameleon Reference Framework [100]. The highest levels are tasks within the domain. 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 but is still implementation-independent. At the end, we have the Final UI that represents the implementation in the final source code [2], [101]. Fig. 2.5 shows this concept with simplified 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 and aims in an interactive application [102]. One widely adopted task-modeling notation is ConcurTaskTrees (CTT) [103]. CTT distinguishes different kinds such as system, in- teraction, user or abstract tasks and a designer can model the interaction of a process in a graphical tool.
26 Chapter 2
Another aspect is the Abstract UI models. Beuvens et al.[104] give a generic definition of them for the definition of user interfaces corresponding to the Platform-Independent Model (PIM) in model-driven engineering.
User interface description languages
Model-based approaches for UI development are often described in a user interface description 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 designing and 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 for applications like Firefox are build fromut of this platform independent description.
IndieUI [107] from W3C is an approach to design the user interface of accessible web applications. With events [108] and user context [109] applications can be built for a wide 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 by different 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 a model.
The workflows are an important part of interactive software products. IFML (Interaction Flow Markup Language) by Brambilla & Fraternali [116] describes these flows in an abstract way. With view containers and their connection via events the interaction through an application is defined and is the basis for further development or code generation.
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 the practicality 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 in literature. A starting point is the work of Umuhoza & Brambilla, which shows several techniques of MDD and defines criteria to classify these approaches [118]. Early examples were still focused on web applications optimised for mobile devices. Braun et 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 creation and evaluation.
MD2 (Heitkötter et al. [121]) creates cross-platform apps from a model. This work focuses on business apps where common source code is compiled into native iOS and Android apps.
Another instance of a model-based method is Le Goaer & Waltham’s [122]. Their custom DSL is used for mobile apps. Majchrzak et al. [123] engineer mobile business cross-platform apps with the aims of model-driven development. Another approach of a DSL for mobile apps is XIS [124]. The model is based on UML and the resulting apps are created for different platforms. The usage of this model-driven method has been 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 of mobile apps [128] as well as the usage for web and mobile applications [129] is part of the work of Brambilla et al.
Barrnet et al. [130] present a tool to generate data-driven apps based on a domain specific 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 can be 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, depending on the users restriction [134]. A framework for accessible applications is Johar by Andrews & Hussain. This approach covers a wide range of disabilities. The interface interpreter transforms the interaction model into a final Java application.
The AT lab app framework [135] allows the creation of games for people with physical disabilities. The work of Gonzales Garcia al. [136, 137] presents the design and implementation 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 an interface generator to transform XML models via XSL into an adapted accessible user interfaces [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 an adaptive 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 to the users. Accessible user interfaces for ubiquitous services are automatic generated in [145].
2.5 Summary
The literature review reveals that model-driven development is used in different areas of development. User interfaces or mobile applications based on MDD can be found in literature. Even the usage to improve accessibility in software products is part of current research.
The research fields accessibility, mobile applications and model-driven development are widely discussed in literature. In Figure 2.6, the overlapping of these different areas is shown. There has already been some exciting work done that deals with the outer intersections. For example, accessibility and mobile development or accessibility and model-driven development have been covered by previous papers, but all three fields of research are seldom discussed together in the scientific community (see [21]).
29 Chapter 2
Mobile Development
A11y + Mobile + Accessibility MDD
Model-driven Development
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 is an 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 efficiently in situations where they miss profound knowledge in terms of accessibility. The aim of this 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 the model.
30 Chapter 3
Model-Driven Development for 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 model for accessible apps we have to identify the components of the app.
Following the WAI the foundation for accessibility is using simple interactions to create complex 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 easy interactions or workflows. Before designing an accessible app, however, one has to design an app at all.
The user interface and the interaction design are the most relevant parts of an app for accessibility. According to Banga and Weinhold [147] good mobile interaction design leads the user through an app. The key factors are clear and simple controls, but more importantly reducing the functionality of the app is essential. Banga and Weinhold [148] offer useful tools and techniques to design user interaction. Suitable tools to design 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 help of 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 the development process. Fig 3.2 illustrates this intuitive method to design the flow within an app, but this tool is limited to iOS development. A similar tool to design interaction and navigation on the Android platform is the Navigation Editor (http://tools.and roid.com/navigation-editor). Unfortunately this tool was just experimental and is 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 section presents the usage of UML for user interaction and accessibility.
For more general modelling of interaction one needs also more generic modelling tools UML is used in different within in software engineering. The next sections shows the usage 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 system mostly from the perspective of a person’s needs. The user as a role e.g. a customer and their use-cases in the system. Fig. 3.3 gives an example of the use case for a routing 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 is used. 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 a sequence diagram [152].
A Collaboration/Communication Diagramm focuses on communication rather than the sequence of messages. An Activity Diagram describes behavioural flows in a system, like procedures or logical flows. The process is described using action states and activity edges. Fig. 3.5 shows the decision process of the address selection in
33 Chapter 3
<
<
Figure 3.3: Example of a UML use case diagram for a simple routing app.
Select Routing Target Routing Target Calculate Route
checkStoredLocations()
getAddressGPSPosition() enterAddress
getGPSfromAddress()
getGPSPosition()
Figure 3.4: Example of a UML sequence diagram for geocoding in routing app.
Select Routing Routing Target
Search Address
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 of sequence and activity diagram. This kind of diagram expresses the overall flow in a system [152].
Ambler [153, 154] claims that UML does not support any diagrams related to flowcharts or storyboards. Nevertheless, Conallen [155] provides examples of employing UML in model 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 app development. Kraemer [156] uses UML with statical and behavioural diagrams to modelling mobile apps. With the help of building blocks and libraries an Android app is created from models. Specific aspects of Android app like intents, data/service requests are part of the approach of Parada et al. [126]. Le Goaer et al. [157] combine modelling and code generation with standard coding for their method of model-driven development. User interfaces generation is the aim of Sabraoui et.al. [158] work. UML is used for graphic user interfaces. Based on a meta-model for basic UI components an 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 of UML. 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. give an example of defining accessibility constraints with UML [164] as well as testing the accessibility 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 accessible app.
As written in the last section there are some requirements for an accessible mobile app.
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 are needed. 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 component is used. These base elements for the accessible app model are described in detail in the 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 break down the overall interaction flow into smaller parts. As seen in the storyboards or wireframes, these define the interaction flow with the connection of several container elements.
This model uses the Screen as the grouping component. The screen element is one component in the interaction flow and contains sub-elements for direct user interaction like 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 from one screen to another is required. The navigation component is Transition, which is part of a screen and lets the user navigate to another target screen element or outside of 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 is required. The Action element allows a method or procedure to be triggered, which is provided by either the system, a library or the developers. An action element is part of a 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 of the 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 like text, 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 accessible app it is important to provide a textual information for any element related to user interaction. Additionally, each element has an optional description attribute for more detailed information, which is provided on demand.
App Container: Last but not least all these elements are part of one complete mobile application. An app element has at least one screen element. Meta information about the 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 user groups. 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 of an app needs a name, package and at least one screen element. Screen items may have input, output, action or transition elements.
Based on this meta model developers and designers may start with a sketch of an app in a paper prototype or a mockup tool and are able to transfer the draft to a more formal model.
0..* 0..* App Screen Input
profil: String [1..5] 1..* name: String name: String Description: String [0..1] appname: String Description: String [0..1] package: String type: String
0..* 0..* 0..* Action Transition Output
name: String name: String name: String description: String [0..1] description: String [0..1] Description: String [0..1] target: String type: String
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) the basic sketch of the app idea. The app has a dashboard with one flow to the second interactive screen. The position screen has a button to trigger the current location which 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 profile blind 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 used in the automatic part of the development process.
appname: Where Am I Position Where Am I package: org.accapto.whereami getGPS-Position profile: blind Start
47.31, 9.64 Screen:Start Screen: Position Output: Where am I Output: Position Transition: Position Action: getPosition Input: 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 processing of the model, text-based formats are also a benefit. The next section goes deeper into the text form of the model.
3.3 Model Description (DSL) for Accessible Apps
For developers, textual descriptions of formal definitions are common. One possible way 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 or syntax for the DSL. An external DSL is based on a new syntax. This provides freedom in the definition but beside creating the modelling language also the processing tools are also new. For example, Barnet et al. [130] use a JSON-like syntax and they implemented 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 language you choose [166].
In this work an internal DSL based on XML is used. XML has many advantages. First of 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 definitions for 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 choose their 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 and transforming XML-based data, developers can mostly choose from various programs on the selected platform.
The model definition in this works defines tags for each element. For example, the Screen element is represent with a screen-tag. Further information on the element is given in either in an attribute (e.g. name="Start Screen") or in a child element. The example below shows a typical screen element as an XML tag.
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 file be valid. The XML Schema Definition (XSD) describes the structure and constrains of the contents of XML documents [168, 169].
The meta-model for accessible apps is defined in XSD. Every valid tag in the definition is defined as a complex type. This represents a composite tag with predefined child tags and attributes. The following example demonstrates the definition of the screen tag. This tag has a sequence of child tags like an input tag. Every child tag can occur more than once and is not mandatory. Every screen tag may have the attributes name and description. The name attribute is mandatory because for proper implementation for accessibility, each element needs at least one textual description.
40 Chapter 3
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. The app model contains a surrounding app element with appname and package. The required profile blind is also in the root tag. The model consists of two screen tags with a name attribute. Both screens include child elements (e.g. output or transition).
41 Chapter 3
3.4 Summary
This chapter presents the model for the development of accessible apps. In many cases, 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 app development..
To answer the research question, What kind of model is needed for the model-driven approach? 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 model consists 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 in XML.
This is the first step in the model-driven development approach. The focus of the next chapter (Chapter4) is the transformation from XML model to Android app prototype.
42 Chapter 4
Generation of Accessible Apps
This chapter focuses on the process from model to final Android application. Fig. 4.1 presents an overview of the app generation process. The first step is the model of the app in the XML file; next comes parsing of the XML file, which leads to an instance of the model in the generator. The app scaffolding and accessibility enhancing is part of the generator; the resulting output is an Android Studio project.
According to Völter [96], code generation is getting important for the development of a 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 integration of accessibility (features). The Accapto generator uses the Templates + Metamodel pattern 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
Accessibility Generated App Model XML Parsing App Scaffolding App XML Extension Project
Parsing XML File Add Accessibility Lib Unmarschal XML Adopt App Components Create Instance of model
Create Project Structure Add custom Code Generate App Components Build App
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 the source code generation is different for distinct mobile operating systems. This thesis focuses on Android.
Android covers about 85% of the market; it is the most widely spread mobile operating system1. It has a layered architecture based on a multi user Linux kernel. The middle layer 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 to the user, like the app launcher, the phone application, various web browsers, etc., are apps. 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 and other 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 connect them 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-s martphone-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 gives an overview of the XML-to-Java relations for the parsing process. In the first step Java classes are created, which represent the XML based model from the XSD. From the schema description the corresponding java classes are generated, These classes match the elements in the XML model (see Appendix A.1 for the complete XSD). After reading and parsing an XML input file, the JAXB framework unmarshals Java objects from 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 model at runtime is the input for the next part in the Accapto generator, the app scaffolding process.
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 an instance of an AppType object. The AppScaffolder creates the whole Android project structure. All ScreenType objects of an AppType are used in the ManifestBuilder and in the ScreenTemplating. ScreenTemplating creates an activity and the layout from each screen of the model. The ManifestBuilder adds the necessary entries in the Android Manifest file. 2https://docs.oracle.com/javase/tutorial/jaxb/intro/arch.html
45 Chapter 4
follows Instances of
marshal
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 the XML input. The input to create the app project prototype is an instance of the model in the form of the Apptype-object. This object contains all meta information about the app, the structure of the user interface and the flow through the app. The necessary files and folders of an empty Android project are created based on the meta information app-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 single user interface screen including elements for user interaction (input and output widgets and interactive components). For each Screen, the templating process transforms the model into Java source-code for an activity and Java methods and the corresponding XML layout definition. The templating of the activity and layout files is described in the next section.
4.3.2 Templating
The transformation from model to source code follows the Templates + Metamodel pattern [96]. The input for this pattern is a concrete instance of the model, for example a Screen object. The template engine FreeMarker3 [175] uses this input to fill the template 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 source code after the templating process.
More details of this process reveals the following example of a transition from one screen 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. The template, which is stored in a separate file, is loaded and processed in the template engine.
private void createTransition(TransitionType transition) {
layoutTemplate.put("name", transition.getName()); layoutTemplate.put("description", transition.getDescription());
47 Chapter 4
Java Object Template package ${package};
... public class ${activityname} extends BaseActivity{ ScreenType screen = new ScreenType(); public void onCreate(Bundle savedInstanceState){ screen.setName("Start"); setContentView(R.layout.${activity_layout}); ... } ...
Output package org.accapto.app;
public class Start extends BaseActivity{
Freemarker 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 the apps workflow starts a new user interface screen with an Android intent. The method gets 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 the resulting button is created with the name of the transition target.
48 Chapter 4
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 source software project and can be found at https://github.com/elmarkrainz/accap to.
4.4 Accessibility Enrichment in Android Apps
Like most integrated development environments (IDE), Android Studio comes with many 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
Chapter2 of this thesis already introduced mobile accessibility and the special cases on the Android platform. This section gives an overview of the right implementation for accessibility. The official Android documentation provides help for accessible de- sign [54], implementation [176] and evaluation [177]. In the Github repository Google Samples a basic accessibility implementation is provided (https://github.com/g ooglesamples/android-BasicAccessibility). Ted Drake’s website [178] in- sists on referring the The Missing Manual for accessibility on Android. To sum up these sources the following topics are most relevant for accessible implementation in Android.
Labeling UI Elements
An important factor for accessibility is perceiving the information. In many cases a textual description is critical for accessibility, because users without reading abilities depend on Talkback. The attribute android:contentDescription should be used for graphical elements . This attribute is ignored for decorative elements having the value null or can be set at runtime applying the method setContentDescription(). To indicate an element’s purpose the attribute android:hint adds a description to an 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.
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 are also too small. The attributes minWidth and maxWidth must have at least a value of 48dp4. Even if the element is not displayed in this size the touchable target is larger.
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 embed them in a container element. This allows the response of all the group elements when the container gets the focus [179].
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 tabbing is 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 in two buttons of the layout (see Keyboard Navigation5).
..
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) should have a minimum contrast ratio of 3.0 to 1. Smaller text requires a contrast ration of 4.5 to 1. This ensures readability for handicapped people. If images are an essential part of the user interface (more than decorative purpose), they should also follow this guideline.
To You want To You want to continue? 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 in mind. The basis for the accessible development is defined in an improved Android Accessibility 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 four code-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 larger fonts 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-code generation 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 elements of the type image. In the code-generation this is transformed to an ImageView. The mandatory name and the optional description are used to create the content descrip- tion attribute.
Image output in modelling language:
Generated ImageView component with non-text description:
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 Android style theme. The prototype includes three styles: default, high-contrast and blind (see Fig 4.7). Each theme has a tailored contrast level, which is designed for different restrictions.
Fig 4.7 (a) shows the default style of the generation process. This style is based on the 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 flow through the app makes the navigation simple. The interaction via external keyboard or via tabbing is possible in this layout.
Touchsize
Every touchable element, especially smaller ones like checkboxes or radio buttons gets a minimum width and height of 48dp. This makes the handling of smaller items easier 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 an optional description. These entities are used to create the name, hint, or an additional label in the resulting user interface.
The snippet below shows an input element with the type text. The item has the name search target and the description enter a routing target.
The transformation creates part of the XML-based layout. The resulting user interface is 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.
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. For further improvement, the Accapto framework includes a library of accessibility patterns to extend the accessibility at app runtime. The following examples show four different use cases for additional functionality to improve accessibility.
TouchAreaExtender
This supporting module allows the touch-target-area of an UI element to be extended at runtime. For example, a person with a motor disability has problems selecting a checkbox control, because it is too small. Developers get an API to extend the clickable 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 padding are the parameters of this method. The area around the UI element can be touched which 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 area around 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 setup of the app (an important factor of an accessible app is the possibility for own settings and 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 change its 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 the high contrast profile. The last selected theme is stored in the app and loaded again at every restart. Fig 4.7 shows examples of the different styles and themes included in the Accapto Accessibility Pattern Library. The following code is loaded for each activity in 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. The changeTheme() 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 user interface, but Talkback also needs training to be a useful assistive technology. In some cases users need only selected spoken feedback, which is included in the app. With the SpeechOutput class developers get a fast way of integrating text-to-speech into an mobile 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 the setup 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 off when 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 or visual disabilities can avoid the onscreen keyboard which is not always accessible. The SpeechInput class wraps the speech input to give developers a fast way to integrate this feature.
The startSpeechInput() exchanges the onscreen keyboard with voice input. The method starts 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 is automatically integrated into the generation process. Features are partly integrated from the beginning in the custom app or can be used by developers to improve the accessibility 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 a toolkit 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 of the complete process from the model in XML, app generation, accessibility enhance- ment and individual code.
Accapto creates Accessibility generates Enrichment depends on
App Model Components Model XMLModel Parsing & XML App Project XML Validation
User Interfaces App
Native Code
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 could lead to transiting to other screens. The interaction model simplifies the interaction of the app as a linear communication process with defined workflows. This is also the foundation 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 tools based on the command line. These types of programs need improved know-how on computers, 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 are publicly available as an open source project at https://github.com/elmarkrai nz/accapto.
4.6 Summary
This chapter presents the generation of accessible apps from an interaction design model (see Chapter3). The generation process starts with parsing the model from an XML input file and creates an instance of the model in the generator. The model is 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 features are 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 and individual 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.This procedure is the accessible app toolkit – Accapto.
58 Chapter 5
Accessibility Evaluation of the Resulting App Prototype
The last chapter presented the generation process and the enrichment of accessibility to the generated app prototype. According to Shaw [18], presenting an example is one possible way of validating a new procedure. This chapter shows the development of 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 prototype of the demanded app. The final implementation was presented in Krainz et al [20]. Furthermore, the accessibility of the generated app prototype is tested with different methods.
Enter Routing Target Routing Overview
From: … .. To: .... Duration: … Distance: .... Search Routing Details
Start Routing Routing App Direction: …
New Target Start
Settings
Settings Settings Routing Profile Normal Normal High Contrast Wheelchair
Talkback Blind
Speech Outp.
Routing Profile
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. Analysing the 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 the arrows from screen object to screen object. With the meta-model presented in Chap- ter3 the model is defined in XML. Listing 20 shows a code snippet of the model with the app meta information appname and package which is essential for any Android app. Furthermore, the model contains the Start screen with a textual output and the transition to the RoutingTarget. The screen RoutingTarget has a textual input compo- nent and an active action element to trigger an underlying functionality. The complete model of the routing app in XML is in AppendixA.
The next step in the development process is the code generation. The code generator is designed as a command line program1. The benefits of this approach is that it is a lean and clear tool. Developers are used to command line functionality2 and command line 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 Android SDK or opened with Android Studio.
1Linux command line program definition http://www.linfo.org/command_line_program.htm l 2For example the Cordova Framework is based on the command line http://cordova.apache.o rg/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 the dashboard of the Start screen in the high contrast profile. This profile is designed for 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 different input fields. This is the standard profile with proper implementation of accessibility like suitable 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 prototype for further development. The next section presents the accessibility evaluation of the generated app.
5.2.1 Accessibility Evaluation Android Smartphone Apps
The measurement of accessibility is not an easy target. Compared to other disciplines in 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 the number 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 usability attributes by Nielsen [27]. Mattheiss & Krajnc [25] present a user study with user observation, 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 good starting point for accessibility testing with Talkback was shown by Henry [185]. Schus- ter [16] provides insights into the usage of Accessibility Scanner. Information about methods which can be directly integrated into the software engineering process also exists (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 for accessibility 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 using the 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 are detected in this step.
In order to evaluate the app, one has to turn on the assistive technologies and use the app. Navigating through the Android system or a native app with these helpful platform features needs some training before the actual usage, but this first check is included in each Android device
Manual Testing Prototype:
The generate app prototype supports the internal screen reader, all elements have sufficient 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 and also 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 possibly missed with manual testing. Missing labels, wrong size of a touchable element or in- sufficient colour contrast can be detected. The tool Accessibility Scanner3 is integrated into the Android system and can be easily activated 4. It scans the user interface of an active app and reports errors in Content labeling, Implementation, Touch target size and 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 in several categories, one of which is accessibility (see https://developer.andro id.com/studio/write/lint.html). Fig 5.3 gives an example accessibility issues reported 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.auditor 4https://support.google.com/accessibility/android/answer/6376570 5https://support.google.com/accessibility/android/answer/6376559
63 Chapter 5
Test tools and frameworks cover programmatically implemented features but testing with 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 provide support 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 Apply to 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 this ruleset manually. The first principle – perceivable – was fulfilled in all three guidelines small 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. The criterion device manipulation gestures was not part of the app and therefore neither passed nor failed. One criterion had failed the evaluation; the the position of apps user interface elements (buttons, checkboxes, etc.) was too generic in the linear order (Linear Layout). Although this is no problem while tabbing through the app, handling the 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, grouping elements, indication of active elements), while the rule instruction for custom gestures was not part of the app.
The robustness as the last principle was passed in the two guidelines easy data entry and support of platform characteristics was passed. The criterion set keyboard to 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 rules passed, three were not relevant and only one failed in the evaluation. The Mobile Accessibility 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
Fulfilment Comment Yes No N/A Principle 1: Perceivable 1.1 Small Screen Size x 1.2 Zoom/Magnification x 1.3 Contrast x checked with Accessi- bility Scanner Principle 2: Operable 2.1 Keyboard Control for Touchscreen x tested with different Devices keyboards including external keyboards 2.2 Touch Target Size and Spacing x checked with Accessi- bility Scanner 2.3 Touchscreen Gestures x 2.4 Device Manipulation Gestures x 2.5 Placing buttons where they are easy x Improvement of widget to access is possible Principle 3: Understandable 3.1 Changing Screen Orientation (Por- x trait/Landscape) 3.2 Consistent Layout x 3.3 Positioning important page elements x before the page scroll 3.4 Grouping operable elements that per- x form the same action 3.5 Provide clear indication that elements x are actionable 3.6 Provide instructions for custom touch- x screen and device manipulation gestures Principle 4: Robust 4.1 Set the virtual keyboard to the type of x data entry required 4.2 Provide easy methods for data entry x 4.3 Support the characteristic properties x generated apps are of the platform only 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 standard for 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 restricted to the web; but its generic rules can also be adapted to all kinds of computer user interfaces.
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 can be 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 navigation within 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 use content 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 and understandable. This rule is related to the language of the content. In the prototype of the app generator, the dynamic multi language aspect was not implemented, which is why 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
Fulfilment Level A Level AA Comment Yes No N/A Yes No N/A Guideline 1.1 1.1.1 Non-text Content x Guideline 1.2 1.2.1 Audio-only and Video-only x (Prerecorded) 1.2.2 Captions (Prerecorded) x 1.2.3 Audio Description or Media x Alternative (Prerecorded) 1.2.4 Captions (Live) x 1.2.5 Audio Description (Prere- x corded) Guideline 1.3 1.3.1 Info and Relationships x 1.3.2 Meaningful Sequence x 1.3.3 Sensory Characteristics x Guideline 1.4 1.4.1 Use of Color x 1.4.2 Audio Control x 1.4.3 Contrast (Minimum) x 1.4.4 Resize text x 1.4.5 Images of Text x Guideline 2.1 2.1.1 Keyboard x 2.1.2 No Keyboard Trap x Guideline 2.2 2.2.1 Timing Adjustable x 2.2.2 Pause, Stop, Hide x 2.2.3 No Timing x Guideline 2.3 2.3.1 Three Flashes or Below x Threshold Guideline 2.4 2.4.1 Bypass Blocks x 2.4.2 Page Titled x 2.4.3 Focus Order x 2.4.4 Link Purpose (In Context) x 2.4.5 Multiple Ways x 2.4.6 Headings and Labels x 2.4.7 Focus Visible x
67 Chapter 5
Results of WCAG Evaluation 20 Overall Level A Level AA 15 10 5 0
Pass Fail N/A
Figure 5.5: Results of the WCAG evaluation. Overall 20 rules passed, 2 rules failed in the evaluation and 15 rules were not applicable.
Table 5.3: Evaluation with W3C WCAG 2.0 levels A and AA, part 2
Fulfilment Level A Level AA Comment Yes No N/A Yes No N/A Guideline 3.1 3.1.1 Language of Page x not imple- mented in this version 3.1.2 Language of Parts x not imple- mented in this version Guideline 3.2 3.2.1 On Focus x 3.2.2 On Input x Guideline 3.3 3.3.1 Error Identification x 3.3.2 Labels or Instructions x 3.3.3 Error Suggestion x 3.3.4 Error Prevention (Legal, Fi- x nancial, Data) Guideline 4.1 4.1.1 Parsing x 4.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 not enough. For a real user experience the app needs more functionality.
Based on the prototype generated with the model-driven development approach, the routing app was enhanced to a working prototype. app. The given user interface and app work-flow was extended with a data connection to an existing routing service, the integration of a built-in routing algorithm and a map.
The result is an accessible smartphone app on the Android platform. It allows access to a routing service with different configurations for the needs of special user groups and 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 the settings to change different visual styles for different disabilities. This evaluation has already 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 that match the pattern of our application. To get as many views as possible, we used three different 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 system among 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 test users had different limitations such as visual or cognitive impairment. Among the participants there were eight men and four women between the ages of 20 and 65 years. Three people had a very strong visual restriction (IDC-10 H54.0 - H54.1)6, they required 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 of 60. To acquire some data about the general usability of the app two tests with users without 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. Starting with typical tasks like changing the app setting and the visual appearance, afterwards the participants had to navigate to a given target location. The location was provided in the form of an address. Users had two options: follow a turn by turn navigation with textual 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 the app 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. The app provided two navigation options; following the path on a visual map or following turn 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. To meet 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 the regular ones later. The specific task of following the text output of navigation mode was not tested. The people in the test group would not have been able to focus on more than one source of information. The routing app received positive feedback. The average 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 and the 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-H54 7http://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 would be an improvement for them later on. For example, voice control for the app might be helpful [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 cognitive disabilities. The average TLX score over the three tasks was 18.9, with the highest score 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 slightly higher. On the other hand, the lowest value was 45, which is much lower than the lowest value in the first test group.
Similar to the first user test, the app got positive feedback. Testers requested that there 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 impaired people tested the application. This user group did not test the function "routing with the help of the map" (this function cannot be used without eyesight).
This target group found the application less demanding than the group of people with cognitive disabilities. The average NASA TLX was 29.2. Comparing the average score of the tasks evaluated by the group of elderly people (average: 15.4 for these two tasks), the default use of the application seems to be much easier than using it with 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 the lowest score in the second test group (57.5).
In contrast to the tests with the other participants, these tests showed limitations in the application, which are partly due to the accuracy of the GPS signal. While the other two test groups could compensate for some inaccurate instructions with their full eyesight, blind people depended on the information’s accuracy [20].
People without restrictions
The user evaluation was finished with two users without restrictions. Their average NASA-TLX value (11.25) indicates, that the demand while using the app was lower for people without any restrictions. The average SUS score (85) showed that the application is more convenient to use. However, the results of this group are close enough 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-impaired reference testers gave the best ratings, it is remarkable, that visually impaired people evaluated the settings-task to be the hardest, while it was considered an essential task among all the other test groups, as Fig. 5.8 shows. TLX of User Test 40 Cognitive Impairment Elder Persons Visual Impairment No Impairment Overall 30 20 Workload 10 0
change visual style navigation with textual description navigation with map
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 accept the application concept. However, Fig. 5.9 indicates that the most significant accep- tance of the tested application came from non-impaired people, whereas people with cognitive impairments gave our application the lowest ratings [20].
72 Chapter 5 SUS of User Test 90 Cognitive Impairment Elder Persons Visual Impairment No Impairment Overall 85 80 SUS 75 70
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 comparable values. 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 first accessibility 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 the integrated 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.4 shows an example of this rating.
The next step is the automatic check with the Accessibility Scanner. This tool gives feedback about improper implementation in the visual appearance of an app. The tool finds errors referring to the material accessibility guidelines. For the QAC all reported errors in the categories touch size, image contrast, text contrast, missing label, double
73 Chapter 5
Table 5.4: Quick accessibility check - Assistive technologies
very very not good neutral poor good (1) poor (5) reported Screenreader Tabbing external keyboard label and wrong implementation of accessibility are counted. The rating is presented in Table 5.5. Table 5.5: Quick accessibility check - Errors from Accessibility Scanner
Errors Touch size Image contrast Text contrast Missing label Double label Wrong 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 position of the UI elements. These rules are also rated on a Likert scale from very good (1) to very poor (5), as seen in Table 5.6.
Table 5.6: Quick accessibility check - manual checks
very very not good neutral poor good (1) poor (5) reported Clear and simple texts Clear navigation Readable font size Possibility of magnification Position 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 can be 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 without deeper 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 Content Accessibility Guidlines. Table 5.7 shows the association of QAC rules and WCAG success criteria and guidelines.
The Quick Accessibility Check is used in the empirical evaluation of the model-driven development process to create comparable values of similar apps. (see Chapter6)
74 Chapter 5
Table 5.7: Association of QAC Rules to WCAG Success criterions and guidelines
QAC Rule WCAG Success Criterion Assistive technologies Screenreader 1.1.1, 1.2.2 Tabbing 1.3.2, 2.4.3 external keyboard 2.1.1, 2.1.2, 2.1.3 Accessibility Scanner Touch size 2.1 Image contrast 1.4.3 Text contrast 1.4.3 Missing label 1.1.1, 1.2.2 Double label 1.1.1, 1.2.2 Wrong implantation of accessibility 4.1 Manual checks Clear and simple texts 3.1.1 Clear navigation 1.3.1, 1.3.2, 2.4.1, 2.4.3 Readable font size 1.4.4 Possibility of magnification 1.4.4 Position 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 Chapter 3) and the model-driven development approach (see Chapter4) are used to create a prototype app.
The resulting mobile application was checked with assistive technologies, evaluated with state-of-the-art guidelines (WCAG) and tested by users with different restrictions. This comprehensive accessibility evaluation shows that model-driven development leads to an accessible app prototype. Furthermore, this chapter presents a fast way to evaluate 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 the Model-Driven Development Process
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 accessible app 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 et al. [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 persistence API was the target in the work of Picconi et al. [194]. In this task-oriented study 25 experienced developers evaluated the features of this API. To improve and redesign the 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 12 developers.
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 of cryptographic 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 compare two 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 the pre-questionnaire, there were also questions designed to get an impression as to the users? awareness of the usability and accessibility of apps.
The second task was the implementation of a working app prototype. The starting point was an informal mockup prototype, which showed the essential screen with some user interface elements like labels or checkboxes. Furthermore the interaction and navigation from one screen to another was defined. The participants did not have to implement any backend functionality.
The next step was the accessibility evaluation of the resulting app. For this task the Quick Accessibility Check QAC (see Chapter5) was used.
The last task for the participants was the post questionary including a simplified Task Load Index to rate the workload of the development and self evaluation process and a second look on the users awareness of usability an accessibility.
6.2 Target Group
The target group for the empirical evaluation was developers who had experience in software development, with a special focus on mobile apps. All participants had knowledge of user interface development on the Android platform to transform the given app draft into working implementation.
This study included 50 participants. They were between 21 and 58 years old, with 7 female and 43 male programmers. 13,2 % were senior developers with a master’s degree and several years in software development, 37% were students with working experience enrolled in a part time master’s program for mobile software development and 49% are currently students in a bachelor’s degree program with existing skills in programming, human computer interaction and mobile development (see Fig 6.1). All participants were familiar with Java development and Android Studio.
77 Chapter 6
Work experience of participants
Senior developers
Junior developers
Students
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 lower than the programming skills (Fig 6.2 right).
The participant were also asked about their self-rated skills regarding user interface design and accessibility. More than 30 developers rated their design skills above the average (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 in the evaluation part.
6.3 Development Tasks
All participants started with the same requirements for a simple app prototype. They received a short description of the expected app and a simple interaction sketch with the requested user interfaces and flows through the app. Fig. 6.4 shows the paper prototype for developers.
With this requirement, the developers used two different development methods. The first 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
Programming Skills Mobile Development Skills 20 20 15 15 10 10 number number 5 5 0 0
6 very good 5 4 3 2 1 0 none 6 very good 5 4 3 2 1 0 none
Figure 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 with the tool Accapto. They got a detailed description of the structure of the meta-model in XSD and an example of the model description language in XML. From this starting point, they had to create a in the first step the model from the given app draft. With the command line tool Accapto, the model was transformed into an Android Studio app project. There were no additional tasks to implement code functionality in the IDE, but they had to use built-in tools to compile the source code and create a runnable app for the 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 the given app and package name. Following the standard development method1, they used Activities, XML-based layouts with UI elements and the intent system to create the workflow with in the app.
As all participants had already used these tools and everyone had already created at least one Android app, they had only minor problems with this task.
The detailed description of the tasks and the supporting material can be found in the project’s Github repository https://github.com/elmarkrainz/accapto/t ree/master/evaluation and in AppendixC.
1https://developer.android.com/training/basics/firstapp/index.html
79 Chapter 6
User Interface Design Skills Accessibility Skills 20 20 15 15 10 10 number number 5 5 0 0
6 very good 5 4 3 2 1 0 none 6 very good 5 4 3 2 1 0 none
Figure 6.3: UI design and accessibility skills
New POI
Name app name: POI App .. package name: org.accapto.poiapp GPS Is Public Points of Interest Add Photo
All POIs New Save Search My POIs ..
Settings POI 1 POI 2 POI 2
Settings
GPS is Active New
Username ..
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-defined accessibility 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 the Accessibility scanner in the different categories were counted. This showed an overall rating where a lower number represents better accessibility. Table 6.1 shows a typical evaluation report from a single participant. This example presents a average rating of the assistive technologies at 1.33, the numbers ob errors found by the Accessibility Scanner 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 value 4.13. This is an objective and comparable result.
Table 6.1: Single Accessibility evaluation
Assistive Technologies Screenreader 1 Tabbing 1 External keyboard 2 average 1,33 Accessibility Scanner Touch size 0 Image contrast 0 Text contrast 0 Missing label 0 Double label 0 Wrong implantation of accessibility 0 sum 0 Manuelle Checks Clear and simple texts 2 Clear navigation 2 Readable font size 3 Possibility of magnification 4 Position of the ui elements 3 average 2,8 Overall Accessibility Rating 4,13
Not all participant finished the evaluation. Some users did not finish the development part, other had problems with the accessibility tools. In the end 42 accessibility reports where 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 to estimate 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.5 presents the first impressions. Participants of the model-driven development group estimated the accessibility of their app with a mean of 3.27, better than that of those who 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
Self-estimated Accessibility of resulting app
10 Model-driven Development Conventional Android Development 8 6 4 2 good good Accessibility self-estimated bad 0
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 as well 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 rating and also in the three sub categories. Fig 6.7 presents the difference between both methods.
The first impression showed a big difference in the overall accessibility of the resulting apps. Those apps which were created with the model-driven development method had an average overall accessibility rating of 6.19, compared to 12.29 for the conventional method (a lower value indicated better accessibility). This is a significant difference; a look 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 for example, 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 much better 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, with 2.38 to 2.56.
Accessibility Evaluation
12 Model-driven Development Conventional Android Development 10 8 6 4 2 good good Rating Accessibility bad 0
Overall A11Y Rating AssistiveTech A11yScanner Manual_Checks
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 the conventional 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 the generality 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 to better 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,38 var 35,53 0,40 31,99 0,20 SD 5,96 0,63 5,66 0,45 median 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,56 var 93,93 1,02 79,89 0,32 SD 9,69 1,01 8,94 0,57 median 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 test statistics 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. The Shapiro-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 different from a normal distribution. The two samples are not normal distributed. Therefore, the t-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
Boxplot Accessibility Evaluation 40 30 20 10 good good Rating Accessibility bad 0
Model.Driven.Development Android.Studio.Development
Development Method
Figure 6.7: Boxplot of accessibility rating. from the t-test is that it does not need a normal distribution of the data and yields similar 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 the group employing the classic development approach (mean = 12.29, SD= 9.69). With a p-value of p= 0.0007789 being lower than 0.05, the hypothesis H0 of statistical equality of the means of two groups was rejected.
The analysis of the evaluation data of the model-driven development and the standard procedure shows a significant difference in the accessibility of the resulting app. The model-driven approach with Accapto creates apps with better accessibility right from the 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 approach has a different workload than the conventional Android development. The results were also compared with the workload of the evaluation task, which was the same for both groups.
To get comparable results the TLX [183] was used. The participants had to rate the mental, physical and temporal demand, the performance, the effort and the frustration of 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 single items in the TLX were balanced.
TLX of Evaluation 10 Model-driven Development Conventional Android Development 8 6 Workload 4 2
0 Mental Physical Temporal Overall Demand Demand Demand Performance Effort Frustration
Figure 6.8: TLX of the evaluation task.
The the workload of the development task is displayed in the bar-plot diagram in Fig 6.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 taskload index from the model-driven participant group (mean=4.7, SD=1.0) was approximately 20% higher than that of the other participants (mean=3.7, SD=1.3).
86 Chapter 6
TLX of Development 10 Model-driven Development Conventional Android Development 8 6 Workload 4 2
0 Mental Physical Temporal Overall Demand Demand Demand Performance Effort Frustration
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 empirical evaluation 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 the developers. They had to learn the modelling and generation process. Longer training in 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 awareness and learning effect of accessibility in the development process. This work aims to an- swer the question: Do model-driven approaches increase awareness of and practice in 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 points for the development of mobile apps neutral important unimportant rather important rather unimportant Q1 Satisfying user experience Q2 Simple operating concept Q3 Labeling of operating elements Q4 Graphical representation of functions Q5 Description of controls Q6 New forms of interaction Q7 Physical accessibility of operator elements Q8 Written instruction manual Q9 Record user data Q10 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. Table 6.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 with more general aspects and should camouflage the testing towards accessibility. The resulting data compares the effect before and after the given tasks of development and evaluation. Tthe difference between the two different development methods is compared, 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 approaches show 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 to consider 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 it was rather unimportant or unimportant.
88 Chapter 6
Q1: pre-questionary (grey) Q1: model-driven dev. (blue) post-questionary (blue) standard-dev. (grey)
100% 90% 100% 80% 70% 80% 60% 50% 60% 40% 40% 30% 20% 20% 10% 0% 0% 1 2 3 4 5 1 2 3 4 5
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.A minor shift is recognised, but not significant improvement toward accessibility could be observed (see Fig. 6.11 left).
The comparison of the two different developer groups indicated only minor differences in the rating of question Q3 (see Fig. 6.11 right).
Q3 pre-questionary (grey) Q3 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey) 60% 60% 50% 50% 40% 40% 30% 30% 20% 20%
10% 10%
0% 0% 1 2 3 4 5 1 2 3 4 5
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 be found in AppendixC.
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-driven development method was positive. The fast way of development with Accapto "with model-driven development one can create simple apps very fast" and in the automatic integration of accessibility "it is good to see how fast accessibility can be integrated in the app," were positive responses to the new method. However, some open issues from the developers? point of view were reported, such as the lack of documentation and 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 promising framework that saves development time by simply describing and generating proto- types / program skeletons."
The accessibility evaluation was commented on positively. The quick accessibility check received good feedback; "Points for accessibility rating were well chosen and reflect questions that arise in the development," as did the automatic check with the scanner; "Reviewing with the Accessibility Scanner is very easy, but it did not find any bugs - which was a bit puzzling at first, until it was checked against another app." Developers still suggested going beyond developer-based testing and insisted on conducting the test with real users ("For a real app you need real test persons with limitations, because you can only estimate what your audience really wants from an app").
Some participants had problems with the assistive technologies, especially the new method 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 were interviewed. In a semi-structured interview, the participants were asked the following questions:
• What do you know about (mobile) accessibility?
The interview partners already had basic knowledge of accessibility not only from their education ("learned about it in lectures"), but also from literature and research ("learned from book, web or colleagues, but sometimes annoying"). One participant noted the legal regulations to include accessibility in public products ("I know about legal 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 used online tools to evaluate problems ("..included alt-tags for images, web projects and used online tools to find issues"). The other ones replied to have not really cared about accessibility in their recent projects if it was not a concrete requirement ("..accessibility wasn?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. The topic 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 a complicated topic" showed that the developers would like to have more support from IDEs or coding tools.
• How well is model-driven development suitable for integrating accessibility?
The subjective lack of accessibility support in software development programs led to this 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 missing bi-directional workflows in many tools and also in Accapto can bring problems in the practical usage ("mdd is sometimes one-way, and changes are not reported back to the model").
• How far have your knowledge and awareness of accessibility increased?
The measurement of accessibility awareness is problematic. Following the responses of 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 not always including it in the development process. When developers are concerned with the topic of software accessibility, their awareness increases a little bit ("another input to think about it".
All comments from the empirical study as well as the interviews can be found in the AppendixC.
Discussion
The participants already had sufficient knowledge and awareness of accessibility. The importance 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 app accessibility. 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 accessible app development?
The first impression showed a big difference in the overall accessibility of the resulting apps. Those apps which were created with the model-driven development method had an average overall accessibility rating of 6.19, compared to 12.29 for the conventional method (a lower value indicated better accessibility). This is a significant difference; a look at the sub categories provides more insights.
The analysis of the evaluation data of the model-driven development and the standard procedure shows a significant difference in the accessibility of the resulting app. The model-driven approach with Accapto creates apps with better accessibility from the beginning.
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 to reduce the demand. The questions about practice in and awareness of accessible apps 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 research questions are presented along with an outlook on further work in this field. Finally, this thesis 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 research questions.
RQ 1: How can model-driven development support the development of 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 transferred to a formal model. This model includes screen, transitions, and user interaction in an XML 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 Android app 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 accessible prototype. Furthermore, the accessibility pattern library gives developers an additional tool 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 users with different restrictions. The evaluation showed that the integration of accessibility from the beginning leads to accessible apps.
The result is a new procedure. The accessible app toolkit – Accapto – contains a model for accessible app interaction and a generator to transform models into apps. Accapto includes accessibility from the beginning. Furthermore, the following research questions 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 study with more than 50 developers, the new model-driven method was compared with the standard development tool regarding accessibility.
The model-driven development method had an average overall accessibility rating of 6.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 this result, 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 experience and know-how of accessibility in development. Developers already had knowledge and awareness of accessibility. The importance of supporting technologies and their proper implementation is not to be discussed. Including accessibility software is an extra step for most developers, and sometimes skipped. Improved tools or new devel- opment approaches that limit accessibility as a mandatory factor score for accessible software products.
Based on the findings it can be concluded, that model-driven development significantly enhances 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 still an 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 improvement will 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 apps more efficiently. For better usability and non-programmers, a visual editor to create the model based on the DSL would be helpful.
Direct integration of Accapto into a modelling tool or the integration directly into Android Studio could help developers integrate accessibility. This could be done via a plugin for 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 a wider 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 this important 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 in the programs to create new software like apps or webpages.
Finally, improved development methods like model-driven development with Accapto include proper implementation and additional support for developers to improve the accessibility of mobile applications.
1https://www.fastcodesign.com/3060090/how-designing-for-the-disabled-is-g iving-google-an-edge
95 Bibliography
[1] E. Krainz and K. Miesenberger, “Accapto, a generic design and development toolkit 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/th e-future-of-mobile-application/
[4] D. Chaffey, “Mobile marketing statistics compilation,” 2016. [Online]. Avail- able: http://www.smartinsights.com/mobile-marketing/mobile-marketing-analyti cs/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 and motor disabilities,” in Proceedings of the 11th international ACM SIGACCESS conference 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.a ccessibility.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.europ a.eu/ipg/standards/accessibility/index_en.htm
[13] European Union, “Directive (eu) 2016/2102 of the european parliament and of the council of 26 october 2016 on the accessibility of the websites and mobile 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-acc essible-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 software engineering,” in Proceedings of the 28th international conference on Software engineering. ACM, 2006, pp. 1051–1052.
[18] M. Shaw, “What makes good research in software engineering?” International Journal 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 finding on mobile devices for different user groups,” in Proceedings of the 18th International Conference on Human-Computer Interaction with Mobile Devices and 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 Accessible Apps – Model Driven Development of Transportation Apps for Visually Impaired People. 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 Visually Impaired 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 interface approach on smartphones for visually impaired and blind persons,” Information Quality in e-Health, pp. 585–594, 2011.
[24] E. Krajnc, J. Feiner, and S. Schmidt, “User centered interaction design for mobile applications focused on visually impaired and blind people,” HCI in Work and Learning, Life and Leisure, pp. 195–202, 2010.
[25] E. Mattheiss and E. Krajnc, “Route descriptions in advance and turn-by-turn instructions-usability evaluation of a navigational system for visually impaired and 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 communication with public transport vehicles to support visually impaired and blind people,” in 19th 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 for Standardization, 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 on Database 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-acc essible-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.section 508.gov/section-508-of-the-rehabilitation-act
[39] US. Americans with disabilities act. [Online]. Available: https://www.ada.gov/c guide.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/s tandard/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 apply to mobile,” 2015, http://www.w3.org/TR/mobile-accessibility-mapping/.
[47] K. Patch, J. Allan, G. Lowney, and J. F. Spellman, “User agent accessibility 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 and other w3c/wai guidelines apply to mobile,” W3C, Tech. Rep., 2015.
[50] Apple. Accessibility on ios. [Online]. Available: https://developer.apple.com/acc essibility/ios/
[51] Apple. (2016) Accessibility programming guide for ios. [Online]. Available: https://developer.apple.com/library/content/documentation/UserExperience/Co nceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhon e.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/access ibility-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.goo gle.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 mobile phones,” 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 touchscreen accessibility for people with visual impairments,” in Proceedings of the 5th Nordic 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 smartphones to talkback: Understanding the smartphone adoption process of blind users,” in Proceedings of the 17th International ACM SIGACCESS Conference on 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 gestures for blind people on mobile devices,” Human-Computer Interaction–INTERACT 2015, 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 on Compilers, 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 mobile apps for visually impaired and blind users using touch screen based mobile devices: 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 for All 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 Proceedings of 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, “Enhancing android accessibility for users with hand tremor by reducing fine pointing and steady 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 Computing Systems. ACM, 2016, pp. 1934–1946.
[70] K. PLAUMANN, M. BABIC, T. DREY, W. HEPTING, and D. STOOSS, “Improving input accuracy on smartphones for persons who are affected by tremor using motion sensors,” 2017.
[71] S. A. Lesner and M. Klingler, “Apps with amps: Mobile devices, hearing assistive technology, 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 the iphone 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 apps game 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 deaf community,” in Proceedings of the international cross-disciplinary conference on 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, “A proposed 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 videos for deaf people–a sign language approach,” in International Conference on Computers for Handicapped Persons. Springer, 2012, pp. 225–228.
[78] A. Holzinger, G. Searle, and A. Nischelwitzer, “On some aspects of improving mobile 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 older people,” Procedia Computer Science, vol. 27, pp. 57–66, 2014.
[80] M. Azuddin, S. A. Malik, L. M. Abdullah, and M. Mahmud, “Older people and their use of mobile devices: Issues, purpose and context,” in Information and Communication 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 smartphones are changing the face of mobile and participatory healthcare: an overview, with example 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 are mobile too! identifying the barriers and facilitators to older adults’ use of mhealth for pain management,” BMC geriatrics, vol. 13, no. 1, p. 43, 2013.
[83] S. A. Malik, L. M. Abdullah, M. Mahmud, and M. Azuddin, “Mobile applications using augmented reality to support older people,” in Research and innovation in information 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 in practice,” 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 unified conceptual 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-ModelingAnd theMOF.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) workshop on 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-Aided Design 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 reference framework, 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 plastic user 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, and R. 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,” Computer networks, 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, and M. 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,” in International Workshop on Design, Specification, and Verification of Interactive Systems. 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 user interfaces,” in Proceedings of the ACM AVI’2004 Workshop" Developing User Interfaces 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 language for the description of interactive systems at multiple abstraction levels,” in Pro- ceedings workshop on developing user interfaces with XML: advances on user interface 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 ubiquitous environments,” 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-driven UI 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 ui design offer to end-user software engineering?” in Proceedings of the 4th ACM SIGCHI 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 and Information Systems. Springer, 2016, pp. 93–107.
105 Chapter 7
[119] P. Braun and R. Eckhaus, “Experiences on model-driven software development for 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. 23rd IEEE/ACM International Conference on. IEEE, 2008, pp. 509–512.
[121] H. Heitkötter, T. A. Majchrzak, and H. Kuchen, “Cross-platform model-driven development 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 domain specific languages. ACM, 2013, pp. 28–33.
[123] T. A. Majchrzak and J. Ernsting, “Reengineering an approach to model-driven development of business apps,” in EuroSymposium on Systems Analysis and Design. Springer, 2015, pp. 15–31.
[124] A. Ribeiro and A. R. da Silva, “Xis-mobile: A dsl for mobile applications,” in Proceedings 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 and Applications, 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 navigation for 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 front end,” 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 method for seamless web and mobile experience,” in Proceedings of the 1st International Workshop 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, simulation and code generation for web and mobile applications,” in Proceedings of the 9th International 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 development of 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 user interfaces 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 physical disabilities,” 2014.
[136] M. González-García, L. Moreno, P. Martínez, R. Miñon, and J. Abascal, “A model-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 SIGACCESS Conference 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 4th ACM 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 for people with special needs in model-based ui development process,” Universal Access 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 users using 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.” in GI-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 for ubiquitous 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/Con ceptual/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 agile introduction. [Online]. Available: http://www.agilemodeling.com/artifacts/uiFlo wDiagram.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 Longman Publishing 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 International Conference 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 blind students,” 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 using awmo: 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: a case study,” Procedia Computer Science, vol. 27, pp. 460–470, 2014.
[163] V. Petrausch, S. Seifermann, and K. Müller, “Guidelines for accessible textual uml modeling notations,” in International Conference on Computers Helping People 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 xhtml documents 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, “Extensible markup 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.c om/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/stu dio/build/index.html
[174] E. Ort and B. Mehta, “Java architecture for xml binding (JAXB),” Sun Developer Network, Mar 2003. [Online]. Available: http://www.oracle.com/technetwork/art icles/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.a ndroid.com/guide/topics/ui/accessibility/apps.html
[177] Android. Accessibility testing checklist. [Online]. Available: https://developer.a ndroid.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 use what you create!” [Online]. Available: https://codelabs.developers.google.com/c odelabs/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,” Procedia Computer 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 on Computers for Handicapped Persons. Springer, 2012, pp. 607–614.
[182] A. S. Shaik, G. Hossain, and M. Yeasin, “Design, development and performance evaluation of reconfigured mobile android phone for people who are blind or visually impaired,” in Proceedings of the 28th ACM International Conference on Design 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/accessib ility-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: Web standards 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 the intimidation 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 International Symposium on. IEEE, 2013, pp. 5–14.
[195] J. Stylos, B. Graf, D. K. Busse, C. Ziegler, R. Ehret, and J. Karstens, “A case study 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 usability evaluation,” in Proceedings of the 29th international conference on Software Engineering. IEEE Computer Society, 2007, pp. 302–312.
[197] G. Salvaneschi, S. Proksch, S. Amann, S. Nadi, and M. Mezini, “On the positive effect 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 IEEE Symposium on Security and Privacy, 2017.
[199] U. Kuckartz, S. Rädiker, T. Ebert, and J. Schehl, Statistik: eine verständliche Einfü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 variables is 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.
113 Chapter A
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- ter5.
115 Chapter A
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.16 Aufgrund der Beieinträchtigung Auswahl zwischen 1-7
männlich (25-34 Jahre), Lese-, Schreib,- Sprechschwierigkeiten sehr viel Erfahrung mit Smartphones und Android, verlässt nie ohne Begleitung das Haus, kann das App nur mit Unterstützung der Begleitperson bedienen TLX Style ändern Linie folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 5 100 1 0 1 körperl. A. 100 5 2 4 zeitl. A. 5 100 3 4 Anzahl der benötigten Tipps: Ausführung 5 75 4 0 7 Anstrengung 50 60 5 2 Frustration 50 5 6 4 Total 215 345 7 4 Normalisiert 35,83 57,5 8 4 9 2 10 1 Summe 25 SUS-Score 62,5
männlich (25-34 Jahre), Schreibschwierigkeiten sehr viel Erfahrung mit Smartphones und etwas mit Android, verlässt mehrmals täglich ohne Begleitung das Haus TLX Style ändern Linie folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 45 60 1 4 6 körperl. A. 30 30 2 4 zeitl. A. 5 5 3 2 Anzahl der benötigten Tipps: Ausführung 5 5 4 4 2 Anstrengung 40 30 5 4 Frustration 5 5 6 4 Total 130 135 7 4 Normalisiert 21,67 22,5 8 4 9 4 10 4 Summe 38 SUS-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 wurde etwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 5 5 5 1 0 1 körperl. A. 5 5 5 2 4 zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps: Ausführung 65 70 70 4 2 5 Anstrengung 5 5 5 5 4 Frustration 5 5 5 6 4 Total 90 95 95 7 4 Normalisiert 15 15,83 15,83 8 4 9 4 10 4 Summe 34 SUS-Score 85 weiblich (über 65), leichte visuelle Beeinträchtigung, die im Alter entwickelt wurde etwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 5 5 5 1 4 1 körperl. A. 5 5 5 2 4 zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps: Ausführung 5 50 30 4 0 4 Anstrengung 5 10 15 5 3 Frustration 5 5 5 6 3 Total 30 80 65 7 4 Normalisiert 5 13,33 10,83 8 4 9 3 10 4 Summe 33 SUS-Score 82,5 weiblich (über 65), Alterserscheinungen die ab ca 70 entwickelt wurden etwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 5 5 5 1 4 3 körperl. A. 5 5 5 2 4 zeitl. A. 5 5 5 3 4 Anzahl der benötigten Tipps: Ausführung 15 15 15 4 4 4 Anstrengung 5 5 15 5 3 Frustration 5 5 5 6 4 Total 40 40 50 7 4 Normalisiert 6,67 6,67 8,33 8 4 9 3 10 4 Summe 38 SUS-Score 95 weiblich (55-65), leichte visuelle Beeinträchtigung, die im Alter entwickelt wurde etwas Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 5 45 25 1 3 2 körperl. A. 5 5 15 2 4 zeitl. A. 5 5 25 3 4 Anzahl der benötigten Tipps: Ausführung 45 50 50 4 4 0 Anstrengung 5 5 10 5 2 Frustration 5 5 10 6 4 Total 70 115 135 7 4 Normalisiert 11,67 19,17 22,50 8 4 9 3 10 4 Summe 36 SUS-Score 90 männlich (über 65), Alterserscheinungen die ab ca 60 entwickelt wurden sehr viel Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 40 35 50 1 1 2 körperl. A. 15 25 20 2 3 zeitl. A. 20 25 35 3 2 Anzahl der benötigten Tipps: Ausführung 50 50 50 4 2 0 Anstrengung 20 25 30 5 2 Frustration 40 20 30 6 1 Total 185 180 215 7 1 Normalisiert 30,83 30,00 35,83 8 2 9 1 10 3 Summe 18 SUS-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 entwickelt sehr viel Erfahrung mit Smartphones und Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 50 40 1 2 7 körperl. A. 5 15 2 4 zeitl. A. 55 15 3 3 Anzahl der benötigten Tipps: Ausführung 25 30 4 4 2 Anstrengung 5 5 5 2 Frustration 5 5 6 2 Total 145 110 7 4 Normalisiert 24,17 18,33 8 4 9 4 10 4 Summe 33 SUS-Score 82,5 männlich (55-65), Blindheit mit Restsehfähigkeit, im Alter von 40 Jahren entwickelt sehr viel Erfahrung mit Smartphones und gar keine mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 100 5 1 2 8 körperl. A. 5 5 2 2 zeitl. 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 schuld Frustration 5 5 6 2 Total 195 95 7 0 für Blinde, wegen TalkBack Normalisiert 32,50 15,83 8 4 9 4 das Ändern der Stylse wurde als sinnlos angesehen 10 2 Summe 23 SUS-Score 57,5 männlich (35-44), Blindheit mit 20% Restsehfähigkeit, seit 2007 entwickelt sehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 25 50 1 3 9 körperl. A. 25 25 2 4 zeitl. 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 2 Frustration 25 5 6 4 Total 275 230 7 2 Normalisiert 45,83 38,33 8 2 9 3 10 3 Summe 31 SUS-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ächtigungen sehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 10 30 25 1 3 2 körperl. A. 10 30 15 2 3 zeitl. A. 5 20 20 3 3 Anzahl der benötigten Tipps: Ausführung 25 15 15 4 4 0 Anstrengung 10 10 10 5 2 Frustration 5 5 10 6 3 Total 65 110 95 7 3 Normalisiert 10,83 18,33 15,83 8 4 9 3 10 4 Summe 32 SUS-Score 80 männlich (unter 25), keine Beeinträchtigungen sehr viel Erfahrung mit Smartphones und etwas mit Android, kann sich ohne Begleitung außerhalb des Hauses bewegen TLX Style ändern Text folgen Karte folgen SUS Resultat Anzahl der Verbesserungsvorschläge: geistige A. 15 5 10 1 2 0 körperl. A. 25 5 5 2 4 zeitl. A. 5 5 5 3 3 Anzahl der benötigten Tipps: Ausführung 10 5 5 4 4 0 Anstrengung 5 5 5 5 3 Frustration 10 5 5 6 4 Total 70 30 35 7 4 Normalisiert 11,67 5 5,83 8 4 9 4 10 4 Summe 36 SUS-Score 90
Figure B.4: User tests with persons without restrictions
120 Appendix C
Details from the Empiric Evaluation
C.1 Evaluation Instruction
The survey serves to compare two different development approaches for Android apps. 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 to method 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/elmar krainz/accapto/tree/master/evaluation.
C.2 Questionary
The questionaries were done with before and after implementing an app prototype with two different development methods.
121 Chapter C
C.2.1 Pre-Questionary
The participants were asked about their personal data, their development skills and about usability in app development with an online questionary (https://docs.goo gle.com/forms/d/e/1FAIpQLSfhkozWEBS-AR7vYv-8s3rolItkVQs-Bx548q-A C6ZZfzGtVA/viewform)
TeilnehmerInnen Nr. *
TeilnehmerInnen Name (opt.)
Alter Geschlecht weiblich maennlich keine Angabe o o o
Genutzte Mobile Platform Android iOS andere Eigene Verwendung o o o Entwicklung o o o
Hoechste Ausbildung Matura Bachelor Master andere o o o o IT Ausbildung keine auto- HTL FH Universitaet IT Ausbildung ditaktisch o o o o o
IT Kenntnisse sehr gut 6 5 4 3 2 1 0 keine Allgemeine Programmierkenntnisse o o o o o o o o Kenntnisse zu mobiler App Entwicklung o o o o o o o o Kenntnisse zu Android Entwicklung o o o o o o o o Kenntnisse zu Model-Driven Development o o o o o o o o Kenntnisse zu User Interfaces Design o o o o o o o o Kenntnisse zu User Interface Umsetzung o o o o o o o o Kenntnisse zu Usability/UX o o o o o o o o Kenntnisse zu Barrierefreiheit o o o o o o o o
Usability Kenntnisse sehr gut 6 5 4 3 2 1 0 keine Usability Heuristiken o o o o o o o o User Interfaces Design Prinzipien o o o o o o o o Android Material Design Guidelines o o o o o o o o W3C Standards zu Accessibility o o o o o o o o Rechtliche Bestimmungen zu Barrierefreiheit o o o o o o o o
122 Chapter C
Usabilty in App Development eher eher wichtig neutral unwichtig wichtig unwichtig Zufriedenstellende User Experience o o o o o Einfaches Bedienungskonzept o o o o o Beschriftung von Bedienungselementen o o o o o Graphische Darstellung von Funktionen o o o o o Beschreibung von Bedienungselementen o o o o o Neue Interaktionsformen (z.b Swipe) o o o o o Physische Erreichbarkeit von Bedienungselementen o o o o o Schriftliche Bedienungsanleitung o o o o o Aufzeichnen von Benutzerdaten o o o o o Alternative Darstellungsmoeglichkeiten o o o o o (z.b. Farbschema)
C.2.2 Accessibility Test
The participants entered their accessibility evaluation results in an online form (http s://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 o Tabbing o o o o o o Assitive Technologies Android o o o o o o Anmerkung Fehler Accessibility Scanner Anzahl der Fehler Touchsize Bildkontrast Textkontrast fehlendes Beschreibungsfeld doppeltes Beschreibungsfeld Fehler in der Implementierung Anmerkung Manuelle Checks Sehr gut gut neutral weniger gut nicht gut keine Angabe Klare und einfache Texte o o o o o o Klare Navigation o o o o o o Passende Schriftgroesse o o o o o o Vergroesserung mˆglich o o o o o o Position der Bedienungselemente o o o o o o Anmerkung
123 Chapter C
C.2.3 Post - Questionary
The participants were asked about their workload, about their own impressions of the tasks (see online questionary (https://docs.google.com/forms/d/e/1FAI pQLSdBfKAQvDvqsVFnFbk-cruydMjPgcRO3qNwGxE1ySbTOThtNA/viewform).
TeilnehmerInnen Nr. *
TeilnehmerInnen Name (opt.)
Workload App Development nieder 1 2 3 4 5 6 7 8 9 10 hoch Geistige Anforderung o o o o o o o o o o Koerperliche Anforderung o o o o o o o o o o Zeitliche Anforderung o o o o o o o o o o Leistung o o o o o o o o o o Anstrengung o o o o o o o o o o Frustration o o o o o o o o o o
Workload Accessibility Check nieder 1 2 3 4 5 6 7 8 9 10 hoch Geistige Anforderung o o o o o o o o o o Koerperliche Anforderung o o o o o o o o o o Zeitliche Anforderung o o o o o o o o o o Leistung o o o o o o o o o o Anstrengung o o o o o o o o o o Frustration 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 eher eher wichtig neutral unwichtig wichtig unwichtig Zufriedenstellende User Experience o o o o o Einfaches Bedienungskonzept o o o o o Beschriftung von Bedienungselementen o o o o o Graphische Darstellung von Funktionen o o o o o Beschreibung von Bedienungselementen o o o o o Neue Interaktionsformen (z.b Swipe) o o o o o Physische Erreichbarkeit von Bedienungselementen o o o o o Schriftliche Bedienungsanleitung o o o o o Aufzeichnen von Benutzerdaten o o o o o Alternative Darstellungsmoeglichkeiten o o o o o (z.b. Farbschema)
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), their IT skills and about their knowhow in usability.
IT Kenntnisse Usability Skills TeilnehmerInnen Nr. TeilnehmerInnen Alter Geschlecht Platform Mobile Genutzte Entwicklung Platform Höchste Ausbildung IT Ausbildung IT SKILLS Allg. Programmierkenntnisse Entwicklung App mobiler zu Entwicklung Android zu Development Model-Driven zu Design Interfaces User Umsetzung Interface User Usability/UX Kenntnisse zu Barrierefreiheit Skills Usab Heuristiken Usability Prinzipien Design Interfaces User Material Design Guidelines Android Accessibility zu Standards W3C Barrierefreiheit zu Rechtlichea 101 Developer 23 m Android Android BSc FH 32 6 4 4 3 4 3 4 4 16 4 4 2 3 3 102 Developer 27 m Android Android BSc FH 40 6 4 4 4 5 5 6 6 26 6 5 4 6 5 103 Developer 23 w Android Android BSc FH 21 4 3 4 2 3 3 2 0 8 1 2 3 2 0 104 Developer 23 m Android;iOS Android BSc FH 28 6 4 4 1 4 3 4 2 9 3 3 2 1 0 105 Developer 32 m Android Android BSc FH 35 6 5 5 4 4 4 4 3 18 5 5 3 3 2 106 Developer 24 m iOS Android BSc FH 20 6 3 4 2 1 3 1 0 3 1 2 0 0 0 107 Developer 28 m Android Android BSc FH 26 5 3 3 4 4 2 4 1 8 2 3 2 1 0 108 Developer 21 m iOS iOS BSc FH 27 5 2 2 4 3 5 3 3 6 3 2 0 1 0 109 Developer 25 m Android;andereAndroid BSc FH 32 5 3 5 5 3 4 4 3 13 4 4 2 3 0 110 Developer 35 m Android Android BSc FH 27 5 4 4 4 3 3 2 2 16 3 4 3 3 3 111 Developer 28 m Android Android BSc FH 36 6 4 4 6 4 4 4 4 21 5 5 4 5 2 112 Developer 25 m Android;iOS BSc FH 21 5 0 0 0 4 4 4 4 10 3 4 1 1 1 113 Developer 58 m MSc FH 12 3 2 2 1 1 1 1 1 1 0 0 1 0 0 114 Developer 46 w iOS Android BSc FH 6 1 0 0 0 1 1 2 1 2 0 1 0 0 1 115 Developer 27 m Android Android BSc UNI 31 5 5 5 3 4 3 4 2 11 1 4 4 1 1 116 Developer 24 m Android Android;andereBSc FH 31 4 3 3 4 4 3 5 5 28 6 5 6 6 5 117 Developer 23 m Android Android Matura HTL 33 5 5 5 2 4 4 4 4 9 2 3 2 1 1 118 Developer 25 m Android;iOS Android BSc HTL 39 5 4 3 5 6 6 6 4 24 6 6 5 4 3 119 Developer 26 m iOS Matura FH 20 3 2 2 3 2 2 3 3 11 3 2 2 3 1 120 Developer 24 m Android;iOS Android BSc F 28 6 4 4 2 3 4 3 2 8 0 2 2 2 2 201 Student 22 m Android Android Matura FH 30 4 3 3 2 5 4 5 4 23 5 5 5 5 3 202 Student 22 m Android Android Matura - 30 4 4 3 3 4 4 4 4 18 4 4 3 4 3 203 Student 22 m Android Android Matura HTL 21 6 5 4 3 2 1 0 0 3 0 0 0 2 1 204 Student 21 m iOS iOS Matura FH 35 6 4 4 3 4 5 5 4 25 5 6 4 6 4 205 Student 25 m iOS Android Matura FH 31 4 3 3 3 5 4 5 4 14 4 4 0 4 2 206 Student 23 m Android Android Matura HTL 17 4 2 3 1 2 2 2 1 10 3 2 2 2 1 207 Student 22 m Android Android Matura HTL 20 6 4 4 0 2 4 0 0 6 1 1 3 1 0 208 Student 24 w Android Android Matura - 24 3 2 2 1 4 3 5 4 15 3 3 1 4 4 209 Student 22 w iOS Android Matura FH 26 3 2 1 2 5 3 5 5 19 5 4 4 3 3 210 Student 22 w iOS Android Matura FH 27 3 2 1 2 5 4 5 5 18 4 5 2 3 4 211 Student 25 m iOS Android Matura FH 12 2 3 3 1 1 2 0 0 9 2 2 2 3 0 212 Student 21 m Android Android Matura HTL 34 5 4 4 4 5 4 4 4 17 4 4 3 3 3 213 Student 22 m Android;iOS Android Matura FH 29 5 2 2 1 5 3 6 5 22 6 5 2 5 4 214 Student 22 m Android Android Matura HTL 18 4 2 2 0 3 3 3 1 3 0 1 0 2 0 215 Student 24 m Android Android Matura - 24 6 6 6 6 0 0 0 0 0 0 0 0 0 0 216 Student 24 m Android Android Matura HTL 16 3 1 1 2 2 2 3 2 10 3 3 1 2 1 217 Student 22 m Android;andereAndroid Matura FH 34 5 4 4 3 4 4 5 5 25 5 5 6 5 4 218 Student 22 m Android Android Matura FH 35 4 4 4 5 4 6 3 5 21 5 4 4 4 4 301 Senior Developer47 m iOS Android;iOS MSc UNI 35 5 5 4 3 4 5 5 4 17 5 5 3 4 0 303 Senior Developer43 m iOS Android;iOS MSc UNI 32 5 4 4 4 4 5 3 3 16 2 5 3 4 2 304 Senior Developer32 m Android;iOS;andereAndroid MSc FH 29 6 4 4 4 3 3 3 2 14 3 4 3 2 2 305 Senior Developer27 m Android Android BSc FH 29 4 4 4 3 4 3 4 3 14 3 4 4 3 0 306 Senior Developer27 m Android Android;iOS BSc FH 28 4 3 3 4 4 4 4 2 11 2 4 2 3 0 307 Senior Developer22 w iOS Android;iOS BSc FH 31 5 5 5 2 1 3 5 5 14 3 3 3 4 1 309 Senior Developer24 m Android Android BSc FH 32 5 5 5 2 4 4 4 3 16 3 4 3 3 3 310 Senior Developer48 m Android Android;iOS BSc FH 34 6 4 4 3 5 5 4 3 16 4 4 3 3 2 311 Senior Developer28 m iOS iOS BSc UNI 33 5 5 2 4 5 5 4 3 16 3 5 2 3 3 312 Senior Developer29 m Android BSc UNI 40 6 4 5 3 5 5 6 6 23 4 6 1 6 6 313 Senior Developer27 m Android Android MSc FH 34 6 6 6 5 3 4 2 2 7 1 0 4 2 0 314 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. Anmerkungen Eine Änderung der Größeneinstellungen hat sich nicht auf die Demo App ausgewirkt. ausgewirkt. App Demo auf die nicht sich hat aktivieren Größeneinstellungen der nicht Änderung Eine Grund irgendeinem aus sich gut lässt eine accapto mit leicht aber ist Es Checkbox GPS wurde). generiert App die (da perfekt nicht Anordnung die ist Natürlich schaffen. zu Basis könnte noch optimiert werden ich bin Label sehr zu Am doppelten gefühlt Scanner: Texte A11y Zu Screenreader; vom vorgelesen NavigationDrawer. ggf. nicht sein. wurde Labels EditText links oben sollte Back-Button Checks: manuellen schuld.Zu am Randaber ist linken "klebend", Geschmacksache aber nervig die Sprachausgabe, ok, beim verlangsamt Erstellenviel Vorausdenken des Reaktionenerfordert viel XML, Erfahrung Checkboxen mir bei machine the werden opperate to it hard slow making is "Buttons" very Talkback berücksichtigt.Bei nicht XML vom Description die wird Checkboxen Bei dazugeneriert.Bei jeder "Interaction" wird eine neueHistory Activity aufgenommen.gestartet und wird Bsp.:jedes"gezwungen") Mal Man dazu neu indrückt Back"das so die merkt manöftersund hintereinander, die vielen "offenen" ActivityimScreens, wenn man Entwicklen "Back" per StartScreenbeim wird man (bzw. auf "Settings"einfach reads Talkback sehr title app Label Screen, 2xNo App justfor per wholethe one app. wirklich -> Im accapto SettingsScreenmit Funktioniert auf "Save and Screenreader Was beim Zum Die Bedienung Screenreader: ist kommen. zu Anleitungtrotz Ziel ein einziger Graus -gewünschtes mir ich mein damitkann vorstellen, nicht an Mensch sehender (das bekommt schlecht Fokus oder den Element als blinder kein aber Wenn Seite. geöffnete die hört und App die öffnet Man auffällt: es Elemente welche könnte Accapto "schauen" und beispielsweise tabben bzw gut. rumklicken Gegend der in muss - man gibt Seite immer dieser auf Touchscreenbedienung zur sicherstellen)im Gegensatz funktioniert wartet Tastaturbedienung mangibt. so vergebens auf eine Meldung was es jetzt
3 3 1 3 3 4 3 4 2 1 2 2 3 4 3 2 2 3 4 2 3 Position der Bedienungselemente der Position
4 4 4 1 3 4 3 3 1 2 4 4 3 3 2 2 4 2 3 Vergrößerung möglich Vergrößerung
3 1 3 1 2 2 3 1 4 2 3 3 3 3 3 2 1 4 2 3 3 Passende Schriftgröße Passende
2 2 1 2 2 1 4 2 3 2 2 1 2 2 3 2 1 2 1 2 2 Klare Navigation] Klare
2 3 1 1 3 2 1 3 2 2 3 2 1 2 3 2 1 1 1 3 1 Klare und einfache Texte einfache und Klare Manuelle Checks
0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Fehler in der Implementierung der in Fehler
0 0 0 1 5 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 doppeltes Beschreibungsfeld doppeltes
0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 fehlendes Beschreibungsfeld fehlendes
0 0 0 0 2 0 0 0 0 0 0 2 0 0 0 1 0 0 0 0 0 Textkontrast
0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Bildkontrast
0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Touchsize 18
Fehler Accessibility Scanner Accessibility Fehler
Assitive Technologies Android Technologies Assitive 2 1 4 1 1 3 2 2 1 3 2 3 1
Tabbing 1 2 1 2 3 1 1 2 1 2 1 2 3 2 1 1 3 2 1 Screenreader 1 3 1 1 2 1 2 2 1 2 2 1 2 3 4 1 2 2 1 4
AT - Assitive Tech. Rating_Manual_Checks
2,80 2,60 2,00 1,60 2,60 2,60 2,80 2,50 2,80 1,60 2,40 2,40 2,60 2,80 3,00 2,00 1,25 2,40 2,40 2,40 2,40 2,38 0,20 0,45 2,40 ErrorsA11yScanner
0,00 0,00 0,00 1,00 0,00 1,00 0,00 0,00 0,00 0,00 2,00 0,00 0,00 1,00 1,00 0,00 0,00 0,00 0,00 2,10 5,66 0,00
20,00 18,00 31,99 Rating_AssistiveTech
1,33 2,00 1,00 1,50 3,00 1,00 1,33 2,00 1,50 2,00 2,00 1,33 1,67 3,00 2,67 1,00 1,50 2,67 1,50 2,00 1,80 0,40 0,63 1,58 A11Y Rating A11Y
4,13 4,60 3,00 4,10 3,60 5,13 4,50 4,30 3,60 4,40 5,73 4,27 2,80 7,00 5,67 2,25 5,07 3,90 4,40 6,19 5,96 4,40
25,60 21,90 35,53 Getestet auf folgendem Device folgendem auf Getestet
Virtuellen Device, API 24, Android 7, x86 Virtuellen API 24, Android Device, (emulator) 25 API 5 Nexus AVD Emulator 5.1 WVGA API 25 Emulator, 7.1.1 Pixel5, Android API 25, Android virtual Device virtuellesNexus Device, API 5X, 24 Plus 3t One 7 Android 5 Nexus Nexus_5x Device Virtuelles Edge S7 Galaxy P10Lite Android 7.0 Nexus 6P, 8.0, OREO 8 Android Pixel Google Version 8.0.0 G8141, Sony Android Virtuelles Nexus Device, 5, Api Level 24 virtuelles Device - Nexus 5X 5X Nexus mean var SD Median Development Methode Development
MDD MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto MDD mit Accapto TeilnehmerInnen Nr. Nr. TeilnehmerInnen
102 104 106 108 110 112 116 120 204 206 208 210 212 214 216 218 301 305 309 311 313 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Figure C.2: A11y evaluation test group Accapto.
127
Chapter C Anmerkungen Nervig am AVD zu testen. Mehrmaliges betätigen von Button bis korrekte Aktion ausgeführt wird. Zu beginn beginn Zu wird. ausgeführt Aktion korrekte bis Button von betätigen Mehrmaliges testen. zu am AVD Nervig nicht ubedingt klar über die Funktionalität. vordefiniert Aufgabenstellung Für michdurch bereits Elemente keinen unbedingten Mehrwert. Wenig Spielraum da hoffe Ich ich werde soetwas niemals sollte her jetztbenötigenIst aber die Konzept vom nicht App, High-End es so funktioniern ->Screenreader gut vielleicht beimesdauert etwasAbkürzen, lange bis viel Text vorgelesen wurde Acc. vom Werte Keine am AVD. schrecklich Befehle Talkback möglich. fast ammit nicht Maus AVD Tabbing abgestürzt. Scan beim mal oder jedes gemeint GPS API25 mit Aktivierung hier Scanner (wird GPS checkbox z.B. aussagen mehr etwas k√∂nnten Texte - hinzuf√ºgen zu dersind GPS location der NEW-Oberfl√§che POI) der - in UI/Positionenmargins, etc... Gruppierung der ElementeCheckboxen Die k√∂nnte noch sein. verbessert werden auseinander z.B. Beim weiter Testen mittelsAPP, der ein merkt man,Talkback, dass die Beschriftungen, für Elemente, fehlen.Die k√∂nnten Bedienungselemente nah aneinander. Die Texteingaben sind alle fokussiert. talkback hasse ich gleich hat Hat nicht Fehlereinen die schnelle funktioniert, geworfendurch manuelle Entwicklung passen ganz nicht usw Schriftgröße keine doppelklick ist ein dreck wenn man ungeübt ist (wennetwas das mehr sein. erklärt zum anmerkung es mitupload, wäre gut in anleitung der wieanzugeben tabbing die Datei gemeint ist)die Fragestellung soll,werden benannt wenn ich das zippe hilftist und vielvl POIAPP standard nicht weiter, ich 304 hab könnte angehängt. fields Liestrequired von keine Anmerkungen vor getestet. nicht daher Umständliche Tastatur bei Screenreader Keine externe vorhanden, Ausgaben durch Bei Navigation: Einheitliche ("Nicht ispublicaktiviert Kästchen"), Checkbox Liste angezeigt")Keine mit QWERTZwird Tastatur hat langeTastatur Screenreaderausgaben: QWERTZ Deutsch Bearbeitungsfeld ("Search Settings gibt es "SaveButton & Back", Bei aufnicht 1. SeiteNewSavekehrt nur und Button der heißt zurück. Uneinheitliche DialogText- bei Settingsdann (New Checkboxes, zuerst zuerstdann POI: Checkbox, Text-Input, alle MainActivity: Input). Buttons imBereich Seite, der oberen bei Probleme daher Einhandbedienung.
2 2 3 4 1 2 3 4 4 2 3 3 4 3 3 1 2 2 3 2 3 Position der Bedienungselemente der Position
1 3 4 4 3 2 4 4 4 4 4 4 2 4 2 4 4 4 4 Vergrößerung möglich Vergrößerung
3 3 4 1 1 2 2 4 3 2 2 4 4 4 1 3 2 3 2 4 2 Passende Schriftgröße Passende
4 2 2 1 1 2 2 2 4 2 3 3 4 2 1 1 2 2 4 4 2 Klare Navigation] Klare
2 2 1 2 2 2 3 2 1 2 2 1 4 2 1 1 1 2 2 2 1 Klare und einfache Texte einfache und Klare Manuelle Checks
0 0 0 0 0 0 0 1 0 0 0 9 0 0 0 0 0 1 0 0 Fehler in der Implementierung der in Fehler -1
0 0 0 0 0 0 0 0 0 0 0 6 0 0 0 0 2 0 0 0 doppeltes Beschreibungsfeld doppeltes -1
0 0 3 0 0 3 1 1 2 0 0 0 0 0 0 0 0 0 0 fehlendes Beschreibungsfeld fehlendes -1 15
3 0 0 0 0 0 4 3 0 3 3 5 0 1 0 3 1 3 0 0 Textkontrast -1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Bildkontrast -1
6 0 7 0 0 6 4 6 4 6 6 4 0 0 0 2 6 6 0 Touchsize -1 12
Fehler Accessibility Scanner Accessibility Fehler
Assitive Technologies Android Technologies Assitive 2 1 3 1 1 4 3 4 3 3 3
Tabbing 5 5 3 2 2 4 2 4 4 3 3 4 1 4 3 3 Screenreader 2 4 4 5 2 2 2 3 4 5 1 4 4 2 3 2 1 2 3 2 2
AT - Assitive Tech. Rating_Manual_Checks
2,40 2,40 2,80 2,00 1,80 2,20 2,40 3,20 3,20 2,40 2,80 3,00 4,00 2,60 2,00 1,60 2,20 2,25 3,00 3,20 2,40 2,56 0,32 0,57 2,40 ErrorsA11yScanner
9,00 0,00 0,00 0,00 9,00 9,00 6,00 9,00 9,00 0,00 0,00 3,00 5,00 6,00 0,00 6,76 8,94 6,00
-6,00 10,00 11,00 39,00 13,00 10,00 79,89 Rating_AssistiveTech
2,00 4,50 4,00 3,67 2,67 1,67 1,67 3,00 4,00 5,00 1,50 3,67 4,00 2,67 3,00 2,67 2,50 1,50 3,50 2,67 2,50 2,97 1,02 1,01 2,67 A11Y Rating A11Y
6,90 5,67 4,47 5,27 4,27 7,70 8,75 4,90 9,69
-2,13 13,40 16,80 13,07 15,20 18,20 13,40 13,30 15,67 47,00 18,00 16,50 11,87 12,29 93,93 13,07 Getestet auf folgendem Device folgendem auf Getestet
AVD, AVD, Nexus API25 5X, 7 Android 5X Nexus Virtual API Real25; Device: Samsung Device: Galaxy S7 edge, API 24 AVD, Nexus 26 5X, Marshmallow virtuelles Device 5X 25 API AVD 7.0 (Nougat, AVD, Nexus Android 5X, API 24) Version7.0 Android V8. BLADE ZTE 8 Nexus 5x, API 26, Android HTC One m9 Galaxy 7.0 S8, Android 27 API 6 Nexus 7 NEXUS x86 26 API 5X Nexus Device Virtual Rom custom 25 API Emulator, Nexus API 5X 26, Orio 6 Nokia 7.1.1 Virtual Android Device, LG Nexus8.1.0 5X Android 7.0 Huawei Android MediaPad M3, Huwai physisches Device, 5x, 6.0.1 mean var SD Median Development Methode Development
Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android Studio Android TeilnehmerInnen Nr. Nr. TeilnehmerInnen
101 103 105 107 109 111 115 117 119 203 207 209 211 213 215 217 304 306 310 312 314 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
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 experience Q2 Simple operating concept Q3 Labeling of operating elements Q4 Graphical representation of functions Q5 Description of controls Q6 New forms of interaction Q7 Physical accessibility of operator elements Q8 Written instruction manual Q9 Record user data Q10 Alternative display options
Awareness & learn effect: Accapto vs. Android Studio Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Developers Accapto wichtig 19 14 7 2 7 2 13 0 0 2 eher wichtig 3 8 11 7 10 4 9 4 5 7 neutral 0 0 1 11 3 8 0 6 8 10 eher unwichtig 0 0 3 2 2 7 0 5 7 1 unwichtig 0 0 0 0 0 1 0 7 2 2 in % 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 Developers wichtig 18 15 9 2 6 1 8 0 2 3 eher wichtig 3 6 10 10 7 10 7 1 2 6 neutral 0 0 0 7 8 8 5 7 11 7 eher unwichtig 0 0 1 1 0 1 0 5 2 3 unwichtig 0 0 1 1 0 1 1 8 4 2 in % 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. After Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Before wichtig 44 35 7 9 8 4 25 1 5 6 eher wichtig 6 14 28 17 16 22 14 8 9 18 neutral 0 1 10 20 16 15 7 12 24 12 eher unwichtig 0 0 5 3 8 7 3 15 8 9 unwichtig 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 5 eher wichtig 6 14 21 17 17 14 16 5 7 13 neutral 0 0 1 18 11 16 5 13 19 17 eher unwichtig 0 0 4 3 2 8 0 10 9 4 unwichtig 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
Q2 voerher(rot) nacher(blau) % Q2 mdd (blau) vs as (rot)
80%
60% 100%
40% 50% 20%
0% 0% 1 2 3 4 5 1 2 3 4 5
Q3 voerher(rot) nacher(blau) % Q3 mdd (blau) vs as (rot) 60% 60% 40% 40%
20% 20%
0% 0% 1 2 3 4 5 1 2 3 4 5
Q5 voerher(rot) nacher(blau) % Q5 mdd (blau) vs as (rot)
50% 40% 60% 30% 40% 20% 10% 20% 0% 0% 1 2 3 4 5 1 2 3 4 5
Q9 voerher(rot) nacher(blau) Q9 mdd (blau) vs as (rot) %
60% 60% 50% 50% 40% 40% 30% 30% 20% 20% 10% 10% 0% 0% 1 2 3 4 5 1 2 3 4 5
Q10 voerher(rot) nacher(blau) Q10 mdd (blau) vs as (rot) %
50% 50% 40% 40% 30% 30% 20% 20% 10% 10% 0% 0% 1 2 3 4 5 1 2 3 4 5
Figure C.5: A11y awareness & learning effect chart 1.
130 Chapter C
Q1 pre-questionary (grey) Q1 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey) 100% 100%
50% 50%
0% 0% 1 2 3 4 5 1 2 3 4 5
Q4 pre-questionary (grey) Q4 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey) 60% 60% 40% 40% 20% 20% 0% 0% 1 2 3 4 5 1 2 3 4 5
Q6 pre-questionary (grey) Q6 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey) 60% 60% 40% 40% 20% 20% 0% 0% 1 2 3 4 5 1 2 3 4 5
Q7 pre-questionary (grey) Q7 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey)
60% 100% 40% 50% 20% 0% 0% 1 2 3 4 5 1 2 3 4 5
Q8 pre-questionary (grey) Q8 model-driven dev. (blue) post-questionary (blue) standard-dev. (grey) 40% 40%
20% 20%
0% 0% 1 2 3 4 5 1 2 3 4 5
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 gefordert war. Ich hatte erst eine Anfrage, die war nicht relevant. Die war im Web- Bereich. Im mobilen Bereich bis jetzt noch nicht.
F3: Ja, z.B. Berücksichtigung von Abständen, Kontrast ist wichtig und man kann es automatisch 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, Php Storm, 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 besser geworden
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-sensitive Hilfseinträge, nicht nur Titel, man soll sprechende Namen verwenden. Ich habe auch schon Validierungsmöglichkeiten gekannt.
132 Chapter C
F2: Man muß unterscheiden zw. privaten und öffentlichen Projekte. Aber eigentlich bisher nicht berücksichtigt, ich glaube, daß die wenigsten das machen. Die wenigsten App-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 der Umsetzung. Durch Vorgaben achtet man mehr auf A11y. Nicht etwas speziell Neues gelernt, 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 schon die descriptions zu verwenden. Der geführte Prozess ist gut. Das Ergebnis ist sicher strukturierter 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 ist auf jeden Fall gestiegen. Man kann mit tool-generierten Layout auch noch nachsehen wie 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 als lästige Arbeit empfunden. Ich habe mein Bewußtsein durch Forschungsprojekte in diesem Bereich bereits gebildet. Bei iOS hat man das Gefühl, daß es ohnehin vom System gemacht wird.
F2: Mir war es bewußt, jedoch habe ich es trotzdem nicht umgesetzt. In kleinen Projekte 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 im Web, 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 lieber mit 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 braucht niemand. Es gibt kein Zertifikat A11y check, und fehlende Wertschätzung der En- twickler. Accapto passt gut zum Entwickler Workflow, ein Command-Line Programm ist 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 damit beschäftigt
F2: In Projekten habe ich es versucht sehr zu berücksichtigen (Frage - in welcher Form?) ich habe für Sehbehinderte Bilder mit alt-Tags versehen, habe Internet Tools verwendet und Fehler ausgebessert.
F3: Ja, es gab neue Sachen, die ich vorher nicht gekannt habe. Aber ich habe nichts Allgemeines dazugelernt.
F4: Noch nicht so gut wie es sein könnte. In einer Wertung von 1-10 wäre es 6. Es könnte mehr vorgeben werden.
F5: Ja, es erleichtert einiges. Im Gegensatz zur zweiten Art (Anm. Vergleichsgruppe ohne MDD) ist es viel einfacher
F6: Im Laufe der Jahre achtet man mehr darauf. Wissen habe ich ausgebaut. Gewiße Dinge, die noch nicht Routine sind, sind hier wieder aufgetaucht. Ich kann aber nicht mehr 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 Applied Sciences, 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, Jonkoping University, Schweden
• 2010 Lecturer for Computer Science 1, Technical University Graz, Austria
135 Chapter D
• 2009 and 2010 Guest lecturer for Usability Engineering. Savonia University of Applied 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 the design, usability and accessibility of software applications (Human Computer Interac- tion), the developing process in object oriented languages and the implementation of mobile 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 of my research.
Other research interest are the various methods and aspects of eLearning and didactic concepts 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, national research 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 visualize accessibility problems of mobile apps in source code. In Proc. 20. International Conference 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 development toolkit for accessible mobile apps. Studies in health technology and informatics, 242:660- 664, 2017.
Elmar Krainz, Werner Bischof, Markus Dornhofer, and Johannes Feiner. Catching the Right Bus – Improvement of Vehicle Communication with Bluetooth Low Energy for Visually Impaired and Blind People, pages 9-15. Springer International Publishing, Cham, 2016.
Elmar Krainz, Johannes Feiner, and Martin Fruhmann. Accelerated development for accessible apps – model driven development of transportation apps for visually im- paired people. In Human-Centered and Error-Resilient Systems Development - IFIP WG 13.2/13.5 Joint Working Conference 6th International Conference on Human- Centered Software Engineering, HCSE 2016, and 8th International Conference on Human Error, Safety, and System Development, HESSD 2016, Proceedings, pages 374-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 Services Adjunct, MobileHCI ’16, pages 799-806, ACM, New York, USA, 2016.
Markus Dornhofer, Werner Bischof, and Elmar Krajnc. Comparison of open source routing services with Openstreetmap data for blind pedestrians. In FOSS4G-Europe 2014, 2014.
Elmar Krajnc, Wilhelm Zugaj, Mathias Knoll, and Johannes Feiner. Generic mobile applications for small and medium enterprises. In International Scientific Conference UNITECH’2014, volume II, pages 363-367, Bulgaria, 2014. Technical University of Gabrovo.
137 Chapter D
Elke Mattheiss and Elmar Krajnc. Route Descriptions in Advance and Turn-by-Turn Instructions – Usability Evaluation of a Navigational System for Visually Impaired and Blind 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 improvements of an RFID based indoor navigation system for visually impaired and blind people. In 2011 International Conference on Indoor Positioning and Indoor Navigation; Paper, Guimaraes, Portugal, 2011.
Elmar Krajnc, Mathias Knoll, Johannes Feiner, and Mario Traar. A Touch Sensitive User 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 report markup language: Formalising the exchange of usability findings. In Proc. 2nd ACM SIGCHI 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 , pages 195-202. Springer Berlin Heidelberg, 2010.
D.5 Other scientific Activities
• Co-Chair UX Community Showcase, UX Day Graz 2016 https://uxday.fh-joanneum.at/team/
• Reviewer UXPA 2017 in Seattle http://uxpa2016.org Achieved: May 2016
• Observer of the IFIP TC 13.1 HCI Education http://ifip-tc13.org/
• Chairperson UX Community Showcase, UX Day Graz 2015 http://uxdaygraz2015.iicm.tugraz.at/team
• Reviewer UXPA 2016 in Seattle http://uxpa2016.org Achieved: May 2015
138 Chapter D
• Reviewer: May 2015, Future Generation Computer Systems, Volume 62, Septem- ber 2016, Elsevier Achieved: May 2015 https://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 2013 http://uxdaygraz2013.iicm.tugraz.at/team
• Conference Organisation "The Future of the Internet" FH JOANNEUM, 11.11.2011 Organiser and Editor
D.6 Profiles on Science Platforms
• Profil Google Scholar http://scholar.google.at/citations?user=E5Fgx0MAAAAJ&hl=de
• Profil ResearchGate https://www.researchgate.net/profile/Elmar_Krainz
139