Keywords

1 Introduction

Mobile applications are one of today’s fastest growing software areasFootnote 1. Apps, with simple intuitive user interfaces, are easy to use. The UI is mostly based on graphical representation a touch input.

For visually impaired and blind people this interaction paradigm is a challenge. Accessible web or desktop applications are already widespread, but this know-how cannot always be adopted to mobile apps.

Including accessibility is a challenge for developers and therefore it is handled more like a feature or add-on than a prerequisite. This work shows an approach to use Model-Driven Development (MDD) to create accessible mobile apps.

2 Related Work

The topics Accessibility, Mobile Applications and Model-Driven Development are part of current research. This is also visualised in Fig. 1, which shows the overlapping domains of Model Driven Development (MDD), Accessibility and Mobile Development. There is already some exiting work which covers the outer intersections. For example, Accessibility and Mobile Development or Accessibility and Mobile Applications have been covered by previous papers, but seldom all three fields of research are discussed together in the scientific community.

Fig. 1.
figure 1

The research focus is in the intersection of Model Driven Development (MDD), Mobile App Development, and Accessibility.

The main contribution of this work lays in the middle of the three circles, namely the intersection of all three domains. Following existing research is related to our approach:

The book Model driven Software Development (MDSD) from Voelter et al. covers the (semi-) automatic generation of software [20], but mentions mobile devices only in one minor example and accessibility is not covered at all. In the fast growing area of mobile applications there is also a need for this agile and effective methods to create software. There are different approaches. Barrnet et al. [4] describes a tool to generate data-driven apps based on a Domain Specific Language (DSL, compare [7]), with MD2 form Heitkoetter et al. [11] even cross-platform apps are created from a model. The latter tool focuses on business apps where common source code is compiled into native iOS and Android apps, sadly neglecting accessibility topics.

MDD also helps to include accessibility in the development process. The Johar framework from Andrews and Hussain [1] uses an interface interpreter to create accessible applications for a range of users with different abilities. González-García et al. [8, 9] use a model-based graphical editor tool to design an accessible web based media player. The UsiXML presented by Vanderdonckt [19] promotes the integration and use of a User Interface Description Language (UIDL).

For accessibility combined with mobile app development, there are several publication which discuss smartphone-based assistive technologies for the blind. For example, Narasimhan et al. [15] presented in 2009 the mobile phone tool Trinetra to assist visually impaired people during grocery shopping. Guidelines to develop for visually impaired and blind people can be found in [17]. Harder [10] discussed the possibilities for general mobility already in 1999, but for several modern approaches of implementation and design of touch-based smartphone interfaces see [4, 1214]. These contributions focus on accessible way-finding apps as well as new ways of touchscreen usage for blind people.

3 A Concept for Model-Driven-Development for Accessible Apps

This work shows a concept to generate transportation apps for visually impaired and blind people. These people have special needs when it comes to live an independent life. Traveling and moving on their own is a very important factor [10]. Various apps are available to support this user group, but not every app provides an accessible user interface.

The innovative part of the empirical work in this contribution uses MDD to generate accessible apps. With the help of a meta model a concrete model of an transportation app is designed. Several features and workflows for the domain of transportation apps are included in this model. For example, most transportations apps need the functionality to fetch the current GPS position, which is part of the meta-model. Specifying getposition (see Sect. 3.1) in the model adds to appropriate code to the app. With an instance of this model an app scaffold is generated.

Based on best practices for accessible apps (see [4, 1214]) and the adoption of common standards (see [5, 18]) required accessibility features are included from the beginning.

App programmers open the generated sources in the development environment (IDE) and can focus on the business logic which is not generated automatically. The resulting app has a simplified workflow and an accessible user interface (see screenshot in Fig. 2).

Fig. 2.
figure 2

Screenshot of the resulting routing app.

3.1 Model

Concerning the model, we choose a domain specific approach. Which leads to a very specific and a straightforward model. We choose the domain of mobility and transportation apps. These kinds of apps help visually impaired, and disabled people to be more independent while travelling. For this reason a research on common transportation apps was necessary.

Transportation apps like Google Maps, OSM Routing or apps from different public transport companies have similar features. These are:

  • Fetching your actual position

  • Entering a target location

  • Searching for a location

  • Showing a route

  • Display a map

  • Receiving infos from public transport

These features and workflows within an app are defined in a model. With a defined notation developers are able to build the scaffold of their own transportation app.

3.2 Modeling Language

Domain Specific Languages (DSL) help you to describe a model in your domain [7]. In this work an internal DSL is used. The language definition and the dedicated models are written in XML. We choose XML, because there are various tools available to create and process XML-based languages. But in the end it is more the less a personal decision, which language you use [6]. For better usability and non programmers a visual editor to create the model based on this DSL would be helpful.

Example of an GPS position finder app:

figure a

3.3 App Accessibility

People with special needs are nowadays able to operate standard computers without great difficulties. With the help of, for example, a braille display and build-in features of an operating system a visually restricted person can perform tasks on a PC. Visually impaired and blind people where also used to handle key-based mobile phones with screenreader software as add-on. With the uprise of touch-based smartphones these users had to find new ways of interaction.

On the popular mobile platforms iOS and Android are already some accessibility features included. The VoiceOverFootnote 2 system on iPhone allows a blind person to use a smartphone. On the Android platform TalkBackFootnote 3 is the integrated accessibility feature to react the user’s touch input to voice output. But both systems can only provide an accessible user experience if an app is created properly. Developers have to follow the guidelines for iOS [3] or for Android [2]. Both platforms have some similarities but have also some big differences.

The Web Accessibility Initiative (WAI) of the W3C provides standards to improve accessibility for the Web. The actual standard for web applications is WCAG 2.0 [5] this guideline is based on general principles for accessible development rather then technical solutions. Therefore this standard provides a basis for non web solutions as well. Relevant principles of WCAG 2.0 [5] are:

  • Perceivable

  • Operable

  • Understandable

  • Robust

These principles are relevant to modern web applications but can be applied to non-web contents like mobile applications.

Currently a first public draft for a new standard for mobile accessibility [18] is available. This document describes how the principles and guidelines of existing standards like WCAG 2.0 can also be applied to native mobile apps.

In an (semi-) automatic generation process we have to consider platform independent principles and also platform related source code enhancements.

3.4 App Generation

With the model specified in Sect. 3.1 we are now able to generate an app scaffold for accessible transportation apps. This step, also known as transformation [20], is handled by a chain of tools. The first one in this chain is JAXB [16], whose task is to read the XML file and transform it into Java objects. Having the information stored in objects allows now to use it in combination with the Android command line tools to create an Android project scaffold. After this we are triggering a templating engine which generates the files, which are needed for the structure specified in the model. The process from XML-based model to a final app is illustrated in Fig. 3. The previous step also includes the mentioned accessibility features which are noticed in the Sect. 3.3.

Fig. 3.
figure 3

Workflow from Meta-Model to Model to App Scaffold to final App.

The outcome from this transformation process is an app scaffold with accessibility features. All required app components (e.g. start-activity) and libraries (e.g. routing-lib) are available in the app project. Further product flavours can be integrated in the app’s source code. Features like content description for integrated screen reader support or active voice output in selected parts of the app are automatically generated.

4 Conclusion

In this paper we describe the combination of the topics accessibility, mobile apps and model-driven development. In the Section related work we looked at the intersection of these domains.

In the empirical part of this work we build a meta-model for the domain of transportation apps. With an instance of this model one can create a app-scaffold for accessible transportation apps. In the model-transformation process all main-screens, workflows and platform related accessibility features are produced. Developers can focus on the app features, because accessibility is build in from the beginning.

Further work will be the improvement of this concept concerning the utility and usability of the model generation and transformation.