An Assistive Technology for Pedestrians with Mobility Impairments

James Madison University JMU Scholarly Commons

Senior Honors Projects, 2020-current Honors College

5-7-2020

CampusPartner: An assistive technology for pedestrians with mobility impairments

Cynthia Zastudil

Follow this and additional works at: https://commons.lib.jmu.edu/honors202029

Part of the Other Computer Engineering Commons

Recommended Citation Zastudil, Cynthia, "CampusPartner: An assistive technology for pedestrians with mobility impairments" (2020). Senior Honors Projects, 2020-current. 44. https://commons.lib.jmu.edu/honors202029/44

This Thesis is brought to you for free and open access by the Honors College at JMU Scholarly Commons. It has been accepted for inclusion in Senior Honors Projects, 2020-current by an authorized administrator of JMU Scholarly Commons. For more information, please contact [email protected]. CampusPartner: An Assistive Technology for Pedestrians with Mobility Impairments ______

An Honors College Project Presented to

the Faculty of the Undergraduate

College of Integrated Science and Engineering

James Madison University ______

by Cynthia Rose Zastudil

April 2020

Accepted by the faculty of the Department of Computer Science, James Madison University, in partial fulfillment of the requirements for the Honors College.

FACULTY COMMITTEE: HONORS COLLEGE APPROVAL:

Project Advisor: Michael C. Stewart, Ph.D., Bradley R. Newcomer, Ph.D., Assistant Professor, Department of Computer Dean, Honors College Science

Reader: Nathan Sprague, Ph.D., Associate Professor, Department of Computer Science

Reader: Erin Brady, Ph.D., Assistant Professor, Department of Human-Centered Computing at IUPUI

PUBLIC PRESENTATION This work is accepted for presentation, in part or in full, at GROUP 2020 on January 6, 2020.

Table of Contents

Table of Contents ...... 2

List of Figures ...... 5

Abstract ...... 7

Acknowledgements ...... 8

Introduction ...... 9

Motivation ...... 9

Background ...... 9

CampusPartner ...... 13

Relevant Literature ...... 14

Environmental Factors Affecting Navigation ...... 14

Spatial Awareness in Unfamiliar Locations ...... 14

Development of Assistive Technology ...... 15

Limitations ...... 16

Existing Assistive Technologies for Mobility Impaired Pedestrians ...... 18

AXS Map, Wheelmap.org, Project Sidewalk, & AccessMap Seattle ...... 18

RouteCheckr ...... 18

OpenStreetMap ...... 19

OpenRouteService ...... 19

VirtualLeap & VirtualWalk...... 20

Design of CampusPartner ...... 22

Design Process...... 22

Technical Details ...... 25

CampusPartner Use Case...... 28

Launching the Application ...... 28

Creating a Route & Beginning Navigation ...... 29

Creating a Route & Bookmarking it ...... 31

Editing a User Profile ...... 32

Editing OpenStreetMap using Go Map!! ...... 33

Future Work ...... 36

Co-Design ...... 36

Implementing More Routing Functionality ...... 36

Turn-By-Turn Routing Interface...... 36

More Route Customization Options ...... 37

Integration of Existing Services ...... 37

Crowdsourcing Data ...... 37

Conclusion ...... 39

Appendix ...... 40

Bibliography ...... 41

List of Figures

Figure 1. Route customization options provided in Google Maps...... 11

Figure 2. The fastest route from ISAT/CS to UREC...... 12

Figure 3. The route from ISAT/CS to UREC that doesn't use any stairs...... 12

Figure 4. A failed wheelchair routing request in ORS...... 20

Figure 5. A route created in ORS from ISAT/CS to UREC avoiding stairs...... 20

Figure 6. The profile creation scene shown when the app is opened for the first time...... 23

Figure 7. The navigation scene displayed after a user has previously opened the app...... 23

Figure 8. The bookmark view and the profile editing view...... 24

Figure 9. The interactions between existing services used and CampusPartner...... 26

Figure 10. Profile creation screen upon opening CampusPartner for the first time...... 29

Figure 11. The route from ISAT/CS to UREC drawn on the map...... 30

Figure 12. The instructions for the route as returned by GraphHopper...... 30

Figure 13. An individual route step from the route returned by GraphHopper...... 31

Figure 14. The bookmarks screen. It shows all of the user's saved routes...... 32

Figure 15. The selected route reloaded onto a map view. The user can begin navigation or return to the bookmarks screen...... 32

Figure 16. The profile editing screen. When a user begins editing, a warning is shown until they save...... 33

Figure 17. The saved and updated profile screen...... 33

Figure 18. The alert asking the user if they would like to update data in Go Map!!...... 34

Figure 19. The screen where the user drops a pin to indicate the location where they would like

Go Map!! to open to...... 34

Figure 20. Go Map!! when it opens to a specified to a user-specified location...... 35

Abstract

Route-planning applications such as Google Maps and Apple Maps are used by millions of people each month. However, these mapping applications are optimized for vehicle navigation, and although they provide pedestrian routing, the route customization options aren’t sufficient for pedestrian users, especially those with mobility impairments. CampusPartner is an assistive mobile application that was designed with the purpose of supporting people with mobility impairments in planning and previewing their walking routes. By viewing routes in advance, users can see an overview and detailed information about them as well as turn-by-turn instructions. CampusPartner integrates existing services, GraphHopper, OpenStreetMap, and

Mapbox, to provide navigation functionality. Users are able to create a profile upon opening the app, which will include information such as obstacles and road types to avoid, as well as their bookmarked or most commonly used routes. For example, if someone was looking for a route from one side of campus to the other and they couldn’t take stairs due to a mobility impairment, this app would assist them in determining the best route to take or notify them if they should look for an alternative form of transportation, such as a bus. Additionally, users are able to correct missing or inaccurate information, such as the absence of stairs on the map or temporary obstacles.

Acknowledgements

I would like to thank Dr. Michael Stewart for being my advisor on this project. He dedicated time every week to make sure I was making progress and was willing to help in any way he could. He was also incredibly supportive of submitting my work to conferences, leading to my first publication at GROUP 2020. The support he provided to me on this project for the past three semesters has been invaluable. I would also like to thank my readers, Dr. Nathan

Sprague and Dr. Erin Brady for taking the time to review my work and provide suggestions for its improvement at many steps.

In addition to thanking my advisor and my readers, I would also like to acknowledge the various open source technologies I used in my application. GraphHopper provided the routing functionality without which this application’s functionality would be severely lacking. I would also like to thank GraphHopper for providing a discount for access to the API. OpenStreetMap was used as the underlying data source, provided accessibility information used in generating routes, and Mapbox was used to display the map interface. To access the GraphHopper routing

API, I utilized the GraphHopper Routing Swift Framework created by Roman Blum and Phil

Schilter from HSR University of Applied Sciences. Lastly, the Go Map!! application created by

Bryce Cogswell was used to facilitate users’ edits and additions to OpenStreetMap from my application.

Introduction

CampusPartner is an assistive mobile application which was designed with the purpose of supporting people with mobility impairments in planning and previewing their walking routes.

Motivation

The primary motivation for my capstone project came when I was sitting on the first floor of Jackson Hall waiting for an interview for a study abroad program I was hoping to participate in the following summer. The student who went before came down from the second floor, the professors following behind her carrying the knee scooter she was using due to a broken bone.

Jackson Hall doesn’t have any elevators in it. When she arrived for her interview, another student helped her carry her scooter up to the interview and the professors helped her on the way out. I was disappointed to find out that a building can exist without any elevators in it, especially in a time after the ADA was passed. However, this is not an uncommon problem in many of

JMU’s historic buildings, another example being Hillcrest House.

Background

According to the National Center for Education Statistics, in the 2015-16 academic year, approximately 19.4% of undergraduate students reported having some kind of disability [4] and out of those students, approximately 4.5% reported having an orthopedic/mobility impairment

[12]. While JMU doesn’t have any data of this kind publicly available, we can look at the construction and geography of the campus and see that it potentially poses a problem for current students and visitors who come to campus.

In a previous capstone project done by Meredith Browder, students from the Office of Disability

Services were surveyed about their feelings about inclusivity at JMU. Some of the students who reported having felt excluded at JMU said that it was due in part to inaccessible building and

some students who reported feeling isolated at JMU said it was due to the different transportation students with disabilities have to take, especially during events like first-year orientation. Some recommendations made by the students who responded were to make buildings more accessible and provide a more reliable form of disability transportation [3].

Although the Americans with Disabilities Act (ADA) has made great strides to ensure that people with disabilities are not unfairly discriminated against, in many cases, the accessible entrances of buildings are hard to find, obstacles are not clearly labelled or marked, and historic buildings may be lacking in accessibility. While the general accessibility of JMU’s campus is no doubt greatly affected by the mountainous terrain of the Shenandoah Valley, there are also a significant number of buildings on JMU’s campus that don’t have to be fully compliant with the

ADA because of their historic status.

While I did not choose to focus on indoor navigation and accessibility for my project, this experience prompted me to think about ways in which I could positively contribute to the accessibility of JMU’s campus. Route-planning applications such as Google Maps and Apple

Maps are used by 177.7 million users monthly [13]. However, these mapping applications are poorly suited for those with mobility impairments. When creating a pedestrian route in Google

Maps, there is not sufficient customization provided to the user in terms of obstacles they wish to avoid (see Figure 1). These applications are not adequate for people with mobility impairments

[8]. Students and campus visitors with temporary or permanent mobility impairments should have a way to determine the fastest accessible way to get from one place to another or whether or not they should look for an alternative form of transportation.

Figure 1. Route customization options provided in Google Maps. A particularly motivating example of this is the differences between the walk to UREC from ISAT/CS using the fastest route and the walk there without using any stairs. As shown below using Google Maps, the fastest route to UREC from ISAT/CS is 0.2 miles and estimated to take 6 minutes, whereas the route that avoids stairs is more than doubled, taking 0.5 miles and an estimated 11 minutes. Not only is this route significantly longer, but there is not a sufficient amount of readily accessible information about the quality of the route, in other words, whether or not the roads being taken are wheelchair accessible or if there are curb ramps where there should be. If you are new to campus or unfamiliar with the area, it’s likely that you aren’t aware of these obstacles and the best way to get around campus. You could be seriously caught off-

guard, not only could this take a physical toll on you, but it could be emotionally and mentally exhausting as well.

Figure 2. The fastest route from ISAT/CS to UREC.

Figure 3. The route from ISAT/CS to UREC that doesn't use any stairs.

CampusPartner

Following these motivations, I decided to build a mobile application to explore the design space of accessible pedestrian route planning. I will briefly describe CampusPartner before reporting on my review of the relevant research literature.

CampusPartner is an iOS mobile application that is intended to assist people with mobile impairments in planning their routes across campus and crowd-source map data updates.

CampusPartner is intended specifically for JMU, but it has the potential to be extended beyond

JMU and college campuses in future work. While CampusPartner is designed primarily for those who are less familiar with the JMU campus, this app would also be beneficial for those who recently gained Mis and are unfamiliar with routes accessible to them. Often, people with mobility impairments may need to plan ahead, researching everything from building entrances, the route to get there, and any other accommodations that may need. [10] CampusPartner’s purpose is to make this easier because it aggregates a lot of the information people would need to know all in one place and makes it portable.

Relevant Literature

In researching for this project, I found a wide array of research regarding developing navigational aids for visually impaired people. While I decided relatively early on in my project to focus primarily on developing a navigational aid for pedestrians with mobility impairments, I still found this research useful in determining the trajectory of my project as well as learning about some important practices when developing assistive technology.

Environmental Factors Affecting Navigation

There are many different kinds of environmental factors that may affect the accessibility of a location for someone with a disability. A specific example of this can be the effect surface- level changes have on people with low vision. In a study done at Cornell University, they found that surface-level changes were a “source of uncertainty and even fear for all participants.” [11]

These kinds of surface-level changes include anything from stairs, curbs, potholes, and similar things that may occur in the natural environment. While these findings are centered around people with visual impairments, I found them helpful in determining what road/footpath features to consider when looking for the data source for my application.

Spatial Awareness in Unfamiliar Locations

Often, people without mobility impairments will research an unfamiliar location before going to it, just to get a sense of where you are going and how to get there. The most common examples of this that people are familiar with are Google Maps and Apple Maps, but they have shortfalls as discussed earlier (see: Introduction). There is a serious need for applications that support people with disabilities in knowing exactly how to get somewhere, with their specific needs in mind. Like everyone who may research unfamiliar locations prior to navigating there, people with disabilities may need to plan ahead and otherwise familiarize themselves, but they

have the additional need to include everything from building entrances, ground surface types, rate of elevation change (“grade”), and other accommodations they may need. [10]

CampusPartner would make this easier because it would aggregate a lot of the information people would need to know in one, portable place.

Development of Assistive Technology

While developing a mobile application was a large portion of the learning process throughout this project, I also learned a great deal about developing technology for people with disabilities in the process. I was fortunate enough to be a student volunteer at ASSETS1 2019 in

Pittsburgh this year, and it provided me with a great deal of information regarding how to (and how not to) develop assistive technologies for people with disabilities. I was particularly inspired by the keynote speaker, Karen Nakamura, who spoke about the failings of some artificial intelligence and machine learning algorithms in regard to the accessibility and accuracy many reverse Turing-tests and recognizing disabled people in various contexts (e.g. self-driving car algorithms failing to recognize wheelchair users as people). Both of these problems are caused in part by the failure of the developing entities to include people with disabilities as co-designers

(in the design, coding, training, and other aspects of these algorithms) rather than simply as a remote design inspiration or end-user testing when design decisions are largely concretized. [6]

In my research about designing assistive technology, I came across the proposal of using the idea of interdependence alongside the goal of independence as a way to guide work in

1 The International ACM SIGACCESS Conference on Computers and Accessibility (“ASSETS”) is the premier forum for presenting research on the design, evaluation, use, and education related to computing for people with disabilities and older adults.

assistive technology. Interdependence in this context means ensuring that people with disabilities are involved in the design process and their viewpoints and input are included. [1] Although the navigation features CampusPartner will provide are important, ensuring CampusPartner’s user experience is accessible and actually useful to its intended user base is of the utmost importance.

According to Bennett et al., some scholars agree that interdependent relationships are needed to fully create access. [1] In order to do this, developing assistive technology must not just be done for (or even “to”) people with disabilities, the development process must also include them.

Limitations

While devoting my time to learning mobile application development (including the Swift programming language, related iOS software development kit features, and how to interact with third-party application programming interfaces), I was also learning about how to make my design process more authentic, equitable, and democratic by systematically involving and prioritizing interactions with people with disabilities at each step in the process. In this project, I learned important points too late to apply them in this early stage of CampusPartner. The majority of my time during this project was dedicated to developing the application, and I was not able to complete user studies or work with people with disabilities. Without a doubt, this has had an effect on the quality of this project and will be discussed further in the

Future Work section of this paper. Currently, CampusPartner is more of a prototype of an assistive technology that still requires user studies, co-designing with members of the target population, and further software development iterations.

Existing Assistive Technologies for Mobility Impaired Pedestrians

AXS Map, Wheelmap.org, Project Sidewalk, & AccessMap Seattle

AXS Map was created by Jason DaSilva invites users to rate the wheelchair accessibility of buildings using a rating system much like Yelp. AXS Map is a mobile application as well as a web application and uses crowd-sourced data with the goal to “ease the burden of social exclusion by providing people with disabilities the freedom to be spontaneous about where they eat, shop, work, and play.” [14] Wheelmap.org is a similar application in which users rate the level of wheelchair accessibility of how wheelchair accessible different locations. [15]

AccessMap Seattle [2] provides information such as elevation change, curb ramps, public elevators, etc. This approach is complemented by tools like Project Sidewalk which facilitates volunteer and paid crowd-workers in tagging accessibility issues found in Google Street View

[7]. All of these applications and projects have made valuable contributions to the field of accessible routing, however, none of them provide routing functionality that includes their data.

RouteCheckr

RouteCheckr is an application that was developed at the Technical University of

Dresden, and it aims to provide multi-criteria routing for mobility-impaired pedestrians. [8] This includes motor impaired, elderly, visually impaired, and blind people. When developing their application, they found that there was a lack of data optimized for pedestrian navigation due to the fact that most navigation systems are optimized for cars. In an attempt to work around this, they included an annotation functionality so that users could annotate geographical data with information that is relevant to them (i.e. points of interest, obstacles, etc.). The developers of

RouteCheckr used two forms of annotations, the user-specific annotations, as described earlier, and information from the user’s LOM-Modality. [9] The LOM-Modality is a derived modality

that includes the user’s location, orientation, and movement, and this modality is used in determining how to annotate geographical data using combinations of the three mentioned spatial dimensions. [8] While this application appears to provide the services that I am aiming to provide with my application, I couldn’t find any current information about this project. I took a lot of inspiration and guidance from this project, as I have included a way for users to interact and improve the data source via Go Map!! and I implemented user profile functionality, which customizes the routes provided.

OpenStreetMap

OpenStreetMap (OSM) is a web service (including a web application front-end user interface) that one could describe as a “Wikipedia for street maps”. [16] Individuals can contribute updates and improvements to the information available about the streets, walkways, buildings, and etc. with which they are familiar.

OpenRouteService

OpenRouteService (ORS) provides both an application programming interface (API) and a user-friendly web-application for retrieving directions for multiple modes of transportation, the most relevant ones to this project being pedestrian and wheelchair routing. [17] Initially

OpenRouteService seemed like an ideal candidate for supporting CampusPartner because it provides the routing functionality I need and also uses OpenStreetMap as its data source. While their web application is great in its own right, it’s is essentially unusable on mobile (the primary use case I intend for CampusPartner). Additionally, the amount of data in OSM prohibitively large (approximately 50 GB to start, and then changesets of varying size each week on the order of 3 GB), so understandably the ORS pulls updates too infrequently for the purposes of

CampusPartner. Otherwise whenever a CampusPartner user encounters inaccurate data, such as

the lack of stairs on the map, and they updated the OSM, those changes would not be reflected in

CampusPartner or in the routes provided to the user which could potentially be inconvenient, confusing, or dangerous. One other downside to OpenRouteService is that the wheelchair routing functionality is only available in Europe, due in part to where ORS is most used, and the size of the data set required to support this feature.

Figure 4. A failed wheelchair routing request in ORS. Figure 5. A route created in ORS from ISAT/CS to UREC avoiding stairs.

VirtualLeap & VirtualWalk

VirtualLeap and VirtualWalk are two different forms of applications that use turn-by-turn navigation and points of interest (POIs) to support the navigation of visually impaired users.

VirtualLeap features a route overview, which includes intersections, POIs, and turn-by-turn instructions. On the other hand, VirtualWalk provides navigation information to the user as they are walking and reaching POIs and other landmarks. [5] The overall goal of both of these

applications is to help visually impaired people to develop, “memorable representations of the real world.” [5:281] I developed CampusPartner for pedestrians with mobility rather than visual impairments; however, I believe that the goal of the VirtualLeap and VirtualWalk projects applies to mine as well. Providing some way for a person to become familiar with a new environment can be very important, and hence is a goal of my design. CampusPartner includes both a route overview as well as a form of dynamic turn-by-turn instructions for the user.

Design of CampusPartner

When the user opens the application for the first time after installation, they are shown a brief tutorial about how the application works, and then they will be prompted to create a profile for routing. Currently, the only option supported for routing options is to avoid stairs, but there are other options provided to the user with the idea that routing functionality and customization could be improved in the future. CampusPartner does not have a database to store user data because the data the app is required to store is relatively lightweight and doesn’t necessitate a full database. The app is using the iOS feature of UserDefaults, which stores information about the user while the application is installed, and all user-specific data is deleted if the app is uninstalled. Once the user has created a profile, they have the option to go back to their profile and edit the information they provided. This directly modifies the values in the UserDefaults and automatically updates the user’s profile.

Design Process

The early stages of the design process included creating sketches of what I wanted the front-end of CampusPartner to look like. I didn’t mock-up the entire application, only the portions of it which provide a high amount of user interaction and functionality.

Figure 6. The profile creation scene shown when the app is opened for the first time.

Figure 7. The navigation scene displayed after a user has previously opened the app.

Figure 8. The bookmark view and the profile editing view. Once I had an idea of what I wanted the front-end of the application to look like, I needed to consider what kind of functionality I wanted to include. I determined that the most important pieces of functionality were the following: allowing a user to customize their routing profile, generate routes taking the user’s routing profile into consideration, provide a way for users to update information in OpenStreetMap, and providing a way for users to plan for future routes by bookmarking created routes and loading it at a later time. Once this had been determined, I had to figure out what services I would need to integrate into my application.

Fortunately, the OpenStreetMap wiki [18] provided a lot of insight into existing services that use OpenStreetMap and provide the functionality I need for my app. This is one of the ways

I was introduced to OpenRouteService and Mapbox. CampusPartner uses OpenStreetMap via

Mapbox [19] to provide the map view to the user. Mapbox was chosen primarily because it is open source and since the underlying routing algorithm utilizes OpenStreetMap’s data it felt

appropriate to use Mapbox because it also uses OpenStreetMap. Additionally, edits on a mobile device are made with Go Map!! which shows the OpenStreetMap data. CampusPartner leverages the routing algorithm provided via GraphHopper’s API because it supports flexible routing options that include road types you like to avoid, particularly steps. In the earlier stages of this project, I was intending to use OpenRouteService’s API, due to the fact that it provides similar features to the GraphHopper API, however, the infrequent data updates from OpenStreetMap made it less appropriate for this project. When a routing request is made to GraphHopper’s API, a list of possible paths is returned, in the order of fastest to slowest. Each path returned contains a total distance and estimated time for the route, the coordinates of the route, turn-by-turn instructions for the route, among other details about the route.

Technical Details

CampusPartner was developed using Swift 5 and is intended for the most recent versions of iOS (the most recent iOS at this time is iOS 13.4.1) going back to iOS 10 and 11.

Additionally, the app was developed with the most recent iPhones in mind, and as such is not intended for use on other Apple products, such as iPads or MacBooks. Due to a bug in the most recent version of XCode, I was not able to test CampusPartner on an iPhone, however, I was able to test it on an iPad. The user interface was not created with the ability to adapt to different screen sizes, so the user interface does not look correct, but the functionality works correctly.

This application takes advantage of a lot of existing services, as described in the previous section. Their interactions, both between each other and CampusPartner, can be visualized in the following diagram.

Figure 9. The interactions between existing services used and CampusPartner. The last major piece of the technical aspect of this project I would like to discuss is with respect to the data storage techniques I utilized for this app. The first kind of data I needed to figure out a way to store is the user’s profile. When a user creates their profile, their information, first name, last name, whether or not they want to avoid steps and/or unpaved surfaces, and the preferred maximum elevation change, is stored using UserDefaults. When the user chooses to bookmark a route, all relevant information about the route (a name for the route, the starting point, and the destination point) is saved using iOS’s NSKeyedArchiver. This is another lightweight way to persist data in the app. Whenever a route is added to the bookmarks, it is saved a file that is dedicated to storing all of the saved routes. This file is accessed anytime the

app needs to load, save, or delete routes. In both cases, UserDefaults and NSKeyedArchiver, if the app is uninstalled all of the information that has been stored will be deleted along with it.

CampusPartner Use Case

In order to illustrate the intended usage of CampusPartner, I will walk through a hypothetical use case of CampusPartner. In this scenario, the user will be someone who has recently developed a mobility impairment and is using a knee scooter navigating from ISAT/CS to UREC.

Launching the Application

When the user first opens up CampusPartner, they are shown a brief tutorial and introduction to the application which then segues into the profile creation screen as seen in

Figure 10. The user must provide a first and last name. Currently, the profile defaults to avoid stairs, since that is the primary functionality of the application. The user can also indicate that they want to avoid unpaved roads and set a maximum change in elevation. These profile options are not currently being taken into account for routing but may be in the future.

Figure 10. Profile creation screen upon opening CampusPartner for the first time. Creating a Route & Beginning Navigation

Once the user has finished creating their profile and any other time they open the application, they will be shown the routing view. The source location defaults to the user’s current location, but they can delete that text from the search box in order to set it to something else. Upon searching for a source and destination, the user has two options: immediately begin navigation or save the generated route for later use. If the user chooses to begin navigation as soon as a route is created, they are shown a list of all of the instructions of the route. The app highlights the step that the user is closest to by constantly updating the user’s current location

and comparing it to the starting coordinates of every instruction, and the one with the minimum distance is highlighted. If a user clicks on a row in the list of instructions, they are shown a sub- step of the route on a map view. In addition to the starting and ending points of the route step, the user’s current location and heading are shown in relation to the route step. The navigation interface is shown below in the following figures.

Figure 11. The route from ISAT/CS to UREC drawn on the Figure 12. The instructions for the route as returned by map. GraphHopper.

Figure 13. An individual route step from the route returned by GraphHopper.

The user’s location is shown in relation to it. Creating a Route & Bookmarking it

If a user chooses to bookmark a route rather than immediately beginning navigation, that route will be saved to the bookmarks tab of the app. The user can then return later to select a route they have saved and begin navigation. Since this is meant for routes the user will use later, the intended usage of this is to search for both a source and destination location rather than using the user’s current location.

Figure 14. The bookmarks screen. It shows all of the user's Figure 15. The selected route reloaded onto a map view. saved routes. The user can begin navigation or return to the bookmarks screen.

Editing a User Profile

At any time after the user creates their profile the first time the app is opened, they can return to the profile view to edit any of the information they provided.

Figure 16. The profile editing screen. When a user begins Figure 17. The saved and updated profile screen. editing, a warning is shown until they save.

Editing OpenStreetMap using Go Map!!

One of the most important pieces of functionality of CampusPartner is the ability for users to interact with the data source they are using via updating/correcting existing data or adding new data to OpenStreetMap. After a user exits the navigation view, they are prompted with an alert asking them if they found any part of the route inaccurate or something was missing from the route. If they select yes, they are shown a view with the map and the route they took.

Then they can long-press on the map to drop a pin where they would like to edit in Go Map!!.

Once they have dropped a pin, they can navigate to Go Map!! or install it on their device if it hasn’t been already. In addition, a user can leave CampusPartner at any time from the More tab of the app. In this case, GoMap!! will open to the user’s current location.

Figure 18. The alert asking the user if they would like to Figure 19. The screen where the user drops a pin to update data in Go Map!!. indicate the location where they would like Go Map!! to open to.

Figure 20. Go Map!! when it opens to a specified to a user-specified location.

Future Work

Co-Design

As I discussed before, since this application has not been developed in collaboration with people with mobility disabilities, this application can really only be considered a prototype.

Beyond independence, interdependence relationships are needed to fully create access. [1]

Particularly, in the case of navigation aids, putting the user in the subjugated place of simply following the instructions given to them can be problematic. CampusPartner is designed to ally the user with the assistive technology and with past and future users to cooperatively find and verify the accuracy of the routes. Developing assistive technologies must not just be developed for people with disabilities. The development process must also include them. Next steps should include working with JMU campus partners (such as The Office of Disability Services) to understand any needs they have already collected in this space and to gauge their interest in co- designing and in helping recruit co-designers with mobility impairments.

Implementing More Routing Functionality

Turn-By-Turn Routing Interface

One clear place for improvement of this application is to provide a more familiar

turn-by-turn routing interface, such as the ones provided by Google Maps and Apple

Maps. While Mapbox does provide turn-by-turn navigation functionality, the format of

the routes provided by GraphHopper was not compatible with Mapbox. In the future,

route responses could be reformatted to match Mapbox’s expected format. In addition,

having the ability to reroute and dynamically update the instructions would greatly

improve this app.

More Route Customization Options

As has been discussed throughout this paper, specifically in the CampusPartner

use case section, I think it would improve the functionality of this application greatly to

support additional customization options for the user and to actually take them into

account when generating routes. Currently, the profile has places to indicate whether or

not you want to avoid unpaved roads and specifying the maximum elevation change at

any time. The primary reasons why these are not currently taken into account is that (1)

GraphHopper’s routing algorithm doesn’t support these at the moment and (2) those

options would require a lot more data annotation of JMU’s campus and elsewhere in

OpenStreetMap.

Integration of Existing Services

Another potential place for future work is in integrating existing services such as AXS

Map or Wheelmap.org. Both of these applications provide valuable information about the wheelchair accessibility of buildings and facilitate users’ additions and updates of this information. Currently, CampusPartner only provides routes from the specified source point to the specified destination point. I think it would be a valuable addition if when the map view is displayed to the user, it also shows the egress points of buildings and their accessibility information.

Crowdsourcing Data

The last point of future work I would to discuss is the potential for CampusPartner to be used as a form of anonymous, crowd-sourced data. CampusPartner could report in a dashboard- like format, the most used route for people with mobility impairments, the number of people

using the app, and other similar metrics. The kind of data could be of interest to the Office of

Disability Services and other organizations at JMU.

Conclusion

Although the ADA has made great strides to make sure that people with disabilities are not unfairly discriminated against, in many cases, the accessible entrances are hard to find, obstacles are not clearly labelled or marked, and historic buildings may be lacking in accessibility. Commonly used mapping applications do not provide the information and support needed by people with mobility impairments. The need for way-finding applications that can support these is great. An application such as CampusPartner can alleviate some of the stress of visiting an unfamiliar place and not knowing whether you could reach your destination.

Appendix

The website I created for this project, which includes a video demonstration of the application, as well as a link to the repository where the code is stored is at the following link: https://czastudil.github.io/campuspartner.html.

Bibliography

1. Cynthia L. Bennett, Erin Brady, and Stacy M. Branham. 2018. Interdependence as a Frame for Assistive Technology Research and Design. Proceedings of the 20th International ACM SIGACCESS Conference on Computers and Accessibility, Association for Computing Machinery, 161–173.

2. N. Bolten, S. Mukherjee, V. Sipeeva, A. Tanweer, and A. Caspi. 2017. A pedestrian-centered data approach for equitable access to urban infrastructure environments. IBM Journal of Research and Development 61, 6: 10:1-10:12.

3. Meredith Browder. 2019. JMU campus inclusivity video project. Retrieved April 23, 2020 from https://commons.lib.jmu.edu/honors201019/653/.

4. Taylor Campbell and Jamie Wescott. 2019. NCES Disability Data. Retrieved April 23, 2020 from https://nces.ed.gov/pubs2019/2019467.pdf#page=131&zoom=auto,-50,11.

5. João Guerreiro, Dragan Ahmetovic, Kris M. Kitani, and Chieko Asakawa. 2017. Virtual Navigation for Blind People: Building Sequential Representations of the Real-World. Proceedings of the 19th International ACM SIGACCESS Conference on Computers and Accessibility, Association for Computing Machinery, 280–289.

6. Karen Nakamura. 2019. My Algorithms Have Determined You’re Not Human: AI-ML, Reverse Turing-Tests, and the Disability Experience. The 21st International ACM SIGACCESS Conference on Computers and Accessibility, Association for Computing Machinery, 1–2. http://disability.jp/talks/assets2019/Nakamura-Assets2019.pdf

7. Manaswi Saha, Michael Saugstad, Hanuma Teja Maddali, et al. 2019. Project Sidewalk: A Web-based Crowdsourcing Tool for Collecting Sidewalk Accessibility Data At Scale. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, Association for Computing Machinery, 1–14.

8. Thorsten Völkel and Gerhard Weber. 2007. A New Approach for Pedestrian Navigation for Mobility Impaired Users Based on Multimodal Annotation of Geographical Data. Universal Access in Human-Computer Interaction. Ambient Interaction, Springer, 575–584.

9. Thorsten Völkel and Gerhard Weber. 2008. RouteCheckr: personalized multicriteria routing for mobility impaired pedestrians. Proceedings of the 10th international ACM SIGACCESS conference on Computers and accessibility, Association for Computing Machinery, 185– 192.

10. Rayoung Yang, Sangmi Park, Sonali R. Mishra, et al. 2011. Supporting spatial awareness and independent wayfinding for pedestrians with visual impairments. The proceedings of the 13th international ACM SIGACCESS conference on Computers and accessibility, Association for Computing Machinery, 27–34.

11. Yuhang Zhao, Elizabeth Kupferstein, Doron Tal, and Shiri Azenkot. 2018. “It Looks Beautiful but Scary”: How Low Vision People Navigate Stairs and Other Surface Level Changes. Proceedings of the 20th International ACM SIGACCESS Conference on Computers and Accessibility, Association for Computing Machinery, 307–320.

12. The NCES Fast Facts Tool provides quick answers to many education questions (National Center for Education Statistics). Fast Facts: Students with disabilities. Retrieved April 23, 2020 from https://nces.ed.gov/fastfacts/display.asp?id=60.

13. Top U.S. mapping apps by users 2018. Statista. Retrieved April 23, 2020 from https://www.statista.com/statistics/865413/most-popular-us-mapping-apps-ranked-by- audience/.

14. AXS MAP. When I Walk. Retrieved April 23, 2020 from https://www.wheniwalk.com/axs- map.

15. Wheelmap. Wheelmap. Retrieved April 23, 2020 from https://wheelmap.org.

16. OpenStreetMap. OpenStreetMap. Retrieved April 23, 2020 from https://www.openstreetmap.org/.

17. Openrouteservice. Retrieved April 23, 2020 from https://openrouteservice.org/.

18. OpenStreetMap Wiki. Retrieved April 28, 2020 from https://wiki.openstreetmap.org/wiki/Main_Page.

19. Mapbox. Retrieved April 28, 2020 from https://www.mapbox.com/.