mapit

Getting started/ Test and Deploy

Make sure you have better-sqlite3 installed:

npm install better-sqlite3

Make sure you have pnpm installed with correct permissions:

sudo npm install -g pnpm
rm -rf node_modules
rm -rf .next
rm -rf pnpm-lock.yaml
pnpm install
sudo chown -R $(whoami) .

Run locally:

pnpm dev

Other development notes

  • This website relies on a public Google Sheets as a makeshift database. It’s hosted on Ceci’s spam Google Drive account (ravioliyumyum@gmail.com), and has a corresponding sheetdb.io account linked to this Google account to setup the API connection

Abstract

Describe the general need (including who the user is, what activity they are doing, what environment they are in, what their goal/need is):

Original Version

  • There are many mobile apps providing accessibility resources for people with disabilities. One such type of app is access map. Some of them have demonstrated some success in helping people using wheelchairs navigate through the city. For instance, Sociability and accessibility features in Google Maps provide photos of places and access resource locations on the map. However, there are still some challenges remaining. One of the challenges is the information about access resources on those apps. Some information is outdated and wrong. Furthermore, users who contribute to an app (either with accessibility resources to be added to a location, or for larger-scale app design changes) are not always met with a timely response.
  • The users we are aiming for are people who need accessibility resource information around UW campus. They could use our platform whenever they use mapping resources in their everyday lives. The goal is that users are able to see if these places are accessible for them to navigate around before they have to physically go to the location.

Plain Language Version

What Problem Are We Working On?

  • Access maps help disabled people find accessibility resources. Some access maps succeeded in helping wheel-chair users navigate the city. For example, Sociability and Google Maps show resource locations on a map. Sometimes, they also include photos of places. However, some challenges with those applications include:   - Wrong or outdated data     - Example: a user adds a new accessibility resource to a location   - Slow updates when users give feedback     - Example: a user provides feedback about a new feature they want on the app

Who Is Our Audience?

  • The target users for our app are anyone in the UW community who needs accessibility resource information. For example, users could be students, faculties, or visitors. Our goal is for users to have accessibility information before arriving at a place.

What First Person Account are you drawing from?

  • Our first person account (described in more depth below) focuses on how Google Maps falls short in providing up-to-date, accurate accessibility information. As such, we want our project to prioritize up-to-date accessibility information. We’ll accomplish this goal by crowdsourcing data with instant propagation of changes (ignore parallel issues for now), adding timestamps to accessibility information and displaying warnings when something hasn’t been updated recently.
  • Link to First Person Account by TikToker msfridayology

What are you proposing to do

  • We propose an access map system by taking a crowdsourcing approach and featuring immediate feedback. Specifically, the map we are creating allows any users (hopefully well-intentioned ones) to input the access resources they found on UW campus and add it to the building resources accordingly. To ensure the correctness of the data and prevent outdated information, there will be time constraints putting on resources each individual user upload. When going over the time constraint, the access resources will be given warnings and other users have permissions to update with the latest information.

Project Details

Motivation

  • Building a system to find accessibilility resources on campus

Disability Model Analysis

Disability Justice Principle 1

Please state and define your first DJ Principle:

  • Leadership of those most impacted means that disabled people are involved in (and leaders in) the systems that will and do affect them. In the context of designing systems, it means that disabled people are involved in every step of the process: ideation, design, implementation, testing, and iteration.

Reflect on how your technology relates to this principle:

  • Our accessibility map relates to leadership of the most impacted because in building a project for this class, we must consider our positionality with respect to the end users of our project. We are designing a system that is meant for use by disabled people with many disabilities that we don’t have (such as wheelchair accessible resources, etc.). In this way, it’s important that we recognize as a group our shortcomings in meeting this principle. We don’t have as much leadership of the most impacted in the ideation, design, implementation, testing, and iteration of this map as would be ideal.
  • On the other hand, there are some ways that our project positively meets this principle. Our map is designed for crowd sourcing data. Instead of being a map with predefined accessibility data, our project is to build a system where others can input data. Hopefully, this will mean that disabled users or people who personally want some feature that has helped them to be available on the map will be the main contributors to the map’s data. This is, indeed, an instance of leadership of the most impacted.
  • However, it’s also important to note that with crowdsourced data, it puts the onus of building onto those most impacted. For example, a disabled user who inputs an accessibility resource they wish had been on the map has to have gone through the experience of not having this map to help them in order to put their data on the map. This should also be acknowledged in this project, and in an ideal world, there would be some compensation for this time and energy (but we don’t have the resources for this in our class).

Disability Justice Principle 2

Please state and define your second DJ Principle:

  • Interdependence means that as we work towards collective liberation, we depend on each other to meet our needs instead of governments (who have historically failed at meeting the needs of disabled people). In the context of designing systems, this means designing systems that help community-based need-meeting and don’t overly rely on governmental systems. (Curious to hear more about this one though, because a lot of systems can grow to impact and benefit more people with more funding, and funding can come from the government…)

Reflect on how your technology relates to this principle:

  • Our accessibility map relates to interdependence because it is a system for sharing crowd-sourced data. This clearly supports interdependence because it is a system that allows disabled people to support others with a similar need by sharing their experience and what they’ve found around campus in terms of accessibility resources. However, as mentioned above, this does require disabled people (or map users in general) to take on the onus of finding accessibility resources and taking the time to enter the data into the map (and the data-enterer will not have had the map when they needed to find the resource).
  • However, our project also has some tension with the principle of interdependence because it is being produced from a class at a public university and it is a map of a public university. This inherently involves the state and the government, which is frowned upon in this DJ principle.

Provide further reflection that addresses the following questions:

  1. Is the technology ableist? Explain why it is or is not.
  2. Is the technology informed by disabled perspectives? Explain the relationship to disabled perspectives.
  3. Does the technology oversimplify disability/identity? Explain how it does or does not.
  • We would like to think that our map is trying to fight ableism in mapping by being more inclusive of types of accessibility resources, honest time-marked data, and centering user-based data collection. However our technology may still be ableist in the spots where we prioritize some accessibility resources over others (how easy they are to access or categorization on the legend) or in how accessible our website is to use as a navigator and/or data inputter.
  • Our map is not informed by as many disabled perspectives as we’d wish in terms of the project’s design and implementation. However, our focus on user-inputted data is aimed at centering disabled perspectives in the data displayed on the map.
  • Our project likely oversimplifies identity or disability in that our user interface may not be accessible to all users (due to time limitations as well as our own lack of knowledge of ways that might be more accessible). Further, the legend of the map will have categories of accessibility resources that can be checked or unchecked, and these categories certainly will not encompass every person’s needs equally.

Background Research

Seattle Accessible Route Planner

What research paper, newspaper article blog post, website, or app relevant to your goal did you review?

  • Link to Seattle Accessible Route Planner
  • Seattle Accessible Route Planner is a website that provides a map of Seattle through the lens of accessibility. It overlaps information about accessibility such as accessible pedestrian signals, curb ramp conditions, ADA parking, elevators, sidewalk conditions, public transportations stops, street slopes, etc. onto a map of the city. This information is intended to help users navigate the city in a more informed fashion. The website says that the data displayed is “the most current data”, but doesn’t specify what this means.
  • This website is relevant to our project idea because it is the same general idea of an accessibility map. However, it is different in a few key ways. In particular, this app doesn’t provide all of the same accessibility resources that we would provide in our tool; it excludes things that we plan to include like public restrooms, benches, accessible entrances and menstrual products, and it includes some things like street slope data that we didn’t think of. Further, the website doesn’t include timestamps on when data was last updated, and focuses on all of Seattle (but actually doesn’t have the UW campus well-mapped) whereas we will focus mainly on UW.
  • By trying out this website, I learned that having a good legend for our map is a consideration in building it because a map is most useful when it is more readable. Finally, I learned that we could also consider including a rating of accessibility features in our project rather than a binary presence or absence of a resource.

Sociability (Claudia’s Review)

  • The app that I chose to review is an app called ‘Sociability’. Essentially, Sociability is a navigation app that is focused on helping disabled people find accessible cafes, restaurants and social spaces. They observe things like entrances, seatings, lighting and even noise. How the app works is a group of people would gather for a mapping day, where they go around and take pictures of spaces, and then log in onto the location on the map. The app is relevant to our project idea because the goal of our app is also to crowdsource users to input any accessibility information on the spaces that they visit. However, their app is based in the UK and so most of their data collection is being done in the UK. When trying the app, Seattle does have a few locations on the map when you first look. But when actually clicking on the location, there isn’t actually any information on accessibility on the space. What should show up as pictures of the place, are actually empty with the writing “Want to know about this venue’s accessibility?”. So by trying this app firsthand, I see that this app isn’t really global yet, and is only accessible to users in the UK. I think that if this app were to be more popular worldwide, it would actually be a great app to increase accessibility for people who are disabled.

Sociability (Yi’s Review)

  • This is a blog about the sociability app review, an accessibility app that helps disabled people find accessible cafés, bars, restaurants and social spaces. Sociability assesses different locations in various aspects including entrances & exits, toilet facilities…etc.  The author reviewed some pros and cons for sociability. Some pros include that this app has attractive and easy-to-use UI, with QR code integration and integrated map can give you an idea of places that you hadn’t considered. The cons are the map is glitchy and it requires consistent internet access.
  • This is relevant for our project idea, in terms of giving us more insights about what the existing applications are out there and what some potential flaws are regarding accessibility, so that we can get a better understanding of what needs to be addressed.  
  • What I learned about this app is that it is UK-based, meaning that there are way less information to utilize outside UK. Venues on Sociability has pictures of entrances from different angle, as well as toilets and indoors. Another I noticed is that there is a last updated time for each venue to contribute users’ judgements about this information. Finally, I noticed that there is no way for users to provide feedback to specific venues about their access resources.

Storyboard and Timeline (linked in doc below)

Validation/ Accessibility Assessment

For each of the following, state what your project’s level of compliance is, which should be one of:

  1. Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
  2. Partially Supports: Some functionality of the product does not meet the criterion (explain which)
  3. Does Not Support: The majority of product functionality does not meet the criterion (explain which)

Success Criterion 4.1.2 - Name, Role, Value

  • Supports (as far as we can tell, using VoiceOver on Mac and going to form controls has all of the form controls listed. However, we may have missed some things since we aren’t frequent screen reader users)

Success criterion 2.4.3 - Focus Order

  • Supports (we were able to navigate the website with a screen reader, but we also may have missed things)

Success criterion 1.4.10 - Reflow

  • Does not support (magnification under 200% cuts off some elements and doesn’t even enable scrolling horizontally.)

Success criterion 1.4.4 - Resize Text

  • Does not support (magnification under 200% cuts off some elements, as mentioned above)

Success criterion 1.4.11 - Non textual contrast

  • Supports (we checked the contrast between icons and their backgrounds using the WAVE accessibility checker)

Success criterion 1.3.1 - Info and Relationships

  • Partially supports (We marked it as partial because the website is missing some header levels, but still follows some good practices for Info and Relationships such as most of the headers being correct and having headers at all)

How to comply with success criterion 1.1.1 - Non-text Content

  • Does not support: WARNING: our website’s image upload feature does not support ALT text currently. Image upload is optional, but when used, it’s completely inaccessibile to ALT text users.

How to comply with success criterion 1.3.4 - Orientation

  • Not relevant: we made a post on Ed about this, but our website is intended for laptop use only for now.

How to comply with success criterion 4.1.3 - Status messages

  • Does not support (we don’t use aria-live-regions, so passing status messages to assistive technologies won’t be supported)

Success criterion 1.4.3 - Contrast (Minimum)

  • Partial (satisfies minimum contrast but not enhanced): see UAR ID: GROUP-WAVE-03

What other validation did you do? What did you find worked or did not work?

Tasks (assuming that the website interface is accessible for any user to use)

  1. Add a resource: add the existence of a microwave in the HUB, and add a picture
    • Adding the microwave works
    • Adding an image works when the image is viewed on the same device that added the photo, but not on another device because the image’s local path is saved in the spreadsheet
  2. Finding a location that satisfies multiple criteria: find a building with an accessible entrance with menstrual products
    • Assuming that our website is already populated with data, (for testing we inputted test data that shows Allen Library having both an accessible entrance and menstrual products), we were able to use the website’s search functionality to find out that the building satisfies both criteria
    • It’s important to note that the search functionality is an OR rather an AND, so buildings will show up that have any of the checked criteria. To find a building satisfying multiple criteria, look that there are icons highlighted in blue for all criteria you want to meet

Other Limitations

We also thought about certain limitations that our website still has:

  • There isn’t navigation to the actual location of a resource within the building
  • Photos: interface for entering a photo doesn’t allow for inputting a link to a photo that’s already publicly hosted… and generally, users will have to hold the responsibility of hosting their photo publicly
  • As mentioned on our UARs, there are some accessibility issues with the website’s interface

Learnings and Future Work

What Did We Learn From This Project?

  • How to utilize AI coding agents to prototype and create efficiently
  • How to focus in on the core purpose of a project
  • How to scope a project
  • How to use and troubleshoot with Git

Future Work For This Project

  • Going forward, we hope that many aspects of our website could be iterated on and improved. We’ll split these into a couple categories: accessibility of our website, website design changes, and data collection and platform adoption.

Website/ Interface Accessibility

  • First, in auditing our website, we found many parts of the interface that were inaccessible. If we had more time on this project, we’d like to fix these issues. Some examples of this include restructuring the website so that elements resize correctly under 200% magnification, having correct headers in the DOM and not skipping header levels, and having higher color contrast across the site to satisfy the WCAG AAA (Enhanced Color Contrast). We’d also like to do a more robust walkthrough of the website with a screen reader and with other ATs.

Website Design Changes

  • Second, our platform’s design could be improved upon in many ways. We built only a prototype of our idea in this project because we had to scope it for four weeks, but if we had more time, we would add many more features to the platform. Our original idea for this project was a map, but this project turned into more of a searchable list for accessibility resources. However, it could be cool to explore the idea of a map more fully.  We are interested in having an interactive map with accessibility resources that users can click on. Or, since we probably couldn’t implement a mapping app better than Google Maps (or another existing mapping platform), we could pitch our idea of adding an accessibility resources search function to an existing platform. Integrating maps into our platform could include both outdoor mapping (to get to a building) and/or indoor mapping (to navigate to a resource within a building).
  • Alternatively, we’re interested in exploring the idea of including “distance to a resource” as one of the search criteria. This would involve being able to calculate the distance between the user and all buildings that match their search criteria. This was a goal that we didn’t get to in this project.
  • Another improvement for our platform would be to refine the filtering/ search process for finding accessibility resources. We’d be interested to poll potential users as a way to decide on which filter categories to include. There’s a balance between comprehensiveness and usability. On the one hand, we want to include categories that someone might find helpful, but on the other hand, having too many categories makes the site too crowded. Perhaps there’d be a way for a user to pre-define the categories they want when they sign up for the app so that there could be more options for a wide array of users without any individual user’s experience being overcrowded.
  • Additionally, we’d like to refine the process of our site’s warnings for possibly outdated data. Currently, we have a warning that shows up for possibly outdated data after a set amount of time. Ideally, we’d have this warning show up after different amounts of time depending on the volatility of the resource.
  • We’d also like to iterate on the process of how users can interact with existing data. For example, if there’s a warning for potentially outdated data, a user should be able to confirm or deny the existence of that resource to reset the data’s last updated time and get rid of the warning. Or, if a user has additional information to add about an accessibility resource that’s already been logged, they should be able to edit the same resource entry. Or, if a user (maliciously or accidentally) inputs false data, there should be a process for reporting and correcting information by other users and/or the platform’s managers.
  • Two other improvements we’d like to make involve technical improvements to the site. First, the ability to upload pictures should be fixed. Currently, when a user uploads a photo, the local path of that photo is saved, so the photo can only be viewed from the same device as it was uploaded. We’d like to correct this process by storing the photo itself with the accessibility resource data. Additionally, we’d like to figure out the process of having users include ALT-text when they upload a photo. Second, we’d also like to improve upon the way that we store data. For this project, we used Google Sheets as a makeshift database. This is both insecure (because it’s a public document that anyone with the link could mess with) and likely not the best practice for storing data. Ideally, we’d use an actual database with proper security and permissions setup.

Data Collection and Platform Adoption

  • Third, we’d like to spend time on data collection and platform adoption. Our website relies on crowdsourced data, so the more users the site has, the more useful the platform becomes. We’d like to spend time promoting the site and encouraging users to input data and use the site. This would make the platform more helpful to other users and more accurate in terms of what data and experiences with accessibility resources are recorded.