GoGo (Accessibility App)

Web app: 3D rendering of morgridge hall
Web app: 3D rendering of navigation
Mobile app: Homepage display
Mobile app: voice assistant for navigation
Mobile app: Locations available on campus

Inspiration

As a team of teaching assistants, we noticed that some students with disabilities faced difficulties reaching the classroom and sometimes arrived late. Getting to the building was only part of the journey. Finding a usable entrance, locating an elevator, and navigating unfamiliar hallways could take additional time.

That experience sparked our interest in building GoGo. A knee injury made the problem personal, too. An ordinary staircase suddenly meant finding another way around. It reinforced something we were already seeing on campus that people need directions that account for how they can actually move through a space. We chose Morgridge Hall for our demo to ground the idea in a real campus building. But the need extends to hospitals, airports, malls, and anywhere people must navigate an unfamiliar interior.

Indoor navigation presents a technical challenge as well. GPS alone cannot reliably guide someone between rooms and floors, and a route must account for entrances, elevators, and changing obstacles. We created GoGo to help people navigate all the way to their destination, with accessibility built into the route from the start. We also wanted to make navigation usable without relying on a screen. For people who are blind or have low vision, and people who find touch interfaces difficult to use, entering locations and following a visual map can introduce additional barriers. That motivated us to build a voice agent that lets users describe their journey aloud and receive spoken guidance.

Everyone deserves a way in. GoGo helps you find yours.

What it does

GoGo is a disability specific navigation app for users after they enter a building. Users can enter their starting point and destination through the interface or simply speak to GoGo’s Agentic voice agent.

Its core features include:

Agentic AI voice navigation: Tell GoGo where you are and where you want to go. Its voice agent clarifies unclear requests, looks up rooms, checks routes against your access needs, and starts navigation. When conditions change, it replans the route and guides you aloud, supporting people who are blind, have low vision, or find touch controls difficult to use.
Personalized accessible routes: GoGo considers the user’s access needs when selecting a route, including whether they need to avoid stairs.
Door-to-room guidance: Navigation connects the outdoor approach to a usable entrance, the appropriate path between floors, and the destination room.
Spoken directions:The voice agent communicates navigation instructions aloud, helping users follow the journey without repeatedly checking a screen.
Obstacle reporting and rerouting: Reports of blocked paths help GoGo update route choices as building conditions change.

For example, a user can say, “I’m at the entrance to Morgridge Hall. Take me to Room 6618.” The voice agent uses the spoken starting point and destination to initiate navigation, while the routing system considers the user’s access preferences. Voice interaction and accessible routing work together as users need both a way to communicate with the app and a route they can physically use.

The business need extends to the organizations managing these spaces. Insurance companies, universities, hospitals, airports, and malls need ways to communicate usable routes and keep accessibility information current.

Innovation

GoGo brings conversational interaction, sensor information, computer vision, and accessibility-aware routing into one navigation workflow. The technical challenge is making those components work together meaningfully. Detecting a barrier matters when it can be associated with a location and change a route. Detecting a floor transition matters when it helps place the user within the building. Voice interaction matters when it lets someone complete the navigation task.

Our prototype focuses on Morgridge Hall so we can demonstrate this approach in a real campus setting.

How we built it

We organized GoGo around an accessibility graph: a connected representation of entrances, corridors, ramps, stairs, elevators, and rooms. Route selection uses information about these connections to account for the user’s access needs.

Our architecture combines:

JavaScript for the mobile interface, including access preferences, destination selection, and navigation.
Agentic voice agent connects speech recognition, request interpretation, and spoken responses so users can provide their starting point and destination aloud and interact through voice commands.
LangGraph for coordinating the steps involved in interpreting a request, checking route information, and explaining directions.
YOLO-based computer vision for identifying candidate features and obstacles, such as stairs, doors, and barriers, in images.
Phone barometer readings as a signal for detecting changes in elevation and supporting floor awareness.
The accessibility graph as the common data structure connecting navigation, building features, and obstacle reports.

The graph is central to the design. Recognizing a staircase in an image is useful only when that information can be connected to a location and influence the route. Our prototype currently focuses on buildings in UW-Madison only so we can demonstrate the journey concretely before expanding coverage.

Challenges we ran into

Understanding location indoors : A position on a map does not tell us which floor someone is on or which corridor they can reach. We had to think about horizontal position, elevation, and the building’s layout together. Sensor readings also introduce uncertainty that navigation needs to handle.
Defining what makes a route usable: The shortest route is not always appropriate. A staircase, doorway, or unavailable elevator can change whether someone can complete a journey. This made route selection a problem of satisfying access requirements as well as minimizing distance.
Handling changing conditions: A route can become unusable after it has been mapped. Obstacle reports raise questions about location, reliability, and how long a report should remain active. Keeping route information current is an ongoing part of the product.

Accomplishments that we're proud of

We’re proud of taking a familiar frustration and turning it into a concrete engineering problem: how can navigation continue through a building while respecting the needs of the person using it?

We brought mobile development, computer vision, sensor information, and route planning into one prototype. More importantly, we made accessibility part of the route-selection process from the beginning. We’re also proud of thinking beyond an individual app screen. Useful navigation depends on the people who maintain buildings and the people who use them. Our approach creates room for community reports.

The project gave us a focused starting point for a much broader goal of helping fellow badgers reach unfamiliar places with greater independence and less uncertainty.

What we learned

We learned that accessibility depends on the entire journey of the disabled person. An accessible entrance is only useful if someone can find it and continue from there to their destination. We also learned that indoor navigation depends as much on reliable information as on algorithms. A sophisticated route planner cannot compensate for missing connections or an elevator status that is no longer accurate.

Another lesson was the importance of designing with people who have different access needs. Our own experience helped us recognize the problem, but it cannot represent every user. On the business side, we learned to distinguish between the person using navigation and the organization that could pay to maintain it.

Our mentors also helped us reflect on the project:

Christopher Mende: Helped us translate a personal experience into a viable product, recognize the broader need for indoor navigation, and explore potential customers and monetization strategies.
Frank Hansen: Helped us refine the idea and identify indoor navigation as a promising focus for differentiating GoGo and making it more useful.
Shivansh Gupta: Suggested adding an agentic AI component to GoGo and guided us so our voice interface could take action.
Ethan Feiges: Suggested the voice feature for the GoGo app and how we could add an agentic AI component to it.

Business model

We propose offering insurers and health plans an annual subscription based on the number of members covered. Plans could offer GoGo as an accessibility benefit, helping members navigate unfamiliar buildings through personalized routes and voice guidance.

Our business hypothesis is that better navigation could help members reach appointments with less difficulty, support greater independence, and reduce avoidable requests for assistance. We would explore whether routing around known barriers could also reduce exposure to fall hazards. These are outcomes we would test through pilots before claiming healthcare savings.

Our proposed revenue model combines a per-member annual fee with implementation fees for mapping and integrations. Over time, we could offer participating organizations tools to identify recurring access barriers using aggregated data, with member privacy built into the design.

Universities remain an important starting point for testing and a complementary customer segment. A campus subscription could support student navigation and facilities updates while helping us develop a repeatable deployment process.

The broader opportunity is to connect the organizations supporting people’s care with the buildings those people need to navigate. We would begin with a focused pilot, demonstrate measurable value, and expand across participating healthcare networks and other public spaces.

Future Scope

GoGo starts at Morgridge Hall, with plans to expand across UW-Madison, then to Big Ten campuses, hospitals, and airports. Our goal is to help more people with disabilities navigate unfamiliar buildings independently.

Next, we plan to add verified obstacle reports, live elevator and door status, more precise indoor positioning, and routes that support a wider range of accessibility needs. We’ll clearly flag incomplete or unverified route information so users can make informed decisions before setting out. We also want to explore emergency assistance with facilities teams and safety professionals. Any emergency navigation features would require validated building procedures and dedicated testing before use.

To support this growth, we’ll explore campus subscriptions and health-plan partnerships while keeping GoGo free for individuals. Long term, we aim to let universities, hospitals, airports, malls, and insurers integrate GoGo’s accessibility information and routing into their own apps.

Our goal is simple: help people find a route they can actually use, without disability being a barrier for them.