StepSafe

Inspiration

We wanted to build an application that supports people with sensory issues or people who would like to know if their route to the class is blocked today. The application shows hazards on walking routes within campus that people care about such as uneven surfaces, missing curb ramp, potholes, etc and the app cautions the user through sound and vibration if there is such a hazard ahead. Similarly, it also tells the user when to turn through vibration and sound.

What it does

StepSafe is a mobile-friendly web app for walking around the UMD campus. It shows a map of community-reported sidewalk barriers like blocked sidewalks, potholes, uneven surfaces, and missing curb ramps. Each marker shows its category and age, and is labeled unverified. Anyone can add a report by picking a category, confirming the spot on the map, and adding an optional note. The app also offers prepared walking routes. Along a given route, the phone gives distinct vibration cues for left, right, and caution, each with a text and sound alternative, and a caution cue when the walker nears a reported barrier.

How we built it

A React + Vite frontend with Leaflet and OpenStreetMap showing the hazard map, the report form, and the route guidance. A Node/Express backend in TypeScript that stores reports in SQLite, validates every request with Zod, and serves prepared UMD walking routes traced from OpenStreetMap footpaths. We use an OpenAPI contract between the frontend and the backend. The phone provides location through the Geolocation API and the turn and caution cues through the Vibration API, with sound and text alternatives.

Challenges we ran into

Mismatched APIs: the frontend and backend disagreed about the route data, which blanked the page until we fixed it. Map bugs: map clicks were ignored because of a stale callback. Phone limits: vibration isn't supported on iPhones

Accomplishments that we're proud of

We're proud that we were able to build a solution that helps people who are deaf, hard of hearing, blind or have a low-vision walk through the campus and that other users can report a hazard and help each other as a community.

What we learned

On the technical side we learned how to incorporate sensory outputs such as sound and vibration through phone and we learned how important it is to plan the app right from the idea to the API design to external APIs and databases and how it should look to the users.

What's next for StepSafe

Verify prepared routes on foot and replace sample reports with real observations. A moderation or expiry workflow for old reports. Accessible route preferences (for example avoiding stairs or missing curb ramps) if reliable data is available. Offline map and report caching for the campus. Bring back Sensor Lab as a clearly labelled experiment with consented, labelled data and human review, never automatic reports. Usability feedback from people with relevant lived experience, without presenting the prototype as a validated accessibility tool.