Keywords

1 Introduction

According to the Quotas Law [1], in Brazil, from 2 % to 5 % of the total jobs in a large company (100 or more employees) must be dedicated to people with disabilities (PwD). The problem comes up against the difficulty of recruiting PwD with the required qualifications for these job opportunities.

The number of people which uses a cell phone is about 125 millions in Brazil. In 2015, the number of smartphone users reached 61 % of this population [2]. Within this context, a mobile solution for learning presents itself as a good way to train and reach a great number of learners, including PwD.

Based on the Android platform, we have developed a mobile application (app) which is also accessible. The user interface in our app supports special requirements of accessibility, such as:

  • voice commands,

  • setting up the position of buttons,

  • font size setting and

  • high contrast.

Since the goal of the app is training people in software development technologies using an accessible manner, the classes of a Java program, for example, are also adapted for PwD, providing translation to sign language for deaf people.

Our solution is integrated into our existing Accessible Learning Management System (ALMS). This way, a chat and a forum are also offered, facilitating the communication among students and tutors. If necessary, this communication can be mediated by a interpreter of sign language.

This approach maximizes technological qualification and employment opportunities in the Information Technology (IT) job market through a solution supported by the features of internet on mobile devices. We expected to motivate PwD students, so they can be inserted into the labor market.

The structure of this work is as follows: we describe the requirements gathering process in Sect. 2. Then we present the prototyping process in Sect. 3. The aspects of the app development are shown in Sect. 4 and in Sect. 5 we present our final considerations.

2 Requirements Gathering

At the requirements gathering process, we interviewed a group of 53 people with disabilities. A Brasilian sign language interpreter worked along with us to provide an effective communication among deafs and the development team.

These interviews aimed to understand the experience of each PwD using smartphones, tablets and their operational systems. The secondary goal was discovering what they think about mobile education. At last, we needed to find out how easy or hard is the use of common mobile applications like email, instant chat messaging or social networks.

Figure 1 shows, on the left, that 81 % of the group has a mobile device with the Android operating system. That is why, among other reasons, we choose to start the application development using native programming for Android, instead of other platforms or even a hybrid approach.

Fig. 1.
figure 1

Interview answers (Color figure online)

Full size image

One of the interview questions reveals the concern with Internet access and data consumption on mobile depending on where they are going to use the mobile device. This can be seen in Fig. 1 on the right, where we can see the ranking of the main answers given by the respondents.

Having these information about PwD user experience, we were able to produce an application which supports the special requirements of accessibility, creating a tool which can be used easily by anyone, PwD or not.

At the end of this process, we have built a package of important requirements which includes most people to learn in the app. The system can separate some profiles. The profile for people with hearing disabilities, for example, has access to all texts in Brazilian sign language using videos. For students with physical or low sight problems, the application provides actions or shortcuts associated to buttons. This way, all actions can be accessed with a minimal effort.

3 Prototyping

The prototyping process was conducted in early stages of the project, and involved not only design professionals but mainly the PwD team, which could better tell what kind of features and accessibility items the application should have.

We had two groups of people with distinct disabilities: the first composed by physically disabled people and the second composed by hearing impairment people. Each group was exposed to the same 10 selected scenarios, they could discuss among themselves all the ideas and decide which features were relevant for a prototype. Then they produced 40 paper low fidelity models, 4 for each scenario including both cell phone and tablet screen sizes in portrait/landscape orientations.

The whole concept behind this prototyping process is bound on the participative design methodology. Participative design suggests that after a first typical requirements gathering phase, the prototyping phase must include participation of individuals who better understand the proposed object goals or that will directly interact with this object [5], in this case the mobile application. The idea is to collect the most closer to real user reactions and interests about the application, and more than this, because of the inclusive nature of the project, their main difficulties and suggestions about how the interface should behave in order to better help them in everyday use.

After this process, a few more requirements were delivered to the PwD team, after their first contribution over the prototype. The participatory design process proved itself very useful and trustable, because it brings the final user vision into the design of application users interface and features when its more cheaper and easier to manipulate and apply: the very beginning of the project. Studies shows that changes cost significantly more in time and complexity at a given stage on the project than it did on its previous stage, so applying the right concepts on early phases brings more stability and lower costs to the project.

4 Software Development

The team involved in the software development and content production consists of researchers in Human-Computer Interaction, systems analysts, pedagogues, professors, software testing analysts, developers, sign language interpreters, project managers and PwD.

In addition to inicial software requirements, new ones were added during the development process. This process was favored due to the physical proximity to the PwD, even though the requirements have previously been gathered and all the prototypes were made before the beginning of the software development. Several requirements have been adapted over the development process. Because of this proximity to PwD, the testers could be observed, and we noticed that features related to the interface are very sensitive depending on the user’s disability. For example, an optional reverse position for main menu was created because one of the PwD testers claimed that the default position (left side of the screen) was not comfortable for people who have only one arm. This improvement was only possible due to the inclusion of PwD in the development process.

The software release is generated every two months. Once the test version is launched, the acceptance test is applied. This test aims to verify the solution meets the business rules and their requirements, as they are related to functionality, usability and accessibility. The testing team consists of 50 testers: 32 deaf, 16 physically disabled, 1 with low vision, 1 blind person, 2 test analysts and 2 sign language interpreters. The interpreters were responsible for coordination and translating the tests.

A test case document was created with all scenarios that should be tested, according to the type of users disability. Since it is necessary to test features, understanding the content, accessibility and usability is crucial. So testers were and have being trained constantly. The training involves issues management, Nielsen heuristics [6] and accessibility guidelines defined by the Web Content Accessibility Guidelines - WCAG [3, 4].

The mobile application was developed as a native application on the Android platform, aiming the mobile learning (m-learning) methodology, and integrated platform to our ALMS via REST services. The application implemented its own accessibility features: high contrast; increase and decrease the font size; video download with sign languages; enabling the student to schedule a study time; and study even if there is not Internet connection available. The app also uses native accessibility features of the mobile Android system: voice command and caption to buttons to make it possible to use the Android talk back function.

The application also allows the configuration of forms of notification and download videos and learning objects. If the user has available space on disk, the user can download the videos or watch online. This feature is shown in Fig. 2.

All management of files that user downloads is managed within the application itself. Videos and metadata downloaded to the user’s device can be deleted using the File Manager, one of the application’s features. The application also communicates with the platform through Google’s messaging service (Google Cloud Messaging - GCM) for sending and receiving notification messages. The app can also be installed on devices android up to the Android 3.1 Honeycomb (API level 12) version and to suit different screen sizes (smartphones and tablets). The app provides tools such as chat, forum, and its own mail messages so that students feel part of a community and that they feel assisted by course tutors and system support team.

Fig. 2.
figure 2

The application

Full size image

5 Conclusion

The research project responsible for the requirements gathering, prototyping and software development has been working with PwD for 2 years. Although we consider all the points of the end user during prototyping and survey requirements, it was necessary to have constant feedback to improve the software. We realized that the inclusion of two physical disabled people in the test process to work with the developers brought greater quality to the software. This quality was noted through higher quality in the technical error reports and, at the same time, through empirical suggestions to improve the system. The PwD were included in more technical processes such as video editing.

Another lesson learned during the application development process is that the test team should be as diverse as possible. Including people of different ages, different cultural and education backgrounds. This diversity made possible the content to be understood by this target users and that the application was becoming more intuitive over the releases launches.

The testing process and requirements gathering involved a PwD community similar to application end users. This testing method delivered a qualified content to a very demanding public. Finally, the results indicate that the community of PwD are attracted by accessible resources and the usability provided by our application.