1 Introduction

Mobile technology has enabled a wide range of applications that improve the quality of everyday life, possibly targeting people with specific needs and characteristics. The usefulness of mobile applications, i.e., the quality of being helpful and serving some purpose, has increased greatly in recent years allowing users to perform several tasks in a mobile context.

Maps for Easy Paths (MEP) [13] is an ongoing project for the enrichment of geographic maps with information about the accessibility of urban pedestrian pathways, targeted at people with mobility problems. The main goal of the project is twofold: to provide to target users with motor disabilities, blind people, etc. information about accessible routes (and possibly guiding them through the city to easily reach the desired destinations), and supporting the surveying task through the collection of motion data from sensors commonly available in mobile devices [5].

MEP offers two mobile applications: MEP Traces and MEP APP. The former allows to automatically trace a path traveled by a user by exploiting GPS positions and motion sensors (like accelerometer and magnetometer measurements): the user simply activates the application at the beginning of the path, leaves it running in background until the end of the path, and, when a Wi-Fi connection is available, with a simple click, she/he sends the data to the MEP server for path computation. Innovative algorithms based on sensor fusion reconstruct the path [2]. MEP Traces has been designed to be used by people with motor disabilities, with the idea that if the person is able to do a path, that path may be considered accessible and be shared with other people having the same type of disability.

The second application, MEP APP, is instead thought for any user who wants to display on a map the accessible routes collected through MEP Traces. Anyone can also denounce impediments (e.g., architectural barriers) and/or malfunctions through messages or pictures; it is also possible to enrich other accessibility information like, for example, availability of parking lots for disabled people, accessible transport, accessible entrances, etc. The MEP application can also guide the user from his/her current GPS position to a preferred destination, avoiding the signaled architectural barriers.

Visualization and interaction of the information over the map, path visualization, and navigation tasks are crucial activities; accessibility and usability must consider different types of disability impairments, such as visual, physical, hearing, and cognitive impairments. Some important parameters such as connectivity, small screen size, limited processing capability, and power identified in [9, 23] have been considered in the design of the application. Such parameters address some of the shortcomings of existing usability models when applied to mobile applications.

In the chapter, we describe the MEP project in general, illustrate the usage of MEP Traces and MEP APP, and discuss their design to meet the requirements of usability, accessibility, and usefulness. We report our usability–accessibility evaluation done both with automatic tools and with manual/visual analysis and describe the experience in using it in different cities and in campaigns with middle and high school students, to understand the perceived usefulness and ease of use.

The chapter is organized as follows: Sect. 6.2 reports related work. Sect. 6.3 explains how the two-mobile applications work and Sects. 6.4 and 6.5 describe in detail all the issues regarding their usability and their evaluation for the two applications. Sect. 6.6 analyzes the user experience of different kinds of users and reports the results of the cities mapped by such users. Finally, Sect. 6.7 draws the conclusions and reports future plans.

2 Related Work

Several collaborative projects aim to improve city accessibility, through the Web, or, more recently, through smartphone/tablet applications, as surveyed in [7]. The main contributions available in the scientific literature consist in surveys and studies mainly targeted at wheelchair users: requirements were usually collected for the identification of barrier types in order to identify areas where planning activities could improve city accessibility [3] or to measure the experience of reaching (or failing to reach) a destination [17].

The most cumbersome activity in providing an enriched map with accessibility information is gathering such information through field surveys; this has been faced with Web/Mobile applications, available to the public and, typically, by involving target users in surveying. However, Points of Interests (POIs) like restaurants, museums, etc. are the main focus of most of the available applications, whereas sidewalks are considered only by few applications like, e.g., ComuniPerTutti [8] and Mapability [14]. In these applications, typical elements that are evaluated include conditions of sidewalks, presence of cobblestones, conditions of pedestrian crosswalks, curb ramps, street lighting, pedestrian semaphores, tactile paving, visual signaling, reserved parking, sidewalk congestion, etc.; typical barriers are related to holes, depressions, poles, trees, narrow sidewalks, etc. In all these applications, data about city accessibility are collected manually by users through volunteer’s surveys. Some approaches exploit crowdsourcing and collaborative techniques [4, 20] through web or mobile applications to facilitate the data collection process. Only a few contributions proposed a solution for the identification of accessible paths, typically exploiting GPS data [3, 16, 17]. Compared to such proposals, we try to extract as much as information as possible from the available sensors fusing the GPS with the inertial data to reconstruct the exact path of the user.

Considering mobile applications, the majority of available accessible map apps targeting physically impaired users focus on the accessible spots and places within the cities, regardless of the travel experience through the city paths. With active contribution of the users through reviewing, ranking, and adding pictures of the places, these applications (services) provide a set of information that helps the user choose an accessible place to eat, to shop, to hangout, and to find the accessible public transport stations. Wheely NYC [21], Wheelmap [22], and AXSmap [1] are among the most recognized applications in this category. In fact, the use of mobile devices in such applications is limited to having access to the maps on move and the possibility to take and upload single pictures and to add reviews.

On the other hand, all the common navigator applications use GPS/Magnetometer, Proximity, Gyroscope, and Accelerometer sensors in smartphones to calculate speed, direction, and position of the device. However, they lack the information that may help those users for whom the accessibility condition of the path may extensively affect their experience. With the focus on a POI (accessible point of interest) within the outdoor environment, mPASS [18] aims to equip users with the path choices within which the disliked elements are avoided to provide a personalize navigation based on the accessibility preferences of the user. This system uses the data collected by the smartphone sensors, the user reviews, and the authorities’ database to rank the POIs within the city; considering the profile of the user, the system is able to provide him with the potential preferred accessible path to his destination. However, the system does not extract the continuous user experience to calculate the preferred accessible path, it only considers the POI rakings and the total length of the paths.

Extending the use of mobile devices and their embedded sensors, authors of [12] introduced a system to measure street-level accessibility in Tokyo. Within this system, a combination of sensory data and the videos taken by smartphones from the route surfaces are processed to extract the human action sensing. Then, using machine learning techniques, the system is able to navigate users based on previous experiences. The proposed application is basically relying on the data taken from the human action sensing in addition to the surface condition detection. The use of videos taken in this application is limited to the assessment of ground condition, while much more benefits could be derived from a continuous video recording system that could be added to the current capabilities of the current version of the application.

With the aim of enhancing the ground-level perspective, Mapillary [15] application is designed to collect pictures and sensory data taken simultaneously by the users’ smartphone to create a free, huge, street-view picture dataset. Analyzing the raw data to derive a 3D model of the scene, this application is an example of how to extract more information about the surrounding environment. However, the collected raw and analyzed data are only available for further use, and the application itself does not provide anything more than the possibility of uploading images and exploring other’s pictures.

3 Data Collection and Processing Overview

Figure 6.1 describes the general architecture of the two MEP applications: MEP Traces is highlighted in the top part and MEP APP in the bottom part. The former is thought for target users, who can trace an accessible path for their disability; the latter can be used by any active citizen, willing to contribute with reports about accessibility problems, and by all the target users interested in information about accessibility.

Fig. 6.1
figure 1

Overview of the process for data collection and processing

Full size image

When a user starts a route, she/he can activate the MEP Traces mobile app to collect along the whole path data needed to reconstruct it in an accurate way; such data include GPS position estimates and motion sensor data (e.g., accelerometer, gyroscope, etc.); all the data are first stored on the device SD card and, when a Wi-Fi connection is available, they can be uploaded on the server in a PostGIS spatial database [1] for further processing.

On the server, since the accuracy in the positioning of GPS data is quite low for mobile device GPS receivers, we fuse GPS positions with motion data to provide a better estimate of the path, especially in those parts of the route where GPS satellites are not visible like, e.g., urban canyons. The adopted sensor fusion algorithm is based on the adaptation of a framework for robots tracking, to be suitable also for users on wheelchairs, for which step detection-based approaches cannot be used; details about the algorithm can be found in [2]. The output is a path, which is further corrected exploiting the cartography so that paths do not pass over buildings and is positioned in a geographical map [6]. All the collected data are displayed in the MEP APP application.

Both MEP Traces and MEP APP allow also the notification of (geo-localized) obstacles met along the path: users can take pictures and describe their characteristics. It is possible to enrich maps also with accessible elements like, e.g., parking lots for disabled people, accessible transport, accessible entrances, and presence of elevators, etc.

In the next subsections, the final design of MEP Traces and MEP APP obtained after usability tests is illustrated in more detail.

3.1 MEP Traces Application

MEP Traces is the application for the collection of data from common hardware sensors like GPS, accelerometer, magnetometer, gyroscope, etc., embedded in the current generation of smartphones and tablets. Sensor data are collected simultaneously, at the highest possible frequency, and locally stored in the mobile device.

Figure 6.2 shows some snapshots of our Android prototype: after registration, the user visualizes a simple menu (Fig. 6.2a) to start the recording of the route, manage his/her profile, send collected data, and exit the application. The main task of MEP Traces is the tracking of the route while the user is travelling, with the idea of mapping only accessible paths. Tracking works in background can always be paused/resumed/stopped with a single click (see Fig. 6.2b); obstacles or accessible elements can be reported along the path, and information, like available memory, and battery level can always be checked. This information is used to warn the user when critical levels are reached and promptly save the acquisitions not to miss important data for processing. The interface has been designed with large buttons, to be usable also on small screens. Also, accessibility has been considered: to improve text visibility, bold format has been used; to better focus the attention of the user, icons dimension has been increased using different background colors; some attributes used by the operative system to read images for blind target people have also been implemented. Cognitive Load has been considered as well: the acquisition phase allows the user to take the smartphone in standby and put it, e.g., in the pant pocket while tracing routes, to maintain this task as transparent as possible. User attention is required only when he/she wants to report a problem along the way.

Fig. 6.2
figure 2

Some snapshots of the MEP Traces app: (a) main menu; (b) sensor recording; (c) obstacle type selection; and (d) obstacle description and notification

Full size image

During the acquisition phase, the application performs many tasks in background, so its execution is only possible on devices that are at least dual core. The issues of limited processing capability and power have been tested in [5]: despite many computations in parallel, MEP Traces does not exhibit high battery consumption, which is on average around 5–6% per hour.

Obstacles can be notified with a simple click among predefined obstacle types (Fig. 6.2c), including a blocked path, absence of sidewalk, narrow path, presence of steps, inclined path, issues at the crosswalks, or pavement problems. Once the barrier type has been selected, the user specifies some characteristics of the obstacle like the fact that it is temporary (e.g., in case of works in progress) and the criticality level of the barrier that can range from low, i.e., accessible with some help, to high, i.e., not accessible at all (Fig. 6.2d). If the same barrier is characterized by different obstacle types (e.g., there is a pavement issue and the path is also inclined), the same notification can be associated with more types. Optionally, some pictures of the obstacle and a description can be included. In a similar way, also accessible elements like accessible entrances/toilets/transport, parking lots for disabled persons, etc. can be notified.

All the collected data (sensor data and obstacles reports) are sent to the server for further processing and sharing. Before sending them, the upload effort is minimized thanks to data compression, to overcome the issue of connectivity described by [14]. The upload is forced to happen with a connection between the device and our server over Wi-Fi using the SSH File Transfer Protocol (SFTP). Fig. 6.3 shows the activities to manage the local folders on the mobile device containing the sensor data (e.g., folders may be deleted in case of mistakes) and the compression/upload tasks. During this task, the acquisitions uploaded correctly to the server, after a client/server check, are automatically deleted from the mobile device.

Fig. 6.3
figure 3

MEP Traces upload interface example: (a) manual selection of all the acquisitions; (b) data compression and connection/uploading task

Full size image

3.2 MEP APP

MEP APP is the application displaying on a map all the data collected with MEP Traces, i.e., traveled paths, obstacles, and accessible elements. Currently, the visualized map is based on OpenStreetMap [19]. The final goal is to drive the final user to his/her preferred destination, avoiding obstacles along the path, and considering his/her specific disability.

Fig. 6.4 shows some snapshots of MEP APP Android prototype. Users can access most of the collected information without authentication: they can visualize the city accessibility, obstacles with comments, and photos geolocalized over the map and use the navigation tools. User authentication is required only when the user wants to notify obstacles, insert comments, and visualize the path computed avoiding obstacles considering his/her specific type of disability, i.e., when the user actively contributes by providing data or needs a personalization of the results according to a predefined profile.

Fig. 6.4
figure 4

Some snapshots of MEP APP application: (a) map visualization; (b) main menu; (c) localization message; and (d) current GNSS position map rendering

Full size image

When the user accesses the application, it asks the user the permission to enable the GPS sensor (if not already enabled) and loads all the elements close to the current position, highlighted in Fig. 6.4a. The user may also explicitly specify the city to visualize, by using a simple searching toolbox in the interface (Fig. 6.4b). The main menu of the application (Fig. 6.4c) allows to compute the path to a given destination, to specify which kind of information to visualize on the map (e.g., only paths, only obstacles of a given type, etc.), to manage his/her own profile and contributions (e.g., to update or modify previous contributions), and to see the user performances in terms of recorded distances.

Figure 6.5 shows some results applied to Como city. Figure 6.5a depicts all the paths that have been collected using MEP Traces (details about the field surveys will be described in the User experience session).

Fig. 6.5
figure 5

Some snapshots of MEP APP visualization in Como: (a) accessible paths visualization; (b) elements clustered; (c) obstacle detail visualization; and (d) image of the obstacle

Full size image

To improve the organization of all the map information, very close obstacle elements are clustered together (Fig. 6.5b). By zooming-in the map, clusters are disjoint into subclusters, until the final element visualization is reached. By clicking on an obstacle or accessible element, details are provided (e.g., the type, description, and photo of the obstacle) as shown in Fig. 6.5c and Fig. 6.5d.

The application has been developed to provide to the user the path to navigate from its current GPS position (or any other initial destination) to a destination point, avoiding obstacles along the path according to his/her disability. Figure 6.6a shows an example of a path with some associated information (i.e., distance expressed in meters and the walk duration estimate). Figure 6.6b renders the route directions.

Fig. 6.6
figure 6

Some snapshots of MEP APP navigation: (a) path visualized on map; (b) route directions

Full size image

4 Usability and Accessibility Issues

A good application, in a general sense, is an application that is Accessible, Usable, and inclusively designed. All these factors are closely related, and depending on the target audience and the functionalities that the application is designed for, the focus on each aspect may vary.

According to the definitions offered by ISO standard:

  • “Accessible design focuses on principles of extending standard design to people with some type of performance limitation to maximize the number of potential customers who can readily use a product, building or service” [11].

  • “Usability extends to how a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use” [10].

  • “Inclusive design, or Universal design, is the design of products, environments, programmes and services to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design” [11].

However, since the focus of MEP applications is on people with mobility impairments, the inclusive design is not considered a priority. However, in our use case scenario, the accessibility requirements would improve also the usability of the application and would cover most of its aspects in terms of efficacy, efficiency, and user satisfaction. Therefore, having people with mobile impairment as target users, accessibility standards and usability requirements can be simultaneously considered as usability–accessibility measures.

4.1 Mobile Usability–Accessibility

Mobile devices, as the name implies, refer to handheld computers used on move. Therefore, to fit the context, they come up with some hardware, and consequently software, limitations that the normal computers do not deal with. Lower display resolution, smaller screen sizes, limited input methods, limited process capability and power, and the mobile context itself are of those issues that have been introduced by the advent of mobile devices.

As discussed by [9], the commonly used usability models are not applicable on mobile devices since they do not consider the mobility factor. Instead, PACMAD (People At the Centre of Mobile Application Development) Usability model considering the user and his special needs to access and use the application, context of use (i.e., the environment in which the user will use the application), and the task (i.e., the goal the user is trying to accomplish with the mobile application) extends the former definition of usability mobile devices.

Ensuring that in a given situation, the final user with his limitations is able to use the application and perform the tasks efficiently and effectively with satisfaction without any health threads, PACMAD provides an inclusive model including both usability and accessibility matters. In our work, we were inspired by the PACMAD model as a comprehensive mobile usability–accessibility framework. This includes

  • Effectiveness: the ability of the user to complete a task in a specified context;

  • Efficiency: the ability of the user to complete his/her task with speed and accuracy;

  • Satisfaction: the perceived level of comfort and pleasantness while using the software;

  • Learnability: the ease with which a user can gain proficiency with the application;

  • Memorability: the ability to retain how to use an application effectively;

  • Errors: the possibility to recover from them in case of a mistake;

  • Cognitive Load: the impact that using the mobile device while performing additional tasks, like walking.

5 MEP Usability–Accessibility Evaluation

To ensure the usability–accessibility of MEP applications, we have considered both technical (using standards checklist and guidelines) and user interface (real user experience) components. Therefore, we accomplished the tests in the following steps:

  • In-lab tests with target users, starting already in the earliest phases of the design. It helped us to avoid design and development mistakes and to ensure that the application works well and is usable for the end user.

  • We asked a group of “Accessibility: Models and Applications” course students in the Como Campus of Politecnico di Milano University to do an Accessibility test on both MEP applications as their final course project.

  • A group of volunteer users with/without mobility impairment have tested the MEP APP and MEP Traces to map the accessibility of Como and other cities.

5.1 In-Lab Tests

In-lab tests with target users were done before the development, on an interactive mock-up simulating the apps. The following tasks were considered: (1) registration as a new user, (2) visualization of the map and selection of an obstacle, (3) search for an accessible path from point A to B, (4) insertion of a new obstacle to contribute to the map, and (5) set up of the user profile. After task completion, they were asked some qualitative and quantitative questions to evaluate their experience with the interface. General results were positive: users found the interface comprehensible and could easily understand the icons and their meanings; participants with the electric wheelchair did not have any particular problems with interaction with the app through their joysticks. However, also some issues were highlighted and improved in the current version: in some tasks, they found the interaction sequences too long to follow (the navigation has been redesigned with shortest sequences and activities were simplified); tests done indoor and outside provided different results, since the designed icons couldn’t be easily seen in an outdoor setting due to reflections on the screen (larger buttons, possibly with different colors, have been introduced with this aim in both applications); they required a simple menu always available on the screen to understand which is the current activity (the current activity remains on the screen).

5.2 Accessibility Tests

To evaluate accessibility of the applications, the Accessibility Scanner (a Google app) was run on all the activities of both applications (an example of use is in Fig. 6.7).

Fig. 6.7
figure 7

Example of accessibility scanner results

Full size image

Then, other critical aspects were inspected “manually” by the students of the accessibility course. All the possible impairments were considered by different groups of students (visual, hearing, physical, and cognitive) to provide an inclusive interface. However, collecting the reports, we prioritized the reported issues by putting the users with physical impairment on top. Doing a trade-off, we omitted those issues that by considering them we could worsen the user experience in physically impaired context. For example, considerations related to replacing buttons with touch gestures have been excluded to reduce the complexity and difficulty of use for people with advanced physical impairments: some participants in our tests could only move one or two fingers, could use a mini-joystick to control their smartphone or had a special button located under their head on their wheelchair or could use their smartphones but with some restrictions. In general, buttons with single clicks could be used by all the participants.

With the accessibility scanner, it was possible to check if all the elements have an associated label that can be read from the screen reader and all their descriptions are different to avoid confusion; if the contrast between images or text and the background is sufficient; if the touch target is large enough (e.g., also in case of fat fingers or to allow both left- and right-handed persons). Tests for visual impairments were simulated also using the Talkback application and checking that all the elements of the activities were properly considered.

Issues with no conflict have been already implemented or planned for the next release. The proper resizable text, audio alternatives for static texts, color contrast, and many other matters to ensure the application is perceivable, operable, and understandable for the final user have been applied. In MEP Traces, several issues related to the contrast between the green icons and the white text/background were highlighted by the scanner: texts were made bold and their sizes maximized. Dialogs and messages of completed operations have all been checked.

6 User Experience and Results: Test and Evaluation

MEP Traces has been largely tested and evaluated in two different ways: through its use by individual users (autonomously and without time and path constraints) and in organized groups.

As far as organized groups are concerned, awareness-raising campaigns on the issue of motor disability have been organized. The MEP application was used for 1 day by four middle school classes (ages between 10 and 13 years – a group of 35 students in the city of Como and a group of 40 students in the city of Brugherio (Milan)); eight high school students (all males, aged 16–18 years) used it for 4 weeks.

The students of the middle school were organized in groups, equipped with Android devices, and had to map an area of their city. They were accompanied by a person with motor disability (on electric or manual wheelchair), whose role was to help the working groups to better understand his/her difficulties in traveling through a city.

The usage of the application was briefly explained before starting the mapping task. After the mapping was concluded, a questionnaire was provided, including some questions about the age and the usage of smartphones in daily activities and about the following indicators: simplicity in using the application, clarity of the user interface, usefulness of the application, ease of learning, intention to recommend the application to other users, satisfaction in using the application, and future use of the application. Each indicator was associated with a score from 1 to 5 (1 = strongly negative, 5 = highly positive).

The responses returned by the working groups of the campaigns were very similar both for the group of students aged between 10 and 13 years (Group 1 in the following) and the group of students aged 16–18 years (Group 2 in the following). Results are reported in Table 6.1.

Table 6.1 Questionnaire results about MEP usability by groups of users
Full size table

It is important to point out that the questionnaire for Group 2 was distributed in two different moments: at the end of the first day and at the end of the whole period. This double analysis was carried out to intercept the existence of a difference between the perception of first use and that of prolonged use.

Most of the results are comparable. All the participants found the application easy to use and its interface clear. Group 2, after using the application for a longer period, still reported some difficulties during the signaling of the obstacles, especially in its correct classification.

Ease of learning for Group 2 was evaluated only on the first day. Learning was a little bit more difficult for middle school students; they had some difficulties in the registration phase and in the final upload of the data.

It is interesting to note that “simplicity” is in contradiction with the “ease of learning”: if the application is simple, it should also be easy to learn. Scores with values 1 and 2 under “ease of learning” represent only 5.5% of the total; they were interpreted (it was not possible to find out who responded) as outliers and are perhaps due to the young age of the respondents. By excluding these outliers, the answers to the questionnaires of the two groups are aligned.

The clarity of the application and the “recommendation to others” has similar results, emphasizing that the perceived difficulty in using it at the beginning is a deterrent to the disclosure of the application.

The satisfaction variable is particularly high for the middle school students: indeed, it includes also the “satisfaction” for the whole experience both in using a new application and in having the possibility of doing a new experience.

The usage of the application in the future for Group 2 has been evaluated only in the second questionnaire. In Group 1, some students added a comment at the end of the questionnaire and remarked that they assigned a low score, because at home they have only non-Android devices, and therefore, it will be impossible to use it.

The total satisfaction level assessed on both groups is between 2 and 5, with 5 as median; it is represented in the histogram in Fig. 6.8.

Fig. 6.8
figure 8

Overall evaluation of the user experience with MEP Traces: number of answers (on the y axis) for each score between 1 and 5 (on the x axis)

Full size image

Overall, the strengths highlighted by the analysis concern the ease of use, the utility, and satisfaction. A point of weakness remains the “future use.” The absence of a real need for participants reduces the perception of utility for the future, as the potential contribution does not fall directly on themselves, even if during the campaign their role in contributing to a meaningful and useful goal was appreciated and made them proud of the experience.

The application has been used independently but for longer time also by some individual users (without disabilities) who have tested its functionalities in different contexts: a 55-year-old male, a 47-year-old female, and a 52-year-old female. In Italy, in total, they traced the municipalities listed in Table 6.2, sorted by traveled distances.

Table 6.2 Data about Italian cities traced by individual users
Full size table

The mapped areas are all urban but positioned in different geographic contexts and with a different historical and economic characterization, briefly reported, to better understand the kinds of detected obstacles.

Cantù is in the Italian Alpine foothills and is characterized by an economy based on handicraft and small enterprises; its urban development is mainly linked to support business activities and paid little attention to pedestrians. Often you can find roads without sidewalks and streets with a cobblestone pavement.

Como, with a center situated on the lake – and therefore mainly flat – is characterized by an important historical nucleus (mainly pedestrian) with medieval walls and with a history dating from the Roman period; being very attractive for tourists, it is sensitive to pedestrians. However, to retain some of the medieval characteristics, there are often cobbled or granite floors that make mobility for wheelchairs and walkers more difficult. Cernobbio, very close to Como on the same lake, shares similar characteristics. In a similar way, L’Aquila, located on the slope of a hill, in a basin at 721 m above sea level, has often cobbled pavements and granite slabs. Rome, traced only for a small part of the city center, features urbanization, population density, and historical features that make urban changes for accessibility extremely hard; except for large squares and pedestrian areas (which, however, have some pavement problems linked to its history), it is frequent to find narrow sidewalks, problematic crosswalks, and unpaved pavement. Ravenna and Ferrara, although quite flat cities, due to their cultural heritage (Ferrara was a Renaissance city and Ravenna a Byzantine city), have accessibility problems similar to Como and L’Aquila.

Tavenerio and Magreglio are two small villages in the Italian Prealps. They developed from small nuclei and have characteristics that make mobility for people with wheelchairs particularly difficult: pavement, sloping paths, pathways, and sidewalk absence are the most significant obstacles.

Capri and Anacapri, two cities of the island of Capri, though characterized by strong slopes, narrow streets, and paths, thanks to the tourist attraction, have evolved in the direction of accessibility.

Giulianova is a city divided between hinterland and sea. The part along the sea (the part that has been mapped) that is strongly linked to tourism is very accessible. Likewise, Loano, a tourist town on the Ligurian Riviera, is very attentive to accessibility issues.

Corsico is a small town in the Milanese hinterland, based on agriculture in the nineteenth century; in recent decades, it is among the most urbanized areas of Milan; it has some pedestrian areas but has accessibility deficits mainly due to carelessness.

Considering the characteristics of the cities (historical, industrial, and size), soil morphology (mountain, hill, plain), and their geographic location, it can be noticed that the most common problems are caused by carelessness, especially for the sidewalk pavement and the crosswalks (representing 57.1% of all reports). Less frequently, nonaccessibility is due to steps (9.1%) and narrow paths (8.1%). The slope problem is profoundly different: although it represents 8.8% of the reports, this type of obstacle is typical of the hinterland and mountain regions; although not solvable (at least not in a simple and inexpensive way), this type of alert is important, because it gives users a conscious choice of a place (e.g., for holidays) and/or help identify the less demanding path for them. An example of excellence is represented by the municipalities of Capri and Anacapri that offers transport buses suitable for the transport of disabled persons that can be booked by the users themselves. However, both municipalities have a hilly geo-morphology and many routes are accessible only with some help (electric wheelchairs or an accompanying person).

Abroad, the cities listed in Table 6.3 were traced. These cities have the same level of accessibility of Italian cities. Helsinki is a city overlooking the Baltic Sea, mostly flat; the main detected problems concern the pavement. Sheffield is a morphologically different city with hills; excluding the problems related to the inclination (natural in its context), the city presents problems of pavement and narrow paths. Brussels (traced only in the central part) is a city with some slight slope characteristics. As an historic city, it presents some paving problems and narrow paths. These European cities (mapped for a total of 53.28 km) have the same characteristics as the corresponding Italian cities drawn for the same population and historical importance.

Table 6.3 Data about non-Italian cities where the applications were experimented
Full size table

Individual users evaluated simplicity, clarity, and the other usability dimensions. The results are reported in Table 6.4.

Table 6.4 Usability results of individual users
Full size table

The result of interviews on individual users has highlighted the need to deepen the “simplicity” and “clarity” aspects. A first analysis has shown that these two items are closely related to each other. The application is considered very clear and very simple in terms of pure tracking because no specific knowledge, skills, or user intervention is required; the interface is considered simple and intuitive.

The complicated and unclear identified point concerns the alerts that the user posts in case an obstacle is found and must be signaled. The user’s opinion is that it is simple, intuitive, and very quick to report situations involving small areas or specific points of the path (e.g., rough pavement, a bottleneck point, steps, etc.), while it is unclear how you can report situations related to long and continuous paths (e.g., a climb, a route with several problems). In fact, the application allows you to report an obstacle at the exact point where the user is and not the continuity of the obstacle. Users agree on the fact that an improvement in this direction would require an increased user involvement by producing the side effect of making the application costlier and with the added risk of introducing errors or inaccuracies. For example, reporting a climbing path should prompt the user to trigger the alert at the start of the path and deactivate it at the end, making the user more responsible during the acquisition; forgetting to “close” the signaling would make the whole traveled route an uphill road. The current version of the application allows the user to simply trace an accessible path and to focus only on specific points, with a limited cognitive load during the mapping task.

Overall, the application is considered simple. User profiling, track activation, and data delivery are easy and intuitive. Reporting obstacles (excluding the problem highlighted above) is simple and intuitive: signaling them through icons, taking pictures, and having the possibility of specifying different types of obstacles for the same problem is considered a significant advantage over adding descriptive texts (long and challenging). In general, the application is considered very good.

7 Conclusions and Future Work

In this chapter, we have presented the two applications developed within the MEP project, MEP Traces and MEP APP: the former is used to trace an accessible path, the latter to show the collected data on a map to the final users and to allow them reporting barriers or accessible elements.

They have been carefully designed to consider the usability and accessibility issues of the target users, including mainly people with motor impairments; tests considering all the kinds of disabilities have been conducted, and many changes have been implemented to meet most of the accessibility requirements.

Usability and user experience tests have been carried out with different kinds of users: middle school students organized in groups and accompanied by people on wheelchairs, high school students, who used the applications for 4 weeks, and individual users, who used them in different contexts and for quite long distances. MEP Traces and the functionalities to signal barriers/accessible elements have been largely tested. Evaluation of the applications was in general positive.

In addition to the tangible results of experimentation in the different cities, campaign with students had also a social impact in

  • raising the awareness of the mobility problem, to make students (and, more in general, citizens) more aware and sensitive to people with disabilities;

  • sustainability: the user involvement is minimized, and data can be easily kept updated; indeed, paths can be automatically detected with MEP Traces and system data are dynamically updated;

  • participation: the proposed method allows anyone to become an active user by participating directly in creating content.

It is interesting to notice that the municipality of Cernobbio (in the province of Como) has participated in the experimentation of the project and has shown the intention to improve the accessibility of the city over the next few years by considerably reducing pavement problems (excluding certain sections of gardens), some narrow-path problems.

Plans for the development include, at one side, enhancements of some functionalities: for example, for MEP Traces it will be possible to send collected data automatically as soon as a Wi-Fi connection exists; for MEP APP advanced interactions with voice synthesis, usage of vibration during navigation or acoustic alerts when the person approaches obstacles. On the other side, further usability tests to better evaluate routing and navigation will be performed.